Brian Stucker wrote:
If we're going to change the way that error messages are handled that
are returned for NOTIFY messages isn't it going to be a bit complicated
to determine at the transaction layer if the NOTIFY was negotiated via
INVITE or via SUBSCRIBE?
I mean, the endpoints may know what's going on, but boxes in the middle
might not.
I don't see any reason why *proxy* middle boxes need to know anything
about this. B2BUAs will need to know, but then they will know.
I'm a bit concerned that by tweaking 3265 in this way we're going to
move more complexity into all subscription processing whether it's a
usage within a dialog, a separate dialog or this new thing.
It would only affect those that support it.
And I don't think it will be a big deal, but then this is just
speculation at this point, since no details have been worked out. Its
always possible that it would turn into a mess.
Paul
Regards,
Brian
-----Original Message-----
From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
Sent: Friday, October 19, 2007 10:55 AM
To: Hadriel Kaplan
Cc: Elwell, John; sip; Michael Procter; Adam Roach; Stucker,
Brian (RICH1:AR00)
Subject: Re: [Sip] INFO
Hadriel Kaplan wrote:
Which is one of the reasons I think it should be INFO.
Using it would only be an update to rfc2976, right?
-hadriel
I don't think the distinction is significant. Either way it
should be designed to be backward compatible. And neither way
will require actually changing those other documents.
Using NOTIFY:
- will need some new header(s) in INVITE and responses to
negotiate this
new capability within the invite dialog usage.
- once that is done it will have established some new rules for using
NOTIFY in that context. This will not be used unless negotiated,
so there aren't any backward compatibility issues.
- for those that *do* support this, the same code should ideally be
able to use either this technique or real subscriptions, with only
minor tweaks.
- I would expect that any event packages defined in the future that
could meaningfully be used in this way would be designed from the
ground up to support both styles.
Using INFO:
- I don't think it will be sufficient to just add headers to
NOTIFY itself. IMO there still needs to be negotiation of
the particular usages of NOTIFY. So there still need to be
new header(s) in invite and responses.
- once the negotiation is done there will need to be some new
header(s) to provide added context for the INFO.
- any usage that currently has an event package would have
to be modified to be used with INFO.
Bottom line - I think a "lighter weight" subscription
mechanism serves all the same needs that an enhanced INFO
does, is no harder to implement, and has other benefits.
Thanks,
Paul
-----Original Message-----
From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
Sent: Friday, October 19, 2007 7:48 AM
To: Elwell, John
Cc: sip; Michael Procter; Adam Roach; Brian Stucker
Subject: Re: [Sip] INFO
Yes, my thinking has been that this would be a matter of
negotiating
the use of NOTIFY *within* the invite-dialog-usage. Of course that
isn't legal today - this would be an extension to both
3261 and 3265.
Paul
Elwell, John wrote:
Michael,
Yes, I guess some of the postings on this thread have
hinted that it
would be the same dialog usage. I suppose if the
subscriptions are
deemed to terminate at the time of the BYE transaction, then it
would indeed by the same dialog usage. So it would appear to be
within the letter of the dialogusage draft. However, one or two
postings have suggested different.
John
-----Original Message-----
From: Michael Procter [mailto:[EMAIL PROTECTED]
Sent: 19 October 2007 08:48
To: Elwell, John; Adam Roach; Paul Kyzivat
Cc: sip; Brian Stucker
Subject: RE: [Sip] INFO
John,
My impression of the discussion so far is that using NOTIFY (or
INTIFY as Christer suggests) in this way would not
constitute a new
dialog-usage. A new usage would imply periodic
resubscription and
specific termination, whereas sending INTIFY within the
context of
the INVITE-usage means that the lifetime issues can be ignored:
terminate the call, and INTIFY no longer has a context.
This neatly avoids violating the letter of the
dialogusage draft,
but you could probably argue that creating sub-usages of the
INVITE-usage isn't necessarily in keeping with the
spirit of the draft...
Regards,
Michael
-----Original Message-----
From: Elwell, John [mailto:[EMAIL PROTECTED]
Sent: 19 October 2007 07:41
To: Adam Roach; Paul Kyzivat
Cc: sip; Brian Stucker
Subject: RE: [Sip] INFO
Adam,
Now that you have reminded us of the dialogusage draft,
perhaps it
would be appropriate to remind people of the following from the
abstract:
"This memo argues that multiple dialog usages should be
avoided.
It discusses alternatives to their use and clarifies essential
behavior for elements that cannot currently avoid them."
In other words, while it will only be an Informational RFC, it
seems to deprecate introduction of further dialog
reuses. So if we
were to go with NOTIFY, would this be a new dialog
usage, and if
so,
do we really
want to go ahead with something in contradiction to the
sentiment
of that recently-approved draft?
John
-----Original Message-----
From: Adam Roach [mailto:[EMAIL PROTECTED]
Sent: 19 October 2007 01:05
To: Paul Kyzivat
Cc: sip; Brian Stucker
Subject: Re: [Sip] INFO
Paul Kyzivat wrote:
I mostly agree with Adam. The place where I take exception
is INFO. It
is my impression that INFO was designed for use with
INVITE, and
so
should be considered to be part of an invite-dialog-usage.
And Robert
specified it that way in the dialogusage draft.
You're correct. I had forgotten about that, and the dialogusage
draft
does make it clear: INFO is part of the INVITE usage. RFC
2976 predates
the current terminology, but a quick re-read does show
that it's
pretty clearly appropriate only for INVITE usages.
/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
_______________________________________________
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
