Subject: [Sipping] draft-holmberg-sipping-199-01

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Mon, 4 Jun 2007 12:00:43 +0200

Hi,

I've submitted a new version of the 199 draft, based on comments I've
received.

You can get it at:

http://users.piuha.net/cholmber/drafts/draft-holmberg-sipping-199-01.txt

I've been informed by the SIP WG chair that, since new response codes
are done in SIP, SIPPING should only look at the requirement.

So, I guess what I am asking SIPPING to do is to determine whether the
requirement is useful.

The draft also gives some use-case examples where a mechanism like this
could be useful.

Regards,

Christer
_______________________________________________
Sipping mailing list  https://www1.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: "Gilad Shaham" <[email-masked]>
Date: Mon, 4 Jun 2007 13:31:36 +0100

Maybe I missed something, but I think that in the example provided the
199 response is not necessary. It seems to me that the only place where
this response is necessary is in case the UAS already sent a provisional
response (other than 100) with a to-tag. If such provisional responses
were not forwarded, the UAC will not be aware of the forked request and
therefore cannot do anything useful with the 199 response.

So the way I see it is a follows:

   UAC               P1                  UAS_2    UAS_3    UAS_4
 
    --- INVITE ------>
                      --- INVITE (leg 2) ->
                      --- INVITE (leg 3) ---------->
                      --- INVITE (leg 4) ------------------->
                      <-- 180 (leg 3) --------------           <== with
to-tag
    <-- 180 (leg 3) --                                         <== with
to-tag
                      <-- 4xx (leg 2) -----
                      (P1 does not generate 199 for leg 2)
                      <-- 4xx (leg 3) --------------
    <-- 199 (leg 3) --
                      <-- 200 (leg 4) -----------------------
    <-- 200 (leg 4) --
    --- ACK (leg 4) ->
                      --- ACK (leg 4) ---------------------->

Maybe you should make it mandatory: if no non-100 provisional responses
with to-tag were received, the proxy MUST NOT generate a 199 response.

It also means that to-tag in 199 response should be mandatory.

I think that contact header is also required for early dialog, so
consider this as part of the condition as well.

________________________________

From: Christer Holmberg (JO/LMF) [mailto:[email-masked]]

Sent: Monday, June 04, 2007 1:01 PM
To: sipping
Subject: [Sipping] draft-holmberg-sipping-199-01

Hi, 

You can get it at: 

http://users.piuha.net/cholmber/drafts/draft-holmberg-sipping-199-01.txt
<http://users.piuha.net/cholmber/drafts/draft-holmberg-sipping-199-01.tx
t>  

Regards, 

Christer

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Mon, 4 Jun 2007 14:39:46 +0200

Hi Gilad,
 
In the example I did assume that the early dialogs had been created (i.e. non-100 responses have been sent), but I agree it can't be seen in the picture, so that will have to be fixed.
 
I am not sure whether we need to talk about the Contact header, though. I think it's enough to say "if an early dialog has been established". The rules for establishing early dialogs shall be described elsewhere, because they are not specific to 199.
 
Thanks for you comments!
 
Regards,
 
Christer

	From: Gilad Shaham [mailto:[email-masked]] 
	Sent: 4. kesäkuuta 2007 15:32
	To: Christer Holmberg (JO/LMF)
	Cc: sipping
	Subject: RE: [Sipping] draft-holmberg-sipping-199-01

	Maybe I missed something, but I think that in the example provided the 199 response is not necessary. It seems to me that the only place where this response is necessary is in case the UAS already sent a provisional response (other than 100) with a to-tag. If such provisional responses were not forwarded, the UAC will not be aware of the forked request and therefore cannot do anything useful with the 199 response.

	   UAC               P1                  UAS_2    UAS_3    UAS_4
	 
	    --- INVITE ------>
	                      --- INVITE (leg 2) ->
	                      --- INVITE (leg 3) ---------->
	                      --- INVITE (leg 4) ------------------->
	                      <-- 180 (leg 3) --------------           <== with to-tag
	    <-- 180 (leg 3) --                                         <== with to-tag
	                      <-- 4xx (leg 2) -----
	                      (P1 does not generate 199 for leg 2)
	                      <-- 4xx (leg 3) --------------
	    <-- 199 (leg 3) --
	                      <-- 200 (leg 4) -----------------------
	    <-- 200 (leg 4) --
	    --- ACK (leg 4) ->
	                      --- ACK (leg 4) ---------------------->

	Maybe you should make it mandatory: if no non-100 provisional responses with to-tag were received, the proxy MUST NOT generate a 199 response.

	I think that contact header is also required for early dialog, so consider this as part of the condition as well.

	

	 

	Hi, 

	I've submitted a new version of the 199 draft, based on comments I've received. 

	You can get it at: 

	http://users.piuha.net/cholmber/drafts/draft-holmberg-sipping-199-01.txt <http://users.piuha.net/cholmber/drafts/draft-holmberg-sipping-199-01.txt>  

	I've been informed by the SIP WG chair that, since new response codes are done in SIP, SIPPING should only look at the requirement.

	So, I guess what I am asking SIPPING to do is to determine whether the requirement is useful. 

	The draft also gives some use-case examples where a mechanism like this could be useful. 

	Regards, 

	Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 04 Jun 2007 10:09:51 -0400

