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? I meant that 199 can be used for other things. Regards, Christer > 原信息> 主题： 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 for> final 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 to> establish 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 to terminate that early dialog. The UAC can then > "switch" to the other dialog.> > This of course requires support of 199 in the UAC, but I > think it's easier to implement that (it is useful also for > other things) than early-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: [Sipping] 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 media clip. > There are two ways to avoid media clip, early-session > and forking 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 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 case there> > 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 this mail is solely property of the sender's > organization. This mail communication is confidential. > Recipients named above are obligated to maintain secrecy and > are not permitted to disclose the contents of this > communication to others.> > This email and any files transmitted with it are > confidential and intended solely for the use of the > individual or entity to whom they are addressed. If you have > received this email in error please notify the originator of > the message. Any views expressed in this message are those of > the individual sender.> > This message has been scanned for viruses and Spam by > ZTE Anti-Spam system.> > > > > >> --------------------------------------------------------------> ----------> > > > _______________________________________________> > 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 mail is solely property of the sender's > organization. This mail communication is confidential. > Recipients named above are obligated to maintain secrecy and > are not permitted to disclose the contents of this > communication to others.> This email and any files transmitted with it are > confidential and intended solely for the use of the > individual or entity to whom they are addressed. If you have > received this email in error please notify the originator of > the message. Any views expressed in this message are those of > the individual sender.> This message has been scanned for viruses and Spam by > ZTE Anti-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
