Subject: Re: [Sip] INFO

From: Eric Burger <[email-masked]>
Date: Thu, 11 Oct 2007 17:34:53 -0400

Right: "DTMF may not be the only information users want to send to each
other during a session."  This is why one MUST establish multiple
subscription dialogs.  How else would one keep track of the different
elements / local routing decisions?  If you are proposing application
routing a'la P-Asserted-Service...

On 9/11/07 2:30 AM, "Christer Holmberg (JO/LMF)"
<[email-masked]> wrote:

> 
> 
> Hi,
> 
> Let's also keep in mind that DTMF may not be the only information users
> want to send to each other during a session. So, you will need to
> establish subscription dialogs for every type of event that the users
> may want to send during the session...
> 
> Regards,
> 
> Christer
> 
>> -----Original Message-----
>> From: Christer Holmberg (JO/LMF)
>> [mailto:[email-masked]]
>> Sent: 11. syyskuuta 2007 12:27
>> To: Hadriel Kaplan; Eric Burger
>> Cc: sip
>> Subject: RE: [Sip] INFO
>> 
>> 
>> Hi,
>> 
>>>> Consider a PSTN call.  The call goes from the gateway to
>> softswitch /
>>>> Proxy.  Proxy routes to VM App Server.  INFO has to pass through
>>>> softswitch / Proxy.
>>>> In KPML-land, VM App Server *directly* subscribes to UAC key press
>> state, bypassing the softswitch.
>> 
>> [Christer] As I've said before, there are environments where some
>> proxies must (for whatever reason) be passed through. I guess an
>> outbound proxy is a good example.
>> 
>>>> KPML and INFO have the same number of messages for a SINGLE digit;
>> KPML wins
>>>> hands-down for multiple digits or reports.
>>> 
>>> Not exactly - for a single digit, KPML would generate a
>>> Subscribe/200/Notify/200 before the single DTMF was even
>>> pressed - before the actual Notify with the digits in it.
>>> And of course there is now also a subscribe dialog involved.
>>> Assuming a one-shot single digit type, then, we're talking 6
>>> SIP messages for KPML vs. 2 for Info.
>> 
>> [Christer] And, in cases where you need to send DTMFs (or whatever
>> information) in both directions you actually need 2
>> subscription dialogs
>> - one in each direction, and maintaining dialog state also consumes
>> resources. And, in some cases you may not even know whether you will
>> ever have to use the dialog.
>> 
>> 
>>>> More importantly, let's take a Call Management (CM)
>> application that
>>>> calls a VM application when they cannot find the
>> subscriber.  INFO has
>> 
>>>> to pass through the softswitch / Proxy to the CM
>> application.  Cool -
>>>> it is a proxy, so it knows to relay.  But OOPS!  The CM application
>>>> has to proxy the INFOs to the VM application.  Yes - you could be a
>>>> good programmer and remember to do that EVERYWHERE you place an
>>>> outbound call, but it is really easy to get wrong.
>>> 
>>> I'm not sure I understand the scenario.  The VM learned about
>>> this call how?
>>> By being in the signaling path, no?  So why wouldn't the CM
>>> forward INFO along the path? (I mean it is in the same
>>> dialog, after all)  Now I don't doubt it could screw that up,
>>> and eat the info thinking it was for itself, but lots of
>>> things can get screwed up - my guess is KPML will not be
>>> impervious to screw ups.
>> 
>> [Christer] I also have problems understanding the scenario. INFO is
>> routed to wherever the INVITE that initiated the dialog was routed...
>> 
>> 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-masked] for questions on current sip
>> Use [email-masked] for new developments on the application of sip
>> 
> 

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 12 Oct 2007 04:38:06 +0200

Hi Eric,

I am not sure I understand what you mean, but INFOs are routed according
to the route set of the invite dialog they are sent within.

If you want to transport information using some other path you can of
course not send the information within the invite dialog.

Regards,

Christer

> From: Eric Burger [mailto:[email-masked]] 
> Sent: 12. lokakuuta 2007 0:35
> To: Christer Holmberg; Hadriel Kaplan
> Cc: sip
> Subject: Re: [Sip] INFO
> 
> Right: "DTMF may not be the only information users want to 
> send to each other during a session."  This is why one MUST 
> establish multiple subscription dialogs.  How else would one 
> keep track of the different elements / local routing 
> decisions?  If you are proposing application routing a'la 
> P-Asserted-Service...
> 
> 
> > Let's also keep in mind that DTMF may not be the only information 
> > users want to send to each other during a session. So, you 
> will need 
> > to establish subscription dialogs for every type of event that the 
> > users may want to send during the session...
> > 
> > Regards,
> > 
> > Christer
> > 
> pressed - 
> >>> before the actual Notify with the digits in it.
> >>> Assuming a one-shot single digit type, then, we're talking 6 SIP 
> >>> messages for KPML vs. 2 for Info.
> >> 
> >> information) in both directions you actually need 2 subscription 
> >> dialogs
> >>> I'm not sure I understand the scenario.  The VM learned 
> about this 
> >>> call how?
> >>> By being in the signaling path, no?  So why wouldn't the 
> CM forward 
> >>> INFO along the path? (I mean it is in the same dialog, 
> after all)  
> >>> Now I don't doubt it could screw that up, and eat the 
> info thinking 
> >>> it was for itself, but lots of things can get screwed up 
> - my guess 
> >>> is KPML will not be impervious to screw ups.
> >> 
> >> This list is for NEW development of the core SIP Protocol Use 
> >> [email-masked] for questions on current sip Use 
> >> [email-masked] for new developments on the application of sip
> >> 
> > 
> 
> 
> 
> Notice:  This email message, together with any attachments, 
> may contain information  of  BEA Systems,  Inc.,  its 
> subsidiaries  and  affiliated entities,  that may be 
> confidential,  proprietary,  copyrighted  and/or legally 
> privileged, and is intended solely for the use of the 
> individual or entity named in this message. If you are not 
> the intended recipient, and have received this message in 
> error, please immediately return this by email and then delete it.
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 12 Oct 2007 04:38:06 +0200

Hi Eric,

Regards,

Christer

---

From: Dean Willis <[email-masked]>
Date: Mon, 15 Oct 2007 13:04:25 -0500

> routing a'la P-Asserted-Service...

One of the arguments for INFO is that it happens in a dialog, not a  
session. That is, even if you have multiple event streams, they  
happen on the same dialog.

The trick is demuxing the event streams, or in other words, figuring  
out the context for each event. INFO currently gives us nothing but  
the content- modifiers to figure this out. That's not enough, as has  
widely been argued.

Francois proposed using an event wrapper within the dialog This does  
give us a bigger handle for demuxing. For example, we could  
reasonably demux jpegs which are snapshots from the built-in camera  
from jpegs that are intended as keypad overlays or HTML imagemaps.  
Might could have done that with content-disposition too, so it's an  
imperfect example.

Is the event class enough of a differentiator? For example, we  
probably wouldn't be able to differentiate two different DTMF sources  
being routed to different applications within a single dialog. I  
suspect that's an acceptable limitation, at lest for the sorts of  
applications that seem to attract INFO use.

--
Dean

---

From: "Brian Stucker" <[email-masked]>
Date: Mon, 15 Oct 2007 13:26:44 -0500

> From: Dean Willis [mailto:[email-masked]] 
> > Right: "DTMF may not be the only information users want to send to 
> > each other during a session."  This is why one MUST 
> establish multiple 
> One of the arguments for INFO is that it happens in a dialog, 
> not a session. That is, even if you have multiple event 
> streams, they happen on the same dialog.
> 
> The trick is demuxing the event streams, or in other words, 
> figuring out the context for each event. INFO currently gives 
> us nothing but the content- modifiers to figure this out. 
> That's not enough, as has widely been argued.

How does 3265 make this any better?

We're talking about identifying a data blob using an event plus a
content-type instead of a supported plus a content-type for a period of
time to start and end in conjunction with the INVITE dialog (so the
subsciption-state header is mooted).

So a NOTIFY with an event header or an INFO without an event header, all
other things being the same and the constrained semantics of the NOTIFY
usage being put forward here... 

Wouldn't it be equally valid to simply allow the INFO message to carry
an event header and say that INFO is the same as a NOTIFY with an
implicit subscription to an INVITE dialog? Isn't this pretty much what
it does already (minus the event header).

Deep thought: Is all INFO is missing is simply the event header?

Regards,
Brian

---

From: Dean Willis <[email-masked]>
Date: Tue, 16 Oct 2007 16:18:32 -0500

> subsciption-state header is mooted).

3265 makes it better in two ways:

1) It provides distinct dialogs for each channel of the mux. Thus,  
two events of the same class, but related to different subscriptions,  
can be distinguished.

2) It provides semantic distinction, such that two events that  
transport the same kind of content but that have different effects on  
the application can be distinguished.

The provide NOTIFY-over-an-INVITE dialog loses advantage 1, but  
retains 2. The argument is that this makes it good enough for some  
applications. However, there are obviously applications where it  
might NOT be good enough, and a separate dialog ala 3265 would be  
required.

> it does already (minus the event header).

There needs to be an explicit declaration of willingness to receive  
the semantic load indicated by the event package. Given that, one  
could certainly envision revising INFO to do the job.

> Deep thought: Is all INFO is missing is simply the event header?

Yes. The problem is that INVITE and 200 (OK) are missing the  
"subscribe" header.

--
Dean

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 16 Oct 2007 23:33:35 +0200

Hi, 

>>>the content- modifiers to figure this out.
>>content-type instead of a supported plus a content-type for a period 
>>of time to start and end in conjunction with the INVITE dialog (so the

>1) It provides distinct dialogs for each channel of the mux. 
>Thus, two events of the same class, but related to different 
>subscriptions, can be distinguished.
> 
>2) It provides semantic distinction, such that two events 
>that transport the same kind of content but that have 
>different effects on the application can be distinguished.
> 
>The provide NOTIFY-over-an-INVITE dialog loses advantage 1, 
>but retains 2. The argument is that this makes it good enough 
>for some applications. However, there are obviously 
>applications where it might NOT be good enough, and a 
>separate dialog ala 3265 would be required.

I don't think anyone has proposed to forbid using separate dialogs.

And, eventhough the receiver may be able to dispatch the event to the
correct application, the sender may still have to send it on each
subscription (if it doesn't know which application is associated with
each subscription), so the result would be the same as using INFO.

But, these are the kind of things we would need to document. What are
the issues, limitations etc with different solutions. Then let's the
implementors use what they need.

>>So a NOTIFY with an event header or an INFO without an event header, 
>>all other things being the same and the constrained 
>>semantics of the 
>>NOTIFY usage being put forward here...
>>

>There needs to be an explicit declaration of willingness to 
>receive the semantic load indicated by the event package. 
>Given that, one could certainly envision revising INFO to do the job.
> 

All we need is draft-subscribe-header-for-invite... :)

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 16 Oct 2007 19:08:06 -0400

> All we need is draft-subscribe-header-for-invite... :)

THis of course is predicated on the assumption that the same two parties 
are the right ones to be involved in the subscription and the invite. 
This works out ok for DTMF. It remains to be seen where else it is valid.

It might seem that it would be valid for the dialog event package. But 
it might not be if the goal is to get consolidated event state for all 
UASs of the same AOR. Its far from clear that the subscriber would know. 
So there probably at least needs to be some way to accept the INVITE but 
reject the bundled subscription. And in that case the caller needs to 
move to "plan B".

The "bundled subscriptions" need to be negotiated in both directions. 
That means something like:

INVITE must contain:
- these are the events I am willing to send
- these are the events I desire to receive

response must contain:
- these are the events I will send (subset from invite)
- these are the events you should send (subset from invite)

Note that probably excludes events that take various combinations of 
parameters, and subscriptions that require filters. (Though both of 
these could probably be required by adding enough complexity.)

	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 16 Oct 2007 21:59:00 -0400

> might NOT be good enough, and a separate dialog ala 3265 would be

Actually, I'd argue the converse as well: there are applications where "advantage 1" is a disadvantage, or at least potentially confusing.  DTMF is a primary example of this.  If two app servers kpml subscribe to my Invite dialog, I will send them both the dtmf event, assuming the regex works out.  Which one should act on it?  They both will.  Neither knows about the other.  (although I should note I don't think supporting two kpml subscriptions is even required by rfc4730, which makes it even less deterministic, and gives up "advantage 1" anyway)

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Tue, 16 Oct 2007 21:05:28 -0500

On Oct 16, 2007, at 6:08 PM, Paul Kyzivat wrote:

> The "bundled subscriptions" need to be negotiated in both  
> directions. That means something like:
>
> INVITE must contain:

Do we need that first line ? Or do we just need "These are the events  
I'm willing to receive. If I get them, great. If I don't, well, I  
don't care, I'll assume that sending them wasn't important to you."

> - these are the events I will send (subset from invite)

Same here. I don't think the receiver needs to know what events will  
be sent. They already know that any events that will be sent will be  
a subset of the events they've said they're ready to handle.

> - these are the events you should send (subset from invite)

Let's take for example DTMF. If you tell me you can receive DTMF  
events, I might send you some. If you don't, I won't send you any. If  
you tell me you can receive DTMF events and I don't send any, do you  
care whether it's because I don't know how or because I don't have  
any to send you?

Is there a use case for turning this into a full bidirectional offer- 
answer? If so, it's starting to sound a lot more like an event-media  
session (described in SDP and negotiated  by offer-answer) than what  
I'm thinking would be appropriate for INVITE-bounded notification. Or  
maybe its should be a pair of SUBSCRIBE-bounded opposing dialogs.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 17 Oct 2007 00:31:18 -0400

inline

Dean Willis wrote:
> I'm willing to receive. If I get them, great. If I don't, well, I don't 
> care, I'll assume that sending them wasn't important to you."

I think the first line is needed, so that the UAS will know whether it 
will be getting what it wants this way. It needs to know that so it 
doesn't fall back to "plan B" - generating an explicit subscription.

> Same here. I don't think the receiver needs to know what events will be 
> sent. They already know that any events that will be sent will be a 
> subset of the events they've said they're ready to handle.

Same answer here. If I want DTMF, I might prefer to get it this way, but 
if that doesn't work out I will then probably send an explicit 
subscription for it.

	Paul

> Let's take for example DTMF. If you tell me you can receive DTMF events, 
> I might send you some. If you don't, I won't send you any. If you tell 
> me you can receive DTMF events and I don't send any, do you care whether 
> it's because I don't know how or because I don't have any to send you?
> 
> 
> Is there a use case for turning this into a full bidirectional 
> offer-answer? If so, it's starting to sound a lot more like an 
> event-media session (described in SDP and negotiated  by offer-answer) 
> than what I'm thinking would be appropriate for INVITE-bounded 
> notification. Or maybe its should be a pair of SUBSCRIBE-bounded 
> opposing dialogs.
> 
> -- 
> Dean
> 
> 
> 
> 
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 17 Oct 2007 09:06:53 +0200

Hi, 

>THis of course is predicated on the assumption that the same 
>two parties are the right ones to be involved in the 
>subscription and the invite. 
>It might seem that it would be valid for the dialog event 
>package. But it might not be if the goal is to get 
>consolidated event state for all UASs of the same AOR. Its 
>far from clear that the subscriber would know. 
>So there probably at least needs to be some way to accept the 
>INVITE but reject the bundled subscription. And in that case 
>the caller needs to move to "plan B".
> 

Maybe we could re-use the SDP direction attributes (sendrecv, sendonly,
recvonly) for this?

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 17 Oct 2007 08:41:43 -0400

> Maybe we could re-use the SDP direction attributes (sendrecv, sendonly,

Are you serious? Or have you been smoking something? :-)

Certainly you can use the SDP direction attributes if you want to 
establish media sessions for this event signaling. But AFAIK the point 
here is to negotiate the use of signaling in the sip session itself.

	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 17 Oct 2007 14:50:01 +0200

Hi, 

>Are you serious? Or have you been smoking something? :-)

Sometimes I think that would help in these discussions :)

>Certainly you can use the SDP direction attributes if you 
>want to establish media sessions for this event signaling. 
>But AFAIK the point here is to negotiate the use of signaling 
>in the sip session itself.

I guess I should have been more clear. I didn't mean that we start using
SDP for this, but that we could use something SIMILAR to the direction
attributes - but in the form of some SIP header parameters.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 17 Oct 2007 09:23:53 -0400

> attributes - but in the form of some SIP header parameters.

Oh - thats not quite so crazy.

Yes, I suppose something like that could be done. But given how much 
confusion that seems to have caused with SDP, I would certainly think 
twice before using it again.

Note that this will need to be more than a one-time negotiation. Its 
possible that the agreement will need to be renegotiated in mid-call. 
(This comes up at least in 3pcc scenarios, where a device in the middle 
is performing a transfer without the knowledge of the other side.)

	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 17 Oct 2007 15:41:44 +0200

Hi, 

>>>>>The "bundled subscriptions" need to be negotiated in both
directions.
>>>> Maybe we could re-use the SDP direction attributes (sendrecv, 
>>>> sendonly, recvonly) for this?
>>>establish media sessions for this event signaling.
>>>But AFAIK the point here is to negotiate the use of signaling in the 
>>>sip session itself.
>> 
>>I guess I should have been more clear. I didn't mean that we start 
>>using SDP for this, but that we could use something SIMILAR to the 
>>direction attributes - but in the form of some SIP header 
>>parameters.
> 
>Yes, I suppose something like that could be done. But given 
>how much confusion that seems to have caused with SDP, I 
>would certainly think twice before using it again.
> 
>Note that this will need to be more than a one-time 
>negotiation. Its possible that the agreement will need to be 
>renegotiated in mid-call. 
>(This comes up at least in 3pcc scenarios, where a device in 
>the middle is performing a transfer without the knowledge of 
>the other side.)

I agree. I guess there could also be needs to add/remove "event
subscriptions" (or whatever we would call it) during the call, so...

Regards,

Christer

---

From: "Sumit Garg" <[email-masked]>
Date: Wed, 17 Oct 2007 09:43:55 -0400

Another approach to avoid unnecessarily long bodies: (this would be more
on lines of offer-answer)
INVITE- these are events A desires to receive.

1st reliable response (provisional/200OK) from B:
      - this is the subset of events (from the offer from A) which can
be provided by B.
      - this is the set of events B desires from A.

ACK/PRACK:
      - this is the subset of events (from the offer from B) which can
be provided by A.

Wouldn't the best approach be to supersede the INFO RFC with one which
takes care of issues, i.e. with these additional headers.
We can't get people to change the old implementations, but at least the
for new usages if the additional work required is a smaller delta (from
base INFO, as compared to having to implement SUBSCRIBE/NOTIFY), they
might be more amenable to use the new EVENT based INFO mechanism.

-Sumit

"The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all progress
depends on the unreasonable man."
-- George Bernard Shaw

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Wednesday, October 17, 2007 9:24 AM
To: Christer Holmberg
Cc: sip; Francois Audet; Brian Stucker; Dean Willis
Subject: Re: [Sip] INFO

directions.
> direction attributes - but in the form of some SIP header parameters.

	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 17 Oct 2007 10:39:39 -0400

> Sent: Tuesday, October 16, 2007 10:05 PM
> To: Paul Kyzivat
> Cc: sip; Francois Audet; Brian Stucker; Christer Holmberg
> Subject: Re: [Sip] INFO
>
>

But that's not always the case with dtmf.  If a softphone makes a call, would the softphone always care to receive DTMF?  Not all of them would.  But they would want to tell the far-end they can _send_ DTMF.  Not that I think this means we need a send/receive distinction - I think just a "I support dtmf-info" semantic is good enough for dtmf.

> answer?

I guess the question is if it matters that a UA which can only send event foo but can't do anything useful receiving foo, could be sent foo anyway.  For example, suppose we created an event-package for a jpeg picture, for remote-party call display.  If a hard-phone has no LCD to display a picture, but has a stored jpeg to give to the far-end, would it matter if it can't say "I can send a jpeg but don't want to receive one"?  Obviously it could just accept a received one (ie, 200 ok the INFO) and discard the jpeg.  But is that the right thing to do?  I dunno.  We could just leave the concept up to specific info-event-package definitions to handle - i.e., make an event-package define send vs. receive event-packages pairs if it cares about it.

-hadriel

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 17 Oct 2007 10:18:24 -0500

I think the recv/send/sendrecv approach that Christer was proposing
addresses this. 

> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: Wednesday, October 17, 2007 07:40
> To: Dean Willis; Paul Kyzivat
> Cc: sip; Audet, Francois (SC100:3055); Stucker, Brian 
> (RICH1:AR00); Christer Holmberg
> Subject: RE: [Sip] INFO
> 
> 
> But that's not always the case with dtmf.  If a softphone 
> makes a call, would the softphone always care to receive 
> DTMF?  Not all of them would.  But they would want to tell 
> the far-end they can _send_ DTMF.  Not that I think this 
> means we need a send/receive distinction - I think just a "I 
> support dtmf-info" semantic is good enough for dtmf.
> 
> 
> I guess the question is if it matters that a UA which can 
> only send event foo but can't do anything useful receiving 
> foo, could be sent foo anyway.  For example, suppose we 
> created an event-package for a jpeg picture, for remote-party 
> call display.  If a hard-phone has no LCD to display a 
> picture, but has a stored jpeg to give to the far-end, would 
> it matter if it can't say "I can send a jpeg but don't want 
> to receive one"?  Obviously it could just accept a received 
> one (ie, 200 ok the INFO) and discard the jpeg.  But is that 
> the right thing to do?  I dunno.  We could just leave the 
> concept up to specific info-event-package definitions to 
> handle - i.e., make an event-package define send vs. receive 
> event-packages pairs if it cares about it.
> 
> -hadriel
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 17 Oct 2007 12:17:21 -0400

>       - this is the subset of events (from the offer from B) which can

That would work. I find it slightly more attractive than the 
sendrecv/sendonly/recvonly/inactive approach, though both are roughly 
equivalent in power.

> might be more amenable to use the new EVENT based INFO mechanism.

Frankly, I think what we are discussing would be better applied using 
NOTIFY in the INVITE dialog. We would then be devising a new means to 
negotiate event packages that will share the invite dialog, but using 
the same NOTIFY messages to carry the data, not INFO.

	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 17 Oct 2007 12:51:47 -0400

Yes, but Dean is asking if we even need the concept of a recv/send/sendrecv.  You would need to specify recv/send/sendrecv for each info-event-package.
The question is: is it necessary for a general info-event-package negotiation mechanism?

-hadriel

> From: Francois Audet [mailto:[email-masked]]
> Sent: Wednesday, October 17, 2007 11:18 AM
> To: Hadriel Kaplan; Dean Willis; Paul Kyzivat
> Cc: sip; Brian Stucker; Christer Holmberg
> Subject: RE: [Sip] INFO
>

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 17 Oct 2007 17:49:16 +0100

> Sent: 17 October 2007 17:17
> To: Sumit Garg
> Cc: sip; Francois Audet; Brian Stucker; Dean Willis; Christer Holmberg
> Subject: Re: [Sip] INFO
> 
> 
> 
> Sumit Garg wrote:
[JRE] A down side is that for mid-dialog changes it requires re-INVITE,
rather than UPDATE.

John

---

From: Dean Willis <[email-masked]>
Date: Wed, 17 Oct 2007 11:57:36 -0500

On Oct 17, 2007, at 9:39 AM, Hadriel Kaplan wrote:

> But that's not always the case with dtmf.  If a softphone makes a  
> call, would the softphone always care to receive DTMF?  Not all of  
> them would.  But they would want to tell the far-end they can  
> _send_ DTMF.  Not that I think this means we need a send/receive  
> distinction - I think just a "I support dtmf-info" semantic is good  
> enough for dtmf.

I think we need two different approaches here.

There is a big difference between "I could deal with X should you  
want to send it" and "I NEED you to send me X" or "I want to know if  
you intend to send me X".

The first is a simple declarative, along the lines of what we do with  
Supported and Allow. The latter two are more directive, something  
like what we do with a Require.

Otherwise said, there's a difference between "I support" and "I will  
use" or "Will you use?".

> I guess the question is if it matters that a UA which can only send  
> event foo but can't do anything useful receiving foo, could be sent  
> foo anyway.  For example, suppose we created an event-package for a  
> jpeg picture, for remote-party call display.  If a hard-phone has  
> no LCD to display a picture, but has a stored jpeg to give to the  
> far-end, would it matter if it can't say "I can send a jpeg but  
> don't want to receive one"?  Obviously it could just accept a  
> received one (ie, 200 ok the INFO) and discard the jpeg.  But is  
> that the right thing to do?  I dunno.  We could just leave the  
> concept up to specific info-event-package definitions to handle -  
> i.e., make an event-package define send vs. receive event-packages  
> pairs if it cares about it.

I suspect that things that need two way send-receive negotiation need  
to use full subscriptions. Actually, they may need to use full  
subscriptions in each direction.

But let's play with this negotiation a minute.

Suppose instead of having a single header field for "all the events- 
in-invite-dialogs we know about", we have two header fields: one for  
events we are willing to receive, and another for events we are  
offering to send. Those two sets might not match for a given device,  
but they would need to reduce down to pairwise matches after the  
offer-answer phase, so that neither end would be intending to send  
something the other hadn't indicated a willingness to receive.

So, for example. Alice might INVITE Gateway, saying "I understand  
keymap and image-display events and may send you keypad events", and  
gateway might answer in the 200 OK "I understand keypad events and  
may send you keymap events" (note that gateway is NOT offering to  
send image-display events) . Alice might then echo (in ACK) "We agree  
that I may send you keypad events and that you may send me keymap  
events".

Or, as you suggested, we could define directional event packages and  
use a single header field.

Alice might INVITE Gateway, saying "I'm offering to use send-keypad  
and receive-keymap and receive-image-display events". Gateway  
responds with "I will support receive-keypad and send-keymap  
events" (note it didn't include send-image-display). Alice then ACKS  
with "I understand I will be doing send-keypad and receive-keymap".

The two are functionally equivalent, I think we just have a syntax  
question. I suspect that the two-header approach is easier to parse.

But a broader question is lurking here . . .

How is this not just an example of a more general feature or  
capability negotiation mechanism? If instead of "event packages" we  
talk about "features", where a feature might be "send event X",  
"receive event X", or perhaps something broader like "transition to a  
DOOM game"? Could we use it to discover a peers screen resolution,  
keyboard layout, or access network bandwidth? Could we do the same  
media-channel O/A that we do in SDP? I believe the answer is "yes",  
but it requires a registry process for each of the "features", much  
as we currently have a registry process for event packages. Do we  
want to go in this direction? If not, where do we draw the line? And  
just exactly how does this relate to RFC 3840/3841 preferences and  
capabilities negotiation (which, I might add, don't really work in a  
proxyless world).

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 17 Oct 2007 13:40:20 -0400

We don't need all these nuances - just a few. It isn't important to say 
"I could deal with X if you sent it but I don't want you to send it."

There are two paradigms already used in sip, and discussed here, and 
either could be used:

1) X tells Y: I would like you to send A,B,C
    Y tells X: I will send you B,C; I would like you to send B,C,D,E
    X tells Y: Please send B,E

2) X tells Y: I can send A,B,C; want to receive B,C,D,E
    Y tells X: I will send you B,C; Please send me B,E

The use of the directionality attributes is an encoding of (2):

2b) X tells Y: sendonly(A), sendrecv(B,C), recvonly(D,E)
     Y tells X: inactive(A,D), sendrecv(B), sendonly(C), recvonly(E)

	Paul

Dean Willis wrote:
>> them would.  But they would want to tell the far-end they can _send_ 
>> DTMF.  Not that I think this means we need a send/receive distinction 
>> - I think just a "I support dtmf-info" semantic is good enough for dtmf.
> 
> There is a big difference between "I could deal with X should you want 
> to send it" and "I NEED you to send me X" or "I want to know if you 
> intend to send me X".
> 
> Supported and Allow. The latter two are more directive, something like 
> what we do with a Require.
> 
>> jpeg picture, for remote-party call display.  If a hard-phone has no 
>> LCD to display a picture, but has a stored jpeg to give to the 
>> far-end, would it matter if it can't say "I can send a jpeg but don't 
>> want to receive one"?  Obviously it could just accept a received one 
>> (ie, 200 ok the INFO) and discard the jpeg.  But is that the right 
>> thing to do?  I dunno.  We could just leave the concept up to specific 
>> info-event-package definitions to handle - i.e., make an event-package 
>> define send vs. receive event-packages pairs if it cares about it.
> 
> I suspect that things that need two way send-receive negotiation need to 
> use full subscriptions. Actually, they may need to use full 
> Suppose instead of having a single header field for "all the 
> events-in-invite-dialogs we know about", we have two header fields: one 
> for events we are willing to receive, and another for events we are 
> offering to send. Those two sets might not match for a given device, but 
> they would need to reduce down to pairwise matches after the 
> So, for example. Alice might INVITE Gateway, saying "I understand keymap 
> and image-display events and may send you keypad events", and gateway 
> might answer in the 200 OK "I understand keypad events and may send you 
> keymap events" (note that gateway is NOT offering to send image-display 
> events) . Alice might then echo (in ACK) "We agree that I may send you 
> keypad events and that you may send me keymap events".
> 
> Or, as you suggested, we could define directional event packages and use 
> a single header field.
> 
> Alice might INVITE Gateway, saying "I'm offering to use send-keypad and 
> receive-keymap and receive-image-display events". Gateway responds with 
> "I will support receive-keypad and send-keymap events" (note it didn't 
> include send-image-display). Alice then ACKS with "I understand I will 
> be doing send-keypad and receive-keymap".
> 
> How is this not just an example of a more general feature or capability 
> negotiation mechanism? If instead of "event packages" we talk about 
> "features", where a feature might be "send event X", "receive event X", 
> or perhaps something broader like "transition to a DOOM game"? Could we 
> use it to discover a peers screen resolution, keyboard layout, or access 
> network bandwidth? Could we do the same media-channel O/A that we do in 
> SDP? I believe the answer is "yes", but it requires a registry process 
> for each of the "features", much as we currently have a registry process 
> for event packages. Do we want to go in this direction? If not, where do 
> we draw the line? And just exactly how does this relate to RFC 3840/3841 
> preferences and capabilities negotiation (which, I might add, don't 
> really work in a proxyless world).
> 
> -- 
> Dean
>

---

From: "Brian Stucker" <[email-masked]>
Date: Wed, 17 Oct 2007 12:50:32 -0500

> From: Christer Holmberg [mailto:[email-masked]] 
> Sent: Tuesday, October 16, 2007 4:34 PM
> To: Dean Willis; Stucker, Brian (RICH1:AR00)
> Cc: Eric Burger; sip; Audet, Francois (SC100:3055); Hadriel Kaplan
> Subject: RE: [Sip] INFO
> 
> 
> Hi, 
> 
> but retains 
> >2. The argument is that this makes it good enough for some 
> >applications. However, there are obviously applications 
> where it might 
> >NOT be good enough, and a separate dialog ala 3265 would be required.
> 
> And, eventhough the receiver may be able to dispatch the 
> event to the correct application, the sender may still have 
> to send it on each subscription (if it doesn't know which 
> application is associated with each subscription), so the 
> result would be the same as using INFO.
> 
> But, these are the kind of things we would need to document. 
> What are the issues, limitations etc with different 
> solutions. Then let's the implementors use what they need.
> 

And/or event header for INFO. Or perhaps not, but at least it's clearer
(to me) what's missing now.

---

From: Spencer Dawkins <[email-masked]>
Date: Wed, 17 Oct 2007 15:46:02 -0500

> the same NOTIFY messages to carry the data, not INFO.

FWIW, I agree with Paul here. 

Thanks,

Spencer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 17 Oct 2007 17:18:06 -0400

As a swag for how to encode this in actual headers, how about:

INVITE ...
Exchange-Events: dtmf;sendrecv, foo;sendonly;
                  bar;recvonly; xyzzy;sendrecv

200 OK
Exchange-Events: dtmf;recvonly, foo;recvonly;
                  bar:sendonly; xyzzy:inactive

Each event type named in Exchange-Events in the INVITE is a candidate 
for use with the directionality specified by the direction parameter. 
Event types not listed implicitly have a direction of "inactive". Event 
types listed without a direction are implicitly sendrecv.

The Exchange-Events in the response defines which event types will 
actually be exchanged, and the direction(s) they will be sent. Default 
directions are the same as above. The valid directions in the response 
are constrained by what was in the request in the same way as in sdp.

One agreed upon, NOTIFY may be sent in the agreed upon direction(s) 
within the INVITE dialog usage. Whether an initial NOTIFY is required 
will be determined on a per-event-package basis. (Its not needed to 
establish the dialog, so its a matter if it is semantically needed in 
the context of the event type.)

Just as there are INVITEs that don't offer SDP (because they don't know 
what to offer) there is a need for INVITEs that don't offer events. An 
INVITE that contains no Exchange-Events header is not offering any. In 
that case the offer of events is in a reliable response and the final 
answer about what events will be used is in the ACK or PRACK. (To 
indicate that you don't desire to exchange any events, include a 
Exchange-Events header with no events listed.)

There is no separate subscription or timer. The dialog usage is 
refreshed by INVITE or UPDATE in the conventional manner. Events to be 
exchanged are renegotiated from scratch with every reINVITE or UPDATE.

