Subject: Re: [Sip] draft-ietf-sip-info-events-03: comments and questions

From: Eric Burger <[email-masked]>
Date: Fri, 6 Mar 2009 16:55:34 -0500

Inline.

On Feb 16, 2009, at 7:18 PM, Brett Tate wrote:

> Howdy,
>
> The following are a few comments and questions concerning draft-ietf- 
> sip-info-events-03.
>
> Thanks,
> Brett
>
> -------------
>
> 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.

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

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

Maybe living in New Hampshire has made me more conservative. A lot of  
folks will today say that while "Be conservative in what you send and  
liberal in what you receive" may have been the greatest mistake we  
ever made in protocol design. 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.

I will defer to the WG on this one. Any other opinions?

> Section 5.1 Table 1: The usage of "g" seems potentially outdated or  
> incorrectly reference since discussed within RFC 2543 instead of RFC  
> 3261.  The same applies to usage Via row concerning "(2)".

Poor cutting & pasting. Will fix.

> Section 5.2.2: The "general-header" reference is outdated or  
> incorrectly reference since defined within RFC 2543 instead of RFC  
> 3261.  RFC 3261 uses "Message-Header".

Ditto.

> Section 7.7 paragraph 2: The following potentially could be reworded  
> since it is okay to return failure responses (401, 503, 500, ...)  
> even when overlapping occurs: "in the event a UAC issues overlapping  
> INFO requests for an Info Package, the UAS MUST NOT return an error  
> response".

Good idea.  Will do.

> Section 8: Why specifically defining and using "nil"?  I'm mainly  
> just curious of the benefit over not having defined "nil" for  
> similar use within the Supported header.

That is a good one. since we go to the trouble of registering "nil",  
it is just an Info-package-type.  Will fix.

---

From: Bob Penfield <[email-masked]>
Date: Sat, 7 Mar 2009 10:09:46 -0500

inline

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Burger
>Sent: Friday, March 06, 2009 4:56 PM
<snip>
>On Feb 16, 2009, at 7:18 PM, Brett Tate wrote:
<snip>
>I will defer to the WG on this one. Any other opinions?

RFC 5057 indicates that a 489 should destroy the dialog usage.
However, it also says:

   (12) 489 Bad Event:  In our example scenario, [5] declares that the
      subscription usage in which the NOTIFY is sent is terminated.
      This response is only valid in the context of SUBSCRIBE and
      NOTIFY.  UAC behavior for receiving this response to other methods
      is not specified, but treating it as an unknown 4xx is a
      reasonable practice.

I'm inclined to say that since the INFO is not suppose to change
dialog state, a 489 response to an INFO should not destroy the INVITE
dialog usage. With SUBSCRIBE/NOTIFY its a failure of the dialog
establishing/target-refresh request which is essential to the dialog
usage. But INFO is not essential to the INVITE dialog usage, so
applying the last sentence above makes sense to me.

cheers,
(-:bob

---

From: Dean Willis <[email-masked]>
Date: Sat, 7 Mar 2009 17:30:22 -0600

Bob said:
> applying the last sentence above makes sense to me.

Doesn't a 489 in any in-dialog Non-Invite-Transaction destroy the  
dialog usage? It seems like we break the state machine if we make INFO  
a special case.

--
Dean

---

From: Brett Tate <[email-masked]>
Date: Sun, 8 Mar 2009 14:31:32 -0700

Thanks for the response; reply inline.

> > "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.