Re: draft-ietf-sip-info-events-03: comments and questions

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