On 11/28/07 7:14 AM, Hadriel Kaplan wrote:
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.
The comment was meant in the context of grandfathering existing uses of
INFO, and DTMF is the elephant in the room. The more general advice
would be: "be careful in discussion of grandfathering existing INFO uses
that you only include well-defined uses -- otherwise, you'll find
yourself having to provide the detailed definition of such uses."
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)
Basically, I think you'll run into problems if you can't support a
scenario like this:
A 3PCC B
|(1) INVITE | |
|(no Recv-Info) | |
|<------------------| |
|(2) 200 | |
|(Recv-Info A) | |
|------------------>| |
| |(3) INVITE |
| |(Recv-Info A) |
| |------------------>|
| |(4) 200 |
| |(Send-Info A) |
| |<------------------|
| |(5) ACK |
| |------------------>|
|(6) ACK | |
|(Send-Info A) | |
|<------------------| |
|(7) Media | |
|.......................................|
| |(8) INFO |
| |<------------------|
|(9) INFO | |
|<------------------| |
Without the ability to negotiate Info Packages in messages (2) and (5),
you run into the basic inability to support this kind of thing.
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.)
Beyond those use cases, you should keep the following flow in mind as
well, which requires the ability to renegotiate Info Packages in re-INVITEs:
A 3PCC B
|(1) INVITE | |
|(no Recv-Info) | |
|<------------------| |
|(2) 200 | |
|(Recv-Info A) | |
|------------------>| |
|(3) ACK | |
|(no Send-Info) | |
|<------------------| |
| |(4) INVITE |
| |(Recv-Info A) |
| |------------------>|
| |(5) 200 |
| |(Send-Info A) |
| |<------------------|
|(6) INVITE | |
|(Send-Info A) | |
|<------------------| |
|(7) 200 | |
|(Recv-Info A) | |
|------------------>| |
| |(8) ACK |
| |------------------>|
|(9) ACK | |
|<------------------| |
|(10) Media | |
|.......................................|
| |(11) INFO |
| |<------------------|
|(12) INFO | |
|<------------------| |
This actually highlights another very interesting point -- to make this
flow work at all, A needs to indicate the Info Packages it is willing to
send and receive in message (2), regardless of whether such packages
appeared in message (1) at all. In other words, what appears in a 200
can't be a subset of what was in the INVITE -- it should be a statement
of absolute capabilities.
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?
If you plan for that to be the case, say so in the document. I suggest
copying the first paragraph of RFC 3265, section 4.4.10, and the final
paragraph of section 4.1, with appropriate changes in terminology.
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?).
I won't object one way or the other. I'm trying to make your life easier
-- the arguments here are predictable, and my suggestion is an attempt
to ward them off. You can ignore mu suggestion and I'll stay out of the
way, but I doubt others will. I'll close by quoting an example already
being given in this area (from Eric's draft):
"Some uses of INFO can tolerate this fate sharing of the INFO message
over the entire dialog. For example, in the SIP-T usage, it may be
acceptable for a call to fail, or to tear down the call, if one
cannot deliver the associated SS7 information."
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.
I think we'd be muddling things up pretty badly if we suddenly started
defining aspects of the protocol that are not discoverable via OPTIONS,
but could be discovered via alternate means (e.g. INVITE). It's kind of
changing the meaning of "OPTIONS".
The REGISTER usage isn't as clear cut. The reason I think it would be
nice to have is that it allows me to come along later and define a
caller-prefs that says, "I'm trying to reach Hadriel, and I'd prefer if
I could reach him on a device that supports event package foo."
/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
