Re: [Sip] FW: I-D Action:draft-kaplan-sip-info-events-00.txt

[Adam Roach <[e-mail]>]

On 11/19/07 3:07 PM, Hadriel Kaplan wrote:
> Yeah my bad for not re-writing that whole thing.  It started out as a "rfc3265 Event Packages for INFO" type thing, but after your emails on the subject we were convinced that was a bad way to go.  I apologize for not cleaning it up better before submission.  Do you want me to re-submit using better terminology?  (unfortunately due to the submission deadlines I don't think I can do so officially?)
>
> I was thinking this was really just a discussion point doc for the Vancouver meeting, and if the concept in general was adopted we'd fix all the terminology.
>
> Sorry 'bout that.  :(
>   

No problem -- I know how hectic things can get before the face-to-face 
meetings. Perhaps a bit more heads-up (either in the document or on the 
mailing list) that the event-package terminology was a known issue would 
have helped.

Comments follow. To prevent my fingers from burning while I type this, I 
will use the terms "Info Package", "Send-Info" and "Recv-Info" instead 
of "Info Event Package," "Send-Event," and "Recv-Event" as currently 
found in the document. I'll also talk about the header field 
"Info-Profile" instead of "Event".

----

General nit: s/header/header field/g

----

      [NOTE: do we need to support the "id" concept as well?  Is there 
   a use case?] 


The "id" concept in 3261 is to support multiple SUBSCRIBE usages in a 
dialog. Because INFO is part of an INVITE dialog, there can be only one. 
You don't need "id" for INFO.

----

The document needs some discussion around grandfathering existing 
standardized usages, similar to what 3265 did for PINT. Specifically, we 
want a way at the beginning of the dialog that one can use to usually 
detect that ISUP or QSIG will be sent, and text specifically indicating 
that ISUP and QSIG payloads without an "Info-Profile" header field can 
be interpreted according to the appropriate legacy RFCs. This impacts 
normative languages elsewhere (like the "MUST NOT" in the first 
paragraph of section 5.1).

I would be careful about grandfathering DTMF, simply because doing so 
would require clear definition of what those INFO messages mean, and 
consensus on that topic would take more than a little work. (A taste of 
what you'll argue about: do they represent tones? Keypresses? Generic 
user stimulus? Are they sent with in-band DTMF or instead of it? If you 
receive both, what does it mean? If they are tones, how do they get 
synced with the RTP stream and re-insterted?)

----

In terms of where the events are negotiated: I think this probably needs 
to follow the general offer/answer rules for greatest flexibility. The 
key reason is 3PCC. If a 3PCC is bringing two parties together to 
communicate, it won't be able to indicate supported Info Packages in the 
initial INVITE. It would be useful, then, for the first party contacted 
to be able to indicate Send-Info and Recv-Info in its 200-class 
response, and get a negotiated set of packages in the ACK.

----

   A Re-INVITE or UPDATE request MUST NOT contain any Send-Event or 
   Recv-Event headers, and such headers MUST be ignored on reception.  
   The info-event package negotiation is performed during the initial 
   INVITE transaction, and there is no re-negotiation. 
    
   [Is that ok?  Is there a need to have re-negotiation? (is there a 
   use case?)  It sure makes it simple not to have things change in the 
   middle of a session] 


I think you run into unsolvable 3PCC interactions here as well, since a 
3PCC can switch out one party of a call -- this could result in a 
completely different set of Info Packages being valid after the switch-out.

It is also remotely conceivable that a reconfiguration of the client may 
result in a change in available packages; for example, a client may 
advertise a video-related Info Package for video calls, but not for 
other kinds of calls; an upgrade to video under such circumstances would 
warrant a change in available packages.

----

   If an Invite usage fails or is terminated, the Info-based 
   event state no longer exists, and an INFO request MUST NOT be sent. 


You probably also want to briefly mention INFO/BYE glare (and similar 
situations) and how it should be handled.

----

   Recv-Event          18x        -   -   -   o   o   -   - 


I think you mean "1xx", not "18x"

----

The document needs to talk about appropriate rates of INFO transmission 
so as to not overwhelm the proxy network. You also need to discuss the 
responsibilities of Info Package definitions (similar to RFC 3265, 
section 4.4 and its subsections).

----

I would also suggest a discussion of Supported/Require as it pertains to 
specific Info Packages, so as to avoid the discussion around, "but what 
if I *want* the call to fail if a specific package isn't supported?"

----

Discussion of handling of the Send-Info and Recv-Info in REGISTER and 
OPTIONS is also warranted. You may think it's intuitive and doesn't need 
explanation, but I promise that people will get it wrong without 
specific language around what these things mean (for example: does the 
Recv-Info header field in an OPTIONS response describe all the Info 
Packages a UA can receive, or only that subset that was indicated in the 
OPTIONS request?).  I _DO_ think the presence of these fields in at 
least OPTIONS (and, to a lesser degree, REGISTER) would be a very useful 
thing.

----

Finally, I would argue that INFO is old enough (it predates 3261!) -- 
and consequently sufficiently out of date -- that it makes more sense to 
incorporate the definition of INFO into this document and aim to 
*replace* RFC 2976 instead of update it. (When you take the tables and 
boilerplate out of 2976, it comes to only a couple pages in length).

/a




_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip