Subject: Re: [Sipping] 答复: RE: PRACK: Does non-200 response cease re-transmission ofreliable 18x?

From: Paul Kyzivat <[email-masked]>
Date: Thu, 02 Apr 2009 21:34:24 -0400

[email-masked] wrote:
> 
> Hi,
> 
>  >
>  > >>>Is the flows below valid according to recent arguments?
>  > >>>
>  > >>>   UAC                  UAS
>  > >>>    |----invite(SDP)--->|
>  > >>>    |<--- 183(SDP)------|
>  > >>>    |-----prack(SDP)--->|
>  > >>>    |<--- 200(SDP)------|
>  > >>>
>  > >>>       flow 1
>  > >>>  
>  > >>Assuming the 200 is the PRACK response, yes.
>  > >>>  
>  > >>>   UAC                  UAS
>  > >>>    |----invite-------->|
>  > >>>    |<--- 183-----------|
>  > >>>    |-----prack(SDP)--->|
>  > >>>    |<--- 200(SDP)------|
>  > >>>  
>  > >>>       flow 2
>  > >>>  
>  > >>Not valid. If the INVITE does not contain SDP, a reliable answer must
>  > >>contain SDP. We are currently discussing whether the FIRST reliable
>  > >>response must contain SDP, or whether that rule can be related. But,
>  > >>that is a separate thread.
>  > >
>  > >Hmm. That flow is a consequence of changing that rule that I had not
>  > previously considered.
>  > >
>  > >Allowing flow 2 would cause all sorts of trouble. If the restriction on
>  > offer in first reliable provisional is to be
>  > >relaxed it must be sure to state that the first offer must then be in
>  > *some* reliable provisional, and until that is sent
>  > >there can be no offer sent another way (PRACK or UPDATE).
>  > >
>  > >Just opening that question is enough to make me more concerned about
>  > relaxing the constraint.
>  >
>  > I am not proposing to allow flow 2, and I don't think relaxing the rule
>  > would allow it either. The rule would say that if the INVITE does not
>  > contain an SDP offer the SDP offer must be carried in a reliable
>  > response. The PRACK can only contain an SDP offer if the UAC has receied
>  > an SDP answer.
> 
> Does it means,the first flow is allowed?

Yes.

> I think, the restriction the first reliable response must contain SDP if 
> the INVITE without SDP
> should restrict the called user.

That's the way it is now.

> It seems there is a exception about H.323, but i know nothing about the 
> case at this moment, does

There is currently no such exception. There is some discussion underway 
regarding possibly making one. H.323 behavior is one justification.

> the unreliable response or delaying to send the first reliable response 
> solve the H.323 case?

delaying does.

	Paul

> Regards,
> Eric
> 
> 
> --------------------------------------------------------
> 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: [email-masked]
Date: Fri, 3 Apr 2009 10:24:53 +0800

Hi，

> That's the way it is now.

Sure, I means, the first reliable response from the called user must 
contain 
NORMAL SESSION SDP in order to communication,but AS(application server) 
shouldn't be restricted by this rule as AS may only concern about 
early-session 
for pronunciation. Or, the AS is also restricted if early-session plays 
the same
role as normal session.

Regards,
Eric

> > 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.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 03 Apr 2009 09:31:20 -0400

> for pronunciation. Or, the AS is also restricted if early-session plays 

The AS is an artifact of IMS, it has no role in any of the ietf
standards. It has been expected that components playing various roles
such as this are bound by normal distinctions between UAC, UAS, Proxy, etc.

IMO it isn't a good idea to introduce a new kind of UA (or proxy) that
is bound by different rules.

You might consider the "early-session" mechanism specified by RFC 3959.
But I have never heard of it being implemented, so it may not be useful
to you.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 3 Apr 2009 15:52:59 +0200

Hi Paul, 

I've changed the subject, because I don't think this is related to the
re-transmission of 18x. It is a little related to the discussion about
relaxing the must-insert-SDP-in-first-reliable-18x, but let's still have
a separate thread for it.

> >  > > I think, the restriction the first reliable response 
> must contain 
> > SDP if  > > the INVITE without SDP  > > should restrict the called 
> > user.
> >  >
>>Sure, I means, the first reliable response from the called 
>>user must contain NORMAL SESSION SDP in order to communication,but 
>>AS(application server) shouldn't be restricted by this rule 
>>as AS may only concern about early-session for pronunciation. Or, the 
>>AS is also restricted if early-session plays the same role as normal
session.
> 
>The AS is an artifact of IMS, it has no role in any of the 
>ietf standards. It has been expected that components playing 
>various roles such as this are bound by normal distinctions 
>between UAC, UAS, Proxy, etc.
> 
>IMO it isn't a good idea to introduce a new kind of UA (or 
>proxy) that is bound by different rules.

