Thanks for the response; reply inline. > > Section 3.1 paragraph 1: Concerning "MUST advertise" and > > "provisional 1xx", please clarify that the "MUST advertise" > > is not applicable to the 100 response. Does the > > "MUST advertise" and "provisional 1xx" apply to all (first > > and subsequent within dialog) INVITE non 101-199 > > (intentionally indicated 199)? Concerning ACK for initial > > INVITE's 2xx, does the "MUST advertise" always apply? > > I would offer "MUST advertise" is appropriate. What is the > rationale to not require it? We are expecting "early INFO," > so no reason to screw up UACs by having random appearances > and disappearances of Recv-Info headers.
A 100 response does not create a dialog; thus including it during setup has no meaning or purpose. A proxy can send 100 responses within dialog; however the lack of Recv-Info appears to disable draft support per the following draft snippet. Thus I prefer the text cover 101-299 Reponses instead of 100-299 responses. Section 3.1: "if the UA neglects to include the Recv-Info header, the other UA in the dial will assume the first UA no longer supports INFO as specified by this document." Nit: "dial" should be "dialog". > > Section 3.1 paragraph 2 sentences 1 and 2: Sentence 1 > > indicates "session parameters" and sentence 2 indicates > > "dialog parameters" concerning Info Package negotiation, > > I'm not sure when the negotiation/renegotiation occurs. > > Does it follow SDP offer/answer rules or something else; > > if something else, what? I have the same question > > concerning "dialog refresh" text discussed later within > > the same section since incorrect interpretations might > > trigger deactivation. > > Should be dialog parameters everywhere. Would that clear > up the confusion? Partially; when are dialog parameters renegotiated? My main concern is with impacts of "neglects to include the Recv-Info" as reflected within above section 3.1 snippet; thus the reason I'm trying to understand. To avoid disabling, Recv-Info must be within re-INVITE, UPDATE, ACK-for-2xx, and 101-299 responses for these requests. Is Recv-Info mandatory within PRACK and PRACK 2xx to avoid disabling? Is it mandatory within REFER and REFER 2xx to avoid disabling (REFER isn't listed within section 5.2)? > > Section 4.3: When sending a 489, it indicates "MUST > > terminate the INVITE dialog". The "MUST terminate" > > seems severe even if all the negotiation race conditions > > are adequately addressed. The mentioned "protocol failure" > > reason seems contrary to the "strictly send and lenient > > receive" mantra. <snip> > Let us look at this from a practical perspective. If you are > a bad implementor and send a 489 you didn't mean to, who > knows what else you will get wrong. Conversely, if you > are a bad implementor and forget to tear down a 489-ed INFO, > bad things probably will not happen. Consider ACK from caller glaring with INFO from called. If the ACK adjusted Recv-Info to no longer support foo and INFO contained foo, why MUST the caller terminate the dialog upon sending 489 instead of realizing that it was just a glare? I actually think a good implementer would ignore the MUST and choose to be non compliant to avoid customer complaints; however I'd rather the draft be changed instead. Because updated Recv-Info can be within so many requests and responses within a dialog, there can be glare and ordering issues. Adding to the issue (change and change back), is that the Recv-Info is required to be within so many requests and responses to avoid disabling. _______________________________________________ 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
