hi，To early session, there is only one dialog, where new early session SDP comes, old one is replaced according to rfc3264.You donot need to terminate early dialog by 199 or something else.I think early session and forking early media both have some disadvantages.Can you list "the other things" you mentioned to make forking early media easier than early session? Regards,Eric 原信息主题： RE: early-session & p-early-media /////Re: PRACK: Doesnon-200 response cease re-transmission ofreliable 18x?发件人： "Christer Holmberg" <christer.holmberg@xxxxxxxxxxxx>日期： 2009/04/06 13:41 Hi, >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 forfinal media.>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. You have an excellent tool which can help you with that: 199 :) When you are done with your early-media, you send 199 in order toterminate that early dialog. The UAC can then "switch" to the otherdialog. This of course requires support of 199 in the UAC, but I think it'seasier to implement that (it is useful also for other things) thanearly-session. Regards, Christer ________________________________ From: sipping-bounces@xxxxxxxx [mailto:sipping-bounces@xxxxxxxx]On Behalf Of wang.libo@xxxxxxxxxx Sent: Monday, April 06, 2009 11:05 AM To: Paul Kyzivat (pkyzivat) Cc: sipping-bounces@xxxxxxxx; eric.wangxr@xxxxxxxxx;sipping@xxxxxxxx; Brett Tate Subject: early-session & p-early-media /////Re: PRACK:Does non-200 response cease re-transmission ofreliable 18x? Hi, We introduce early-session to our system as it can solve mediaclip. There are two ways to avoid media clip, early-session andforking p-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 attemptto implement it, and if they do, that they will implement itcorrectly. Given the amount of trouble that people seem to haveimplementing the full o/a mechanism correctly, who likely is it that they willget it right when trying to simultaneously manage two independent o/a negotiations, most likely with the o/a role swapped betweenthem, and all multiplexed over the same invite. Its possible, but I'd liketo 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 helpslighten 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 whichcase there > may be several early diologs. > > Regards, > Eric > > > > > > > Do you find some advantage to it over simply using earlymedia > > > with a different to-tag? > > > > It allows the early media session and answered mediasession to be > > negotiated prior to INVITE 2xx. The main benefit is toreduce > > clipping upon INVITE 2xx if forking has occurred and allUAS > > actually support early-session. > > > > More specifically, UAS may assume only answered media willbe sent > > to the port for answer; thus it could quickly startrendering > > answered media prior to receiving INVITE 2xx. UAC canallocate > > other ports for early media; or it can refuse or hold earlymedia > > without it subsequently delaying answered media (byrequiring > > another offer/answer exchange). > > > > Works good in theory if all user-agents support it. I haveno idea > > how well it works in the real world. :) > > > > _______________________________________________ > > Sipping mailing listhttps://www.ietf.org/mailman/listinfo/sipping > > This list is for NEW development of the application of SIP > > Use sip-implementors@xxxxxxxxxxxxxxx for questions oncurrent sip > > Use sip@xxxxxxxx for new developments of core SIP > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained inthis mail 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 confidentialand intended solely for the use of the individual or entity to whom theyare addressed. If you have received this email in error please notifythe originator of the message. Any views expressed in this message arethose of the individual sender. > This message has been scanned for viruses and Spam by ZTEAnti-Spam system. > > >------------------------------------------------------------------------ > > _______________________________________________ > Sipping mailing listhttps://www.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use sip-implementors@xxxxxxxxxxxxxxx for questions on currentsip > Use sip@xxxxxxxx for new developments of core SIP -------------------------------------------------------- ZTE Information Security Notice: The information contained inthis mail 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 confidentialand intended solely for the use of the individual or entity to whom theyare addressed. If you have received this email in error please notifythe originator of the message. Any views expressed in this message arethose of the individual sender. This message has been scanned for viruses and Spam by ZTEAnti-Spam system. _______________________________________________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