I've been having some side conversations with Christer on this. I've 
been generally supportive of this - the goal seems worthwhile to me - 
though I've been poking at some of the details.

But I've just come to realize one potential issue that may be 
significant. Its something that IMO does not have a clear answer, so I'd 
like to get some other opinions on it:

Is a proxy allowed to generate an in-dialog response on behalf of a UAS 
that established that dialog? To clarify, I mean a response to a request 
using the to-tag of the UAS.

I can't think of any language in 3261 or extensions that explicitly 
forbids this, but I don't think it is in spirit of proxy behavior. (I 
put it in the same category as a "proxy" that sends a BYE within a 
dialog - we don't consider that valid behavior for a proxy. Rather that 
is B2BUA behavior.) I think it is important that the signaling be 
honest, rather than lie.

If a proxy is not permitted to originate a response within an existing 
dialog, then this draft doesn't work, since the UAC is expected to use 
the dialog it is received on to know which dialog has been terminated.

This could be fixed if the proxy sent the 199 without a to-tag, and 
identified the target dialog in some other way - for instance by 
inserting a Target-Dialog header. However before we could do that we 
would have to extend the definition of the Target-Dialog header to 
permit it in responses.

	Paul

Christer Holmberg (JO/LMF) wrote:
> _http://users.piuha.net/cholmber/drafts/draft-holmberg-sipping-199-01.txt_
> 
> ------------------------------------------------------------------------
>

---

From: Robert Sparks <[email-masked]>
Date: Mon, 4 Jun 2007 09:36:37 -0500

Not sure I understand the question. If I do, then a 407 to a mid- 
dialog request is the existence proof you need.

RjS

On Jun 4, 2007, at 9:09 AM, Paul Kyzivat wrote:

> I've been having some side conversations with Christer on this.  
> I've been generally supportive of this - the goal seems worthwhile  
> to me - though I've been poking at some of the details.
>
> significant. Its something that IMO does not have a clear answer,  
> so I'd like to get some other opinions on it:
>
> Is a proxy allowed to generate an in-dialog response on behalf of a  
> UAS that established that dialog? To clarify, I mean a response to  
> a request using the to-tag of the UAS.
>
> forbids this, but I don't think it is in spirit of proxy behavior.  
> (I put it in the same category as a "proxy" that sends a BYE within  
> a dialog - we don't consider that valid behavior for a proxy.  
> Rather that is B2BUA behavior.) I think it is important that the  
> signaling be honest, rather than lie.
>
> If a proxy is not permitted to originate a response within an  
> existing dialog, then this draft doesn't work, since the UAC is  
> expected to use the dialog it is received on to know which dialog  
> has been terminated.
>
> inserting a Target-Dialog header. However before we could do that  
> we would have to extend the definition of the Target-Dialog header  
> to permit it in responses.
>
> 	Paul
>
>> I've been informed by the SIP WG chair that, since new response  
>> codes are done in SIP, SIPPING should only look at the requirement.

---

From: "Gilad Shaham" <[email-masked]>
Date: Mon, 4 Jun 2007 16:09:40 +0100

I think it's true, so it would be preferred to refrain from (and maybe
not allowed) generating mid-dialog responses.

If you place this information in a new header, 199 is not required. The
proxy could simply send it in a 100 response, just like it generates any
other 100 response (the response would not have the to-tag anyway since
we don't want to generate mid-dialog responses).

I think that if the proxy will reuse the target-dialog header, it
implicitly means that the proxy would still need to "understand" the
meaning of dialog.
Another option is to go forward with the same core idea. Create a new
header, for example "proxy-fork-error", and just like target-dialog it
would contain the call-id, from-tag and to-tag of the error response.

I still think it would have been best if the proxy would only send the
response if there had been any provisional response with this to-tag,
but maybe this too requires the proxy to become dialog aware.

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Monday, June 04, 2007 5:10 PM
To: Christer Holmberg (JO/LMF)
Cc: sipping
Subject: Re: [Sipping] draft-holmberg-sipping-199-01: ok for proxy to
genin-dialog responses???

	Paul

> I've submitted a new version of the 199 draft, based on comments I've 
_http://users.piuha.net/cholmber/drafts/draft-holmberg-sipping-199-01.tx
t_

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 04 Jun 2007 12:35:56 -0400

Robert Sparks wrote:
> Not sure I understand the question. If I do, then a 407 to a mid-dialog 
> request is the existence proof you need.

Hmm. Interesting case.

It seems different in some critical ways:

- because it is a 407, its clear that it isn't from the UAS.

- this is a response to an in-dialog request. The *request*
   had both the to- and from- tags, and they are simply being
   replayed in the response.

I guess the 199 will also be clearly from a proxy, not a UAS, so in that 
way they are similar.

In the proposed 199, the proxy will in effect be taking a 4xx response 
that it has received in-dialog (with both tags), and converting it to a 
199. Viewed that way it isn't so bad.

I'm still interested in what others think, but I'm beginning to be 
convinced that this particular case isn't so bad.

	Paul

>> significant. Its something that IMO does not have a clear answer, so 
>> I'd like to get some other opinions on it:
>>
>> UAS that established that dialog? To clarify, I mean a response to a 
>> request using the to-tag of the UAS.
>>
>> dialog - we don't consider that valid behavior for a proxy. Rather 
>> that is B2BUA behavior.) I think it is important that the signaling be 
>> honest, rather than lie.
>>

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Mon, 4 Jun 2007 22:23:06 +0200

