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

[Paul Kyzivat <[e-mail]>]

I agree with Adam's comments. I've added a small amount of commentary.

	Thanks,
	Paul

Adam Roach wrote:
> 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.

I think the id is used to support multiple subscribe usages *of the same 
event type* in a dialog. (Not needed for different event types.)

Presumably more than one of these "Info Packages" can be used in the 
same INVITE dialog. I guess the question remains whether it would ever 
make sense to have more than one of the same type. I guess that depends 
on whether they can be parameterized in some way such that it would make 
sense to have more than one. I suppose the simplest answer is to declare 
that this won't be supported. Then the id isn't needed.

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

AMEN!

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

A hybrid of the two above is a PSTN GW, where a call transfer happens on 
the PSTN side.

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


_______________________________________________
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