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

["Christer Holmberg" <christer.holmberg at ericsson.com>]

Hi Brett, 

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

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

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

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

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 :)
>
>To me, it sounds like an update to RFC 3261; however I'm ok with saying
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
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip