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://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors cs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip
|
