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