If an event type takes parameters, they can be included in 
Exchange-Events. That can work in some simple cases, but not in complex 
cases. I think event types that need complex parameters will be 
problematic in this usage. (Note that the kpml package only requires 
parameters to identify the dialog. In this usage those won't be needed.)

There is a problem if the event type may (or must) use a body in the 
subscribe. The kpml package falls into this category. :-(
The body could simply be included in the message carrying the 
Exchange-Events header. But that potentially means a bunch of body parts 
with the recipient having the problem of deciding how each part should 
be matched to a particular event type. That is more or less the same 
problem we are trying to solve here, so its not good. Also, it would 
seem that every time you send a reinvite or update you might have to 
send these again.

One alternative is simply to say that this mechanism cannot be used with 
event packages that require a subscribe body. That seems to exclude the 
use of KPML. :-(

	Paul

Paul Kyzivat wrote:
>>> thing to do?  I dunno.  We could just leave the concept up to 
>>> specific info-event-package definitions to handle - i.e., make an 
>>> event-package define send vs. receive event-packages pairs if it 
>>> cares about it.
>>
>> events-in-invite-dialogs we know about", we have two header fields: 
>> one for events we are willing to receive, and another for events we 
>> are offering to send. Those two sets might not match for a given 
>> device, but they would need to reduce down to pairwise matches after 
>> the offer-answer phase, so that neither end would be intending to send 
>> gateway might answer in the 200 OK "I understand keypad events and may 
>> send you keymap events" (note that gateway is NOT offering to send 
>> image-display events) . Alice might then echo (in ACK) "We agree that 
>> I may send you keypad events and that you may send me keymap events".
>>
>> and receive-keymap and receive-image-display events". Gateway responds 
>> with "I will support receive-keypad and send-keymap events" (note it 
>> didn't include send-image-display). Alice then ACKS with "I understand 
>> I will be doing send-keypad and receive-keymap".
>>
>> but it requires a registry process for each of the "features", much as 
>> we currently have a registry process for event packages. Do we want to 
>> go in this direction? If not, where do we draw the line? And just 
>> exactly how does this relate to RFC 3840/3841 preferences and

---

From: Dean Willis <[email-masked]>
Date: Wed, 17 Oct 2007 17:25:07 -0500

>                  bar:sendonly; xyzzy:inactive

It's more concise to have:

INVITE ...
Send-Events: dtmf, foo, xyzzy
Recv-Events: dtmf, bar, xyzzy

200 OK ...
Send-Events: bar
Recv-Events: dtmf, foo

ACK ...
Send-Events: dtmf, foo
Recv Events: bar

Do we need to encode in 200 OK that xyyyz was offered and rejected,  
or is just not including it in the 200 OK enough?

I think that if you offer to send it, and I don't offer to receive  
it, then we know we aren't using it.

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 17 Oct 2007 18:54:29 -0400

Why does there need to be a 3-way exchange?
Can the 200-ok have Events listed that weren't offered? (why would it bother to?  The offerer didn't say it could do them.)
So isn't the ACK always a mirror image of the 200ok, in which case why bother?
Unless you had competing Event types, where only one should be used, or couldn't do some combo of them.  And then this concept is getting bloated, and will end up looking like SDP capabilities negotiation.

And I'm still stuck on your last question, which is what application use-case really needs directionality, other than as a nit?

-hadriel

> Sent: Wednesday, October 17, 2007 6:25 PM
> To: Paul Kyzivat
> Cc: sip; Francois Audet; Christer Holmberg; Brian Stucker
> Subject: Re: [Sip] INFO
>
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 17 Oct 2007 21:38:55 -0400

Howdy,
Inline comments, but also: this seems like going down the road of complexity again.  One of the reasons I think people use INFO-dtmf instead of KPML is it's so darn simple/easy.  If we want people to change their implementations to support negotiation and explicit content context indication, it should be as trivial as possible, IMHO.  No bells, no whistles.

> Exchange-Events header with no events listed.)

Why do this?  What use case is there for not saying what you can do in the Invite?  Offer-less Invites cause enough problems.  We shouldn't repeat them.

> seem that every time you send a reinvite or update you might have to

Ya that's bad.  If someone wants to define an info-event that needs such things, they can define it to exchange it in an INFO when they do.

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Thu, 18 Oct 2007 03:02:21 -0500

On Oct 17, 2007, at 5:54 PM, Hadriel Kaplan wrote:

> Can the 200-ok have Events listed that weren't offered? (why would  
> it bother to?  The offerer didn't say it could do them.)
> Unless you had competing Event types, where only one should be  
> used, or couldn't do some combo of them.  And then this concept is  
> getting bloated, and will end up looking like SDP capabilities  
> negotiation.
>

The only argument I can see is -- it prevents race conditions. Don't  
send an event until the ACK.

> And I'm still stuck on your last question, which is what  
> application use-case really needs directionality, other than as a nit?

Yeah, me too. Or to rephrase, what application needs "I want to  
send . . ." rather than "I understand . . ."

--
dean

---

From: "Michael Procter" <[email-masked]>
Date: Thu, 18 Oct 2007 02:33:05 -0700

> send an event until the ACK.

That sounds like the media clipping problem.  If the INVITE indicates
willingness to receive a specific event, then maybe it should be able to
do so before it has seen the 200 response.  Then the UAS needn't wait
for the ACK before sending events.

> send . . ." rather than "I understand . . ."

DTMF?  I noticed this problem with RFC2833 negotiation a couple of years
ago.  A device wanted to indicate willingness to send RFC2833, but
wasn't able to render received indications.  Since SDP describes what
the device can receive, the 'solution' was to fib.

Not necessarily something that needs to be supported, but a data point
from the field to be considered.

Regards,

Michael

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 18 Oct 2007 08:46:08 -0400

> Inline comments, but also: this seems like going down the road of complexity again.  One of the reasons I think people use INFO-dtmf instead of KPML is it's so darn simple/easy.  If we want people…

SIP is not simple. If you have mastered doing the rest of sip then this 
is not a burden. IMO people are more concerned with extra messages and 
extra state than they are with making it extra simple.

I do agree that things should be as simple as possible - but no simpler. 
Too often things are made "simple" at the expense of being inadequate 
for the real job. INFO is in fact an example of this.

More below.

> Why do this?  What use case is there for not saying what you can do in the Invite?  Offer-less Invites cause enough problems.  We shouldn't repeat them.

I know of lots of cases that can loosely be categorized as 3pcc where 
there is a B2BUA in the middle that initiates invites. It needs to learn 
the capabilities of one UA and then offer them to another. Because it is 
simply going to act as a signaling relay it doesn't have any preferences 
of its own about these things.

In general I have found that 3pcc is a good source of requirements that 
are otherwise often overlooked. Better to capture them up front than 
discover them later.

> Ya that's bad.  If someone wants to define an info-event that needs such things, they can define it to exchange it in an INFO when they do.

I'm hoping we don't have to define a whole new set of event packages. 
That is one of the reasons I would prefer to use an 
in-invite-dialog-usage NOTIFY than INFO for this. Ideally already 
existing event packages can then be used in this new way.

Maybe some of them will need some slight enhancement, but that would be 
better than having to define a whole new and parallel set.

Not only will that speed things up in the standardization process, but 
also it will simplify implementation and improve chances of support.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 18 Oct 2007 08:48:46 -0400

I think this problem can be solved with a 2-way exchange. Introducing a 
3-way exchange means that the "delayed offer" needed for 3pcc can't be 
supported in a straightforward way. IMO that is a strong argument 
against it.

	Paul

Dean Willis wrote:
>> Can the 200-ok have Events listed that weren't offered? (why would it 
>> bother to?  The offerer didn't say it could do them.)
>> Unless you had competing Event types, where only one should be used, 
>> or couldn't do some combo of them.  And then this concept is getting 
>> bloated, and will end up looking like SDP capabilities negotiation.
>>
> 
>> And I'm still stuck on your last question, which is what application 
>> use-case really needs directionality, other than as a nit?
> 
> Yeah, me too. Or to rephrase, what application needs "I want to send . . 
> ." rather than "I understand . . ."
> 
> 
> -- 
> dean
>

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 18 Oct 2007 14:08:09 +0100

Paul,

Yes, I agree. Your argument is a stronger one than the UPDATE argument I
put forward earlier.

John 

> Sent: 18 October 2007 13:49
> To: Dean Willis
> >> So isn't the ACK always a mirror image of the 200ok, in 
> which case why 
> >> bother?
> application

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 18 Oct 2007 10:31:19 -0400

> send an event until the ACK.

We could just define that no INFO (or NOTIFY if that be the method) can be sent until the ACK, regardless.  Like BYEs.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 18 Oct 2007 10:36:54 -0400

> On Oct 17, 2007, at 8:38 PM, Hadriel Kaplan wrote:
>
> > Ya that's bad.  If someone wants to define an info-event that needs
> > such things, they can define it to exchange it in an INFO when they
> > do.
> >
>
> The trick here is to split it into two events packages -- one that
> defines the input template, and another that generates key events
> within that template.

Sure, but the event package offered in the Invite only needs to be one.  And if someone were to actually go do this thing, you could define a parameter to indicate the attachment is the subscription information (vs. the event itself), so that there would need to be only one event name and other events could re-use the parameter instead of having to define 2 event names.  But that's getting ahead of ourselves anyway. ;)

> If the events in play change, I can't see NOT needing a reINVITE, or
> classicaly, new SUBSCRIBE requests.

Sure, Paul mentioned a re-Invite restarting the subscriptions, which seemed reasonable.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 18 Oct 2007 10:47:15 -0400

> From: Michael Procter [mailto:[email-masked]]
> Sent: Thursday, October 18, 2007 5:33 AM
> To: Dean Willis; Hadriel Kaplan
> Cc: sip; Paul Kyzivat; Brian Stucker; Francois Audet; Christer Holmberg
> Subject: RE: [Sip] INFO
>
> Dean Willis wrote:

Actually, I think it the other way - if there were no such thing as media before 200ok/ACK, there wouldn't be an early media problem.  So I think the INFO needs to wait for the ACK period, like BYE's do.

> the device can receive, the 'solution' was to fib.

Yeah, that was my first response to Dean's question (that DTMF has such a use-case), but "fibbing" about it isn't really harmful.  You may get extraneous INFO, which you just don't render. (just like for 2833)  The question is if the extra complexity of directionality is worth it or not, and is it necessary to provide in the general negotiation vs. in individual event packages.  In other words, if some event package got defined which really needed directionality, it could handle that itself with two event names.  But if it would be a common problem it's better for the general solution to handle it, IMO.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 18 Oct 2007 11:07:06 -0400

THe general case for event packages is that they are asymmetric 
(unidirectional). It seems to be the infrequent case where it makes 
sense to support an event in both directions. So making bidirectionality 
the default seems wrong.

	Paul

---

From: Dean Willis <[email-masked]>
Date: Thu, 18 Oct 2007 11:08:09 -0500

On Oct 18, 2007, at 9:47 AM, Hadriel Kaplan wrote:

> Yeah, that was my first response to Dean's question (that DTMF has  
> such a use-case), but "fibbing" about it isn't really harmful.  You  
> may get extraneous INFO, which you just don't render. (just like  
> for 2833)  The question is if the extra complexity of  
> directionality is worth it or not, and is it necessary to provide  
> in the general negotiation vs. in individual event packages.  In  
> other words, if some event package got defined which really needed  
> directionality, it could handle that itself with two event names.   
> But if it would be a common problem it's better for the general  
> solution to handle it, IMO.

I think my point has been missed. Why did the device need to indicate  
willingness to send 2833 tones? It can't send them unless the other  
side has indicated willingness to accept them. And, as pointed out,  
it doesn't have to be able to receive them to be able to send them.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 18 Oct 2007 11:12:26 -0500

On Oct 18, 2007, at 10:07 AM, Paul Kyzivat wrote:

> sense to support an event in both directions. So making  
> bidirectionality the default seems wrong.
>

I agree. I didn't mean to suggest bidirectionality. I'm suggesting  
that all that is really needed is the ability to indicate willingness  
to receive. Each end offers what it is willing to receive, without  
saying anything about what it can send. It chooses what to send based  
on its private knowledge of what it can send intersected with the  
other sides offer to receive.

Is there really a use case that needs more than this? There may well  
be. I just don't know what it is yet.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 18 Oct 2007 12:52:58 -0400

Dean Willis wrote:

> willingness to send 2833 tones? It can't send them unless the other side 
> has indicated willingness to accept them. And, as pointed out, it 
> doesn't have to be able to receive them to be able to send them.

There are a (growing) number of ways to transmit DTMF information. A 
particular UA that is interested in receiving DTMF needs nail down a way 
of doing so. And a UA that is to send DTMF needs to nail down the 
way(s?) it will be sending it.

After the initial invite there needs to be some way for the recipient to 
decide if a way has been agreed upon. If not, then it still may have the 
option of sending an explicit subscription. But it needs to know if that 
is required. If nobody every explicitly confirms that they agree to send 
DTMF in some agreed upon way then things are messed up.

	Paul

---

From: Eric Burger <[email-masked]>
Date: Thu, 18 Oct 2007 11:16:46 -0400

Got it in 1!  Tagging the message with the context, also known as event in
3265 parlance, fixes the INFO application routing / context problem.  I was
one of the first to say we could fix INFO.  In fact, I started revising
Dean's draft of almost 5 years ago before I realized I was totally
recreating SUBSCRIBE/NOTIFY.

In particular, the requesting party MUST do something that looks like a
SUBSCRIBE, outside of the INVITE?  Why?  Because the call will fail if the
particular reporting, like DTMF, is no supported.  If the argument is
reporting DTMF is a rare occurrence for, e.g., H.323 gateways, then failing
a call to the H.323 gateway from a SIP Phone is not a desirable feature.

The reason I decided not to go on that route is at best you save 2 messages
(the instant NOTIFY and 200 OK) over using 3265.  At that point, might as
well use 3265.

That said, I suppose, we could offer a "fast start" 3265.  [If this has
shades of H.323...]  In this scenario the fact you advertise support or
acceptance of particular INFO-packages is enough to enable a sender to send
appropriately tagged INFO's to you.

Of course, if one of those INFO's fails, then I will bet 75% of the
implementations will tear down the call.  25% will leave the call up and RTP
port open forever.

I would also offer we give this mechanism a new method name, as it will NOT
be backwards-compatible with INFO.

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 18 Oct 2007 12:48:32 -0500

> Sent: Thursday, October 18, 2007 10:17 AM
> To: Stucker, Brian (RICH1:AR00); Dean Willis
> Cc: sip; Christer Holmberg (JO/LMF); Audet, Francois 
> (SC100:3055); Hadriel Kaplan
> Subject: Re: [Sip] INFO
> 
> 3265 parlance, fixes the INFO application routing / context 
> problem.  I was one of the first to say we could fix INFO.  
> In fact, I started revising Dean's draft of almost 5 years 
> ago before I realized I was totally recreating SUBSCRIBE/NOTIFY.
> 
> In particular, the requesting party MUST do something that 
> looks like a SUBSCRIBE, outside of the INVITE?  Why?  Because 
> the call will fail if the particular reporting, like DTMF, is 
> no supported.  If the argument is reporting DTMF is a rare 
> occurrence for, e.g., H.323 gateways, then failing a call to 
> the H.323 gateway from a SIP Phone is not a desirable feature.

It doesn't *have* to fail. You can define different levels of
requirement for something. I think this is being a bit too harsh.

> 
> The reason I decided not to go on that route is at best you 
> save 2 messages (the instant NOTIFY and 200 OK) over using 
> 3265.  At that point, might as well use 3265.

Actually,

You don't even have to get an immediate NOTIFY/200 to a SUBSCRIBE
anymore:

http://tools.ietf.org/html/draft-ietf-sip-subnot-etags-01

You can suppress the auto-NOTIFY to your SUBSCRIBE, but the implication
here is that you can't SUBSCRIBE (safely) until you have at least an
early dialog or you otherwise know that the subscription isn't going to
fork because you won't get NOTIFYs back from forked dialogs that you can
481.

Again, seems complex to do something outside of the INVITE itself even
if it's not the most flexible mechanism.

Regards,
Brian

> 
> 
> That said, I suppose, we could offer a "fast start" 3265.  
> [If this has shades of H.323...]  In this scenario the fact 
> you advertise support or acceptance of particular 
> INFO-packages is enough to enable a sender to send 

This is going to be super-confusing I think to people. Just use NOTIFY
if it looks, acts, and smells like NOTIFY.

> 
> Of course, if one of those INFO's fails, then I will bet 75% 
> of the implementations will tear down the call.  25% will 
> leave the call up and RTP port open forever.

If your implementation is that broken what we do about INFO doesn't seem
relevant to increasing or decreasing the stability of the software.

> 
> I would also offer we give this mechanism a new method name, 
> as it will NOT be backwards-compatible with INFO.
> 
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 18 Oct 2007 23:04:59 +0200

Hi,

>We could just define that no INFO (or NOTIFY if that be the method) can be sent until the ACK, regardless.  Like BYEs.

I guess the ACK could also be PRACK, because I don't think we want to prevent INTIFY (it's shorter than "INFO or NOTIFY" :) before 200 OK.

Regarding the race condition, I guess the problem is in the backward direction. In the forward direction it's not a problem, once the calling party has received the response.

Regards,

Christer 

-hadriel

---

From: Eric Burger <[email-masked]>
Date: Thu, 18 Oct 2007 16:02:13 -0400

Missing the point.

If, for some reason, a NOTIFY gets a, for example, 410 response (instead of
200 OK), the *subscription* dialog terminates.

If an INFO gets a 410, the *call dialog* terminates.

Probably not the behavior people expect.

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 18 Oct 2007 17:12:01 -0500

Eric,

Where did you find the requirement that a 4xx to an INFO kills the call?
I just re-read RFC-2976, there's nothing in there that says anything
about an error response to an INFO killing the call dialog at all.

Section 2.2:

      "A 481 Call Leg/Transaction Does Not Exist message MUST be sent by
      a UAS if the INFO request does not match any existing call leg."

(No requirement to kill the call dialog, although it would seem
appropriate to do so)

  "Other request failure (4xx), Server Failure (5xx) and Global Failure
(6xx) responses MAY be sent for the INFO Request."

(No requirement to kill the call dialog)

Sction 2.4:

	"...the INFO message MUST NOT change the state of the SIP call,
or the sessions initiated by SIP."

Regards,
Brian

> Sent: Thursday, October 18, 2007 3:02 PM
> To: Stucker, Brian (RICH1:AR00)
> Cc: sip
> Subject: Re: [Sip] INFO
> 
> Missing the point.
> 
> If, for some reason, a NOTIFY gets a, for example, 410 
> response (instead of 200 OK), the *subscription* dialog terminates.
> 
> >> Cc: sip; Christer Holmberg (JO/LMF); Audet, Francois (SC100:3055); 
> >> Hadriel Kaplan
> >> Subject: Re: [Sip] INFO
> >> 
> >> 3265 parlance, fixes the INFO application routing / 
> context problem.  
> >> I was one of the first to say we could fix INFO.
> ago before 
> >> I realized I was totally recreating SUBSCRIBE/NOTIFY.
> >> 
> looks like 
> >> a SUBSCRIBE, outside of the INVITE?  Why?  Because the 
> call will fail 
> >> if the particular reporting, like DTMF, is no supported.  If the 
> >> argument is reporting DTMF is a rare occurrence for, e.g., H.323 
> >> gateways, then failing a call to the H.323 gateway from a 
> SIP Phone 
> >> is not a desirable feature.
> > 
> >> The reason I decided not to go on that route is at best you save 2 
> >> messages (the instant NOTIFY and 200 OK) over using 3265.  At that 
> >> point, might as well use 3265.
> > 
> > Actually,
> > 
> > You can suppress the auto-NOTIFY to your SUBSCRIBE, but the 
> > implication here is that you can't SUBSCRIBE (safely) until 
> you have 
> > at least an early dialog or you otherwise know that the 
> subscription 
> > isn't going to fork because you won't get NOTIFYs back from forked 
> > dialogs that you can 481.
> > 
> >> [If this has shades of H.323...]  In this scenario the fact you 
> >> advertise support or acceptance of particular 
> INFO-packages is enough 
> >> to enable a sender to send appropriately tagged INFO's to you.
> > 
> >> implementations will tear down the call.  25% will leave 
> the call up 
> >> and RTP port open forever.
> > 
> > If your implementation is that broken what we do about INFO doesn't 
> > seem relevant to increasing or decreasing the stability of 
> the software.
> > 
> >> 
> >> I would also offer we give this mechanism a new method name, as it 
> >> will NOT be backwards-compatible with INFO.
> >> 
> >> 
> >> Notice:  This email message, together with any attachments, may 
> >> contain information  of  BEA Systems,  Inc.,  its 
> subsidiaries  and  
> >> affiliated entities,  that may be confidential,  proprietary,  
> >> copyrighted  and/or legally privileged, and is intended solely for 
> >> the use of the individual or entity named in this message. 
> If you are 
> >> not the intended recipient, and have received this message 
> in error, 
> >> please immediately return this by email and then delete it.
> >> 
> > 
> 
> 
>

---

From: Adam Roach <[email-masked]>
Date: Thu, 18 Oct 2007 18:02:01 -0500

The interaction between errors and dialog termination wasn't crystal 
clear in 3261; and multiple usages within a dialog makes it even more 
messy. That's why Robert has poured so much effort into 
draft-ietf-sipping-dialogusage. It's an incredibly useful document the 
puts crystal clarity around exactly these kinds of issues. If we had the 
critical corrections process in place when it was progressing, it would 
have probably been part of that process. As it is, it forms an important 
adjunct to 3261.

I can't completely back out whether Eric meant to talk about two usages 
in a single dialog or two different dialogs. In any case, if you get a 
410 in response to a request -- including an INFO request -- the whole 
dialog goes away, including all of its usages (not just the usage the 
INFO was associated with -- although that's kind of a nebulous concept, 
since INFO isn't inherently associated with a *usage*, merely with a 
*dialog*. This is another place where INFO is underspecified; to be 
fair, though, the concept of usages developed after INFO was published).

So, to be clear: if you send an INFO and get any of 404, 410, 416, 
482-485, 502, or 604, then the dialog goes away. Period.

If INFO causes a 480 or 481, then the INVITE usage goes away. If the 
INVITE was the last usage in the dialog, then the dialog goes away.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 18 Oct 2007 19:28:02 -0400

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.

	Paul

Adam Roach wrote:
>>> From: Eric Burger [mailto:[email-masked]] Sent: Thursday, October 
>>> 18, 2007 3:02 PM
>>> If, for some reason, a NOTIFY gets a, for example, 410 response 
>>> (instead of 200 OK), the *subscription* dialog terminates.
>>>

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 18 Oct 2007 18:34:02 -0500

Duh. I knew I was forgetting something. I wouldn't say 2976 is a bastion
example of specificity so I figured it must be coming from somewhere
else.

However, this usecase seems to also be true of NOTIFY usage within an
INVITE dialog in the specific case of a 410 response if I read tables
1/2 correctly from the dialogusage draft. 

Why are we talking about 410 anyway? I don't think I've ever seen one
generated in the wild.

It still seems to be boiling down to whether or not you want to force
folks to explicitly SUBSCRIBE to usages within the INVITE dialog. If you
use a SUBSCRIBE you can support directionality and that's about it. I
don't think you get a cleaner idea of whether or not the dialog should
exist or not than you have over INFO+event, or an implicit subscription.

Even for DTMF digits, if you setup the call, and then made your
subscription to KPML or whatever, within the dialog, and got back a 489
it seems somewhat uncertain to me what the correct behavior at the UA
should be.

If the UA was accessing a service that required SIP signaling level
awareness of DTMF digits, it may be perfectly reasonable to kill the
call. If it instead assumes 2833 support because 2833 was accepted in
the SDP it may continue on with the call but be broken because the thing
that needs the digits isn't on the media path, etc. Or if it tried for
KPML and 2833 and killed the call because KPML was rejected, the call
may have worked fine because the KPML was being rejected in favor of
2833 by a gateway, etc.

I just don't see how you can always figure out that the application is
broken (especially with something like DTMF which has a couple ways of
doing it) and the dialog needs to end from one reporting failure. I can
definitely envision cases where you could tell, but I can also come up
with usecases (like DTMF) where it's not so clear.

Regards,
Brian 

> From: Adam Roach [mailto:[email-masked]] 
> Sent: Thursday, October 18, 2007 6:02 PM
> Cc: Eric Burger; sip
> The interaction between errors and dialog termination wasn't 
> crystal clear in 3261; and multiple usages within a dialog 
> makes it even more messy. That's why Robert has poured so 
> much effort into draft-ietf-sipping-dialogusage. It's an 
> incredibly useful document the puts crystal clarity around 
> exactly these kinds of issues. If we had the critical 
> corrections process in place when it was progressing, it 
> would have probably been part of that process. As it is, it 
> forms an important adjunct to 3261.
> 
> I can't completely back out whether Eric meant to talk about 
> two usages in a single dialog or two different dialogs. In 
> any case, if you get a 410 in response to a request -- 
> including an INFO request -- the whole dialog goes away, 
> including all of its usages (not just the usage the INFO was 
> associated with -- although that's kind of a nebulous 
> concept, since INFO isn't inherently associated with a 
> *usage*, merely with a *dialog*. This is another place where 
> INFO is underspecified; to be fair, though, the concept of 
> usages developed after INFO was published).
> 
> So, to be clear: if you send an INFO and get any of 404, 410, 
> 416, 482-485, 502, or 604, then the dialog goes away. Period.
> 
> If INFO causes a 480 or 481, then the INVITE usage goes away. 
> If the INVITE was the last usage in the dialog, then the 
> dialog goes away.
> 
> /a
> 
> Brian Stucker wrote:
> > Eric,
> >
> > 	"...the INFO message MUST NOT change the state of the 
> SIP call, or 
> > the sessions initiated by SIP."
> >
> > Regards,
> > Brian
> >
> >

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 19 Oct 2007 07:40:43 +0100

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

> Sent: 19 October 2007 01:05
> To: Paul Kyzivat
> Cc: sip; Brian Stucker
> Subject: Re: [Sip] INFO
> 
> Paul Kyzivat wrote:
> 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
> 
>

---

From: "Michael Procter" <[email-masked]>
Date: Fri, 19 Oct 2007 00:47:46 -0700

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

> From: Elwell, John [mailto:[email-masked]]
> Sent: 19 October 2007 07:41
> To: Adam Roach; Paul Kyzivat
> Cc: sip; Brian Stucker
> Subject: RE: [Sip] INFO
> 
> Adam,
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 19 Oct 2007 10:49:46 +0200

Hi,

Michael is correct. The idea would be to only have ONE SINGLE USAGE -
the invite usage, and define some kind of invite-usage-subscription
mechanism for that. I strongly do not think that we should start to
define things based on multiple usages, because Robert's draft shows all
the issues with that.

So, whatever method (INFO, NOTIFY, INTIFY,...) we use, it has to be
something which is allowed for an invite usage, and can also be
identified to belong to an invite usage.

The issue with NOTIFY in th invite-usage-subscription proposal is that
it is a subscription usage command, currently not defined/allowed for
invite usages. So, we would have to change that, or use another method.

Regards,

Christer

> Sent: 19. lokakuuta 2007 10: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
> 
> > Now that you have reminded us of the dialogusage draft, perhaps it 
> > would be appropriate to remind people of the following from the 
> > abstract:
> > 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
> > 
> > 
> > > the current terminology, but a quick re-read does show that it's 
> > > pretty clearly appropriate only for INVITE usages.
> > >
> > > /a
> > >
> > >
> [email-masked] for questions on current sip

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 19 Oct 2007 09:49:35 +0100

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 

> Sent: 19 October 2007 08:48
> > would

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 19 Oct 2007 07:47:47 -0400

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

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Fri, 19 Oct 2007 19:54:52 +0800

Hi

The earlier draft on SIP conferencing models
draft-rosenberg-sip-conferencing-models-01.txt, defines a 5xx response:
500 conference server full response to indicate that the conference
server has reached its maximum capacity of users.

But I do not see this response in subsequent versions of draft / RFC. So
which is the response code that is currently used to indicate this
scenario? Or is it not required at all.

Thanks

Regards
Ranjit

-

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 19 Oct 2007 10:04:19 -0400

Which is one of the reasons I think it should be INFO.  Using it would only be an update to rfc2976, right?
-hadriel

> Sent: Friday, October 19, 2007 7:48 AM
> To: Elwell, John
> Cc: sip; Michael Procter; Adam Roach; Brian Stucker
> Subject: Re: [Sip] INFO
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 19 Oct 2007 11:55:00 -0400

> Which is one of the reasons I think it should be INFO.  Using it would only be an update to rfc2976, right?

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

---

From: "Brian Stucker" <[email-masked]>
Date: Fri, 19 Oct 2007 11:21:08 -0500

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'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.

Regards,
Brian 

> 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:
> 
> 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
> 
> >> 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,
> >>>
> >>> 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
> >>>
> >>>> My impression of the discussion so far is that using NOTIFY (or 
> >>>> INTIFY as Christer suggests) in this way would not 
> constitute a new 
> >>>> 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
> >>>>
> >>>>> "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 
> >>>>>>> is my impression that INFO was designed for use with 
> INVITE, and
> >>>>> so

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 19 Oct 2007 12:52:16 -0400

> I mean, the endpoints may know what's going on, but boxes in the middle

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.

> 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

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 19 Oct 2007 13:50:51 -0400

>    new capability within the invite dialog usage.

No matter which Method gets used, there will need to be some new header(s) in INVITE to negotiate.  So that's equal.

>    able to use either this technique or real subscriptions, with only

