Subject: [Sip] draft-ietf-sip-199-06

From: Adam Roach <[email-masked]>
Date: Thu, 19 Mar 2009 18:40:21 -0500

Between Minneapolis and now, this document has become a lot more 
confusing, which I think bodes pretty ill for its hopes of being deployed.

For example, in section 5:

   If the received initial request contains an 199 option tag, the UAS
   SHOULD NOT send a 199 response for a dialog on which it intends to
   send a final response...

This reads as if sending a 199 response somehow absolves a UAS of 
sending a final response. Certainly this is not the intention of the 
draft (at least, not according to the text in section 7). Section 5 
needs to be re-phrased to indicate what is actually intended here.

In fact, on that topic, it's radically unclear to me how UASes fit into 
the entire scheme at all -- my understanding is that the 199 response is 
only sent by forking proxies. Given that a UAS is inherently an 
endpoint, the entirety of section 5 seems nonsensical. Either I'm 
missing something (in which case it needs some pretty explicit 
motivating text), or section 5 needs to be removed completely.

In section 6:

   When a forking proxy receives a non-2xx final response that it
   recognizes as terminating one or more early dialogs, if the proxy
   does not intend to forward the final response immediately (in
   accordance with rules for a forking proxy) and the UAC has indicated
   support for the 199 response code, the proxy SHOULD generate and send
   a 199 response upstream for each early dialog terminated on the
   downstream side by the non-2xx final response, except for any early
   dialog for which the proxy has previously received and forwarded a
   199 response.

What? On my best run at reading that, I made it to about the 81st word 
before the first predicate clause fell out of my head. If it's really as 
complicated as the structure of this sentence makes it seem, we need a 
flowchart or some other simplifying mechanism.

/a

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 22 Mar 2009 17:49:31 +0100

Hi, 

>Between Minneapolis and now, this document has become a lot more
confusing, which I think 
>bodes pretty ill for its hopes of being deployed.

I can tell you it will be deployed, but let's focus on your comments :)

>This reads as if sending a 199 response somehow absolves a UAS of
sending a final response. 
>Certainly this is not the intention of the draft (at least, not
according to the text in 
>section 7). Section 5 needs to be re-phrased to indicate what is
actually intended here.

I undrstand what you mean. The text can be read in a way that a UA could
use 199 instead of the final response. That is certainly not the
intention. The idea was to cover B2BUAs, which similar to forking
proxies may not send final response for all dialogs.

>In fact, on that topic, it's radically unclear to me how UASes fit into
the entire scheme at 
>all -- my understanding is that the 199 response is only sent by
forking proxies.

No, a UAS (both a UA and B2BUA) can also send it. This was discussed
before, and there were no objections to allowing the UAS to send it.

I do agree that end terminals normally may not send it, but you may have
network entities (applicatoin servers, B2BUAs generating multiple
dialogs etc) which will.

>What? On my best run at reading that, I made it to about the 81st word
before the first 
>predicate clause fell out of my head. If it's really as complicated as
the structure of this 
>sentence makes it seem, we need a flowchart or some other simplifying
mechanism.

I don't understand what is unclear, eventhough the wording and style may
have some 3GPP influences :) Sure, there may be 81 words, but I think it
describes what the proxy does in a rather straight forward way.

I also don't see how a flowchart would make this text more clear,
because the actions depends on what has/has not happened before. But, if
you have a proposal on how to make the text more simple I am happy to
incorporate that.

Regards,

Christer

---

From: "Elwell, John" <[email-masked]>
Date: Sun, 22 Mar 2009 23:30:15 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Christer Holmberg
> Sent: 22 March 2009 16:50
> To: Adam Roach; SIP WG
> Subject: Re: [Sip] draft-ietf-sip-199-06
> 
> 
> Hi, 
> 
[JRE] The reason we need to cover B2BAUs is that a B2BUA may behave like
a proxy and withhold the sending of a final response until it receives
responses from other branches it has created. So can we not have the
same rule for any server (proxy or UAS), telling it what to do when a
final response is withheld? This might make it simpler. There would not
then be any need for a normal UAS to send 199.

> you have a proposal on how to make the text more simple I am happy to
[JRE] I agree with Adam that it is unclear. When trying to write down a
normative requirement that is dependent on multiple conditions, it often
helps to list the conditions in a bulleted list, e.g.:
If
- foo1
- and foo2
- and not foo3
then do bar.

John
> 
> Regards,
> 
> Christer
> _______________________________________________
> Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 23 Mar 2009 07:48:22 +0100

Hi John,

