Subject: [Sip] draft-ietf-sip-199-02: comments and questions

From: "Brett Tate" <[email-masked]>
Date: Mon, 17 Nov 2008 10:10:33 -0500

Greetings,

Here a few comments and questions concerning draft-ietf-sip-199-02.

Section 4 paragraph 4:  Concerning "the client SHALL discard the 199
responses", is "SHALL" too strong since 100rel may be used?  The
strength of "SHALL" is likely only an issue if 18x did not contain
100rel and 199 did.

Section 4 last paragraph: The use of "will act" should likely be changed
to reflect an RFC 2119 defined word.

Section 6 paragraph 2 first sentence: The use of "proxy MUST generate"
should likely be downgraded to SHOULD or MAY too clearly allow the proxy
to avoid sending 199 when forwarding to server expected to answer
quickly (such a voice mail server).

Section 6 paragraph 2 last sentence: Since using another's To tag when
sending the 199, the draft should mention something concerning headers
Contact and Record-Route.  If proxy chooses not to add them, a missing
Contact and Record-Route will not be an issue for UAC; however another
proxy (not supporting this draft) may be surprised to see their
Record-Route entry missing.  Additionally since this draft defines a 1xx
with To tag which does not create a dialog (unless section 4 paragraph 4
modified), does this draft update RFC 3261?

Section 7: Concerning "MUST reply to such requests with a 481", the text
should likely defer behavior to RFC 3261 concerning receiving requests
with To tag associated terminated/unknown dialog.

Sections 9 and 10: Concerning the "MUST NOT"s related to SDP, should
they be downgraded to a "SHOULD NOT" to still allow offer/answer
compliance if desired?
_______________________________________________
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: Sat, 22 Nov 2008 00:44:30 +0100

Hi Brett,

Thanks for you comments! See inline. 

------

>Section 4 paragraph 4:  Concerning "the client SHALL discard the 199
responses", is "SHALL" too strong since 100rel may 
>be used?  The strength of "SHALL" is likely only an issue if 18x did
not contain 100rel and 199 did.

Two alternative solutions that I can thin of:

1. If the 199 is sent reliably, the UAC simply discard it until it has
received the 18x, after which it deals with it. 

2. If the 199 is sent reliably, the UAC PRACKs it even if it has not yet
received the 18x.

------

>Section 4 last paragraph: The use of "will act" should likely be
changed to reflect an RFC 2119 defined word.

Is "shall behave" more suitable?

------

>should likely be downgraded to SHOULD or MAY too clearly allow the
proxy to avoid sending 199 when forwarding to server 
>expected to answer quickly (such a voice mail server).

Even if the proxy forwards the call to a voice mail server, the voice
mail server will establish a different dialog with the UAC than the
dialog which the UAS, from where the proxy received the error response,
established.

------

>Section 6 paragraph 2 last sentence: Since using another's To tag when
sending the 199, the draft should mention
>something concerning headers Contact and Record-Route.  If proxy
chooses not to add them, a missing Contact and Record-
>Route will not be an issue for UAC; however another proxy (not
supporting this draft) may be surprised to see their
>Record-Route entry missing.

Two alternative solutions I can think of:

1. We mandate a forking proxy which supports 199 to store the C/R-R
information received from the UAC, in order to insert it in any 199 it
generates for that session.

2. We say that IF the forking proxy stores the C/R-R information
received from the UAC, it shall insert it in any 199 it generates for
that session.

------

>Additionally since this draft defines a 1xx with To tag which does not
create a dialog (unless section 4 paragraph 4 
>modified), does this draft update RFC 3261?

Since the 199 is sent on already established dialogs, it does not create
a new dialog. Of course, if the 199 passes the dialog establishing 18x
(or the 18x is sent unreliably and gets lost) an entity not supporting
199 may establish an dialog. I would prefer to document that case
instead of updating 3261 :)

------

>Section 7: Concerning "MUST reply to such requests with a 481", the
text should likely defer behavior to RFC 3261 
>concerning receiving requests with To tag associated terminated/unknown
dialog.

Robert S commented on the same text. I could modify it to say:

"If such request is received by a UA, it shall act in the same way as if
it had received the request after sending the final non-2xx response to
the INVITE, as specified in RFC3261."

------

>Sections 9 and 10: Concerning the "MUST NOT"s related to SDP, should
they be downgraded to a "SHOULD NOT" to still allow 
>offer/answer compliance if desired?

I see no reason for that. Since the dialog is terminated, there is no
need to insert an SDP offer/answer.

------

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 24 Nov 2008 09:33:23 -0500

> received from the UAC, it shall insert it in any 199 it generates for

In effect the proxy is sending the response in lieu of the final 
response it is not ready to forward. IMO it ought to include whatever 
Contact and R-R is present in that final response. There isn't any need 
to *store* that information, since the final response is at hand when 
the 199 is being generated.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 24 Nov 2008 15:39:23 +0100

Hi, 

>>>sending the 199, the draft should mention something concerning
headers Contact and Record-Route.  If proxy
>>>chooses not to add them, a missing Contact and Record-Route will not
be an issue for UAC; however another proxy (not
>>>supporting this draft) may be surprised to see their Record-Route
entry missing.

>>received from the UAC, it shall insert it in any 199 it 
>In effect the proxy is sending the response in lieu of the 
>final response it is not ready to forward. IMO it ought to 
>include whatever Contact and R-R is present in that final 
>response. There isn't any need to *store* that information, 
>since the final response is at hand when the 199 is being generated.

True.

But, if the error response also terminates other early dialogs (in case
forking also occured downstream), and if the forking proxy is able to
identify those early dialogs, the forking proxy generates 199s also for
those dialogs. The proxy would need to store the C/R-R information in
order to be able to insert it in the 199s for those early dialogs.

However, I don't think that "multiple forking" will occur very often.

Regards,

Christer

---

From: Bob Penfield <[email-masked]>
Date: Mon, 24 Nov 2008 10:13:36 -0500

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
>Sent: Monday, November 24, 2008 9:33 AM
>To: Christer Holmberg
>Cc: [email-masked]; Brett Tate
>Subject: Re: [Sip] draft-ietf-sip-199-02: comments and questions
>
>
>
>Christer Holmberg wrote:
>>

The problem with this is that the non-2xx final response will not necessarily have Record-Route or Contact headers since 3261 does not require it. In fact, a strict reading of Table 2 & 3 forbids them in most error responses. If the proxy is going to generate a 199 response, it should include the same Record-Route & Contact as the original early dialog creating 1xx response.

cheers,
(-:bob

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 24 Nov 2008 12:09:03 -0500

> The problem with this is that the non-2xx final response will not necessarily have Record-Route or Contact headers since 3261 does not require it. In fact, a strict reading of Table 2 & 3 forbids t…

Good point.

Unfortunately, that significantly raises the bar for the proxy to 
implement this. It needs to store a lot more state than it otherwise 
would need. Not a problem for a B2BUA of course, since it already has to 
store that.

This then leaves us in a situation where a proxy incurs this significant 
extra cost to support 199, unless we make the inclusion of the R-R and 
Contact optional in the 199. I guess the Contact is already optional 
(though we have had discussions about that), but isn't the R-R required 
in all the provisional responses?

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 24 Nov 2008 22:13:46 +0100

Hi, 

>>>>information received from the UAC, in order to insert it in any 199 
>>>>it generates for that session.
>>>>
>>>>received from the UAC, it shall insert it in any 199 it generates 
>>>>for that session.

>>>Contact and R-R is present in that final response. There isn't any 
>>>need to *store* that information, since the final response is at hand

>>>when the 199 is being generated.
>> 
>>The problem with this is that the non-2xx final response will not
necessarily have Record-Route or Contact headers since 3261 does not
require it. In fact, a strict reading of Table 2 & 3 forbids them >>in
most error responses. If the proxy is going to generate a 199 response,
it should include the same Record-Route & Contact as the original early
dialog creating 1xx response.
implement this. It needs to store a lot more state than it otherwise
would need. Not a problem for a B2BUA of course, since it already 
>has to store that.
>
>This then leaves us in a situation where a proxy incurs this
significant extra cost to support 199, unless we make the inclusion of
the R-R and Contact optional in the 199. I guess the Contact is already
>optional (though we have had discussions about that), but isn't the R-R
required in all the provisional responses?

According to the tables in chapter 20 of 3261, Contact is optional in
1xx responses, and R-R is optional in 18x responses (the table doesn't
cover R-R for 199 :).

In addition, according to chapter 12.1.1 R-R is only mandatory in
responses which creates a dialog (which the 199 doesn't).

"When a UAS responds to a request with a response that establishes a
dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route
header field values from the request into the response (including the
URIs, URI parameters, and any Record-Route header field parameters,
whether they are known or unknown to the UAS) and MUST maintain the
order of those values."

Having said that, I don't think it would have a significant impact even
if the forking proxy would have to store this information.

Regards,

Christer