I don't see how that's knowable.  For one, code is obviously implementation dependent.  For another, we would be changing the way in which subscribe bodies could be sent (i.e., they wouldn't, not in the subscription-creation), the handling of subscription duration, and adding a directional negotiation mechanism.  Lastly, you don't *have* to support rfc3265 at all to support 3261, so the code change could be quite a bit more.

>    ground up to support both styles.

True of both cases, I presume.

>    new header(s) in invite and responses.

I'm confused by this - did you mean INFO, and just that the INVITE needs the negotiation headers (as it does for NOTIFY)?

>    to be modified to be used with INFO.

Any current event-package could not simply be used in a NOTIFY model either, for the reason you pointed out in an earlier email: we wouldn't want the package's subscribe body to be in the Invite.  And really there are some that would be illogical to do so (like reg-event).  So in that sense it's a wash: any current event-package wanting to be used would need an extension to say so and how, and any future ones would need to define whether or not they support this new Invite-Notify/INFO and how.

> implement, and has other benefits.

That's assuming we need to actually make this create a real Subscription.  That would mean you'd be including all the concepts of Subscribe usages in an Invite-created dialog, having two usages in the same dialog, etc.  Since the lifetime, relationship, context, usage, etc., between the Invite and event-notification is inexorably linked, there is no need for a real Subscription.  And we already have a method that has that direct relationship to Invite: INFO.

-hadriel

---

From: Jeroen van Bemmel <[email-masked]>
Date: Fri, 19 Oct 2007 22:51:22 +0200

Paul,
> about this. B2BUAs will need to know, but then they will know.
There are (as always) subtle differences. NOTIFY for SUBSCRIBE is needed 
to handle forking (proxies pass at most 1 2xx response for SUBSCRIBE), 
while NOTIFY for INVITE would not be needed for this reason. Proxies 
Record-Route NOTIFY due to the above reason, they could avoid doing that 
for INVITE-NOTIFYs. Record-Routing INFO is useless and somewhat 
wasteful, so well designed proxies don't do that.

Also, I assume there will be no need to "immediately send NOTIFY" for 
INVITE-based events.

All in all, IMO using INFO instead of NOTIFY here is preferrable (also 
given that existing implementations already use INFO within INVITE 
dialogs).

Regards,
Jeroen

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 19 Oct 2007 22:55:41 +0200

Hi,
 
I share Brian's concern regarding stateful intermediates. They may not have knowledge of the new way NOTIFY is used, and they MAY do unwanted things in certain situations.
 
Regards,
 
Christer

________________________________

From: Brian Stucker [mailto:[email-masked]]
Sent: Fri 19/10/2007 18:21
To: Paul Kyzivat; Hadriel Kaplan
Cc: sip; Adam Roach; Michael Procter; Elwell,John
Subject: RE: [Sip] INFO

Regards,
Brian

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 19 Oct 2007 23:09:53 +0200

Hi,
 
One potential issue: the stateful intermediate receives a NOTIFY without any previous SUBSCRIBE. Is there a chance it would act on this, e.g. by sending a 4xx response, or are we sure it would always simply forward the NOTIFY and assume the endpoint will handle it?
 
Regards,
 
Christer

From: Paul Kyzivat [mailto:[email-masked]]
Sent: Fri 19/10/2007 18:52
To: Brian Stucker
Cc: sip; Adam Roach; Michael Procter; Elwell,John
Subject: Re: [Sip] INFO

        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 19 Oct 2007 18:17:03 -0400

Jeroen van Bemmel wrote:
> for INVITE-NOTIFYs.

I don't follow. If the proxy was going to R-R, it needed to do so in the 
SUBSCRIBE. (Or it wouldn't even see the NOTIFY.) If its doing asymmetric 
R-R then it may need to update the R-R entry, but that is conditional on 
the entry it put there in the SUBSCRIBE. The UAS for the NOTIFY needs to 
recognize if it establishes a new dialog and if so remember the R-R, but 
again that doesn't impact a proxy.

> Record-Routing INFO is useless and somewhat 

True. But that again is a matter for the UAC and UAS, not the proxies.

> given that existing implementations already use INFO within INVITE 

No matter what we do, the existing standardized uses of INFO will remain.

And I think it is safe to assume that the existing *unstandardized* uses 
of INFO will not do the kind of negotiation we are talking about, so 
they won't carry over directly.

So we are really only talking about new things.

If we use NOTIFY, then existing, already standardized event packages can 
(hopefully) be easily adapted to support the new technique as well as 
the old. Because the semantics of the package wouldn't change, I would 
hope that it would be easy to get those changes adopted.

If we use INFO, then I guess we can hopefully easily adapt existing 
non-standard INFO usages. But because they haven't been standardized, 
that may be more difficult.

I suppose one could adapt existing event packages to use INFO for this 
style and NOTIFY for freestanding subscriptions. Mechanically its not a 
big deal, but it certainly seems odd.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 19 Oct 2007 18:28:16 -0400

Hadriel Kaplan wrote:
> I don't see how that's knowable.  For one, code is obviously implementation dependent.  For another, we would be changing the way in which subscribe bodies could be sent (i.e., they wouldn't, not in the subscription-creation), the handling of subscription duration, and adding a directional negotiation mechanism. 

I agree this is speculation.

> Lastly, you don't *have* to support rfc3265 at all to support 3261, so the code change could be quite a bit more.

For somebody that doesn't support 3265, and doesn't want to, but that 
does want to support these new packages within an INVITE, this is all 
new implementation in any case. Sure, it would require supporting the 
NOTIFY *method*, as it is used in this new usage. But the hard work is 
in supporting the packages, not the method. And that part is the same 
either way.

> True of both cases, I presume.

So you are assuming that we would define packages that use a common 
encoding and semantics for messages, but that convey them in NOTIFY for 
subscriptions and in INFO for invite-dialog usage?

That is certainly possible. It just seems unappealing to me.

> I'm confused by this - did you mean INFO, and just that the INVITE needs the negotiation headers (as it does for NOTIFY)?

Sorry - yes I typed NOTIFY where I meant INFO. :-(

> That's assuming we need to actually make this create a real Subscription.  That would mean you'd be including all the concepts of Subscribe usages in an Invite-created dialog, having two usages in…

By "lighter weight subscription model" I mean negotiating the use of the 
event package within the invite dialog usage. Its still a subscription 
in some sense, but isn't independently refreshed or expired.

Regardless of INFO or NOTIFY, are we converging on using an adaptation 
of the event package template for defining such a thing - one that 
ideally would support both styles of usage?

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 19 Oct 2007 18:34:33 -0400

> One potential issue: the stateful intermediate receives a NOTIFY without any previous SUBSCRIBE. Is there a chance it would act on this, e.g. by sending a 4xx response, or are we sure it would alwa…

Are you talking about a B2BUA or a proxy?

If a B2BUA, it suffers the common problem that it needs to be aware of 
pretty much all the standards in use by those it is connecting.

If it was not aware of this new extension, and it was trying to enforce 
rules about what messages are allowed in what contexts, then yes it 
might cause trouble. But we specify stuff all the time that has similar 
issues with B2BUAs. Its up to B2BUAs to figure out how to be transparent 
or else go away.

If its a proxy it has no business making such a judgment.

	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 19 Oct 2007 20:40:19 -0400

> So we are really only talking about new things.

Actually, I'm not so sure of that.  I don't know how many would do it, but I think making it as painless/trivial as possible increases the odds of implementation and thus upgrade.  And following Christer's point, I think it also gives an existence proof that INFO as a method will make it through most anything along the path to the UA.

-hadriel
p.s. FWIW, I know my employer would implement it; but I don't think it matters much to us whether it's Notify or Info.

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 19 Oct 2007 21:30:18 -0400

> That is certainly possible. It just seems unappealing to me.

Turning the tables on you: what does the method name matter?  :)
For one thing, it's explicit - INFO would be for notifications tied to an Invite dialog and usage, but not integral to its usage.  I.e., exactly what it meant before.  It would just have a new "Event"-type header, and the Invite transaction would have carried negotiation for which events could be used - neither of which require a new method name.

I guess one question is which Method is more appropriate, given the dialog-usage draft.

The other question is: are we really creating an implicitly-signaled Subscription.  In other words, is the Invite really like REFER in this regard?  If so, then we're really saying one should be able to send a Notify with subscription-state terminated, or with an expires parameter and needing refresh with a Subscribe.  Meanwhile we already have an expires mechanism for Invite sessions, and it really means the Notify is tied to some second usage other than the Invite's.  What would a Notify with a subscription-state of "terminated" mean in this new mechanism? (or would that header not be included?)  If we're not doing that stuff, then there is no real, distinct Subscription a la Notify, and using INFO would be clear about that.

> in some sense, but isn't independently refreshed or expired.

Then why use a method name that has those traits?  There really is NOT a Subscription in the 3265 sense of the word, is there?

-hadriel

---

From: "Christer Holmberg" <[email-masked]>
Date: Sat, 20 Oct 2007 08:08:47 +0200

Hi Paul,
 
I am talking about a proxy.
 
So, you are saying that the proxy would always forward the NOTIFY, even if it does not have any state of a subscription dialog, or subscription usage within a dialog?
 
Regards,
 
Christer

From: Paul Kyzivat [mailto:[email-masked]]
Sent: Sat 20/10/2007 00:34
To: Christer Holmberg
Cc: Brian Stucker; sip; Adam Roach; Michael Procter; Elwell,John
Subject: Re: [Sip] INFO

        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 20 Oct 2007 10:24:44 -0400

> So, you are saying that the proxy would always forward the NOTIFY, even if it does not have any state of a subscription dialog, or subscription usage within a dialog?

Well...

There are transaction-stateless proxies, and transaction-stateful 
proxies, and dialog-stateful proxies.

Only a dialog-stateful proxy could make the kind of decision you are 
talking about.

AFAIK there is very little written about dialog-stateful proxies. I 
think perhaps they have little utility, and have been superseded by 
B2BUAs. So there isn't a lot to go on in determining what they are 
permitted to do.

In general I think a "proxy" is only permitted to return an error to a 
request if it:
- isn't able to forward as requested
- is carrying out policy on behalf of the sender
   or the recipient. (I suppose policy of the
   carrier also applies on the assumption that
   the caller or callee select the carrier and
   hence implicitly agree to its policies.)

My personal opinion is that the kind of checking you are talking about 
is just "meddling" in the affairs of the UAs, and should not be done. 
But I suppose one might desire a policy that enforces standards in this 
way. But if so, as a UA I don't want my agents enforcing policies that 
prevent valid usages by my UA.

Perhaps Hadriel would like to comment on this. His company makes SBCs 
that I think are in the business of sticking their nose into other 
people's sip usage and policing it. Do they do this kind of enforcement?

	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Sat, 20 Oct 2007 17:17:05 +0200

Hi Paul,

So, I guess the compact version of your answer to my question is: "I am
not sure" :)

So, if there is a chance that there is something which will go wrong I
think we should really also consider using another method than NOTIFY.

Regards,

Christer

> Sent: 20. lokakuuta 2007 17:25
> To: Christer Holmberg
> > So, you are saying that the proxy would always forward the 
> NOTIFY, even if it does not have any state of a subscription 
> dialog, or subscription usage within a dialog?
> 
> Well...
> 
> There are transaction-stateless proxies, and 
> transaction-stateful proxies, and dialog-stateful proxies.
> 
> Only a dialog-stateful proxy could make the kind of decision 
> you are talking about.
> 
> AFAIK there is very little written about dialog-stateful 
> proxies. I think perhaps they have little utility, and have 
> been superseded by B2BUAs. So there isn't a lot to go on in 
> determining what they are permitted to do.
> 
> In general I think a "proxy" is only permitted to return an 
> error to a request if it:
> My personal opinion is that the kind of checking you are 
> talking about is just "meddling" in the affairs of the UAs, 
> and should not be done. 
> But I suppose one might desire a policy that enforces 
> standards in this way. But if so, as a UA I don't want my 
> agents enforcing policies that prevent valid usages by my UA.
> 
> Perhaps Hadriel would like to comment on this. His company 
> makes SBCs that I think are in the business of sticking their 
> nose into other people's sip usage and policing it. Do they 
> do this kind of enforcement?
> 
> 	Paul
> 
> > Regards,
> >  
> > Christer
> > 
> >> One potential issue: the stateful intermediate receives a 
> NOTIFY without any previous SUBSCRIBE. Is there a chance it 
> would act on this, e.g. by sending a 4xx response, or are we 
> sure it would always simply forward the NOTIFY and assume the 
> endpoint will handle it?
> > 
> > If it was not aware of this new extension, and it was trying to 
> > enforce rules about what messages are allowed in what 
> contexts, then 
> > yes it might cause trouble. But we specify stuff all the 
> time that has 
> > similar issues with B2BUAs. Its up to B2BUAs to figure out 
> how to be 
> > transparent or else go away.
> > 
> >>> 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.
> >>>> Cc: Elwell, John; sip; Michael Procter; Adam Roach; 
> Stucker, Brian 
> >>>> (RICH1:AR00)
> >>>> Subject: Re: [Sip] INFO
> >>>>
> >>>>
> >>>>
> >>>> Hadriel Kaplan wrote:
> >>>> I don't think the distinction is significant. Either way 
> it should 
> >>>> be designed to be backward compatible. And neither way 
> will require 
> >>>> - will need some new header(s) in INVITE and responses 
> to negotiate 
> >>>> this
> >>>> 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
> >>>>
> >>>>>> 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,
> >>>>>>>
> >>>>>>>>>> You're correct. I had forgotten about that, and the 
> >>>>>>>>>> dialogusage
> >>>>>>>>> draft
> >>>>>>>>>> Sip mailing list  
> https://www1.ietf.org/mailman/listinfo/sip

---

From: Spencer Dawkins <[email-masked]>
Date: Sat, 20 Oct 2007 11:08:37 -0500

Hi, Christer,

I am probably misunderstanding, but I thought Paul's answer was that if a 
proxy goes into business for itself, it's not really a proxy, and if a proxy 
goes into business for itself, that's not because we took this mode of 
operation into account, but because the people who built this "proxy" were 
able to make it completely transparent, so that we didn't need to take this 
mode of operation into account.

Paul, back to you if I got this wrong.

Spencer

From: "Christer Holmberg" <[email-masked]>
To: "Paul Kyzivat" <[email-masked]>

Hi Paul,

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 20 Oct 2007 13:08:58 -0400

> people's sip usage and policing it.

Cute.  I believe Christer's makes them too, as does yours, and a dozen others on this list.  We don't "stick our nose into other people's usage".  They sent SIP to us.  We can't force a UA not to send something to us.  But it doesn't mean we have to accept it.  No one forces you to send your SIP requests to us or any SBC, AFAIK.

> Do they do this kind of enforcement?

Of course we could do that kind of enforcement, depending on configuration, as I assume you guys do.  My guess is even "Proxies" do it, based on config. (and there are plenty of record-routing proxies)  The RFCs say to forward SIP requests, just as they expect routers to forward packets, but that doesn't stop routers from having ACLs, policing, shaping, filtering routes, etc.  Email servers block emails based on usage too.

Regardless, I'm with you that we can't consider local device policies as a roadblock to all new things.  (Although pragmatism has its place)  It's just that it is an advantage for a mechanism if we know it works in more cases due to empirical evidence.  I think there is also some evidence that a Notify in an Invite dialog works, because there is at least one vendor out there that uses Notify in an Invite for DTMF.  But many more do Info, I believe, so I assume its chance of success is greater.

-hadriel

---

From: "Christer Holmberg" <[email-masked]>
Date: Sat, 20 Oct 2007 19:52:46 +0200

Hi, 

>I am probably misunderstanding, but I thought Paul's answer 
>was that if a proxy goes into business for itself, it's not 
>really a proxy, and if a proxy goes into business for itself, 
>that's not because we took this mode of operation into 
>account, but because the people who built this "proxy" were 
>able to make it completely transparent, so that we didn't 
>need to take this mode of operation into account.

My understanding from what Paul said was that a dialog-stateful proxy is
still a proxy.

Whether in real life people add lots of other stuff to dialog-stateful
proxies, so they become B2BUAs, I don't know, but a "pure"
dialog-stateful proxy is still a proxy.

Regards,

Christer

> So, I guess the compact version of your answer to my question 
> is: "I am not sure" :) 
> 
> 
> 
>

---

From: Dean Willis <[email-masked]>
Date: Sun, 21 Oct 2007 19:27:17 -0500

On Oct 19, 2007, at 9:04 AM, 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 concur. And an RFC that clearly replaces the broken RFC 2976 gives  
us a great thing to whack developers with.

Backward compatibility issues can be worked out with an option tag.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Sun, 21 Oct 2007 19:37:52 -0500

On Oct 20, 2007, at 1:08 AM, Christer Holmberg wrote:

> So, you are saying that the proxy would always forward the NOTIFY,  
> even if it does not have any state of a subscription dialog, or  
> subscription usage within a dialog?
>

Many proxies blindly forward NOTIFY. I know this because certain very  
popular phone adapters with blue boxes use unsolicited NOTIFY for  
their message waiting indicators, and many operators seem to have  
deployed them with some success, despite much gnashing of teeth on my  
part.

--
Dean

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 22 Oct 2007 08:00:26 +0200

Hi, 

>Many proxies blindly forward NOTIFY. I know this because 
>certain very popular phone adapters with blue boxes use 
>unsolicited NOTIFY for their message waiting indicators, and 
>many operators seem to have deployed them with some success, 
>despite much gnashing of teeth on my part.

"MANY" is not the same thing as "ALL" :)

Regards,

Christer

---

From: "Brian Stucker" <[email-masked]>
Date: Mon, 22 Oct 2007 02:24:30 -0500

> Sent: Friday, October 19, 2007 11:52 AM
> Cc: sip; Adam Roach; Michael Procter; Elwell, John
> Subject: Re: [Sip] INFO
> 
> 
> 
> Brian Stucker wrote:
> > are returned for NOTIFY messages isn't it going to be a bit 
> > complicated to determine at the transaction layer if the NOTIFY was 
> 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.

Call stateful proxies (not B2BUAs) will probably chew up your call
dialog. 

> 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.

Maybe. Let's just keep the middle in mind so the ends works.

> >> Cc: Elwell, John; sip; Michael Procter; Adam Roach; Stucker, Brian 
> >> (RICH1:AR00)
> >> Subject: Re: [Sip] INFO
> >>
> >>
> >>
> >> Hadriel Kaplan wrote:
> it should be 
> >> - will need some new header(s) in INVITE and responses to 
> negotiate 
> >> this
> no harder to

---

From: "Brian Stucker" <[email-masked]>
Date: Mon, 22 Oct 2007 02:35:44 -0500

> Sent: Friday, October 19, 2007 4:10 PM
> To: Paul Kyzivat; Stucker, Brian (RICH1:AR00)

It depends upon how much state this stateful intermediate is keeping. If
it's transaction stateful, then no, it shouldn't care (as it won't have
remembered any of the previous transactions once their response was sent
back anyway). However, it is entirely possible that, without performing
anything untoward (i.e. not a B2BUA) that a proxy may remember whether
or not a SUBSCRIBE had previously been sent for a particular NOTIFY and
kill the NOTIFY as a security measure thinking that someone's up to no
good trying to spoof a subscription. Yes, this would generally break
implicit subscriptions, but they've generally pretty ill-advised because
of their security profile.

For example, I may send regevent NOTIFYs to endpoints telling them
they've been forcefully deregistered looking for a gullible UA that will
bump itself off the network.

I'm just concerned that by using a method from 3265, with new semantics,
that it could confuse boxes that aren't aware of what's going on. If it
were a different method, either INFO+ or something new, then I'd be less
concerned because the whole thing would just look like a regular
transaction to the untrained implementation.

---

From: "Brian Stucker" <[email-masked]>
Date: Mon, 22 Oct 2007 02:48:18 -0500

> > Lastly, you don't *have* to support rfc3265 at all to 
> support 3261, so the code change could be quite a bit more.
> 
> For somebody that doesn't support 3265, and doesn't want to, 
> but that does want to support these new packages within an 
> INVITE, this is all new implementation in any case. Sure, it 
> would require supporting the NOTIFY *method*, as it is used 
> in this new usage. But the hard work is in supporting the 
> packages, not the method. And that part is the same either way.
> 

I don't agree that the method won't be hard to support. For one thing,
many people use stock SIP stacks they got from somewhere else and have
no idea how to add a new method or usage of a method because they've
simply never had to do so before or simply can't due to other issues.
Adding methods or a new nuance to an existing method may look easy on
paper, but it can be a lot harder to do in practice. Much harder than,
say, putting code together to toString your registration entries into
XML for regevent.

It's not necessarily the same either. If we use the same method, but a
different dialog usage, then you could potentially have to remember
which usage created the subscription in order to send the NOTIFY or
process the error responses (if you're given a chance to do so by your
SIP stack) in a new way.

We need to take into account some history here when we're talking about
fundamental tweaks to the way NOTIFY or INFO work. The dialog-usage
draft makes necessary tweaks because things were broken already, but we
are not similarly forced to fool with NOTIFY in this case.

Non-trivial. May be worth doing, but let's not assume it's going to be
simple until we have more details.

Regards,
Brian

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 22 Oct 2007 08:55:23 +0100

> Sent: 20 October 2007 02:30
> To: Paul Kyzivat
> Cc: sip
> Subject: RE: [Sip] INFO
> 
> 
> 
> For one thing, it's explicit - INFO would be for 
> notifications tied to an Invite dialog and usage, but not 
> integral to its usage.  I.e., exactly what it meant before.  
> It would just have a new "Event"-type header, and the Invite 
> transaction would have carried negotiation for which events 
> could be used - neither of which require a new method name.
> 
[JRE] This has got me thinking again. A few days ago there seemed to be
some consensus that we were not talking about a new dialog usage within
an INVITE-initiated dialog, but merely an extension of the INVITE usage,
which terminates with the BYE transaction. Now this would be different
from NOTIFY requests arising from REFER implicit subscriptions - these
constitute a separate dialog usage, termination of which is determined
by the Subscription-State header field. IMO it gets very messy if we use
the same method for requests relating to the INVITE usage and to other
usages. So I am coming round to thinking NOTIFY would not be a good
choice.

John

---

From: "Brian Stucker" <[email-masked]>
Date: Mon, 22 Oct 2007 03:08:20 -0500

> Sent: Friday, October 19, 2007 5:35 PM
> To: Christer Holmberg
> Cc: Stucker, Brian (RICH1:AR00); sip; Adam Roach; Michael 
> Procter; Elwell,John
> Subject: Re: [Sip] INFO
> 
> 
> 
> Christer Holmberg wrote:
> > Hi,
> >  
> If a B2BUA, it suffers the common problem that it needs to be 
> aware of pretty much all the standards in use by those it is 
> connecting.

No it doesn't. A B2BUA does not need to understand a great many things.
One thing it does need to understand is how all of the fundamental SIP
methods interact with one another. A B2BUA could be doing anything or
nothing, but it always has to know when and how dialogs/usages are
created, maintained and destroyed. That's the minimum requirement.

> 
> If it was not aware of this new extension, and it was trying 
> to enforce rules about what messages are allowed in what 
> contexts, then yes it might cause trouble. But we specify 
> stuff all the time that has similar issues with B2BUAs. Its 
> up to B2BUAs to figure out how to be transparent or else go away.

Nice thought, but they aren't going to go away. It is currently the
case, and going to continue to be the case, that a great deal of the SIP
endpoints in this world will only be addressable with a B2BUA in the
path for a wide variety of possible reasons. 

Before you flame me, go ask your system engineers how many SIP endpoints
they've personally seen commercially deployed that were addressable via
the Internet that were not protected by some sort of ALG or B2BUA scheme
that you'd be willing to post the address of their SIP proxy and the
usernames of several account holders there.

There may be a few, but they're pretty rare, and that's why it matters.

It'd be a shame that, by not acknowledging this simple fact, that we
wind up building our own walled garden. We need to make things work the
best we can in the environment we're given, not the one we wish we had.

Regards,
Brian

---

From: "Brian Stucker" <[email-masked]>
Date: Mon, 22 Oct 2007 03:23:49 -0500

Let me send you my "Twinkle, twinkle, MWI" script. A few hours of having
the right people's phones blinking like they're possessed will fix that.
If not, you can still use it to create the most complicated set of
Christmas tree lights ever assembled.

Regards,
Brian 

> Sent: Sunday, October 21, 2007 7:38 PM
> To: Christer Holmberg
> Cc: Paul Kyzivat; sip; Elwell, John; Michael Procter; Adam 
> Roach; Stucker, Brian (RICH1:AR00)
> Subject: Re: [Sip] INFO
> 
>

---

From: "Brian Stucker" <[email-masked]>
Date: Mon, 22 Oct 2007 03:28:42 -0500

> Sent: Monday, October 22, 2007 3:01 AM
> To: Stucker, Brian (RICH1:AR00); Paul Kyzivat; Hadriel Kaplan
> Cc: Elwell, John; sip; Adam Roach
> Subject: RE: [Sip] INFO
> 
> 
> > Sent: 22 October 2007 08:48
> > Cc: Elwell, John; sip; Michael Procter; Adam Roach
> > Subject: RE: [Sip] INFO
> > 
> > > From: Paul Kyzivat [mailto:[email-masked]] Hadriel 
> Kaplan wrote:
> > > For somebody that doesn't support 3265, and doesn't want to, but 
> > > that does want to support these new packages within an 
> INVITE, this 
> > > is all new implementation in any case. Sure, it would require 
> > > supporting the NOTIFY *method*, as it is used in this new 
> usage. But 
> > > the hard work is in supporting the packages, not the method. And 
> > > that part is the same either way.
> > >
> > 
> On a similar note, I suspect that adding a header (Event?) to 
> INFO would be simpler than subtracting a mandatory header 
> (Subscription-State) from NOTIFY, purely in terms of the 
> support for each in 3rd party stacks.
> 
> Of course, I am making a whole bunch of assumptions here that 
> aren't necessarily true.  So maybe this decision can be 
> postponed until a few more details are ironed out.
> 

In this case, I think it's a pretty safe assumption. Subtracting
mandatory headers from a method is not a great idea because now you've
added a new path in the code where the header is semi-mandatory and the
information to determine when it is mandatory, and when it is not, is
not present in the message itself (so the stack may have to ask the
application what's going on when it's trying to verify that the message
is minimally correct which may not be possible/desirable).

If I get an INFO with an event header in it, and I'm not looking for an
event header in an INFO, then I'm no worse off than I am today, right?
Besides, the event header isn't useful to the lower protocol layers.
It's only useful to the application itself, whereas the
subscription-state header is often handled by another chunk of code
whose sole responsibility is to maintain subscriptions and is neither
part of the stack, nor the application, but used by both.

Regards,
Brian

---

From: Adam Roach <[email-masked]>
Date: Mon, 22 Oct 2007 08:39:37 -0500

Sumit Garg wrote:
> Unsolicited NOTIFYs are widely used for Voicemail and are allowed in
> RFC3265
>   

Um.... no.

Please refer to the following excerpt from the section you quoted.

>
> Designers of such mechanisms are also
>    warned to make a distinction between sending a NOTIFY message to a
>    subscriber who is aware of the subscription, and sending a NOTIFY
>    message to an unsuspecting node.  The latter behavior is invalid, and
>    MUST receive a "481 Subscription does not exist" response (unless
>    some other 400- or 500-class error code is more applicable), as
>    described in section 3.2.4.  In other words, knowledge of a
>    subscription must exist in both the subscriber and the notifier to be
>    valid, even if installed via a non-SUBSCRIBE mechanism.
>   

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 22 Oct 2007 09:37:24 -0400

I'm clearly in the minority here, in preferring NOTIFY over INFO. 
(Minority of one?)

I agree that it is impossible to make definitive claims that something 
is easy to implement when talking about some hypothetical sip stack. So 
I will refrain from making such a claim from now on.

I also agree that the name of the method is secondary to getting the 
functionality right. So I am fine with leaving the decision about the 
method until everything else is worked out.

So, I think the next question is whether there should be a single event 
package definition mechanism for this new approach and for the 3265 type 
of events, or if these should be entirely disjoint. I realize existing 
event package definitions won't be applicable without at least some 
tweaks, and not all event types are suitable for both mechanisms. But I 
do think there are event types that are suitable for both mechanisms 
(e.g. dtmf and dialog) and it would be better if we didn't require 
independent definitions for them in both contexts.

What do others think of that?

	Thanks,
	Paul

---

From: "Sumit Garg" <[email-masked]>
Date: Mon, 22 Oct 2007 09:35:33 -0400

Unsolicited NOTIFYs are widely used for Voicemail and are allowed in
RFC3265
Please refer to the following section....

3.2. Description of NOTIFY Behavior
   NOTIFY messages are sent to inform subscribers of changes in state to
   which the subscriber has a subscription.  Subscriptions are typically
   put in place using the SUBSCRIBE method; however, it is possible that
   other means have been used.

   If any non-SUBSCRIBE mechanisms are defined to create subscriptions,
   it is the responsibility of the parties defining those mechanisms to
   ensure that correlation of a NOTIFY message to the corresponding
   subscription is possible.  Designers of such mechanisms are also
   warned to make a distinction between sending a NOTIFY message to a
   subscriber who is aware of the subscription, and sending a NOTIFY
   message to an unsuspecting node.  The latter behavior is invalid, and
   MUST receive a "481 Subscription does not exist" response (unless
   some other 400- or 500-class error code is more applicable), as
   described in section 3.2.4.  In other words, knowledge of a
   subscription must exist in both the subscriber and the notifier to be
   valid, even if installed via a non-SUBSCRIBE mechanism.

   A NOTIFY does not terminate its corresponding subscription; in other
   words, a single SUBSCRIBE request may trigger several NOTIFY
   requests.

-----Original Message-----
From: Brian Stucker [mailto:[email-masked]] 
Sent: Monday, October 22, 2007 4:24 AM
To: Dean Willis; Christer Holmberg
Cc: sip; Adam Roach; Paul Kyzivat; Michael Procter; Elwell,John
Subject: RE: [Sip] INFO

Regards,
Brian 

> Cc: Paul Kyzivat; sip; Elwell, John; Michael Procter; Adam Roach; 
> Stucker, Brian (RICH1:AR00)
> Subject: Re: [Sip] INFO
> 
>

---

From: Adam Roach <[email-masked]>
Date: Mon, 22 Oct 2007 08:53:28 -0500

> I'm clearly in the minority here, in preferring NOTIFY over INFO. 

It's ridiculously rare that I disagree with you, Paul, but I'm afraid
I'm going to have to weigh in on the "please don't use NOTIFY" camp. If
you go back and read Sumit's message of a few minutes ago, you'll see
that proper usage of NOTIFY is a matter is extreme confusion. What you
propose will muddy the waters enough that I fear they'll change from
"difficult to navigate" to "opaque and impossible to traverse at all."

> method until everything else is worked out.

I completely agree here. In fact, my top preference would be to define a
new method for this thing under discussion (paired with a deprecation of
the much-abused INFO); with my second choice being a package-based fixup
of INFO. Re-using NOTIFY would come in dead last -- by which I mean far
behind "let's re-purpose ACK for this new meaning."

> So, I think the next question is whether there should be a single 
> event package definition mechanism for this new approach and for the 
> 3265 type of events, or if these should be entirely disjoint. I 
> realize existing event package definitions won't be applicable without 
> at least some tweaks, and not all event types are suitable for both 
> mechanisms. But I do think there are event types that are suitable for 
> both mechanisms (e.g. dtmf and dialog) and it would be better if we 
> didn't require independent definitions for them in both contexts.

I think the similarities are superficial at best. Re-use of the MIME
type between these constructs would definitely be useful -- but I can't
see what you gain by attempting to re-use more than that.

/a

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 22 Oct 2007 09:56:43 -0400

Yes I think that makes a lot of sense.  So an RFC for event foo, would say whether it applies to Invite-usage and can be sent in an INFO.  But what if a new event does not make sense in a true Subscribe model?  Would 3265 mandate that an event definition support the event in a Subscribe-based usage?  I can think of at least two event types that would make sense in an INFO model but not in a Sub/Not.

-hadriel

> Sent: Monday, October 22, 2007 9:37 AM
> To: Brian Stucker
> Cc: Michael Procter; Hadriel Kaplan; Elwell, John; sip; Adam Roach
> Subject: Re: [Sip] INFO
>

---

From: Robert Sparks <[email-masked]>
Date: Mon, 22 Oct 2007 08:57:57 -0500

> I'm clearly in the minority here, in preferring NOTIFY over INFO.  

No Paul - not one.

Many - we've just been worn down and aren't being as vocal as we  
should. Thanks for keeping
up this end of the discussion. Others should chime in here. (Or is it  
just me and Paul?)

RjS

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 22 Oct 2007 09:58:38 -0400

Dean Willis wrote:
> popular phone adapters with blue boxes use unsolicited NOTIFY for their 
> message waiting indicators, and many operators seem to have deployed 
> them with some success, despite much gnashing of teeth on my part.

And apparently SBCs do too for this usage at least.

I gnash my teeth over this stuff too, and I don't carry water for those 
who decided to do so. But it does happen. And after awhile you do have 
to consider that maybe the standard stuff isn't sufficient if everybody 
wants to violate it.

Jonathan had a draft a long time ago about creating implicit 
subscriptions as part of registration. It isn't exactly the same 
problem, but I wonder if we ought to be examining the bigger problem of 
why the existing subscription mechanism isn't sufficient for all 
notification needs, and how best to fix that.

	Paul

---

From: "Sumit Garg" <[email-masked]>
Date: Mon, 22 Oct 2007 09:59:22 -0400

It says, knowledge of the subscription (as in for a service/event) and
not the subscribe dialog (as identified by the dialog identifiers, as
there isn't any...thus nothing for the proxy to work on). 481 applies to
knowledge of the dialog identifiers  and thus would be generated by an
unsuspecting UA who does not know about a dynamic (which has dialog ids)
subscription or one negotiated through other means. 

-----Original Message-----
From: Adam Roach [mailto:[email-masked]] 
Sent: Monday, October 22, 2007 9:40 AM
To: Sumit Garg
Cc: Brian Stucker; Dean Willis; Christer Holmberg; sip; Paul Kyzivat;
Michael Procter; Elwell,John
Subject: Re: [Sip] INFO

Um.... no.

/a

---

From: Robert Sparks <[email-masked]>
Date: Mon, 22 Oct 2007 09:02:48 -0500

Hrm. I may have sent that without thinking enough and without enough  
context.

I am guilty of not following this thread closely enough, and I  
replied to the wrong question I think.
To be sure - I'm over in the camp that says to use the whole SIP- 
Events framework to do these kinds
of things (I'm not supporting implicit subscriptions).

On Oct 22, 2007, at 8:57 AM, Robert Sparks wrote:

> up this end of the discussion. Others should chime in here. (Or is  
> it just me and Paul?)
>
> RjS

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 22 Oct 2007 10:12:59 -0400

> path for a wide variety of possible reasons. 

Note I said "*figure out how to be transparent* or else go away."

A B2BUA ought to do the policy enforcement it was *intended* to do, and 
not break anything else. If it was *intended* to block all but a 
specific set of standard usage patterns, then so be it. In that case as 
the specs evolve and the UAs that use the specs evolve to use the new 
features, then the B2BUA will have to evolve to allow the new usages 
that should now be considered legal.

A B2BUA (or proxy) that is in strict enforcement mode is as likely to 
block new headers as it is to block messages sent outside their expected 
context. So we will have similar problems with them no matter what 
approach we take.

> best we can in the environment we're given, not the one we wish we had.

I won't disagree. But we also have to assume that they will evolve to 
fit the changing standards. That is one advantage to standards relative 
to proprietary approaches.

At least I think we are, and should try to remain, in a position where 
the SBCs follow the standards, as opposed to where we are re NATs and 
FWs, where we have to go to ridiculous extremes (ICE) to work around them.

	Paul

---

From: Adam Roach <[email-masked]>
Date: Mon, 22 Oct 2007 09:17:09 -0500

Sumit Garg wrote:
> not the subscribe dialog (as identified by the dialog identifiers

The subscription inherently *includes* identifiers. An example of how 
this was intended to work at the time is REFER. You have a subscription 
that is created -- dialog identifiers and all -- using something other 
than a SUBSCRIBE. If you haven't exchanged enough information via *some* 
mechanism to have dialog identifiers, then there is no subscription.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 22 Oct 2007 10:19:32 -0400

Adam is the expert, since he is the author of 3265.
And ignoring that I still agree with him.

3265 says that the NOTIFY will be sent within a dialog, except in the 
case of forking, where the first NOTIFY may complete the establishment 
of a dialog.

Its impossible to have a 3265 compliant usage that doesn't somehow have 
that dialog. All the "unsolicited notify" MWI usages I am aware are sent 
without an established dialog, and so are non conforming to 3265.

	Paul

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 22 Oct 2007 17:28:37 +0300

> without an established dialog, and so are non conforming to 3265.

and are not a good idea.  if a SIP UA wants to receive MWI notifys, it
must first subscribe to them.

-- juha

---

From: "Brian Stucker" <[email-masked]>
Date: Mon, 22 Oct 2007 09:57:05 -0500

I know that, but it's a bad idea.

Regards,
Brian 

> From: Sumit Garg [mailto:[email-masked]] 
> Sent: Monday, October 22, 2007 8:36 AM
> To: Stucker, Brian (RICH1:AR00); Dean Willis; Christer Holmberg
> "The reasonable man adapts himself to the world; the 
> unreasonable one persists in trying to adapt the world to 
> himself. Therefore all progress depends on the unreasonable man."
> -- George Bernard Shaw
> 
> Let me send you my "Twinkle, twinkle, MWI" script. A few 
> hours of having the right people's phones blinking like 
> they're possessed will fix that.
> If not, you can still use it to create the most complicated 
> set of Christmas tree lights ever assembled.
> 
> Regards,
> Brian 
> 
> certain very

---

From: "Brian Stucker" <[email-masked]>
Date: Mon, 22 Oct 2007 10:05:21 -0500

> >> Cc: Stucker, Brian (RICH1:AR00); sip; Adam Roach; Michael Procter; 
> >> Elwell,John
> >> Subject: Re: [Sip] INFO
> >>
> >>
> >>
> >> Christer Holmberg wrote:
> >>> Hi,
> >>>  
> >> NOTIFY without any previous SUBSCRIBE. Is there a chance 
> it would act 
> >> on this, e.g. by sending a 4xx response, or are we sure it would 
> >> always simply forward the NOTIFY and assume the endpoint 
> will handle 
> >> it?
> >>
> >> If a B2BUA, it suffers the common problem that it needs to 
> be aware 
> >> of pretty much all the standards in use by those it is connecting.
> > 
> >> yes it might cause trouble. But we specify stuff all the time that 
> >> has similar issues with B2BUAs. Its up to B2BUAs to figure 
> out how to 
> >> be transparent or else go away.
> > 
> > case, and going to continue to be the case, that a great 
> deal of the 
> > SIP endpoints in this world will only be addressable with a 
> B2BUA in 
> > the path for a wide variety of possible reasons.
> 
> A B2BUA ought to do the policy enforcement it was *intended* 
> to do, and not break anything else. If it was *intended* to 
> block all but a specific set of standard usage patterns, then 
> so be it. In that case as the specs evolve and the UAs that 
> use the specs evolve to use the new features, then the B2BUA 
> will have to evolve to allow the new usages that should now 
> be considered legal.
> 
> A B2BUA (or proxy) that is in strict enforcement mode is as 
> likely to block new headers as it is to block messages sent 
> outside their expected context. So we will have similar 
> problems with them no matter what approach we take.

Yes, but allowing a new header is typically a matter of configuration.
Changing the transaction model for a given method is probably not.

> 
> > Before you flame me, go ask your system engineers how many SIP 
> > endpoints they've personally seen commercially deployed that were 
> > addressable via the Internet that were not protected by 
> some sort of 
> > ALG or B2BUA scheme that you'd be willing to post the 
> address of their 
> > SIP proxy and the usernames of several account holders there.
> > 
> > wind up building our own walled garden. We need to make things work 
> > the best we can in the environment we're given, not the one 
> we wish we had.
> 
> I won't disagree. But we also have to assume that they will 
> evolve to fit the changing standards. That is one advantage 
> to standards relative to proprietary approaches.

Eventually, but we need to be smart about how we go about fitting things
in where there are options available to us and show others the value of
supporting a particular standard that is important, etc. Just expecting
everyone to blindly go off and implement everything we write down is
obviously not realistic.

> 
> At least I think we are, and should try to remain, in a 
> position where the SBCs follow the standards, as opposed to 
> where we are re NATs and FWs, where we have to go to 
> ridiculous extremes (ICE) to work around them.
> 

Yes. We should strike a balance, where possible, for everyone's sake.

Regards,
Brian

---

From: Spencer Dawkins <[email-masked]>
Date: Mon, 22 Oct 2007 10:22:04 -0500

Just to synchronize with a parallel universe...

about five minutes after completing WGLC on MEDIACTRL requirements, we 
started wondering about scenarios where there's an SBC/B2BUA between the 
Application Server and Media Server.

We're having The Usual Discussion where some people are saying "SBCs can 
change our dialog identifier components (local-tag/call-ID/remote-tag), so 
we need a new header" and other people are saying "SBCs can drop new 
headers, so we DON'T need a new header".

Hilarity ensues.

I was especially pleased to see Paul's note:

> not break anything else. If it was *intended* to block all but a specific 
> set of standard usage patterns, then so be it. In that case as the specs 
> evolve and the UAs that use the specs evolve to use the new features, then 
> the B2BUA will have to evolve to allow the new usages that should now be 
> considered legal.
>

... at least I don't think we're missing something obvious (although it 
would have been nice if we were).

I strongly agree with Paul's final paragraph.

> At least I think we are, and should try to remain, in a position where the 
> SBCs follow the standards, as opposed to where we are re NATs and FWs, 
> where we have to go to ridiculous extremes (ICE) to work around them.
>
> Paul

Thanks,

Spencer

---

From: Adam Roach <[email-masked]>
Date: Mon, 22 Oct 2007 10:55:59 -0500

Allow me to clarify my position further here.

Robert is right: SUBSCRIBE/NOTIFY is the correct way to address these 
issues. If I had my druthers, we'd be using 3265 straight-up for these 
applications. My prior message was based on the assumption that we'd 
lost the "do this the right way" battle. Taken as a given, the options I 
outlined in my earlier note are an attempt at damage control.

/a

On 10/22/07 9:02 AM, Robert Sparks wrote:
> I am guilty of not following this thread closely enough, and I replied 
> to the wrong question I think.
> To be sure - I'm over in the camp that says to use the whole 
> SIP-Events framework to do these kinds

---

From: "Brian Stucker" <[email-masked]>
Date: Mon, 22 Oct 2007 11:29:35 -0500

> Sent: Monday, October 22, 2007 10:56 AM
> To: Robert Sparks
> Cc: Robert Sparks; sip; Paul Kyzivat; Stucker, Brian 
> (RICH1:AR00); Michael Procter; Elwell, John
> Subject: Re: [Sip] INFO
> 
> Robert is right: SUBSCRIBE/NOTIFY is the correct way to 
> address these issues. If I had my druthers, we'd be using 
> 3265 straight-up for these applications. My prior message was 
> based on the assumption that we'd lost the "do this the right 
> way" battle. Taken as a given, the options I outlined in my 
> earlier note are an attempt at damage control.

I for one am all for doing it the right way. I just don't want to muddy
up the usage for NOTIFY if at all possible because it frequently takes
people awhile to get 3265 right. Usages and dialogs are two areas that
people frequently get confused on so the fewer the use cases we have for
NOTIFY processing, the better. I'm just asking that a NOTIFY be
processed the same no matter how the subscription itself was created. It
sounded like this wasn't going to be the case.

Regards,
Brian

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Mon, 22 Oct 2007 13:03:19 -0400

Can the method name used for signaling be a negotiated parameter as
well, in addition to the event package? So if the endpoints in dialog
want to use NOTIFY, they can do that and if other pair of endpoints want
to use INFO or some new method, they can do that as long as both agree
on that.
Regarding concern of whether proxies in the middle of signaling path
will pass this NOTIFY along or not, the endpoints can exchange their
addresses as part of this event package negotiation, like c line in SDP.
So dtmf signaling will be sent end-to-end and will not traverse a proxy
that has added itself in signaling path with a RR header.

Sanjay

>From: Paul Kyzivat (pkyzivat) 
>I agree that it is impossible to make definitive claims that 
>something is easy to implement when talking about some 
>hypothetical sip stack. So I will refrain from making such a 
>claim from now on.
>
>I also agree that the name of the method is secondary to 
>getting the functionality right. So I am fine with leaving the 
>decision about the method until everything else is worked out.
>
>So, I think the next question is whether there should be a 
>single event package definition mechanism for this new 
>approach and for the 3265 type of events, or if these should 
>be entirely disjoint. I realize existing event package 
>definitions won't be applicable without at least some tweaks, 
>and not all event types are suitable for both mechanisms. But 
>I do think there are event types that are suitable for both 
>mechanisms (e.g. dtmf and dialog) and it would be better if we 
>>> On a similar note, I suspect that adding a header (Event?) to INFO 
>>> would be simpler than subtracting a mandatory header
>>> Of course, I am making a whole bunch of assumptions here 
>that aren't 
>>> necessarily true.  So maybe this decision can be postponed until a 
>>> few more details are ironed out.
>>>
>> 
>> added a new path in the code where the header is semi-mandatory and 
>> the information to determine when it is mandatory, and when 
>it is not, 
>> is not present in the message itself (so the stack may have 
>to ask the 
>> application what's going on when it's trying to verify that the 
>> message is minimally correct which may not be possible/desirable).
>> 
>> If I get an INFO with an event header in it, and I'm not looking for 
>> an event header in an INFO, then I'm no worse off than I am 
>today, right?

---

From: Adam Roach <[email-masked]>
Date: Mon, 22 Oct 2007 12:42:29 -0500

> that has added itself in signaling path with a RR header.

Say, I'm liking this idea. Perhaps we can encode the events with RTP 
headers as well, instead of using SIP. Most SBCs will let RTP through 
(and they may block peer-to-peer sip), so this has a really high chance 
of making it end-to-end.

Just as a strawman, perhaps we could actually include an indication of 
the event types in the SDP itself.   For example, if we wanted to use 
payload type number 100 to signal DTMF tones (events 0 through 15) and 
the dial and ringing tones (assuming as an example that these were 
defined as events with codes 66 and 70, respectively), we could include 
the following description in the SDP body:

      m=audio 12346 RTP/AVP 100
      a=rtpmap:100 telephone-event/8000
      a=fmtp:100 0-15,66,70

That should keep any meddlesome middleboxes out of the way altogether.

/a

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 22 Oct 2007 20:10:23 +0200

Hi,
 
I don't necessarily agree with Paul that NOTIFY is better than INFO in this case, but I DO agree with him that we should try to focus on the other issues.
 
We can use the INTIFY method "working name" for now. Later we can then decide to choose an existing method, or come up with something which sounds a little more sexy :)
 
Regards,
 
Christer

From: Paul Kyzivat [mailto:[email-masked]]
Sent: Mon 22/10/2007 15:37
To: Brian Stucker
Cc: sip; Adam Roach; Michael Procter; Elwell,John
Subject: Re: [Sip] INFO

        Thanks,
        Paul

---

From: "Brian Stucker" <[email-masked]>
Date: Mon, 22 Oct 2007 13:25:42 -0500

How about the DATA method. :)

http://old.iptel.org/ietf/callprocessing/interfaces/draft-stucker-sip-pu
blish-00.txt

I agree, let's figure out what we want to do before we get caught up
trying to optimize it.

Regards,
Brian 

> Sent: Monday, October 22, 2007 1:10 PM
> I don't necessarily agree with Paul that NOTIFY is better 
> than INFO in this case, but I DO agree with him that we 
> should try to focus on the other issues.
>  
> We can use the INTIFY method "working name" for now. Later we 
> can then decide to choose an existing method, or come up with 
> something which sounds a little more sexy :)
>  
> Regards,
>  
> Christer
> 
> getting the functionality right. So I am fine with leaving 
> the decision about the method until everything else is worked out.
> 
> mechanisms (e.g. dtmf and dialog) and it would be better if 
> we didn't require independent definitions for them in both contexts.
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 22 Oct 2007 20:40:13 +0200

>How about the DATA method. :)

