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 [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
