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

From: "Brett Tate" <[email-masked]>
Date: Mon, 8 Dec 2008 12:06:14 -0500

Hi Christer,

Replying to email concerning version 2 since these comments are also
applicable to version draft-ietf-sip-199-03.

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

Concerning option 1, it only works if 18x actually reaches the UAC.  If
it doesn't, the 199's would continue to be retried and ignored.

Because of the retry issue, I prefer option 2.  However I don't have
strong preference concerning the strength: MAY, SHOULD, or MUST.

> > Section 4.1 last paragraph: The use of "will act" 
> > should likely be changed to reflect an RFC 2119 
> > defined word.
> 
> Is "shall behave" more suitable?

The use of lower case RFC 2119 words also add confusion since ambiguous
to reader if intentional or error.  I prefer "SHOULD" or "MAY" to allow
the client to decide appropriateness of what should be locally signaled
to caller (silence, ringing, etcetera) until subsequent response
received.

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

I agree.  However if the proxy assumes such a device will answer
quickly, the strength of MUST prevents a proxy from optimizing to avoid
a mostly useless 199.

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

Either alternative is OK with me.

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

To me, it sounds like an update to RFC 3261; however I'm ok with saying
it isn't. :)

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

As mentioned, the reason would be to allow offer/answer compliance.  The
specific example is INVITE without offer sent; 18x non-reliable sent; if
199 sent reliable, it is required to contain an offer.

_______________________________________________
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, 8 Dec 2008 19:26:18 +0100

Hi Brett, 

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

I am ok with option 2.

>>>Section 4.1 last paragraph: The use of "will act" should likely be
changed to reflect an RFC 2119 defined word.
to reader if intentional or error.  I prefer "SHOULD" or "MAY" to allow
the client to decide appropriateness of what should be 
>locally signaled to caller (silence, ringing, etcetera) until
subsequent response received.

I will use upper case, and I suggest "SHOULD".

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

I am still not sure I understand. Even if the device answers quickly,
the proxy can still send 199 if it receives an error response. Also,
keep in mind that the proxy will not generate a 199 unless the device
has actually created an early dialog.

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

I checked 3261, and if I remember correctly C/R-R are not mandatory, so
I would propose option 2.

>>>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 :)
>
it isn't. :)

Well, if we want to be really picky, we could say that it DOES create a
dialog, but it is immediately terminated :)

>>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.
>
>As mentioned, the reason would be to allow offer/answer compliance.
The specific example is INVITE without offer sent; 18x non-reliable
sent; if
>199 sent reliable, it is required to contain an offer.

I guess we could say that it must contain SDP in that case.

Thanks for your comments!

Regards,

Christer

---

From: "Brett Tate" <[email-masked]>
Date: Mon, 8 Dec 2008 14:22:13 -0500

> I am still not sure I understand. Even if the 
> device answers quickly, the proxy can still 
> send 199 if it receives an error response. 

I agree.  However the section 6.1 paragraph 2 text indicates that the
proxy MUST send 199.  I'd prefer that it is downgraded to a SHOULD to
allow the 199 to be avoided when proxy redirecting to something expected
to answer quickly.

For instance consider, call-forward-no-answer to voice mail.  After
early dialog established and no-answer timer expires, the proxy sends
CANCEL and forks the INVITE to voice-mail server expected to answer
quickly.  The current text indicates that proxy MUST send 199 if 487
received before the INVITE 200.

> > > 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.
> > > 
> > > it shall insert it in any 199 it generates for 
> > > that session.
> >
> I checked 3261, and if I remember correctly C/R-R 
> are not mandatory, so I would propose option 2.

I just noticed that you indicated "received from the UAC".  Did you mean
"received from the UAS"?  If not, would the proxy insert it's own
Contact?

Thanks,
Brett

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 8 Dec 2008 20:33:21 +0100

Hi, 

>>I am still not sure I understand. Even if the device answers quickly,
the proxy can still send 199 if it receives an error response.
>I agree.  However the section 6.1 paragraph 2 text indicates that the
proxy MUST send 199. 
>
>I'd prefer that it is downgraded to a SHOULD to allow the 199 to be
avoided when proxy redirecting to something expected to answer quickly.
early dialog established and no-answer timer expires, the proxy sends
CANCEL and forks the INVITE to voice-mail server expected to 
>answer quickly.  The current text indicates that proxy MUST send 199 if
487 received before the INVITE 200.

Aaah, now I understand. The voice mail will send 200 quickly, so the
early dialog between the UAC and the UAS will be terminated anyway,
without a need to send 199.

I guess we could say that the proxy can be configured not to send 199,
if a 200 is expected quickly, or something like that.

>>>199 to store the C/R-R information received from the UAC, in order 
>>>to insert it in any
>>>received from the UAC, it shall insert it in any 199 it generates 
>>>for that session.
>>
>>I checked 3261, and if I remember correctly C/R-R are not mandatory, 
>>so I would propose option 2.
>
>I just noticed that you indicated "received from the UAC".  Did you
mean "received from the UAS"?  If not, would the proxy insert it's own
Contact?

I meant received from the UAS :)

Regards,

Christer

---

From: Robert Sparks <[email-masked]>
Date: Mon, 8 Dec 2008 15:17:25 -0600

I'm only halfway through -03 and I'll be sending more later, but this  
winged one of the comments I was going to make.

I think this MUST that Brett was pointing to needs to be a MAY, not a  
MUST or a SHOULD.

This is an optimization. Nothing breaks if the proxy decides to not  
forward a 199 - you just don't
get the optimization.

Instead of going down the route of specifying how proxies can be  
configured to behave, I suggest
the document simply say choosing how quickly to return a 199 is a  
matter of implementation policy and
leave a note to implementers that in the absence of other reason, "as  
soon as possible" will increase the
effectiveness of the optimization.

RjS

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 9 Dec 2008 09:13:43 +0100

Hi Robert, 

>I'm only halfway through -03 and I'll be sending more later, 
>but this winged one of the comments I was going to make.
> 
>I think this MUST that Brett was pointing to needs to be a 
>MAY, not a MUST or a SHOULD.
> 
>This is an optimization. Nothing breaks if the proxy decides 
>to not forward a 199 - you just don't get the optimization.

I assume you mean GENERATE a 199, right? That is what Brett is talking
about.

Because, if the proxy receives a 199, it would of course forward it
according to normal proxy rules.

I can remove the MUST, but I think we should have a SHOULD. If the proxy
supports the extension (and the UAC has indicated support of it), the
proxy should use it (except in scenarios like the one Brett described).

>Instead of going down the route of specifying how proxies can 
>be configured to behave, I suggest the document simply say 
>choosing how quickly to return a 199 is a matter of 
>implementation policy and leave a note to implementers that 
>in the absence of other reason, "as soon as possible" will 
>increase the effectiveness of the optimization.

I will think about some wording.

Regards,

Christer