Naaah.... sounds too much Star Trek ;)

---

From: Eric Burger <[email-masked]>
Date: Mon, 22 Oct 2007 08:55:21 -0700

On 10/17/07 2:18 PM, "Paul Kyzivat" <[email-masked]> wrote:
[snip] 
> the context of the event type.)

Which is not the way NOTIFY works today, which means the sender has to have
code to the effect:

   if( !real_notify(event_object) )
   {
      if( needs_first_notify(event_object) )
      {
         send_event(event_object);
      }
   }
   else
      send_event(event_object);

Just (1) changed NOTIFY behavior, making it "not NOTIFY" and raised the
complexity of your notification stack by 2.

[snip]
 
> exchanged are renegotiated from scratch with every reINVITE or UPDATE.

So what does the NOTIFY put into expires?  I hear hk now: "Just stuff it
with 99999."  OK, this now adds another hack into send_event(), "If I am a
real SUBSCRIPTION, return the timer; if I am not, return 99999."  Just upped
the complexity by 1.

Worse yet, what does the recipient do when it gets a BYE?  Now it has either
a resource leak or more code:

   if( got_bye(dialog_object) )
   {
      for each pseudo-dialog subscription in the (dialog_object)
      {
         consider the subscription terminated;
      }
   }

Upping the complexity by 2, again.