I don't think a new role is proposed. The AS was just an example, but
from a SIP perspective it is of course behaving as a UAS in this case :)

to you.

I have been assuming that we ARE talking about the 3959 mechanism, and
the question has been whether an "early-session" SDP offer fullfills the
MUST rule to include SDP offer in the first reliable response.

IF we decide to relax the rule I guess it doesn't really matter, but if
we maintain the rule I guess it is a valid question.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 03 Apr 2009 10:39:04 -0400

Comment at end

> we maintain the rule I guess it is a valid question.

Frankly I don't expect to see 3959 ever used. But if it is...

IMO the "early-session" and the "session" must each independently comply 
with the o/a rules. So if you take any call flow using early-session, 
and transform it in either of the following ways, the transformed flow 
should still be valid according to the normal rules for o/a using "session":

1) remove all the body parts with content-disposition of "early-session" 
and content-type "application/sdp". Then if that results in 
multipart/mixed body parts containing only an application/sdp body part 
with c-d of session, remove the multipart, leaving just the sdp in its 
place. Then remove any Supported/Required references to early-session.

2) remove all the body parts with content-disposition of "session" and 
content-type "application/sdp". Then if that results in multipart/mixed 
body parts containing only an application/sdp body part with c-d of 
early-session, remove the multipart, leaving just the sdp in its place. 
Then replace occurrences of C-D:early-session with C-D:session. Then 
remove any Supported/Required references to early-session.

In theory, the above would allow the UAC to initiate both, but in 
practice that would make no sense.

If what I say is correct, then it relaxes no restrictions on anybody.

I don't understand why anybody would bother with early-session. For the 
cases where it might be useful I think the same effect can be 
accomplished easier by simply establishing an early dialog with one 
to-tag, and a different early/final dialog with a different to-tag.

	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 3 Apr 2009 23:52:21 +0200

Hi,

>>>But I have never heard of it being implemented, so it may not be 
>>>useful to you.
>> 

>>the question has been whether an "early-session" SDP offer fullfills 
>>the MUST rule to include SDP offer in the first reliable response.
>> 
>>IF we decide to relax the rule I guess it doesn't really matter, but 
>>if we maintain the rule I guess it is a valid question.
>

In IMS it is an alernative solution to providing some services. It is
optional to support, though.

>IMO the "early-session" and the "session" must each independently
comply with the o/a rules. So if you take any call flow 
>using early-session, and transform it in either of the following ways,
the transformed flow should still be valid 
>according to the normal rules for o/a using "session":
>
multipart/mixed body parts containing only an application/sdp 
>body part with c-d of session, remove the multipart, leaving just the
sdp in its place. Then remove any 
>Supported/Required references to early-session.
>
content-type "application/sdp". Then if that 
>results in multipart/mixed body parts containing only an
application/sdp body part with c-d of early-session, remove the 
>multipart, leaving just the sdp in its place. 
remove any Supported/Required references to early-
>If what I say is correct, then it relaxes no restrictions on anybody.

I am not sure I understand what you tried to explain :)

But, based on your arguments: according to the current rules, if the
first reliable SDP contains an early-session SDP offer, is it also
required to contain a session SDP offer? Or, I the early-session SDP
offer enough?

>I don't understand why anybody would bother with early-session. For the
cases where it might be useful I think the same 
>effect can be accomplished easier by simply establishing an early
dialog with one to-tag, and a different early/final 
>dialog with a different to-tag.

Why weren't you in 3GPP when I was arguing exactly the same thing... ;)

Regards,

Christer

---

From: [email-masked]
Date: Sat, 4 Apr 2009 10:58:49 +0800

Hi，

> >  > > I think, the restriction the first reliable response must contain 

> > SDP if

I think we don't need to introduce a new kind of (UA).
And obeying the existed rules, AS can work well at almost all the 
use-cases.
As UA and AS both exist in a basic call,we just need to make few 
modifications if needed.

> But I have never heard of it being implemented, so it may not be useful

Yes.
Early-session has already been implemented in own system. And I think it 
do
have some advantage, as both early-session and session can be carried by a 
message,
also,early-session solves media clip.
(P-early-media with different TO-tag is another way.)

Regards
Eric

---

From: [email-masked]
Date: Sat, 4 Apr 2009 11:29:43 +0800

Hi,

> >> But I have never heard of it being implemented, so it may not be 
useful
> > the question has been whether an "early-session" SDP offer fullfills 
the
> > IF we decide to relax the rule I guess it doesn't really matter, but 
if

> place. Then remove any Supported/Required references to early-session.t
> 

