[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sipping] 回复： RE: early-session & p-early-media /////Re: PRACK: Doesnon-200 response cease re-transmission ofreliable 18x?
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: [Sipping] early-session & p-early-media /////Re:
> PRACK: Doesnon-200 response cease re-transmission ofreliable 18x?
> 发件人： "Christer Holmberg" <christer.holmberg at ericsson.com>
> 日期： 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 at ietf.org
> [mailto:sipping-bounces at ietf.org] On Behalf Of wang.libo at zte.com.cn
> Sent: Monday, April 06, 2009 11:05 AM
> To: Paul Kyzivat (pkyzivat)
> Cc: sipping-bounces at ietf.org; eric.wangxr at gmail.com;
> sipping at ietf.org; 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 at zte.com.cn 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 at cs.columbia.edu for questions
> on current sip
> > > Use sip at ietf.org 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 at cs.columbia.edu for questions on
> current sip
> > Use sip at ietf.org 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.
>
>
>
>