If you start down this path (I'd rather not), then rather than
considering INFO to be a notification of an implicit subscription you
might was well use NOTIFY for an implicit subscription. Just as there is
a lot of use of INFO in the wild, there is also a lot of use of NOTIFY
without SUBSCRIBE. I find it pretty difficult viewing INFO as an
implicit NOTIFY.
Paul
Gilad Shaham wrote:
Christer,
I think I'm starting to see your point...
It sounds to me as if you are saying something equivalent to the following:
INFO is a notification for some type of implicit subscription on an INVITE
dialog.
(geez, I hope my interpretation doesn't sound stupid)
For example, instead of establishing a new dialog for receiving DTMF
notifications, the INFO is used in order to send events on the INVITE dialog
without requiring a new subscription usage on the dialog (meaning, the implicit
subscription ends with the BYE, unlike explicit subscriptions which are a
different usage).
Is this interpretation acceptable?
Only thing part I feel is missing is actually stating which "subscriptions" the
UAs want to receive/support and the previous discussion on content-type vs. another
header to indicate the purpose of the INFO message.
If DTMF on INFO does become a known RFC, I think for the very least it should
adopt the body from the KPML syntax rather than a proprietary one, but that's
another issue.
Regards,
Gilad
-----Original Message-----
From: Christer Holmberg (JO/LMF) [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 14, 2007 3:38 PM
To: Elwell, John
Cc: SIP IETF
Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage?
Hi John
I am personally not saying people should use one solution instead of
another. I think the issue is that the market has seen a need for
out-of-band transport of DTMF tones, one reason being that all
entities using DTMF do not have access to the media.
[JRE] KPML addresses this space. Because it establishes a
dialog for the purpose, KPML can ensure that SIPS is used,
even if SIPS is not used for the INVITE-initiated dialog.
Why do we need a different solution?
The problem is that the INFO solution was implemented BEFORE KPML was
finalized.
I also believe that many people think it's easier do handle it in a single
dialog, without having to establish and associate two separate ones. But,
that's just my guessing (I have personally never had to make the decisson
which solution to implement based on technical arguments).
Regards,
Christer
-----Original Message-----
From: Christer Holmberg (JO/LMF)
[mailto:[EMAIL PROTECTED]
Sent: 14 June 2007 10:41
To: Elwell, John
Cc: SIP IETF
Subject: RE: [Sip] INFO message belongs only to INVITE
dialog usage?
Hi John,
I hear what you are saying, but I don't see how this is
specific to
DTMF and INFO.
Doesn't this affect all I kind of sensitive information
that you want
to transport over SIP?
Regards,
Christer
-----Original Message-----
From: Elwell, John [mailto:[EMAIL PROTECTED]
Sent: 14. kesäkuuta 2007 12:33
To: Christer Holmberg (JO/LMF)
Cc: SIP IETF
Subject: RE: [Sip] INFO message belongs only to INVITE
dialog usage?
Christer,
Slightly aside from the main direction of the discussion,
but what
about security? I send my audio using SRTP, and would
expect DTMF to
receive exactly the same protection. The signalling may
or may not
be end-to-end secured, depending on which of the current
and future
key management methods are used. Maybe SIPS has to be
used, but we
all know the limitations of that (e.g., if I receive
an INVITE
request to my SIPS URI, can I be sure all hops are
secured?). I am
sure the IETF would not want to endorse a mechanism that
opens up a
security hole that is not present with an existing
mechanism for
doing the same thing (RFC 2833).
John
-----Original Message-----
From: Christer Holmberg (JO/LMF)
[mailto:[EMAIL PROTECTED]
Sent: 14 June 2007 10:20
To: Paul Kyzivat
Cc: SIP IETF; Dean Willis
Subject: RE: [Sip] INFO message belongs only to INVITE
dialog usage?
Hi,
I don't think an application will trigger INFOs in a
spray and pray
matter. You will only send media server control messages
if you are
communicating with a media server control
application that
understands them.
How does my phone know it is communicating with a media
server that
understands INFO for conveying DTMF? The thing I call
may indicate
support of INFO because it supports qsig tunneling.
It should also indicate support (using the Accept
header) of the
content-type which is used to transport the media control
messages.
Before you send a DTMF/INFO, you really need to
know that the
recipient understands DTMF/INFO in general and the
specific encoding of DTMF in INFO that you're
using (there
have been
multiple encodings proposed).
Yes, and you know that if you receive an indication
from the other
party that he supports application/my-dtmf (or whatever
value is used).
And, if we would have standardized one encoding, maybe
there wouldn't
be multiple ones out there...
We currently have no way to say "I support mime-type foo
for use with
disposition bar and method baz", but in reality that is
going to be
the situation. I support sdp for disposition "session" in
the methods
that convey o/a. But I don't support sdp in MESSAGE
or INFO. I
support text/plain with
content-type "render"
in MESSAGE, but not for other
dispositions and other message types.
You don't have any way to say "I support mime-type SDP
for use with
disposition bar and method baz" either - that we specify
elsewhere.
And, if we define a DTMF mime-type, we should of course
also say in
which SIP message it can be used etc. But, again, we
should not
specify the applications that are going to use it.
Also, since INFO is not supposed to affect the SIP
session, we can
also put restrictions on which disposition values are to be
used etc.
So, of course there is some work to do, but that's not a
reason to
reject something. If everything was done and ready, there
would be no
need for the SIP WG :)
Getting an indication of support for application/my-dtmf
is useful
*if* you know that the UA sending it to you always uses it
the same
ways you do. You can only know that if you control it, or
if all the
uses of that type are standardized.
It's up to the applications to make sure that the DTMFs are
sent and
intepreted. If the receiving application has not asked for
DTMFs, and
the sender still sends them, the receiver should simply
discard them.
It's part of the application logic - not the SIP
protocol. The SIP
protocol defines information elements to indicate what
content types
you support, what actions to take if the content type is
not supported
etc.
But, again: we don't specify what the applicatons are going
to do with
information.
It's similar to when you use RFC2833 for sending DTMFs. The
only thing
you do, as part of the offer/answer procedure, is agreeing
that both
endpoints support RFC2833 - but you do not specify what the
endpoints
are going to do with the tones, when they will be sent etc.
And beyond just understanding your encoding of DTMF/INFO,
you need to
know that the recipient you are sending it to is
likely to do
something useful with that INFO, and that this "something
useful" is
what you intend it to do when you send it.
Yes, but you wouldn't send it unless you have a reason to
think the
receiver is going to do something with it, e.g. if you
have been
asked to give your PIN code.
I don't understand why people think that applications
would start
sending all kind of INFOs "just for fun", without any
logic behind.
I have never seen that happen in real world deployments. I
wouldn't
start sending UPDATEs and/or re-INVITEs just for
fun either,
eventhough there is nothing preventing me from doing it.
Lets go back to my phone. *It* doesn't know that I have
been asked to
give my PIN code, even though I do. All my phone knows is
that I have
pressed one of the buttons on the keypad. It may
reasonably infer
that I want *something* to be done with them, and
probably that I
want them sent to the other end in some way. It has no
idea *how* (or
*if*) the other end is prepared to receive them.
I think what you are talking about is how you will design
your SIP
phone.
For example, on my table phone, if I during a call want to
send DTMF
tones I have to first press one button to "active" DTMF,
and then any
button I sent is sent as DTMF. If I am asked to give my PIN
code, but
do not active DTMF, nothing will happen when I press
the buttons.
On my GSM phone, however, I don't need to active DTMF. If I
am asked
to give my PIN code, I simply press buttons and they are
sent as DTMF
tones.
For instance, it may have indicated support for a mime
type that my
phone knows how to use to encode DTMF. But its possible it
was really
trying to say that it would support that type in a
NOTIFY (sent or
received).
IF there are missing parts in the negotiation mechanism,
we need to
fix that.
Something like:
Accept: application/my-dtmf;method=INFO
OR, in the draft defining the content type, we specify
that content
type X can only be sent using this and that method. I
belive we do the
same thing for SDP.
But, so far we haven't been interested in looking into
these issues.
We just say that using INFO is against the spirit of SIP,
it causes
all kind of problems etc etc.
My intention is not to "promote" the usage of INFO. My
issue is that
the market has found and deployed an easy and effective way
of doing
things using INFO, without breaking the protocol, and what
worries me
is that instead of trying to help the market (e.g. by
standardizing
the content types, providing negotiation mechanism
to achieve
interoperability), and in that way indirectly help them
to come up
with new SIP applications, we simply tell them that
what they are
doing (and have been doing for
years) is wrong, that they are breaking SIP, etc etc etc.
And, if we really wanted to restrict the usage of INFO, it
should have
been done a long time ago - not years after the INFO RFC is
published
and people have deployed usages of it.
Anyway, I guess we can go on with this discussion
forever. Maybe we
should find some time in Chicago and sit down and
discuss this?
Regards,
Christer
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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