Hey - we are not done yet!  I will leave as an exercise to the reader the
amount of complexity added to create the implicit subscription in the first
place.

I forgot, this really is targeted for devices that will hard code everything
and not support any real SUBSCRIBE/NOTIFY packages.  [facetious]

It would be much cleaner to call this thing "NOTQUITENOTIFY".

Of course, since we are anal about messages and bandwidth, let's save 300ns
and just call the method "I".  [joking]

[snip]

---

From: Eric Burger <[email-masked]>
Date: Mon, 22 Oct 2007 08:20:01 -0700

It is a design feature of KPML, in fact, an advance in the state of the art,
for multiple, independent, unrelated applications to subscribe for user
stimulus from the same device.

Making multiple subscription handling at the device optional and not
mandatory was, IMHO, an unfortunate loss at the hands of work group
consensus.

However, stating that it is non-deterministic is incorrect.  The subsequent
subscribers know reliably the device rejected their subscription request.

On 10/16/07 6:59 PM, "Hadriel Kaplan" <[email-masked]> wrote:

> Actually, I'd argue the converse as well: there are applications where
> "advantage 1" is a disadvantage, or at least potentially confusing.  DTMF is a
> primary example of this.  If two app servers kpml subscribe to my Invite
> dialog, I will send them both the dtmf event, assuming the regex works out.
> Which one should act on it?  They both will.  Neither knows about the other.
> (although I should note I don't think supporting two kpml subscriptions is
> even required by rfc4730, which makes it even less deterministic, and gives up
> "advantage 1" anyway)
> 
> -hadriel
> 
> 
>

---

From: Eric Burger <[email-masked]>
Date: Mon, 22 Oct 2007 08:55:27 -0700

Folks, this is getting *way* out of hand.

We have one group of people saying we have working, interoperable, satisfies
all requirements, protocol mechanisms for event notification.

We also, I believe, have consensus, that in some corner cases, like
SIP-H.323 gateways, it would be nice to save two messages in each direction
by not having to explicitly subscribe for some events.

Now the question in my mind is, "How complex do we want to make SIP?"

Speaking as Chair and a Participant in the LEMONADE work group, I fully
endorse the work and, as often is the case, added complexity, to address
unique network topologies that impacts lots of users.  For more information
on LEMONADE, see:
http://www.ietf.org/html.charters/lemonade-charter.html
http://www.standardstrack.com/ietf/lemonade/

If I am willing to add quite a bit of complexity to what is considered a
complex protocol like IMAP, why am I pushing back on adding complexity to
SIP?  It is because mobile Internet access, and as such mobile E-Mail
access, is soon to become the predominant modality of user access.  Rather
than being an unusual corner case, mobile access, and its intermittent
connectivity, low power devices, and relatively low bandwidth issues, will
shortly be the normal case.

What is different here?  For one thing, we have had 13 years of experience
since RFC 1740 (IMAP4) was published.  Interestingly, at the time, bandwidth
and connectivity then was only slightly better than current mobile networks.
However, the content of messages has changed by orders of magnitude, which
has driven the need for adding complexity to the protocol suite to serve
this important market.

I do NOT see this situation here.

Review the archives of the past five days.  Many of the proposals are of the
vein:

1. Add something like accepts/sends to create an INFO-in-an-INVITE
mechanism, but if you need to say anything, use SUBSCRIBE/NOTIFY

2. Add something like implicit subscriptions to NOTIFY, somewhat specified
in an INVITE, but if you need to say anything, use SUBSCRIBE/NOTIFY

3. (1) above isn't INFO, so we have to create a new method and state machine
to support it.

4. (2) above is *not* NOTIFY (I'll address that in a separate thread), so we
have to create a new method and state machine to support it.

5. If you do not buy my argument (2) is not the same as the existing NOTIFY,
it means you will be putting a bunch of "if" statements, as the behavior
will be different if there is an explicit SUBSCRIBE outside a dialog or an
implicit SUBSCRIBE within an INVITE-initiated dialog.

With regards to point 5, I strongly urge those in the SIP audience that do
not have Computer Science degrees to review Cyclomatic Complexity (McCabe).

Adding complexity to the protocol *stack* to optimize a corner case is, in
the words of my eldest, "less than ideal."

Please let us not go there.

On 10/18/07 8:46 AM, "Paul Kyzivat" <[email-masked]> wrote:

[snip]

[snip]

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 22 Oct 2007 18:22:14 -0400

Eric,

Please note that I would be happy to keep telling people to use the 
standards as they are. But that doesn't seem to be working, and I don't 
see any way to *make* it work. (Its not working on this list, and its 
not working for me inside my employer's domain either.)

So the alternative seems to be to try and discover *something* that 
isn't fatally flawed, that we could successfully get people to use in 
those cases where they won't use what we already have.

I view this discussion as trying to figure out what, if anything, that 
*something* might be.

IMO something *similar* to a subscription, which allows negotiation of 
what is to be subscribed to, but without the extra round trips to set up 
and tear down, seems like it could do the trick. The specific details 
are all negotiable. But I think something that can incorporate and 
coexist with "real" event packages that do the same thing would be a plus.

	Paul

---

From: Eric Burger <[email-masked]>
Date: Mon, 22 Oct 2007 15:57:19 -0700

Not *factors* of 2 or 4, but cyclomatic complexity increasing by a *count*
of 2 or 4.

However, the result is similar: there is tons of Software Engineering data
that shows when modules get above a cyclomatic comlexity of 7, the number of
latent defects raises non-linearly.

Henning (or some lurker looking for something to do): an interesting
Master's Thesis would be to calculate the theoretical minimum cyclomatic
complexity of the current SIP state machine.  That may answer the, "Why SIP
does not interoperate" question.

On 10/22/07 3:30 PM, "Paul Kyzivat" <[email-masked]> wrote:

> Eric,
> 
> I disagree with your *quantitative* assessments of how much thee things
> increase complexity (by factors of 2 or 4). But I certainly agree that
> complexity *will* increase.
> 
> In the end everything we are doing increases complexity, so maybe we
> should all pack up shop and go home.
> 
> Ultimately this all comes down to deciding how complex things have to
> get before people can do what they think they need to do.
> 
>         Paul
> 
> Eric Burger wrote:
>> 
>> 
>> Notice:  This email message, together with any attachments, may contain
>> information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
>> entities,  that may be confidential,  proprietary,  copyrighted  and/or
>> legally privileged, and is intended solely for the use of the individual or
>> entity named in this message. If you are not the intended recipient, and have
>> received this message in error, please immediately return this by email and
>> then delete it.
>> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 22 Oct 2007 18:30:28 -0400

Eric,

	Paul

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Mon, 22 Oct 2007 20:03:10 -0400

Well there is a trade-off, of complexity vs. less number of messages
required to negotiate a signaling mechanism for dtmf or mid-call
signaling data exchange.
In absence of a standard way of doing implementations have been using
other mechanisms like INFO or unsolicited Notify, which works well
within so called walled gardens. This whole thread started with a
realization that INFO is not correct for such a mechanism. So either we
agree and work out something which is standard or live with proprietary
implementations.

Thanks.

>Sent: Monday, October 22, 2007 6:57 PM
>To: Paul Kyzivat (pkyzivat)
>Cc: sip
>Subject: Re: NOTIFY proposal is not NOTIFY (was Re: [Sip] INFO)
>
>Not *factors* of 2 or 4, but cyclomatic complexity increasing 
>by a *count* of 2 or 4.
>
>However, the result is similar: there is tons of Software 
>Engineering data that shows when modules get above a 
>cyclomatic comlexity of 7, the number of latent defects raises 
>non-linearly.
>
>Henning (or some lurker looking for something to do): an 
>interesting Master's Thesis would be to calculate the 
>theoretical minimum cyclomatic complexity of the current SIP 
>state machine.  That may answer the, "Why SIP does not 
>interoperate" question.
>
>
>> I disagree with your *quantitative* assessments of how much thee 
>> things increase complexity (by factors of 2 or 4). But I certainly 
>> agree that complexity *will* increase.
>> 
>>>> within the INVITE dialog usage. Whether an initial NOTIFY is 
>>>> required will be determined on a per-event-package basis. (Its not 
>>>> needed to establish the dialog, so its a matter if it is 
>>>> semantically needed in the context of the event type.)
>>> 
>>> Which is not the way NOTIFY works today, which means the sender has 
>>> to have code to the effect:
>>> 
>>> Just (1) changed NOTIFY behavior, making it "not NOTIFY" and raised 
>>> the complexity of your notification stack by 2.
>>> 
>>> [snip]
>>> 
>>>> refreshed by INVITE or UPDATE in the conventional manner. 
>Events to 
>>>> be exchanged are renegotiated from scratch with every 
>reINVITE or UPDATE.
>>> 
>>> So what does the NOTIFY put into expires?  I hear hk now: 
>"Just stuff 
>>> it with 99999."  OK, this now adds another hack into send_event(), 
>>> "If I am a real SUBSCRIPTION, return the timer; if I am not, return 
>>> 99999."  Just upped the complexity by 1.
>>> 
>>> Worse yet, what does the recipient do when it gets a BYE?  
>Now it has 
>>> either a resource leak or more code:
>>> 
>>> Hey - we are not done yet!  I will leave as an exercise to 
>the reader 
>>> the amount of complexity added to create the implicit 
>subscription in 
>>> the first place.
>>> 
>>> I forgot, this really is targeted for devices that will hard code 
>>> everything and not support any real SUBSCRIBE/NOTIFY packages.  
>>> [facetious]
>>> 
>>> Of course, since we are anal about messages and bandwidth, 
>let's save 
>>> 300ns and just call the method "I".  [joking]
>>> 
>>> [snip]
>>> 
>>> 
>individual or entity named in this message. If you are not the 
>intended recipient, and have received this message in error,

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 22 Oct 2007 22:09:32 -0400

> real SUBSCRIPTION, return the timer; if I am not, return 99999."  Just
> upped the complexity by 1.

Au contraire.  I explicitly noted these types of issues in my emails as an argument for why it should not create a true Subscription in the 3265 sense of the word, and not use the Notify method.  We should just exchange the events we support in the Invite/response, and use the already-available Invite dialog and usage, and the already existent Info method to carry the events.

-hadriel

---

From: "Brian Stucker" <[email-masked]>
Date: Mon, 22 Oct 2007 21:33:31 -0500

There's a difference. Creating complexity in parallel to existing
mechanisms is one thing because it's optional you can pick and choose
the complexity you want. Overlaying it on top of an existing mechanism
is much worse. That's the concern I've had about using NOTIFY that Eric
did a much better job of quantifying than I have been. I'm worried about
stateful middleboxes that are going to have to figure out what the heck
just happened with this weird NOTIFY and why this isn't an error to them
even though they don't support it. You changed the rules of the game in
a non-backwards-compatible way.

Regards,
Brian 

> Sent: Monday, October 22, 2007 5:30 PM
> To: Eric Burger
> Cc: sip
> I disagree with your *quantitative* assessments of how much 
> thee things increase complexity (by factors of 2 or 4). But I 
> certainly agree that complexity *will* increase.
> 
> In the end everything we are doing increases complexity, so 
> maybe we should all pack up shop and go home.
> 
> Ultimately this all comes down to deciding how complex things 
> have to get before people can do what they think they need to do.
> 
> 	Paul
> 
> Eric Burger wrote:
> > 
> > 
> > Which is not the way NOTIFY works today, which means the 
> sender has to 
> > have code to the effect:
> > 
> > it with 99999."  OK, this now adds another hack into 
> send_event(), "If 
> > I am a real SUBSCRIPTION, return the timer; if I am not, return

---

From: "Brian Stucker" <[email-masked]>
Date: Mon, 22 Oct 2007 21:38:10 -0500

> Sent: Monday, October 22, 2007 9:10 PM
> To: Eric Burger; Paul Kyzivat
> Cc: sip
> Subject: RE: NOTIFY proposal is not NOTIFY (was Re: [Sip] INFO)
> 
> 
> 
> Au contraire.  I explicitly noted these types of issues in my 
> emails as an argument for why it should not create a true 
> Subscription in the 3265 sense of the word, and not use the 
> Notify method.  We should just exchange the events we support 
> in the Invite/response, and use the already-available Invite 
> dialog and usage, and the already existent Info method to 
> carry the events.
> 
> -hadriel
> 

If you wanted to be really evil Eric, you should have said that the
expires header would be stuffed with "%39%39%39%39%39" so you had to put
something in the middle to fix it because the other end's parser would
choke otherwise. :)

It seems like using INFO in the way Hadriel describes is entirely
backwards compatable to existing INFO processing and solves the problem.
Are we arguing asthetics here or does it really absolutely have to be
NOTIFY given that the event packages themselves will likely need to be
tweaked a little to support this usage anyhow?

Regards,
Brian

---

From: "Brian Stucker" <[email-masked]>
Date: Mon, 22 Oct 2007 21:46:58 -0500

You started it. :)

I'm fine with leaving things well enough alone, declaring victory,
moving on, and letting someone who needs an INFO like mechanism be the
one to go through the torture of defining something that everyone can
agree upon or living with RFC-3265 for their purposes. No more uses of
INFO will be approved in the future, no evaluation given about existing
uses, and a pointer off to the email archives for futher information
(perhaps an informational reference? Is that allowed? Hmmm...)

Pretty soon I think we're going to have sent the equivalent number of
email messages on this topic INFO to have conveyed a single DTMF digit
using KPML.

:)

Regards,
Brian 

> Sent: Monday, October 22, 2007 10:55 AM
> Subject: Complexity (was Re: [Sip] INFO)
> 
> We have one group of people saying we have working, 
> interoperable, satisfies all requirements, protocol 
> mechanisms for event notification.
> 
> SIP-H.323 gateways, it would be nice to save two messages in 
> each direction by not having to explicitly subscribe for some events.
> 
> Speaking as Chair and a Participant in the LEMONADE work 
> group, I fully endorse the work and, as often is the case, 
> added complexity, to address unique network topologies that 
> impacts lots of users.  For more information on LEMONADE, see:
> If I am willing to add quite a bit of complexity to what is 
> considered a complex protocol like IMAP, why am I pushing 
> back on adding complexity to SIP?  It is because mobile 
> Internet access, and as such mobile E-Mail access, is soon to 
> become the predominant modality of user access.  Rather than 
> being an unusual corner case, mobile access, and its 
> intermittent connectivity, low power devices, and relatively 
> low bandwidth issues, will shortly be the normal case.
> 
> What is different here?  For one thing, we have had 13 years 
> of experience since RFC 1740 (IMAP4) was published.  
> Interestingly, at the time, bandwidth and connectivity then 
> was only slightly better than current mobile networks.
> However, the content of messages has changed by orders of 
> magnitude, which has driven the need for adding complexity to 
> the protocol suite to serve this important market.
> 
> 1. Add something like accepts/sends to create an 
> INFO-in-an-INVITE mechanism, but if you need to say anything, 
> use SUBSCRIBE/NOTIFY
> 
> 2. Add something like implicit subscriptions to NOTIFY, 
> somewhat specified in an INVITE, but if you need to say 
> anything, use SUBSCRIBE/NOTIFY
> 
> 3. (1) above isn't INFO, so we have to create a new method 
> and state machine to support it.
> 
> 4. (2) above is *not* NOTIFY (I'll address that in a separate 
> thread), so we have to create a new method and state machine 
> to support it.
> 
> 5. If you do not buy my argument (2) is not the same as the 
> existing NOTIFY, it means you will be putting a bunch of "if" 
> statements, as the behavior will be different if there is an 
> explicit SUBSCRIBE outside a dialog or an implicit SUBSCRIBE 
> within an INVITE-initiated dialog.
> 
> With regards to point 5, I strongly urge those in the SIP 
> audience that do not have Computer Science degrees to review 
> Cyclomatic Complexity (McCabe).
> 
> Adding complexity to the protocol *stack* to optimize a 
> corner case is, in the words of my eldest, "less than ideal."
> 
> > SIP is not simple. If you have mastered doing the rest of sip then 
> > this is not a burden. IMO people are more concerned with extra 
> > messages and extra state than they are with making it extra simple.
> >

---

From: [email-masked]
Date: Mon, 22 Oct 2007 23:12:50 -0400

From: Dean Willis <[email-masked]>

   Many proxies blindly forward NOTIFY.

I would hope so; a proxy doesn't get to decide whether the use of a
request is OK, it is required to pass it to the UAS.

Dale

---

From: Adam Roach <[email-masked]>
Date: Mon, 22 Oct 2007 23:51:05 -0500

Francois Audet wrote:
>  
> Man, I stopped looking for a few seconds, and we are still talking about
> INFO????
>
> For the record, I don't care that much what we do. I'd say in order of
> preference: 
> 	(1)
> SUB/NOTIFY-as-is-and-leave-us-alone-we-are-too-busy-and-who-cares-anyway
> s 
> 	(2) NOTIFY-with-SUBSCRIBE-squished-into-INVITE
> 	(3) INFO+negoatiation_mechanism
>
> And for why (2) before (3), it's probably because I don't understand
> Adam's point that
> this is the worst possible idea even (worst that repurposing ACK).
>   

If by (2) you're talking about a SUBSCRIBE-initiated subscription usage 
in the same dialog as an INVITE usage, it's not nearly as bad. (It's 
still bad; c.f. the pain with REFER and [as a separate issue] the 
difficulty managing multiple usages in a dialog). What I was responding 
to was a proposal (by my reading) that some new header in INVITE would 
mean "start sending me NOTIFY messages."

If that didn't make you shudder, you missed something. Go back and 
re-read it.

For the bystanders: one problem is that you're changing what INVITE 
means, and you're changing what NOTIFY means -- and in a very 
non-trivial fashion. Eric has some good, practical examples in this 
thread about why this creates nearly untenable complexity for user agents.

We've also known for many years now that one method with two effects is 
bad -- it is very difficult to account for the various failure and 
half-failure modes that result if one of the effects doesn't go as planned.

/a

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 23 Oct 2007 06:48:26 +0200

Hi,
 
A very good mail, Paul.
 
The thing we have been looking at is a mechanism to provide something which the following characteristics:
 
1. Something similar to subscriptions; and
2. Something which allows "negotiation" without extra roundtrips
2. Something which does not require separate dialogs for each type of data and each direction (i.e. something which is used as part of an invite dialog usage).

Yes, there are many questions (which method to use etc) that have to be answered before we have a solution, but we have to start somewhere.
 
I have started to work on a high-level draft on this.
 
OR - we could write a Master Thesis showing there is no problem, ignore the input we get from the real world, and simply tell people to use what we have instead...

Regards,
 
Christer

From: Paul Kyzivat [mailto:[email-masked]]
Sent: Tue 23/10/2007 00:22
To: Eric Burger
Cc: sip
Subject: Re: Complexity (was Re: [Sip] INFO)

Eric,

        Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 23 Oct 2007 09:30:06 +0200

Hi, 

>>Man, I stopped looking for a few seconds, and we are still talking
about INFO????
>>Adam's point that this is the worst possible idea even (worst that 
>>repurposing ACK).
>>   
> 
>If by (2) you're talking about a SUBSCRIBE-initiated 
>subscription usage in the same dialog as an INVITE usage, 
>it's not nearly as bad. (It's still bad; c.f. the pain with 
>REFER and [as a separate issue] the difficulty managing 
>multiple usages in a dialog).

The idea is that you have only ONE SINGLE usage - the invite usage.
Within that usage you then have something similar to "subscriptions" (if
people get confused by that wording, then let's use something else).

Ie you are NOT using INVITE in order to establish a separate
subscription usage - ONLY to establish an invite usage (which then
contains something similar to subscriptions).

>What I was responding to was a proposal (by my reading) that some new
header in INVITE would 
>mean "start sending me NOTIFY messages."

Yes.

>If that didn't make you shudder, you missed something. Go 
>back and re-read it.
> 
>For the bystanders: one problem is that you're changing what 
>INVITE means, and you're changing what NOTIFY means -- and in 
>a very non-trivial fashion. Eric has some good, practical 
>examples in this thread about why this creates nearly 
>untenable complexity for user agents.

I don't think you are changing what INVITE means: You use INVITE to
establish an invite usage - as you have done since the day SIP was born.

What you ARE doing is enhancing the invite usage, by adding something
the possibility to send something similar to events within it.

>We've also known for many years now that one method with two 
>effects is bad -- it is very difficult to account for the 
>various failure and half-failure modes that result if one of 
>the effects doesn't go as planned.

The idea is that nothing changes. You would only have a single invite
usage, and everything within shares the fate of that usage.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 23 Oct 2007 09:18:48 -0400

> latent defects raises non-linearly.

I'm not really a student of that stuff, but I believe that is for one 
function or other closed unit of code.

When you take a system, if you add the complexity of each piece then of 
course you get a huge number. In theory you don't have to do that 
because the system is hierarchically decomposed into pieces each with 
acceptable complexity, and in *theory* you can understand them one at a 
time.

However I have yet to see a reasonable sized system where the overall 
structure of all the pieces didn't introduce another kind of practical 
complexity that AFAIK isn't normally measured.

> complexity of the current SIP state machine. 

For one thing, SIP can't really be evaluated with a state machine 
because it has stacks. (Via and Route headers, etc.) But that doesn't 
really change the discussion.

I'm not sure its a meaningful question. But it seems like if it could be 
answered, the answer would have to be in the thousands, or more, when 
viewed as a whole. (Which is why adding two or four is irrelevant.)

To get a more meaningful number you would have to decompose it into a 
hierarchy of state machines (or functions, objects and methods, ...) and 
then find the worst case complexity of all those.

> That may answer the, "Why SIP

I certainly agree that SIP is very complex, contrary to the claims that 
were made for it early in its life. I don't have enough context to 
compare it complexity to that of earlier systems for the same job - it 
is my impression that they are worse.

The complexity is why we have been writing guides and clarification 
documents, etc. (They don't *fix* the complexity, but they may help 
people to master it.)

I do appreciate the point that the complexity arises one decision at a 
time, and we should always be trying to make things as simple as we can, 
given what we have to do.

It always comes down to: is the benefit of this new feature worth the 
complexity that it brings. Not everybody comes to the same answer about 
such a question.

	Paul

---

From: Dean Willis <[email-masked]>
Date: Tue, 23 Oct 2007 11:24:48 -0500

On Oct 22, 2007, at 8:37 AM, Paul Kyzivat wrote:

> event package definition mechanism for this new approach and for  
> the 3265 type of events, or if these should be entirely disjoint. I  
> realize existing event package definitions won't be applicable  
> without at least some tweaks, and not all event types are suitable  
> for both mechanisms. But I do think there are event types that are  
> suitable for both mechanisms (e.g. dtmf and dialog) and it would be  
> better if we didn't require independent definitions for them in  
> both contexts.

I also favor a single class of event package registrations, and  
leaving it to each event package to whether and how it works in each  
mode.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Tue, 23 Oct 2007 11:32:11 -0500

On Oct 22, 2007, at 10:55 AM, Adam Roach wrote:

> Robert is right: SUBSCRIBE/NOTIFY is the correct way to address  
> these issues. If I had my druthers, we'd be using 3265 straight-up  
> for these applications. My prior message was based on the  
> assumption that we'd lost the "do this the right way" battle. Taken  
> as a given, the options I outlined in my earlier note are an  
> attempt at damage control.
>

I believe that the empirical evidence of a heck of a lot of  
implementations indicates that there are use cases where people would  
rather not have a full-blown event dialog in parallel to an INVITE  
dialog for very good reasons of capacity and complexity, but still  
need event passing. The original use of INFO for midcall telephony  
signaling is just one example of this.

--
Dean

---

From: Adam Roach <[email-masked]>
Date: Tue, 23 Oct 2007 16:15:59 -0500

On 10/23/07 11:32 AM, Dean Willis wrote:
>> issues. If I had my druthers, we'd be using 3265 straight-up for 
>> these applications. My prior message was based on the assumption that 
>> we'd lost the "do this the right way" battle. Taken as a given, the 
>> options I outlined in my earlier note are an attempt at damage control.
>>
>

Right. So, dust off your old INFO package draft and re-issue it. It 
appears to address the issue you describe while really only being 
objectionable under some relatively fringe objections (mine included).

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 23 Oct 2007 16:25:38 -0500

On 10/23/07 11:24 AM, Dean Willis wrote:
>> better if we didn't require independent definitions for them in both 
>> contexts.
>
> leaving it to each event package to whether and how it works in each mode.

I think this is a bit odd and potentially dangerous.

If you look at an event package, it defines two classes of information: 
a lot of stuff that's pretty specific to 3265 mechanisms, and a syntax 
for conveying information. I think the syntax (i.e., MIME type) has a 
good chance of being re-usable between event packages and INFO packages. 
Everything else won't apply.

The danger come in trying to crowbar in various 3265-related extensions 
and applying them to INFO. Partial notifications? Throttling? Filtering? 
Etags? You want to figure out how all of those work with INVITE/INFO? 
You take on making these things event packages straight up, and that's 
where we'll end up.

Define a different set of INFO packages for things that make sense in 
INFO, and things are much cleaner. I think you'll find the set of 
existing event packages that make sense to "optimize" using INFO is very 
small -- with so little overlap, I don't believe you gain anything.

/a

---

From: Eric Burger <[email-masked]>
Date: Wed, 24 Oct 2007 15:18:39 -0700

You are absolutely correct: one calculates complexity per-module.
Decomposition is accounted for by adding 1 to the module complexity (to
account for calls).

The "things get dramatically worse when complexity exceeds 7" statement was
with reference to any given module, *not* the entire stack.  If that was the
case, we never would have made it down the elevator, no less to the moon.

On 10/23/07 6:18 AM, "Paul Kyzivat" <[email-masked]> wrote:

>>>> everything