I see what Gilad is saying and think its a useful way to think about
the space (at least when SIP-T like problems are trying to use INFO).
(and that does not mean I like it or that I think we should promote
anything like implicit subscriptions going forward - quite the opposite)
Mostly, it gives us a good place to look for how we recommend we
solve those particular problems.
Thanks for sharing that insight Gilad!
RjS
On Jun 14, 2007, at 6:36 PM, Gilad Shaham wrote:
I never said that I endorse it...
Neither am I saying that INFO is implicit NOTIFY. I'm saying INFO's
functionality is notification on INVITE dialog usage without
subscription.
I agree it's an odd way to look at it (hence my comment on stupidity),
but here is the analogy (bear with me):
Suppose an implementation requires information during the lifetime of
the INVITE dialog, something related to the call itself. The normal
way
of doing this is implementing an event package, something that
holds the
call-id, remote-tag and local-tag of the INVITE dialog to which it
references.
One could say that this is a lot of work, why not send the information
on the INVITE dialog itself? Hence INFO roles into the game.
It _does_ the same functionality from user's perspective. Implementers
will find it much easier to do and it seems as a legitimate method for
communicating this information.
Of course it's not possible to say which INFO messages to receive as
opposed to event notification which are specified in the subscription.
Hence the implicit subscription (or lack of explicit subscription).
Furthermore, as Dale pointer out, there is nothing similar to Event
header, only the content-type tells what type of notification is
this. I
already said this is a problem with INFO, but some disagree and say
that
content-type is enough to hold the same information.
That's at least my understanding of what's proposed here:
KPML provides information on DTMF events that occur during the
lifetime
of the INVITE dialog. The events are sent in NOTIFY and the event
package itself refers to the invite dialog with call-id, remote-tag
and
local-tag. One could say that the same information can be passed in
INFO
and it's easier to implement. No one subscribes to this information,
somehow the subscription is implicit.
If the logic of the analogy is correct, I think it has implications on
INFO.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 14, 2007 8:52 PM
To: [email protected]
Subject: Re: [Sip] INFO message belongs only to INVITE dialog usage?
From: Paul Kyzivat <[EMAIL PROTECTED]>
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.
In particular, NOTIFY is labeled with an event-type, so the recipient
knows whether or not it knows how to process the event.
Dale
_______________________________________________
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
