Subject: [Sipping] 回复： RE: early-session & p-early-media /////Re: PRACK: Doesnon-200 response cease re-transmission ofreliable 18x?

From: [email-masked]
Date: Mon, 6 Apr 2009 15:45:32 +0800

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: [Sipping] early-session & p-early-media /////Re: PRACK: Doesnon-200 response cease re-transmission ofreliable 18x?
发件人： "Christer Holmberg" <[email-masked]>
日期： 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-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
	Sent: Monday, April 06, 2009 11:05 AM
	To: Paul Kyzivat (pkyzivat)
	Cc: [email-masked]; [email-masked];
[email-masked]; 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-masked] 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-masked] for questions on
current sip
	>  > Use [email-masked] 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-masked] for questions on current
sip
	> Use [email-masked] 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.

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 6 Apr 2009 09:56:35 +0200

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 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?
> >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 can only 
> >support forking in terms of signaling,not forking to
> 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-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> 	 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 problem I have with it is believing that people 
> will attempt to 
> 	implement it, and if they do, that they will implement 
> it correctly.
> 	
> 	full o/a mechanism correctly, who likely is it that 
> they will get it 
> 	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 
> 	>  o. Services can be supplied with fewer messages.It 
> helps lighten the
> 	> servers stress.
> 	>  o. It's useful for services such as CF(call 
> forward),in which case there
> 	>  > > 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
> 	>  > 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
> 	>  > Works good in theory if all user-agents support 
> it.  I have no idea
> 	>  > Use [email-masked] for questions 
> on current 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.
> 	> 
> 	> 
> 	>
> 	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.
> 	
> 
> 
>