Thanks for the great feedback Adam - comments inline...
> -----Original Message----- > From: Adam Roach [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 27, 2007 5:07 PM > > General nit: s/header/header field/g # that statement is su-perl-ative print "will do\n"; > 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). My take on this is that ISUP/QSIG use of INFO is not Info-Package use, and so follows its own rules (though we should have said so). If this draft becomes a replacement for 2976, however, then that's a bigger deal. So yeah I agree, regardless. > 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. [...snip] What do you mean about "grandfathering DTMF"? (are you reading that in the draft somewhere?) I'm confused. > 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. I'm trying to understand some specific scenarios you're worried about. Can you describe the scenarios with examples why the 3PCC model breaks here? (I don't doubt they exist - I just don't see it) > 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. Yeah for those I can see re-Invite really should re-negotiate Info-package support. (But still not clear on why we need delayed indications of supported Info-packages.) > You probably also want to briefly mention INFO/BYE glare (and similar > situations) and how it should be handled. Yeah good point. > Recv-Event 18x - - - o o - - > I think you mean "1xx", not "18x" Yup. > 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). Is there any such "appropriate rates" discussion in other Request Method RFCs? (other than specific mechanisms such as session-expires) I mean wouldn't that be part of the package definition to deal with, if at all? > 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?" Yeah, so I think that begs the question if we should care about that case. Like there is no real way to signal such for many media-related items. For example you can offer 2833, but you can't do "reject this request if you're not going to answer me 2833", and no one's complained this was needed (right?). > 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. That last sentence was the big question - assuming that holds, we would definitely put in explicit wording around it. > 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). Agreed. -hadriel _______________________________________________ Sip mailing list https://www1.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