Hi Paul, 

>I've been having some side conversations with Christer on 
>this. I've been generally supportive of this - the goal seems 
>worthwhile to me - though I've been poking at some of the details.
> 
>significant. Its something that IMO does not have a clear 
>answer, so I'd like to get some other opinions on it:
> 
>Is a proxy allowed to generate an in-dialog response on 
>behalf of a UAS that established that dialog? To clarify, I 
>mean a response to a request using the to-tag of the UAS.
> 
>I can't think of any language in 3261 or extensions that 
>explicitly forbids this, but I don't think it is in spirit of 
>proxy behavior. (I put it in the same category as a "proxy" 
>that sends a BYE within a dialog - we don't consider that 
>valid behavior for a proxy. Rather that is B2BUA behavior.) I 
>think it is important that the signaling be honest, rather than lie.

Well, since the 199 HAS been triggered by something coming from the UAS,
one could say it IS "honest".

And, a proxy is allowed to create and send CANCEL...

But, it's a interesting question, which we should discuss.

>existing dialog, then this draft doesn't work, since the UAC 
>is expected to use the dialog it is received on to know which 
>dialog has been terminated.

Correct.

>This could be fixed if the proxy sent the 199 without a 
>to-tag, and identified the target dialog in some other way - 
>for instance by inserting a Target-Dialog header. However 
>before we could do that we would have to extend the 
>definition of the Target-Dialog header to permit it in responses.

That would be one option, yes.

The problem without using a To-tag, however, is that you won't be able
to PRACK the 199 (Paul has also raised an issue regarding the PRACK,
which we need to discuss in another thread). So, one alternative would
be that the proxy creates a NEW To-tag, and uses the Target-Dialog
header (or some other information element).

Regards,

Christer

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Mon, 4 Jun 2007 22:27:51 +0200

Hi Gilad,

Using an existing response code, and defining a new header, is another alternative.

I am not sure 100 Trying would work, though, because it's only hop-to-hop, and may not reach the UAC.

Regards,

Christer

> Sent: 4. kesäkuuta 2007 18:10
> To: Paul Kyzivat; Christer Holmberg (JO/LMF)
> Cc: sipping
> Subject: RE: [Sipping] draft-holmberg-sipping-199-01: ok for 
> proxy togenin-dialog responses???
> 
> I think it's true, so it would be preferred to refrain from 
> (and maybe not allowed) generating mid-dialog responses.
> 
> If you place this information in a new header, 199 is not 
> required. The proxy could simply send it in a 100 response, 
> just like it generates any other 100 response (the response 
> would not have the to-tag anyway since we don't want to 
> generate mid-dialog responses).
> 
> I think that if the proxy will reuse the target-dialog 
> header, it implicitly means that the proxy would still need 
> to "understand" the meaning of dialog.
> Another option is to go forward with the same core idea. 
> Create a new header, for example "proxy-fork-error", and just 
> like target-dialog it would contain the call-id, from-tag and 
> to-tag of the error response.
> 
> I still think it would have been best if the proxy would only 
> send the response if there had been any provisional response 
> with this to-tag, but maybe this too requires the proxy to 
> become dialog aware.
> 
> 
> Subject: Re: [Sipping] draft-holmberg-sipping-199-01: ok for 
> proxy to genin-dialog responses???
> 
> answer, so I'd
> mean a response to a request
> 
> > 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
> 
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
> 
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: "Gilad Shaham" <[email-masked]>
Date: Tue, 5 Jun 2007 09:49:50 +0100

> Sent: Monday, June 04, 2007 11:23 PM
> To: Paul Kyzivat
> Cc: sipping
> Subject: RE: [Sipping] draft-holmberg-sipping-199-01: ok for proxy to

I think that viewing this, as Paul suggested, as the proxy converting
the error response to 199 is a good solution. This solution applies
whether the to-tag is preserved or whether the information is placed in
some header.

> header (or some other information element).

A UAC that does not support this specification might actually allocate a
new early dialog upon receiving the new to-tag, so I suggest refraining
from this option.

