Hi， Yes. Most equipments do not support early session and forking now. If they want to avoid media clip, they should at least spport one, I believe. Comparing the two methods, forking costs more resources, as most of the equipments should find out when forking happens,record all dialogs if forking happens, also should find out which the early dialog is and which the session dialog is in order to supply services. REGARDS, ERIC 原信息主题： RE: early-session & p-early-media /////Re: PRACK: Does non-200 response cease re-transmission ofreliable 18x?发件人： "Rockson Li (zhengyli)" <zhengyli@xxxxxxxxx>日期： 2009/04/06 13:07 Eirc, IMHO, many implementations do NOT support early-session,In theory multiple early dialogs must be supported by UAC,so we can use one early dialog for early-media and another one for finalmedia.It looks like a forking or logical forking. But in real world, many device does not support forking or it can only support forking in terms of signaling,not forking toestablish multiple media sessions. Regards,-Rockson ________________________________ From: sipping-bounces@xxxxxxxx [mailto:sipping-bounces@xxxxxxxx] OnBehalf Of wang.libo@xxxxxxxxxxxxxx: Monday, April 06, 2009 11:05 AMTo: Paul Kyzivat (pkyzivat)Cc: sipping-bounces@xxxxxxxx; eric.wangxr@xxxxxxxxx; sipping@xxxxxxxx;Brett TateSubject: early-session & p-early-media /////Re: PRACK: Doesnon-200 response cease re-transmission ofreliable 18x? Hi, We introduce early-session to our system as it can solve media clip. There are two ways to avoid media clip, early-session and forkingp-early-media. To support them both need all equipments (except proxies) update, the problems you mentioned exist in both methods. Do you mean, forking early media is better than early-session? Regards, Eric From the beginning I found the early-session technique "interesting".The problem I have with it is believing that people will attempt to implement it, and if they do, that they will implement it correctly. Given the amount of trouble that people seem to have implementing the full o/a mechanism correctly, who likely is it that they will get it right when trying to simultaneously manage two independent o/a negotiations, most likely with the o/a role swapped between them, and all multiplexed over the same invite. Its possible, but I'd like to hear about it being tested at sipit. Thanks, Paul wang.libo@xxxxxxxxxx wrote:> > Hi,> > Brett Tate has listed some.> Also:> o. Services can be supplied with fewer messages.It helps lighten the> servers stress.> o. You can recognize the session for the tone easily.> o. It's useful for services such as CF(call forward),in which casethere> may be several early diologs.> > Regards,> Eric> > > > > > > Do you find some advantage to it over simply using early media> > > with a different to-tag?> >> > It allows the early media session and answered media session to be> > negotiated prior to INVITE 2xx. The main benefit is to reduce> > clipping upon INVITE 2xx if forking has occurred and all UAS> > actually support early-session.> >> > More specifically, UAS may assume only answered media will be sent> > to the port for answer; thus it could quickly start rendering> > answered media prior to receiving INVITE 2xx. UAC can allocate> > other ports for early media; or it can refuse or hold early media> > without it subsequently delaying answered media (by requiring> > another offer/answer exchange).> >> > Works good in theory if all user-agents support it. I have no idea> > how well it works in the real world. :)> >> > _______________________________________________> > Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping> > This list is for NEW development of the application of SIP> > Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip> > Use sip@xxxxxxxx for new developments of core SIP> > --------------------------------------------------------> ZTE Information Security Notice: The information contained in thismail is solely property of the sender's organization. This mailcommunication is confidential. Recipients named above are obligated tomaintain secrecy and are not permitted to disclose the contents of thiscommunication to others.> This email and any files transmitted with it are confidential andintended solely for the use of the individual or entity to whom they areaddressed. If you have received this email in error please notify theoriginator of the message. Any views expressed in this message are thoseof the individual sender.> This message has been scanned for viruses and Spam by ZTE Anti-Spamsystem.> > >------------------------------------------------------------------------> > _______________________________________________> Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping> This list is for NEW development of the application of SIP> Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip> Use sip@xxxxxxxx for new developments of core SIP --------------------------------------------------------ZTE Information Security Notice: The information contained in this mailis solely property of the sender's organization. This mail communicationis confidential. Recipients named above are obligated to maintainsecrecy and are not permitted to disclose the contents of thiscommunication to others.This email and any files transmitted with it are confidential andintended solely for the use of the individual or entity to whom they areaddressed. If you have received this email in error please notify theoriginator of the message. Any views expressed in this message are thoseof the individual sender.This message has been scanned for viruses and Spam by ZTE Anti-Spamsystem. _______________________________________________Sipping mailing list https://www.ietf.org/mailman/listinfo/sippingThis list is for NEW development of the application of SIPUse sip-implementors@xxxxxxxxxxxxxxx for questions on current sipUse sip@xxxxxxxx for new developments of core SIP