>>This reads as if sending a 199 response somehow absolves a UAS of sending a final response. 
>>Certainly this is not the intention of the draft (at least, not according to the text in 
>>section 7). Section 5 needs to be re-phrased to indicate what is actually intended here.
> 
>>In fact, on that topic, it's radically unclear to me how UASes fit into the entire scheme at 
>>all -- my understanding is that the 199 response is only sent by forking proxies.
> 

You can have network entities which act as "normal" UAS, which also want to send 199. They may e.g. have been configured to do so, since the forking proxy does not support 199. Etc.

And, the text already says that a UAS should not send a 199, unless it has been configured to do so. But, I don't think we should forbid it from doing so.

>>complicated as the structure of this sentence makes it seem, we need a flowchart or some other 
>>simplifying mechanism.
> 
>because the actions depends on what has/has not happened 
>before. But, if you have a proposal on how to make the text more simple I am happy to
>incorporate that.

I can try to do that, if people think it's more clear.

Regards,

Christer

---

From: Hans Erik van Elburg <[email-masked]>
Date: Mon, 23 Mar 2009 09:51:02 +0100

Yes you should, people do think that ;-)

/Hans Erik van Elburg

---

From: Tom Taylor <[email-masked]>
Date: Mon, 23 Mar 2009 05:35:14 -0700

Some text , as requested.

Christer Holmberg wrote:
...
>>   dialog for which the proxy has previously received and forwarded a
...

My suggestion:

"When a forking proxy receives a non-2xx final response that it
  recognizes as terminating one or more early dialogs, it SHOULD generate
  and send a 199 response upstream for each such early dialog satisfying the
  following conditions:
  -- the proxy does not intend to forward the final response immediately
     (in accordance with rules for a forking proxy);
  -- the UAC has indicated support for the 199 response code;
  -- the proxy has not already received and forwarded a 199 response for
     that early dialogue."

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 23 Mar 2009 14:12:13 +0000

> Behalf Of Tom Taylor
> Sent: 23 March 2009 12:35
> To: Christer Holmberg
> Cc: SIP WG; Adam Roach
[JRE] Make it clear that all 3 conditions must be true, e.g., by saying
"satisfying all of the following conditions".

John

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 23 Mar 2009 17:25:13 +0100

Hi,

Thanks for the text, Tom!

Regarding documenting that all 3 conditions must be fullfilled, and way
is to write ";and" after each condition.

 "When a forking proxy receives a non-2xx final response that it
  recognizes as terminating one or more early dialogs, it SHOULD
generate
  and send a 199 response upstream for each such early dialog satisfying
the
  following conditions:
  -- the proxy does not intend to forward the final response immediately
     (in accordance with rules for a forking proxy);and
  -- the UAC has indicated support for the 199 response code;and
  -- the proxy has not already received and forwarded a 199 response for
     that early dialogue."

Reegards,

Christer

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Monday, March 23, 2009 4:12 PM
To: Tom Taylor; Christer Holmberg
Cc: SIP WG; Adam Roach
Subject: RE: [Sip] draft-ietf-sip-199-06

> From: [email-masked] [mailto:[email-masked]] On Behalf Of 
> Tom Taylor

John

> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip Use 
> [email-masked] for new developments on the application of sip
>

---

From: Adam Roach <[email-masked]>
Date: Mon, 23 Mar 2009 16:23:05 -0700

Christer Holmberg wrote:
> You can have network entities which act as "normal" UAS, which also 
> want to send 199. They may e.g. have been configured to do so, since 
> the forking proxy does not support 199. Etc.

No, but you need to motivate why they might do so. Explain that they're 
sending it because they think there's an upstream forking proxy that 
won't. Explain that they might be a B2BUA that has created more than one 
early dialog with the caller, and wants to clean some of them up. It 
makes little sense to say that UAs can do this without some kind of 
explanation about why they would do so.

/a

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 24 Mar 2009 00:31:36 +0100

Hi, 

>>And, the text already says that a UAS should not send a 199, unless it
has been configured to do so. But, I don't think 
>>we should forbid it from doing so.
>   
>
sending it because they think there's an upstream 
>forking proxy that won't. Explain that they might be a B2BUA that has
created more than one early dialog with the caller, 
>and wants to clean some of them up. It makes little sense to say that
UAs can do this without some kind of explanation 
>about why they would do so.

The text does talk about the case when the UAS knows, based on
configuration, that the proxy does not support 199, but I agree that
some text about UAS/B2BUAs creating more than one dialog can be added.

Regards,

Christer