Re: 回复： RE: early-session & p-ear ly-media /////Re: PRACK: Doesnon-200 re sponse 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" <[email protected]>
> 日期： 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: [email protected] 
> [mailto:[email protected]] On Behalf Of [email protected]
> 	Sent: Monday, April 06, 2009 11:05 AM
> 	To: Paul Kyzivat (pkyzivat)
> 	Cc: [email protected]; [email protected]; 
> [email protected]; 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
> 	
> 	[email protected] 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 [email protected] for questions 
> on current sip
> 	>  > Use [email protected] 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 [email protected] for questions on 
> current sip
> 	> Use [email protected] 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 [email protected] for questions on current sip
Use [email protected] for new developments of core SIP