Furthermore, as far as I know the only restriction of a to-tag that
involves PRACK is on a proxy. Section 3 in RFC 3262:
   An element that can act as a proxy can also send reliable provisional
   responses.  In this case, it acts as a UAS for purposes of that
   transaction.  However, it MUST NOT attempt to do so for any request
   that contains a tag in the To field.  That is, a proxy cannot
   generate reliable provisional responses to requests sent within the
   context of a dialog.  Of course, unlike a UAS, when the proxy element
   receives a PRACK that does not match any outstanding reliable
   provisional response, the PRACK MUST be proxied.

Is it an option we need - proxy generating PRACK on the 199?

	Gilad

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Tue, 5 Jun 2007 11:32:56 +0200

Hi Gilad, 

>>>put it in the same category as a "proxy"
>>>that sends a BYE within a dialog - we don't consider that valid 
>>>behavior for a proxy. Rather that is B2BUA behavior.) I think it is 
>>>important that the signaling be honest, rather than lie.
>> 
>I think that viewing this, as Paul suggested, as the proxy 
>converting the error response to 199 is a good solution. This 
>solution applies whether the to-tag is preserved or whether 
>the information is placed in some header.

Ok.

>A UAC that does not support this specification might actually 
>allocate a new early dialog upon receiving the new to-tag, so 
>I suggest refraining from this option.

I agree.

>Furthermore, as far as I know the only restriction of a 
>to-tag that involves PRACK is on a proxy. Section 3 in RFC 3262:
>   An element that can act as a proxy can also send reliable 
>   provisional responses.  In this case, it acts as a UAS for purposes
of that
>Is it an option we need - proxy generating PRACK on the 199?

No, I don't think so.

One issue, which Paul has raised, is whether the proxy is allowed to
terminate the PRACK. Because, if the proxy has generated a reliable 199,
and receives a PRACK, there is really no use in forwarding the PRACK
futher on the dialog.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 05 Jun 2007 18:57:04 -0400

IMO the 199 should be sent unreliably, so there will be no PRACK to 
terminate. And I see no need for the proxy to block any subsequent 
requests sent within the dialog. They should simply be forwarded along. 
Then the UAS will presumably send a 481 in response.

The point of the 199 is an optimization. The PRACK complicates things, 
raises questions about propriety of the proxy terminating them, and 
results in two more messages being sent. In general there will be no 
more messages sent in the dialog after the 199. If one is occasionally 
lost the typical result will only be that the UAC will hold state longer.

	Paul

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Wed, 6 Jun 2007 05:57:21 +0200

Hi Paul, 

>IMO the 199 should be sent unreliably, so there will be no 
>PRACK to terminate. And I see no need for the proxy to block 
>any subsequent requests sent within the dialog. They should 
>simply be forwarded along. 

Is there any current text in 3261 regarding the forking proxy behavior
in this case?

>The point of the 199 is an optimization. The PRACK 
>complicates things, raises questions about propriety of the 
>proxy terminating them, and results in two more messages 
>being sent. In general there will be no more messages sent in 
>the dialog after the 199. If one is occasionally lost the 
>typical result will only be that the UAC will hold state longer.

One question then is what happens if the request contains Require:
100rel? Would the proxy then be able to use 199?

Now, Require only applies to UAs, not proxies, but the UAC probably
expects all provisional responses to be sent reliable.

I guess there is no problem if the UAC supports 199 - it would know it
is sent unreliably. But, what would a UAC not supporting 199 do, when it
receives an unreliable 199 (or any other unreliable provisional
response)?

Regards,

Christer