If I catch you, you mean, if early-session and session exist in the same
signal,how to place the content-type/content-disposition.You can place 
content-type/content-disposition with just the SDP,and place 
"Content-Type: multipart/mixed" at the front.

e.g:

Content-Type: multipart/mixed;boundary=---boundary-boundary---

---boundary-boundary---
Content-Type: application/SDP
Content-Disposition: session
v=0
o=
s=session SDP
c=

---boundary-boundary---
Content-Type: application/SDP
Content-Disposition: early-session
v=0
c=

---boundary-boundary---

> practice that would make no sense.

In the initial INVITE,the UAC needn't initiate the early-session.
But if UAC want to alert the CALLED-UA (e.g UAC want to play some
special music for CALLED-UA), UAC can initiate the early-sesion.

> to-tag, and a different early/final dialog with a different to-tag.

Yes. 
Early-session plays the same role as the fork early dialog, but if 199 
is not implemented, and the call is forwarded, there may exist several
fork early dialogs, which one the UAC shold choose is problem.

IMO, the two methods both have advantages!

Regards,
Eric

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 04 Apr 2009 16:34:04 -0400

[email-masked] wrote:

> Yes.
> Early-session has already been implemented in own system. And I think it do
> have some advantage, as both early-session and session can be carried by 
> a message,

I guess I'll have to stop saying I don't expect to see early-session
implemented by anyone. :-)

Do you find some advantage to it over simply using early media with a
different to-tag?

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 04 Apr 2009 16:39:29 -0400

> Content-Disposition: early-session

Yes. For instance an invite might include a session offer.
Then a reliable 180 could contain both an answer to the received offer, 
and an early-session offer.

Whether there is a use case where that makes sense remains to be seen.

	Paul

---

From: Brett Tate <[email-masked]>
Date: Sat, 4 Apr 2009 14:11:22 -0700

> 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. :)

---

From: Brett Tate <[email-masked]>
Date: Sat, 4 Apr 2009 14:18:23 -0700

Sorry about the resend... needed to change a UAS to UAC.

> -----Original Message-----
> From: Brett Tate
> Sent: Saturday, April 04, 2009 5:11 PM
> To: 'Paul Kyzivat'; [email-masked]
> Subject: RE: [Sipping] PRACK: Does non-200 response cease re-transmission
> ofreliable 18x?
> 

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, UAC 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. :)

---

From: "Christer Holmberg" <[email-masked]>
Date: Sat, 4 Apr 2009 23:20:03 +0200

Hi, 

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).

My main issue with it has been that it also may require all SDP aware
intermediates to support it, if they need to open media gates, or do
some other actions based on/triggered by the SDP. 

I haven't studied the possible impacts on ICE, but I guess it should
work - it may extend the required ICE procedures, though.

Anyway, I we want to discuss early-session verus forking I think we
should do that in a separate thread. I guess we could start our annual
how-to-solve-early-media discussion ;)

Regards,

Christer

---

From: [email-masked]
Date: Sun, 5 Apr 2009 23:57:10 +0800

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

> 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 
> another offer/answer exchange).
> 
> _______________________________________________
> 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

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 05 Apr 2009 20:31:02 -0400

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:
> ------------------------------------------------------------------------
>

---

From: [email-masked]
Date: Mon, 6 Apr 2009 11:04:41 +0800

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

                 Thanks,
                 Paul

[email-masked] wrote:
> 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.

---

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

Hi,

[Paul] Whether there is a use case where that makes sense remains to be 
seen.

If AS(application server) want to play a (coloring) ring back to the 
caller,
or it want to play some tones to notice the caller that the call is 
forward, or 
the call is waiting, etc, AS could insert an early-session offer in the 
180.

Regards
Eric

>  > IMO the "early-session" and the "session" must each independently 
comply

                 Paul

---

From: "Rockson Li (zhengyli)" <[email-masked]>
Date: Mon, 6 Apr 2009 13:05:37 +0800

Eirc,
 
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.
 
Regards,
-Rockson

________________________________

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, 

Regards, 
Eric 

                Thanks,
                Paul

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.

--------------------------------------------------------
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 07:41:29 +0200

Hi, 

>so we can use one early dialog for early-media and another one for
final media.

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. 

	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:
	>  > 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
	> 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.
	> Sipping mailing list
https://www.ietf.org/mailman/listinfo/sipping

	--------------------------------------------------------
	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: Paul Kyzivat <[email-masked]>
Date: Mon, 06 Apr 2009 08:14:15 -0400

> Do you mean, forking early media is better than early-session?

I don't mean it is *better*. But it is (arguably) *easier*, and at least 
requires less special implementation.

	Thanks,
	Paul