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