> >>>> to me -
> behalf of a 
> explicitly 
> >>>> (I
> >>> Well, since the 199 HAS been triggered by something 
> coming from the
> > UAS,
> converting 
> >> whether the to-tag is preserved or whether the information 
> is placed 
> >> in some header.
> > 
> > Ok.
> > 
> > 
> to-tag, and 
> >>> The problem without using a To-tag, however, is that you won't be 
> >>> able to PRACK the 199 (Paul has also raised an issue 
> regarding the 
> >>> PRACK, which we need to discuss in another thread). So, one 
> >>> alternative would be that the proxy creates a NEW To-tag, 
> and uses 
> >>> the Target-Dialog header (or some other information element).
> >> allocate a new early dialog upon receiving the new to-tag, so I 
> >> suggest refraining from this option.
> > 
> > I agree.
> > 
> > 
> to-tag that 
> > terminate the PRACK. Because, if the proxy has generated a reliable 
> > 199, and receives a PRACK, there is really no use in forwarding the 
> > PRACK futher on the dialog.
> > 
> > Regards,
> > 
> > Christer
> > 
>

---

From: "Gilad Shaham" <[email-masked]>
Date: Wed, 6 Jun 2007 10:38:21 +0100

I was wrong on my previous statement with the to-tag. A prack cannot be
sent on a response out of dialog and proxies cannot generate reliable
provisional responses on a dialog.

Sounds to me like another reason for leaving the 199 out of dialog. Just
need to hope that UACs will realize that just like 100 this cannot be
PRACKed, even if some proxy decided to add the require 100rel header on
the way.

> Sent: Wednesday, June 06, 2007 6:57 AM
> To: Paul Kyzivat
> Cc: Gilad Shaham; sipping

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Wed, 6 Jun 2007 11:48:55 +0200

Hi, 

>I was wrong on my previous statement with the to-tag. A prack cannot be
sent on a response out of dialog 

Correct (assuming you mean a response without a To tag)

>and proxies cannot generate reliable provisional responses on a dialog.

Well, that is one of the open issues we are discussing. 

The question is not only whether the proxy can generate a reliable
provisional response on a dialog, but also whether it can terminate the
PRACK received for that provisional response.

>Sounds to me like another reason for leaving the 199 out of 
>dialog. Just need to hope that UACs will realize that just 
>like 100 this cannot be PRACKed, even if some proxy decided 
>to add the require 100rel header on the way.

Assuming the 199 shall not be PRACKed, I still think it could be sent
within a dialog. You would simply leave out the additional headers
(RAck, RSeq etc) required to generate the PRACK.

One advantage of using some header to indicate the terminated dialog,
would be that you could use a single 199 to terminate multiple dialogs. 

199 Early Dialog Terminated
To: A 					///with or without To tag
From: B
Term-Dialog: tag-x, tag-y, tag-z

Regards,

Christer

> PRACK to 
> > >The point of the 199 is an optimization. The PRACK complicates 
> > >things, raises questions about propriety of the proxy terminating 
> > >them, and results in two more messages being sent. In 
> general there 
> > >will be no more messages sent in the dialog after the 199. 
> If one is 
> > >occasionally lost the typical result will only be that the 
> UAC will 
> > >hold state longer.
> > 
> > is sent unreliably. But, what would a UAC not supporting 
> 199 do, when
> it

---

From: "Gilad Shaham" <[email-masked]>
Date: Wed, 6 Jun 2007 11:17:47 +0100

Hi Christer,

> Sent: Wednesday, June 06, 2007 12:49 PM
> To: Gilad Shaham; Paul Kyzivat
> Cc: sipping
Yes, that's what I meant
 
> PRACK received for that provisional response.

Isn't it a complication only if we realize 199 can/must have support for
100rel? Sounds to me this is not the case for now.

> (RAck, RSeq etc) required to generate the PRACK.
I'm a bit more wary of this. Not sure how a UAC would behave if it
receives one response with RSeq and the next without one. I think you
gave the same concerns. Not sure this case was ever specified. Outside
the dialog sounds safer to me as it is more specified. Those that will
most likely break are the ones that don't support forked responses, but
they'll probably break in this environment on other cases as well.

> Term-Dialog: tag-x, tag-y, tag-z
Sounds interesting, just need to make sure it doesn't over complicate
implementations.

Cheers,
Gilad

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Wed, 6 Jun 2007 12:30:21 +0200

Hi, 

>>provisional response on a dialog, but also whether it can terminate
>>the PRACK received for that provisional response.
> 
>Isn't it a complication only if we realize 199 can/must have 
>support for 100rel? Sounds to me this is not the case for now.

Yes, it probably would have a rather big impact on proxies supporting
199, because they would also need to support most of the logic for
100rel.

I will add some text regarding this into the next version of the
document.

>>>Sounds to me like another reason for leaving the 199 out of dialog. 
>>>Just need to hope that UACs will realize that just like 100 this 
>>>cannot be PRACKed, even if some proxy decided to add the require 
>>>100rel header on the way.
>> 
>I'm a bit more wary of this. Not sure how a UAC would behave 
>if it receives one response with RSeq and the next without 
>one.

Today that could happen if the UAC indicates Supported: 100rel. Some
provisional responses may be sent reliably, while others are not.

>I think you gave the same concerns. Not sure this case 
>was ever specified. Outside the dialog sounds safer to me as 
>it is more specified. Those that will most likely break are 
>the ones that don't support forked responses, but they'll 
>probably break in this environment on other cases as well.

I guess we'll need to double check the PRACK spec also, to see what/if
it says regarding this.

>Sounds interesting, just need to make sure it doesn't over 
>complicate implementations.

Yes. And, as the example shows, I don't think you would need to include
the whole dialog id in the new header, only the To tag.

Regards,

Christer

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Wed, 20 Jun 2007 20:44:41 +0200

Hi, 

You can get it at: 

http://users.piuha.net/cholmber/drafts/draft-holmberg-sipping-199-02.txt

I've added some text related to the dialog state maintenance of proxies,
and the open issues we've identified (e.g. related to the use with
100rel). I also added some 18x messages to the example flows.

Regards, 

Christer

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 22 Jun 2007 11:40:17 +0100

Christer,

Apologies if this has been discussed already, but isn't it possible to
have multiple 199s on a single early dialog? I am considering the
following statement:

"When a forking proxy receives a non-2xx final response which terminates
one or more early dialogs and the proxy does not intend to forward the
final response immediately (due to the rules for a forking proxy) it
MUST send a 199 provisional response, for each associated early dialog
that it can associate with the final response, upstream towards the
sender of the associated request."

Suppose the request passes through proxy A, which forks and sends one
branch to proxy B, which also forks. One of the destinations forked to
by proxy B sends a 1xx (creating an early dialog) followed by a 4xx, and
proxy B, being unable to pass on the 4xx immediately, sends a 199, which
finds its way back via proxy A to the UAC. Later proxy B sends a 4xx,
and proxy A, being unable to pass on the 4xx immediately, sends a 199. I
guess if proxy A has released resources for that dialog when it passed
on the first 199, then the second 199 should not arise. But the
requirement to release resources is only a MAY.

This seems undesirable, although harmless other than wasting resources.
Should we place a requirement on proxy A to prevent it?

John

> Sent: 20 June 2007 19:45
> Subject: [Sipping] draft-holmberg-sipping-199-02
> 
> 
> Hi, 
>

---

From: Byron Campen <[email-masked]>
Date: Tue, 26 Jun 2007 10:44:00 -0500

Hrm. I don't think I like the idea of proxies being forced to keep  
dialog state. (heck, I would prefer that proxies not be required to  
be dialog-aware at all) This spec would require proxies to keep a set  
of dialog-keys (Call-Id and tags) in the response context, and add  
keys as provisionals come in. Additionally, if we want to avoid a  
storm of 199 if we have several forking proxies that implement this,  
we need to keep state denoting whether these dialogs have sent back a  
199 already. Lastly, if dialogs are formed using a reciprocal request  
(UPDATE) instead of a provisional, the proxy has no way of knowing a  
dialog was ever formed. It seems like this is something that works a  
whole lot better if the UAS is responsible for sending the 199. I am  
tempted to say leave the proxy out of it.

Best regards,
Byron Campen

---

From: [email-masked]
Date: Tue, 26 Jun 2007 19:17:37 -0400

There seem to be a lot more open issues here that first seems.

In summary, this I-D appears to assume that the proxy in question will
maintain considerable state information about early dialogs that it
handles, not just their tags and state, but also their media session.
It's really rather difficult for a stateless proxy to utilize 199 to
get much benefit.  So I'd like to see some initial discussion of
whether this mechanism is really intended only for stateful proxies,
and what the implications are of that.

More detailed questions:

Is there an assumption that a proxy will normally keep track of all
the early dialogs that have been formed "through" it?  Coming from a
pure-proxy background, this seems an unusual sort of behavior.  I
would expect that a proxy only becomes aware of an early dialog being
terminated by the arrival of a failure response from downstream, and
ipso facto it is only aware of the termination of the early dialog
whose to-tag is on the failure response.  If we expect a proxy to be
able to know more than this, we need to have some discussion of the
mechanism for dong so, or at least a fairly explicit discussion that
proxies may limited in their capabilities.

There is a derivative terminology problem -- I would say that a
failure response only *terminates* one early dialog, the one whose
to-tag is on the response.  But if several early dialogs have been
formed by forking a request downstream, receiving a failure response
for one of them implies that the others *have already been terminated*
... but I wouldn't say that the response *terminates* any of the
others, it's just evidence that termination has happened earlier, by
other messages.

I expect that the only significant resources to be freed are
media-processing streams, so in order for 199 to be useful in
practice, we need to have correlation of media with early dialogs as a
requirement.  However, the I-D doesn't give this as a requirement, or
even indicate how it might be accomplished at all (as it seems to be
assumed that a 199 won't contain any SDP that would carry the
address/port identification).

It would help a great deal to discuss various cases that arise in
mixed systems of proxies and UAs that do and do not understand 199.
It seems that there are various complexities when the upstream proxy
supports 199 but the downstream proxy does not -- is the upstream
proxy required to produce 199s for early dialogs whose failure
responses are absorbed by the downstream proxy?  How is this modified
by whether the downstream proxy has produced a 199?  Does the upstream
proxy have to keep a record of the 199s that have passed through it as
well?

Section 7 requires that a proxy that sends a 199 must retain a record
of it, so that if a UAC sends another request on that early dialog,
the proxy can generate a 481 response.  (And this can happen even if
all components support 199.)  But the same effect could be generated
without stateful proxies by having the proxy forward the request
within the dialog -- the UAS will respond with 481.  ... Now
re-reading the section, I see that this proxy behavior is only
required if the proxy is stateful.  But if acceptable results can be
obtained if the proxy passes the request through, why are stateful
proxies required to short-circuit the request?  It would seem
sufficient to say the proxy MAY short-circuit the request (which it
would not be allowed to do under 3261).

In section 9, I see:

   A forking proxy MUST NOT send a 199 Early Dialog Terminated
   provisional response reliably in a situation where a reliable
   provisional response is required to contain an SDP offer/answer
   message body, according to [4].

Is this reference correct?  I think you want reference [3], the PRACK
RFC, not the pure SDP offer/answer RFC.

Also, it would be helpful if the "situation where a relaible
provisional response is required to contain an SDP offer/answer
message body" was described, rather than requiring us to deduce it.

Section 9 also contains:

   A 199 Early Dialog Terminated provisional response MUST NOT contain a
   new SDP offer/answer message body, but the sender of the response MAY
   insert a copy of a previously sent offer/answer message body.

But how could a proxy know what the previous SDP message body was?

And there is an extension of this behavior that should be described --
a UA can pretend that it contains a proxy upstream of itself.  If that
proxy supports 199, then whenever the UA generates a failure response,
the fictitious proxy can also generate a 199 (under a suitably elastic
interpretation of "does not intend to forward the final response
immediately").  This would seem to be a waste of effort, but in a
world where many proxies do not yet support 199, it could be helpful
to UACs.  But that gets back to the question of whether 199 is
intended to help UACs release resources or more to help proxies
release resources.

Dale

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Sat, 30 Jun 2007 16:05:48 +0200

Hi Byron, 

>Hrm. I don't think I like the idea of proxies being 
>forced to keep dialog state. (heck, I would prefer that 
>proxies not be required to be dialog-aware at all) This spec 
>would require proxies to keep a set of dialog-keys (Call-Id 
>and tags) in the response context, and add keys as 
>provisionals come in.

I don't think the latest version of the draft mandates any extra state.
In the most simple use-case, a proxy simply, when it receives a 456xx
with a To tag, maps it to a 199.

>Additionally, if we want to avoid a storm of 199 if we have several
forking proxies that 
>implement this, we need to keep state denoting whether these dialogs
have sent back a
>199 already.

In real life networks I don't believe there will be long "chains" of
forking proxies.

>Lastly, if dialogs are formed using a reciprocal request(UPDATE)
instead of a provisional, the proxy has no way of 
>knowing a dialog was ever formed.

I am not sure forming a dialog that way is allowed.

And, even if it was, the proxy can still simply map the 456xx into a
199.

>It seems like this is something that works a whole lot better if the
UAS is 
>responsible for sending the 199.

We can discuss that, but I think it's a little strange that a UAS should
send two responses (199 + final) when it wants to reject an INVITE. 

Regards,

Christer

> > "When a forking proxy receives a non-2xx final response which 
> > terminates one or more early dialogs and the proxy does not 
> intend to 
> > forward the final response immediately (due to the rules 
> for a forking 
> > proxy) it MUST send a 199 provisional response, for each associated 
> > early dialog that it can associate with the final response, 
> upstream 
> > towards the sender of the associated request."
> >
> > by proxy B sends a 1xx (creating an early dialog) followed 
> by a 4xx, 
> > and proxy B, being unable to pass on the 4xx immediately, 
> sends a 199, 
> > which finds its way back via proxy A to the UAC. Later 
> proxy B sends a 
> > 4xx, and proxy A, being unable to pass on the 4xx 
> immediately, sends a 
> > 199. I guess if proxy A has released resources for that 
> dialog when it 
> > passed on the first 199, then the second 199 should not 
> arise. But the 
> >> I've added some text related to the dialog state maintenance of 
> >> proxies, and the open issues we've identified (e.g. related to the 
> >> use with 100rel). I also added some 18x messages to the example 
> >> flows.
> >>
> >> Regards,
> >>
> >> Christer
> >>
> >>
> >>
> >> Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Sat, 30 Jun 2007 16:10:18 +0200

Hi John,

The main purpose of 199 is to allow the UAC to release resources.

But, of course proxies may also use it to release resources, but they must then be able to handle the use-case you describe.

Regards,

Christer

> From: Elwell, John [mailto:[email-masked]] 
> Sent: 22. kesäkuuta 2007 13:40
> To: Christer Holmberg (JO/LMF); sipping
> Subject: RE: [Sipping] draft-holmberg-sipping-199-02
> 
> Christer,
> 
> Apologies if this has been discussed already, but isn't it 
> possible to have multiple 199s on a single early dialog? I am 
> considering the following statement:
> 
> intend to forward the final response immediately (due to the 
> rules for a forking proxy) it MUST send a 199 provisional 
> response, for each associated early dialog that it can 
> associate with the final response, upstream towards the 
> Suppose the request passes through proxy A, which forks and 
> sends one branch to proxy B, which also forks. One of the 
> destinations forked to by proxy B sends a 1xx (creating an 
> early dialog) followed by a 4xx, and proxy B, being unable to 
> pass on the 4xx immediately, sends a 199, which finds its way 
> back via proxy A to the UAC. Later proxy B sends a 4xx, and 
> proxy A, being unable to pass on the 4xx immediately, sends a 
> dialog when it passed on the first 199, then the second 199 
> should not arise. But the requirement to release resources is 
> only a MAY.
> 
> > proxies, and the open issues we've identified (e.g. related 
> to the use 
> > with 100rel). I also added some 18x messages to the example flows.
> > 
> > Regards,
> > 
> > Christer
> > 
> > 
> >

---

