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 [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