From: Byron Campen <[email-masked]>
Date: Sat, 30 Jun 2007 10:28:09 -0500

> with a To tag, maps it to a 199.

	I suppose this point is related to your following point about the  
rarity of networks where you have chains of forking proxies. But, we  
don't need a long chain to have a problem here; if I'm a proxy, and a  
single downstream proxy forks, I only get a single 456xx back. I  
never hear about the other early dialogs that form. Now I suppose it  
isn't that terrible of a situation; the extension just fails to send  
some 199s back. We are at least no worse off than we are now.

> In real life networks I don't believe there will be long "chains" of

	I'm thinking a DoS here. An attacker can create a long chain of  
forking proxies by engaging in registration shenanigans. It seems to  
me that all the attacker needs to do is have a few forks hit a UA  
under their control, near the end of the attack, and it could fire  
back a 4xx with some dialog goo in it. That would instigate the proxy/ 
proxies involved to start a 199 storm. (I can present this scenario  
in more detail if you like, I'm just theorizing)

> I am not sure forming a dialog that way is allowed.
	I'm pretty sure UACs end up needing to support this case; think  
dropped 1xx (unreliable, no sdp) or reordering in the network. In  
fact, even if our network is not reordering packets, sending a 1xx  
followed by an UPDATE will often have the UPDATE arriving first,  
since the 1xx has to traverse the full chain of proxies, whereas the  
UPDATE need only traverse the proxies that Record-Routed. It is  
possible that the proxy will never see a 1xx at all, but it is a bit  
of a stretch. Again, we're no worse off than we are now.

> And, even if it was, the proxy can still simply map the 456xx into a
	
	Not if a downstream proxy forks, like I've mentioned before.

> send two responses (199 + final) when it wants to reject an INVITE.

	And I find it even stranger for a proxy to be manufacturing in- 
dialog responses. I understand the temptation to push this  
functionality into proxies; it makes upgrading a network much  
simpler. However, this is about Dialog signaling (end-to-end), and it  
really belongs in the endpoints. It works much better that way. I  
suppose I can see allowing proxies to do this sort of thing if they  
want, but I think any normative requirements should apply to endpoints.

Best regards,
Byron Campen

>> possible to
>> sends one

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Sun, 1 Jul 2007 00:30:45 +0200

Hi, 

>>>keys as provisionals come in.
>>
>	I suppose this point is related to your following point 
>about the rarity of networks where you have chains of forking 
>proxies. But, we don't need a long chain to have a problem 
>here; if I'm a proxy, and a single downstream proxy forks, I 
>only get a single 456xx back. I never hear about the other 
>early dialogs that form. Now I suppose it isn't that terrible 
>of a situation; the extension just fails to send some 199s 
>back. We are at least no worse off than we are now.

Correct, there would not be 199s sent for all early dialogs in this
case.

But, if the forking proxies implement (again, it's optional) some kind
of knowledge about which early dialogs have been created, it can send
199s for all of them.

forking proxies that
have sent back a
>I'm thinking a DoS here. An attacker can create a long 
>chain of forking proxies by engaging in registration 
>shenanigans. It seems to me that all the attacker needs to do 
>is have a few forks hit a UA under their control, near the 
>end of the attack, and it could fire back a 4xx with some 
>dialog goo in it. That would instigate the proxy/ proxies 
>involved to start a 199 storm. (I can present this scenario 

>I'm pretty sure UACs end up needing to support this 
>case; think dropped 1xx (unreliable, no sdp) or reordering in 
>the network. In fact, even if our network is not reordering 
>packets, sending a 1xx followed by an UPDATE will often have 
>the UPDATE arriving first, since the 1xx has to traverse the 
>full chain of proxies, whereas the UPDATE need only traverse 
>the proxies that Record-Routed. It is possible that the proxy 
>will never see a 1xx at all, but it is a bit of a stretch. 
>Again, we're no worse off than we are now.

I still don't believe it's allowed to send UPDATE at that point, because
the UAS does not know (as you also mention) whether the unreliable 1xx
will reach the UAC or not.

But, that discussion should probably be moved to a separate thread,
because it's more core SIP than 199 specific.

>>>UAS is responsible for sending the 199.
>>
>>We can discuss that, but I think it's a little strange that a UAS 
>>should send two responses (199 + final) when it wants to reject an 
>>INVITE.
> 
>And I find it even stranger for a proxy to be 
>manufacturing in- dialog responses. I understand the 
>temptation to push this functionality into proxies; it makes 
>upgrading a network much simpler. However, this is about 
>Dialog signaling (end-to-end), and it really belongs in the 
>endpoints.

Well, in that case, why are the 456xxxs terminated by the forking proxy
(which then sends one response towards the UAC)? Why not forward all
responses all the way back to the UAC?

>It works much better that way. I suppose I can see allowing proxies to
do this sort of thing if they want, but I 
>think any normative requirements should apply to endpoints.

We sure can discuss that alternative :) The main intention behind the
draft is to make the UAC aware of terminated dialogs, so...

Regards,

Christer