Subject: RE: [Sip] INFO

From: "Brian Stucker" <[email-masked]>
Date: Mon, 1 Oct 2007 03:01:11 -0500

> -----Original Message-----
> From: Adam Roach [mailto:[email-masked]] 
> Sent: Thursday, September 27, 2007 11:05 AM
> To: Barnes, Mary (RICH2:AR00)
> Cc: [email-masked]
> Subject: Re: [Sip] INFO
> 
> On 9/27/07 10:22 AM, Mary Barnes wrote:
> > And, here's another very old one:
> >
> > 
> http://quimby.gnus.org/internet-drafts/draft-choudhuri-sip-info-digit-
> > 00
> > .txt
> >   
> 
> Aha! Thanks. I conflated "using application/dtmf" with 
> "transporting DTMF in info", which is a somewhat broader 
> category. My read is that Hadriel and Brian were promoting a 
> specific solution (application/dtmf), which may well not be the case.

No. It is not the case. Sorry, I didn't realize you were thinking I was
promoting a specific INFO solution. I'm trying to figure out where the
harm is being done here (read on) by sending them.

> 
> So, plodding down that path (and going through the old 
> arguments regarding DTMF in INFO), I am reminded that Jiri 
> had a draft proposing DTMF in INFO using MGCP; and Bert 
> Culpepper mentions this same approach in a later draft.

Don't forget Rohan mentioned a similar approach in a draft some time ago
http://www.softarmor.com/wgdb/docs/draft-mahy-sipping-signaled-digits-00
.txt

> 
> But, going back to the discussion at hand: Brian and Hadriel 
> seem to be specifically promoting carrying "appliction/dtmf" 
> in INFO. Since I can only guess at their motiviations, I'll 
> leave it to them to indicate whether an 
> "application/vnd.nortelnetworks.digits" or "message/mgcp" 
> approach would make them happy.

Well, now that you bring up application/vnd.nortelnetworks.digits, it
really should have been application/com.nortelnetworks.digits (that's
bugged me for years)... We do 2833 as well, so I'm not arguing for the
sake of our own ancient MIME type (nor endorsing it either).

Let me be the very first to say that the existance of a draft, no matter
how old, does not make something a good idea. However, just because
something isn't popular doesn't make it wrong or harmful either.

If people wish to deprecate something purely for asthetic reasons, I
simply do not support such an argument. I believe the deprecation of all
uses of INFO OTHER than SIP-T is exactly for this reason. Why? Because
we're allowing SIP-T.

Ask yourself this question: if you are the terminator of a SIP-T call,
what are your requirements as part of RFC-3372? Here they are for quick
reference:

   "Terminator requirements: standard SIP processing, interpretation of
   encapsulated ISUP (for gateways only), support for multipart MIME,
   graceful handling of unknown MIME content (for non-gateways only)."

Further (also from the RFC):

   "In case of an IP termination ..., the SIP UAS that receives
   SIP messages with encapsulated ISUP typically disregards the ISUP
   message.  This does introduce a general requirement, however, that
   devices like SIP phones handle multipart MIME messages and unknown
   MIME types gracefully (this is a baseline SIP requirement, but also a
   place where vendors have been known to make shortcuts)."

So if we're allowing SIP-T, which builds off of a baseline SIP
requirement that if you get a MIME type or method (INFO) that you don't
understand, that you gracefully handle this: send a 415/488 or send a
405, respectively, then why are we disallowing other uses of INFO that
do not introduce ANY requirements beyond those of SIP-T which we are
allowing?

Here's another question for the readers: let's say Eric's draft becomes
an RFC as written for sake of argument. What happens when a UA that does
not support SIP-T gets a call from an ISUP gateway and gets an INFO with
encapsulated ISUP in the message body? How does this processing differ
from an endpoint getting encapsulated DTMF in a format it may not
understand? It doesn't differ because it can't: the UA cannot
differentiate between two different MIME types when it does not
recognize either of them.

I don't want a negotiation mechanism for INFO because I don't see a need
for one. It's already there: 405, 415, and 488. If you don't support my
MIME type, then my functionality is broken, not yours (unless you put my
MIME type in your accept header). That's true of every MIME type in SIP
other than SDP as part of an INVITE transaction as near as I can tell.
If 405, 415, 488, allow, and accept are broken then let's fix that.
Heck, the biggest usage (by volume) I see of INFO is for long-call
audits where it carries absolutely no message body at all. How is this
worse than sending an OPTIONS (which is allowed)?

If someone can clearly address this argument and show how harm is being
done and that RFC-3261 is not adequate to address this situation I'll
shut up about deprecating INFO because then I think we'll have done
three things: identified the real root cause of the problem, identified
a problem in the baseline specification that needs to be fixed, and
written a set of guidelines that others can clearly see why they
shouldn't use INFO beyond the reason that sending something to someone
else that they may not understand is bad, which would be a much shorter
draft and not limited to INFO at all.

Regards,
Brian

_______________________________________________
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: "Brian Stucker" <[email-masked]>
Date: Mon, 1 Oct 2007 03:22:51 -0500

> From: Spencer Dawkins [mailto:[email-masked]] 
> Sent: Thursday, September 27, 2007 10:03 AM
> To: [email-masked]
> Subject: Re: [Sip] INFO
> 
> >> Eric's document basically takes the second approach, 
> grandfathering 
> >> all uses of INFO that are currently published in an RFC or 
> an active 
> >> internet-draft, and forbidding any others. The list is not 
> long; I'll 
> >> replicate it here:
> >>
> >>   1. RFC 3372
> >>
> >> You want more than that, you really need packages.
> >
> > Expand that list to include application/dtmf and I think you'll 
> > largely end the debate.
> 
> It would be a lovely thing for this debate to end. Perhaps we 
> could refocus with that aim in mind. Since I'm Eric's 
> instigator, I'm asking that we remember how we got here.

Spencer,

I'm not debating the problem, I'm trying to figure out what the
underlying problem realy *IS* so it's addressed properly. I could care
less about application/dtmf or application/vnd.nortelnetworks.digits or
any of the other myriad MIME types that may get sent in an INFO. I
suggested adding the MIME types as a way to get agreement from others,
but it's not what I'm worried about at all.

[SNIP]
 
> If we could focus on Eric's draft, which does not deprecate 
> existing standards-track uses of INFO, that might get us to 
> publication of a draft that would discourage additional uses 
> of INFO, and provide the explanation for this, so that random 
> RAI-area drafts (which aren't even in the SIP working group) 
> stop including text that explains Why We Aren't Using INFO - 
> text that may or may not reflect SIP working group consensus.

It's the explanation and allowance of SIP-T that (for me) is causing the
problem because it makes the document really unclear as to what the
actual harm being done here is. It's not clear to me at all why INFO
should be deprecated based upon the arugment that sending stuff to
someone that they might not understand, when gracefully handling such is
a baseline requirement of 3261 and SIP-T itself and is not at all
limited to INFO.

If this is the real problem that we're trying to address, then write a
draft that says that sending things that you're not sure the other side
will understand is a bad idea, here's why, and don't make one SIP method
the whipping boy for an entirely different problem that can arise in any
SIP method.

The biggest use of INFO that I see (by volume) contains no message body
at all. I tried to point this out earlier so it could be included in the
draft but the messenger got shot instead. INFO gets used to detect if
the dialog, and therefore the call, is still alive. In this usage it
does not differ from sending an OPTIONS as a mid-dialog request which is
allowed by RFC-3261. The draft makes no mention of this usage and does
not address why this is harmful (as opposed to OPTIONS) as a result. If
this is harmful, then sending an OPTIONS in mid-dialog is harmful too,
we should deprecate that as well.

If sending MIME types that you're not sure the other side understands is
harmful, then we should always start out a call by sending an OPTIONS
prior to the INVITE so that we can be sure that the MIME types we may
include in a multi-part offer are understood. Let's put that in there
too if unknown MIME types is the real problem to be solved.

Regards,
Brian

---

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

> do not introduce ANY requirements beyond those of SIP-T which we are

This raises the argument that SIP-T should be revisited to more  
clearly negotiate support for the material being tunneled, including  
the context in which it is being tunneled. My UA might, for example,  
know how to render an ISUP message using a pretty-printer. That  
doesn't mean it knows how to do SIP-T for gateways.

So, SIP-T is broken and likely to give surprising results. That is  
not a hearty argument for endorsing the technique of SIP-T for other  
functions.

> recognize either of them.

But assume the UA DOES recognize the MIME type. How does it know what  
to do with it? Is content-disposition adequate?

If it were, why would we have the higher-level negotiation of event  
contexts?

--
Dean

---

From: "Brian Stucker" <[email-masked]>
Date: Tue, 2 Oct 2007 13:53:00 -0500

> From: Dean Willis [mailto:[email-masked]] 
> Sent: Tuesday, October 02, 2007 11:47 AM
> To: Stucker, Brian (RICH1:AR00)
> Cc: Adam Roach; Barnes, Mary (RICH2:AR00); [email-masked]
> Subject: Re: [Sip] INFO
> 
> 
> > requirement that if you get a MIME type or method (INFO) that you 
> > don't understand, that you gracefully handle this: send a 
> 415/488 or 
> > send a 405, respectively, then why are we disallowing other uses of 
> > INFO that do not introduce ANY requirements beyond those of SIP-T 
> > which we are allowing?
> >
> 
> This raises the argument that SIP-T should be revisited to 
> more clearly negotiate support for the material being 
> tunneled, including the context in which it is being 
> tunneled. My UA might, for example, know how to render an 
> ISUP message using a pretty-printer. That doesn't mean it 
> knows how to do SIP-T for gateways.
> 
> So, SIP-T is broken and likely to give surprising results. 
> That is not a hearty argument for endorsing the technique of 
> SIP-T for other functions.

Nor is it a hearty argument for clarifying what's wrong with INFO by
allowing it.

> 
> 
> > Here's another question for the readers: let's say Eric's draft 
> > becomes an RFC as written for sake of argument. What 
> happens when a UA 
> > that does not support SIP-T gets a call from an ISUP 
> gateway and gets 
> > an INFO with encapsulated ISUP in the message body? How does this 
> > processing differ from an endpoint getting encapsulated DTMF in a 
> > format it may not understand? It doesn't differ because it 
> can't: the 
> > UA cannot differentiate between two different MIME types 
> when it does 
> > not recognize either of them.
> 
> But assume the UA DOES recognize the MIME type. How does it 
> know what to do with it? Is content-disposition adequate?

Depends on how it recognizes it to my mind. I recognize you when I see
you, and I recognize my 5-month old son when I see him, but I don't need
a sticky on your foreheads to tell me how I should interact with you. 

If we're saying that everything about how a UA handles a MIME type has
to be meticulously stipulated in the signaling, then I think there's a
lot more out there that's broken than INFO. Basically, you wouldn't be
able to introduce any MIME type into your signaling assuming that the
other end will gracefully deal with it if it doesn't know what to do
with it. How many MIME types are out there and how many of them have
been specifically specified as to how SIP works with them?

> 
> If it were, why would we have the higher-level negotiation of 
> event contexts?

There's a lot more to events than specifying a MIME type. Do they have
to be signaled distinctly in order to be useful? Should the accept
header be deprecated?

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 2 Oct 2007 16:49:40 -0500

I'm still completely baffled by why are we having this thread.

INFO is used by ISUP tunnelling. It's there, we can leave it alone. As
far
as I know, nobody is trying to improve it. Legacy stuff. No RFC required
here. 

DTMF transport is a null issue since the last remaining laggars that
didn't
support RFC 2833 now support it. So it is going away and I really can't
imagine that
anybody would bring a draft to resurect it. No RFC required here.

IETF is certainly not going to come up with new INFO usages. Everytime
somebody shows
up with an INFO idea, he's promptly turned away.

So, what is the "problem" that we are trying to solve? Why are we
wasting
time on this?

Can't we just declare victory and move on?

> Sent: Tuesday, October 02, 2007 09:47
> Cc: [email-masked]; Adam Roach; Barnes, Mary (RICH2:AR00)
> Subject: Re: [Sip] INFO
> 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: "Brian Stucker" <[email-masked]>
Date: Tue, 2 Oct 2007 16:54:06 -0500

Exactly. 

> From: Audet, Francois (SC100:3055) 
> Sent: Tuesday, October 02, 2007 4:50 PM
> To: Dean Willis; Stucker, Brian (RICH1:AR00)
> Subject: RE: [Sip] INFO
> INFO is used by ISUP tunnelling. It's there, we can leave it 
> alone. As far as I know, nobody is trying to improve it. 
> Legacy stuff. No RFC required here. 
> 
> DTMF transport is a null issue since the last remaining 
> laggars that didn't support RFC 2833 now support it. So it is 
> going away and I really can't imagine that anybody would 
> bring a draft to resurect it. No RFC required here.
> 
> IETF is certainly not going to come up with new INFO usages. 
> Everytime somebody shows up with an INFO idea, he's promptly 
> turned away.
> 
> So, what is the "problem" that we are trying to solve? Why 
> are we wasting time on this?
> 
> > That is not a hearty argument for endorsing the technique 
> of SIP-T for 
> > other functions.
> > 
> > 
> know what 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments on the application of sip
> > 
>

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Wed, 3 Oct 2007 15:06:21 -0400

The problem I think for DTMF is there are (1) applications that need DTMF
that are not in the media path, and (2) there is equipment out there that
only does INFO for dtmf.  For (2), I'm cool with assuming 2833 will be the
future.  I don't work for those companies, but I assume they'll move that
way and get their customers to upgrade.

For (1), 2833 is not a solution.  Currently KPML is the only
IETF-standardized solution for that, yet INFO is the clear defacto standard
most people use.  My concern with assuming KPML will be adopted is there is
little incentive for most devices to do so.  The app server vendor who needs
signaling-based dtmf has an incentive, but they need the UA's to support it,
and I don't see that happening.  Instead, INFO is simpler, and many already
do it to support the legacy devices due to problem (2) above.  But I was
thinking someone else would say the same, but apparently not.  So maybe I'm
off base on this one.  Nothing to see here.  Move along.

I don't actually care *that much*.  I was more annoyed by the "info is bad"
draft because it seemed flawed and biased to me, and if anyone wanted to
propose Info for something in the future, the draft would be a needless
block to that.

-hadriel

> From: Francois Audet [mailto:[email-masked]]
> Sent: Tuesday, October 02, 2007 5:50 PM
> To: Dean Willis; Brian Stucker
> Cc: [email-masked]; Adam Roach; Mary Barnes
> Subject: RE: [Sip] INFO
>

---

From: "Audet, Francois (SC100:3055)" <[email-masked]>
Date: Wed, 3 Oct 2007 15:40:25 -0500

If people did KPML without all the complexity (i.e., please report all
digits one-by-one instead of complex pattern matching), then it would
fix (1). 

I do agree that the arguments against INFO are often biased and
flawed.

I'd much rather we just say: if you need out of band, use KPML because
it's the standard, instead of dreaming up weird self-serving reasons why
INFO is
the root of all evils. 

So again, the status quo is we have a standard for out-of-band
(KPML) which is not broken (albeit a bit complicated). If somebody
thinks
it needs to be optimized for performance or whatever, let them propose
it. I don't really have an opinion.

Anyways, I'm not pulling out of this as I have nothing new to 
contribute.

> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: Wednesday, October 03, 2007 12:06
> To: Audet, Francois (SC100:3055); 'Dean Willis'; Stucker, 
> Brian (RICH1:AR00)
> Cc: [email-masked]; 'Adam Roach'; Barnes, Mary (RICH2:AR00)
> Subject: RE: [Sip] INFO
> 
> The problem I think for DTMF is there are (1) applications 
> that need DTMF that are not in the media path, and (2) there 
> is equipment out there that only does INFO for dtmf.  For 
> (2), I'm cool with assuming 2833 will be the future.  I don't 
> work for those companies, but I assume they'll move that way 
> and get their customers to upgrade.
> 
> IETF-standardized solution for that, yet INFO is the clear 
> defacto standard most people use.  My concern with assuming 
> KPML will be adopted is there is little incentive for most 
> devices to do so.  The app server vendor who needs 
> signaling-based dtmf has an incentive, but they need the UA's 
> to support it, and I don't see that happening.  Instead, INFO 
> is simpler, and many already do it to support the legacy 
> devices due to problem (2) above.  But I was thinking someone 
> else would say the same, but apparently not.  So maybe I'm 
> draft because it seemed flawed and biased to me, and if 
> anyone wanted to propose Info for something in the future, 
> the draft would be a needless block to that.
> 
> -hadriel
> 
> > far as I know, nobody is trying to improve it. Legacy stuff. No RFC 
> > required here.
> > 
> laggars that 
> > didn't support RFC 2833 now support it. So it is going away and I 
> > really can't imagine that anybody would bring a draft to 
> resurect it. 
> > No RFC required here.
> > 
> > somebody shows up with an INFO idea, he's promptly turned away.
> > 
> > wasting time on this?
> > > > send a 405, respectively, then why are we disallowing 
> other uses 
> > > > of INFO that do not introduce ANY requirements beyond those of 
> > > > SIP-T which we are allowing?
> > > >
> > >
> of SIP-T 
> > > for other functions.
> > > But assume the UA DOES recognize the MIME type. How does it know 
> > > what to do with it? Is content-disposition adequate?
> > >

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 04 Oct 2007 08:06:57 +0100

Hadriel,

Are those applications necessarily on the INFO path? KPML doesn't
require the applications to be on the INFO path.

I believe plenty of SIP devices only support RFC 2833, not INFO, and
those that do support INFO are likely to do so in different ways,
because it is not standardised. So how can the application provider be
sure, even with INFO, that there will be devices to support it?

John

> Sent: 03 October 2007 20:06
> To: 'Francois Audet'; 'Dean Willis'; 'Brian Stucker'
> Cc: [email-masked]; 'Adam Roach'; 'Mary Barnes'
> Subject: RE: [Sip] INFO
> 
> that need DTMF
> defacto standard
> to support it,
> anyone wanted to
> other uses of

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 4 Oct 2007 10:01:23 -0400

> From: Elwell, John [mailto:[email-masked]]
> Sent: Thursday, October 04, 2007 3:07 AM
> To: Hadriel Kaplan; Francois Audet; Dean Willis; Brian Stucker

As far as I've ever seen yes the apps are in the signaling path, but it's not my area.  One would think, though, that for an app server to know whom to generate a KPML subscribe to, and for what dialog identifiers to put in the Event header, the app server would have to be in the signaling path regardless.  If one could KPML subscribe without that info, which is not clear to me is or is not allowed by 4730, then sure one could just subscribe to UAs without being in call signaling.

> sure, even with INFO, that there will be devices to support it?

That's why I was thinking we could define a simple way to indicate such a thing.  Usually I don't like to have more than one, mandatory way to do something, but that ship has already sailed for DTMF, IMHO.  So the next-best thing is at least negotiation/indication.

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Thu, 4 Oct 2007 09:06:55 -0500

> So, what is the "problem" that we are trying to solve? Why are we

To paraphrase my friends at the 12-step program, the first step to  
fixing a problem is to admit that you have more than one problem and  
decide which one you're working on right now.

I was happy with the status-quo. But here's the main problem as I  
understand it:

People keep either showing up with INFO uses or just inventing them  
in the wild and propagating them until somebody ELSE shows up at IETF  
with a "de facto standard" usage of INFO that we have to turn away,  
thereby wasting our time and theirs, and hurting many people's  
delicate feelings in the process.

If we had an RFC that said "New uses of INFO are not being accepted  
by the IETF for the following reasons, please use something else  
(like an event package) instead" then people might be less tempted to  
use INFO, or at least to bring it to the IETF.

I think we have a consensus on this point. We have some debate on  
whether it's worth developing such an RFC, but I think everybody  
understands this path.

However, there's a second problem, and people keep getting these two  
problems confused (or at least thinking we are discussing the first  
problem when we're really discussing the second) hence we go around  
in a circle.

The second problem is "People are using INFO because it has certain  
advantages that make it more attractive than a new event package for  
some applications. If we fixed the problems with INFO negotiation  
without losing these advantages, the community would benefit greatly  
as a result."

This is the problem whose threads contain things like "KPML is a much  
less efficient mechanism for driving telephone applications that use  
DTMF than DTMF over INFO".

So, there are at least TWO PROBLEMS. Why don't we have at least two  
solutions?

Perhaps we could document the flaws with INFO's design and explain,  
as a BCP, why we don't recommend using it and why IETF should not  
proceed with new usages of INFO as long as those flaws persist.

This would not preclude a second standards-track effort (if we wish  
to pursue it) to fix INFO, or replace it with a new in-dialog  
contextually negotiated content transfer mechanism.

It would also not preclude standards-track efforts to replace  
individual INFO usages with new SIP methods (if we wish to pursue  
them). For example, there's no reason why we couldn't replace ISUP- 
over-INFO with a new SIP method "ISUP", TSIG over INFO with a new SIP  
method "TSIG", DTMF-over-INFO with a new SIP method "DTMF", and so on.

This gets back to my rant some months ago about the SIP community not  
having consensus on one extension methodology, thereby giving us  
multiple extension methodologies that compete (and possibly conflict)  
with each other. We don't agree whether SIP is an application  
protocol or a transport protocol, so we've made it into both at the  
same time. It's about time we grapple with this issue and establish a  
practice going forward.

--
Dean

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 04 Oct 2007 09:31:09 -0500

Hi, Dean,

> People keep either showing up with INFO uses or just inventing them  in 
> the wild and propagating them until somebody ELSE shows up at IETF  with a 
> "de facto standard" usage of INFO that we have to turn away,  thereby 
> wasting our time and theirs, and hurting many people's  delicate feelings 
> in the process.
>
> If we had an RFC that said "New uses of INFO are not being accepted  by 
> the IETF for the following reasons, please use something else  (like an 
> event package) instead" then people might be less tempted to  use INFO, or 
> at least to bring it to the IETF.

Speaking as co-chair of MEDIACTRL who's currently looking at text in one of 
the MEDIACTRL drafts about "why not INFO", that's exactly what I'm hoping 
for.

Thanks for the excellent and short summary.

Spencer

---

From: "Audet, Francois (SC100:3055)" <[email-masked]>
Date: Thu, 4 Oct 2007 10:56:24 -0500

There is a missing point in here.

When you say "new uses of INFO are not being accepted by the IETF for
the
following reasons", the problem is that people are overstating their
case
when discussing the "reasons". This in turn is annoying people who find
the "reasons" not technically accurate.

I'd rather we try to avoid "inventing" reasons and getting into silly
long arguments.

We could say something very simple in that draft. Something like, INFO
was
created as a general transport mechanism in SIP. As SIP evolved, new 
mechanisms for different usages were created (then we can list them, 
and give KPML as an example for keypress). And then just say that new
usages beyond the existing ones, i.e., ISUP/QSIG tunnelling, are
therefore
deprecated.

And leave it to that.

Any attempt at inventing complex reasons will just encourage people to
find flaws in the arguments.

But, again, I'm happy with the status quo.

---

From: "Brian Stucker" <[email-masked]>
Date: Sun, 7 Oct 2007 22:11:52 -0500

> Sent: Thursday, October 04, 2007 10:56 AM
> To: Dean Willis
> Cc: IETF SIP List
> Subject: RE: What are we arguing about when we say INFO? (was 
> Re: [Sip] INFO)
> 
> When you say "new uses of INFO are not being accepted by the 
> IETF for the following reasons", the problem is that people 
> are overstating their case when discussing the "reasons". 
> This in turn is annoying people who find the "reasons" not 
> technically accurate.
> 
> I'd rather we try to avoid "inventing" reasons and getting 
> into silly long arguments.

Yes, exactly.

> 
> We could say something very simple in that draft. Something 
> like, INFO was created as a general transport mechanism in 
> SIP. As SIP evolved, new mechanisms for different usages were 
> created (then we can list them, and give KPML as an example 
> for keypress). And then just say that new usages beyond the 
> existing ones, i.e., ISUP/QSIG tunnelling, are therefore deprecated.
> 
> And leave it to that.

I personally would support such a document.

> 
> Any attempt at inventing complex reasons will just encourage 
> people to find flaws in the arguments.

People like me. I'd rather there be no reason than a bad reason. Bad
reasons tend to get exploited and extended to other support further bad
ideas/reasons down the road.

> > event package) instead" then people might be less tempted 
> to use INFO, 
> > or at least to bring it to the IETF.
> > 
> > problem when we're really discussing the second) hence we 
> go around in 
> > a circle.
> > 
> > Perhaps we could document the flaws with INFO's design and 
> explain, as 
> > a BCP, why we don't recommend using it and why IETF should 
> not proceed 
> > with new usages of INFO as long as those flaws persist.
> > 
> > This would not preclude a second standards-track effort (if 
> we wish to 
> > pursue it) to fix INFO, or replace it with a new in-dialog 
> > with each other. We don't agree whether SIP is an 
> application protocol 
> > or a transport protocol, so we've made it into both at the 
> same time. 
> > It's about time we grapple with this issue and establish a practice 
> > going forward.
> > 
> > --
> > Dean
> > 
> 
>

---

From: Adam Roach <[email-masked]>
Date: Mon, 08 Oct 2007 14:13:48 -0500

> I personally would support such a document.

As would I.

/a

---

From: Eric Burger <[email-masked]>
Date: Mon, 08 Oct 2007 17:12:28 -0400

So, what is missing, or what should be taken out, of draft-burger-sip-info?
I think what you propose is what the document says.  Help me out here!

>> same time. It's about time we grapple with this issue and

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: "Francois Audet" <[email-masked]>
Date: Mon, 8 Oct 2007 17:41:16 -0500

The Abstract should say something like:

   The purpose of the INFO request for the Session Initiation Protocol
   (SIP), as described by RFC 2976, is to provide mid-session SIP User
   Agent (UA)-to-SIP UA application data transport.  In the years since
   the introduction of the INFO request, experience with the use of the
   INFO request indicates a number of problems.  This document explains
   why there are INFO-based, proprietary protocols in the wild; the
   flaws of using INFO; and explains why it is not possible to create a
   framework to rescue INFO for general purpose use.  Thus, this
   document restricts the use of INFO to call establishment signaling,
   as described in RFC 3372 (SIP-T). 

   The INFO method was created as a general transport mechanism in SIP. 
   As SIP has evolved since then, new mechanisms for different usages 
   were created. As these mechanisms are now available, this document
   formally deprecates the use of INFO for new usages beyond the
existing
   standardized ones (i.e., ISUP and QSIG tunnelling).
   
In section 1, instead of having this rethorical description of why INFO
is useful,
just explain that originally INFO was defined for call associated
signalling
(ISUP and QSIG). Then explain that the mechanism was then used as a
generic SIP
transport because it was there, for DTMF, MSCML, etc.

Then explain that standard mechanisms were defined for DTMF, etc. 

I think we need to ditch section 2 altogether ("Flaws with INFO").
That's the
part that people really have problems with.

Then your current section 3 would describe the existing mechanisms. 3.2
should mention
both RFC 2833 and KPML.

I would remove 3.4. Also remove 3.5 (we don't need to be defensive: KPML
would be used here).

Section 4 is OK. I think we should add there IETF will not standardize
any more usages of INFO.

> From: Eric Burger [mailto:[email-masked]] 
> Sent: Monday, October 08, 2007 14:12
> To: Audet, Francois (SC100:3055)
> Cc: IETF SIP List
> Subject: Re: What are we arguing about when we say INFO? (was 
> Re: [Sip] INFO)
> 
> > the following reasons", the problem is that people are overstating 
> > their case when discussing the "reasons". This in turn is annoying 
> > people who find the "reasons" not technically accurate.
> > 
> like, INFO 
> > was created as a general transport mechanism in SIP. As SIP 
> evolved, 
> > new mechanisms for different usages were created (then we can list 
> > them, and give KPML as an example for keypress). And then just say 
> > that new usages beyond the existing ones, i.e., ISUP/QSIG 
> tunnelling, 
> > are therefore deprecated.
> > 
> > And leave it to that.
> > 
> go around 
> explain, 
> 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: Wed, 10 Oct 2007 07:13:31 +0200

>Agent (UA)-to-SIP UA application data transport.  In the 
>years since the introduction of the INFO request, experience with the 
>use of the INFO request indicates a number of problems.

Experience has also shown the opposite. And, one reason why the problems
have occured is because it has not been possible to standardize the
usage.

>This document explains why there are INFO-based, proprietary protocols
in the wild;

And there we would describe the issues which have been raised with the
alternative solutions.

>the flaws of using INFO; and explains why it is not possible to create
a
>framework to rescue INFO for general purpose use.

And, why is it not possible?

>formally deprecates the use oFrom [email-masked] Wed Oct 10 01:19:51 2007
Content-class: urn:content-classes:message
Subject: RE: What are we arguing about when we say INFO? (was Re: [Sip] INFO)
Date: Wed, 10 Oct 2007 07:13:31 +0200
From: "Christer Holmberg" <[email-masked]>
To: "Francois Audet" <[email-masked]>,
	"Eric Burger" <[email-masked]>
Cc: IETF SIP List <[email-masked]>

>Agent (UA)-to-SIP UA application data transport.  In the 
>years since the introduction of the INFO request, experience with the 
>use of the INFO request indicates a number of problems.

Experience has also shown the opposite. And, one reason why the problems
have occured is because it has not been possible to standardize the
usage.

>This document explains why there are INFO-based, proprietary protocols
in the wild;

And there we would describe the issues which have been raised with the
alternative solutions.

>the flaws of using INFO; and explains why it is not possible to create
a
>framework to rescue INFO for general purpose use.

And, why is it not possible?

>formally deprecates the use of INFO for new usages beyond 
>the existing standardized ones (i.e., ISUP and QSIG tunnelling).

I disagree to that. We are still discussing the
advantages/disadvantages/issues with INFO vs other mechanisms.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 10 Oct 2007 07:13:29 +0200

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 10 Oct 2007 07:13:29 +0200

>people to find flaws in the arguments.

Ignorning the reason why people are using INFO is not going to make
things better either...

I think most people are aware of KPML etc - we don't need to tell them
that.

Regards,

Christer

Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:[email-masked]?subject=unsubscribe>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

>people to find flaws in the arguments.

Ignorning the reason why people are using INFO is not going to make
things better either...

I think most people are aware of KPML etc - we don't need to tell them
that.

Regards,

Christer

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 10 Oct 2007 10:37:07 -0500

> Ignorning the reason why people are using INFO is not going 
> to make things better either...
> 
> I think most people are aware of KPML etc - we don't need to 
> tell them that.

I seriously don't think people are using INFO because they think it's 
better than KPML.

I think peopled use to use INFO because (a) they implemented it before
RFC 2833, and (b) because it was difficult for them to implement
RFC 2833 when it got implemented and (c) KPML didn't exist at that time.

I believe at this point, this is an imaginary issue.

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 10 Oct 2007 18:20:37 +0200

Hi,

>RFC 2833 when it got implemented and (c) KPML didn't exist at that time.

(d) they think it's a waste of resources to establish multiple additional subscription dialogs (there may be other type of data than DTMF they are willing to receive) which in many cases may not even be used during the call (it can not be assumed that the one sending the subscription always knows exactly when it will receive events). Maybe DTMF is not the best example in the world (my fault - I should have been more generic), but I am sure there could be events which would not be used in a very high percentage of all calls, but still the additional subscription dialog(s) would have to be established - just in case.
 
I still strongly think it would be much better to describe the issues/advantages/disadvantages with BOTH INFO and events, and study what possible needs to defined related to negotiation etc, instead of just ignoring the real world and providing flexibility to people using SIP for their applications...
 
Regards,
 
Christer

---

From: Dean Willis <[email-masked]>
Date: Wed, 10 Oct 2007 16:54:10 -0500

> I believe at this point, this is an imaginary issue.

Well, let's imagine we aren't talking about DTMF.

If I were cobbling together a SIP app that needed to exchange blobs  
alongside an extant dialog, I'd have to say I'd be tempted to use  
INFO despite all the caveats. It's a heck of a lot easier than  
implementing a new event package, and much less overhead too.

Now, wouldn't it be just as easy to invent a new SIP method to  
transport my blob? It might be. That depends on my stack and on any  
confounded SBCs in the loop. In both cases, it's probably easier to  
just slap a new media type into an INFO.

This gets back to my question of "What is the proper SIP extension  
model?" Do we do new methods or new payloads for existing methods? Or  
something else?

Classic SIP says "new method, same dialog". INFO says "new payload,  
INFO method, same dialog". SUB/NOT says "new payload, new SUBSCRIBE  
dialog, method". Purist SIP says "Make the blob into media, reinvite  
for the new media". SIMPLE says "Carry the blob in an MSRP session,  
reinvite for MSRP".

We've got too many potato peelers and a lot of nervous cats here,  
folks. How do we choose our tool?

--
Dean

---

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

> Well, let's imagine we aren't talking about DTMF.

Good.

> If I were cobbling together a SIP app that needed to exchange 
> blobs alongside an extant dialog, I'd have to say I'd be 
> tempted to use INFO despite all the caveats. It's a heck of a 
> lot easier than implementing a new event package, and much 
> less overhead too.
> 
> Now, wouldn't it be just as easy to invent a new SIP method 
> to transport my blob? It might be. That depends on my stack 
> and on any confounded SBCs in the loop. In both cases, it's 
> probably easier to just slap a new media type into an INFO.
> 
> This gets back to my question of "What is the proper SIP 
> extension model?" Do we do new methods or new payloads for 
> existing methods? Or something else?
> 
> Classic SIP says "new method, same dialog". INFO says "new 
> payload, INFO method, same dialog". SUB/NOT says "new 
> payload, new SUBSCRIBE dialog, method". Purist SIP says "Make 
> the blob into media, reinvite for the new media". SIMPLE says 
> "Carry the blob in an MSRP session, reinvite for MSRP".
> 
> We've got too many potato peelers and a lot of nervous cats 
> here, folks. How do we choose our tool?

Maybe what is needed is a description of which of these
mechanism is appropriate for what class of extension?

And is there a case where one of the non-INFO is not appropriate?

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 10 Oct 2007 18:16:07 -0400

Dean Willis wrote:

> We've got too many potato peelers and a lot of nervous cats here, folks. 

Spoken like a true dog owner!

	Paul

---

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

> (d) they think it's a waste of resources to establish 
> multiple additional subscription dialogs (there may be other 
> type of data than DTMF they are willing to receive) which in 
> many cases may not even be used during the call (it can not 
> be assumed that the one sending the subscription always knows 
> exactly when it will receive events). Maybe DTMF is not the 
> best example in the world (my fault - I should have been more 
> generic), but I am sure there could be events which would not 
> be used in a very high percentage of all calls, but still the 
> additional subscription dialog(s) would have to be 
> established - just in case.

Maybe a way to subscribe to packages within an INVITE dialog would
be suitable. You then would get the NOTIFYs withind the dialog, and
they wouldn't be out-of-the-blue because you would have subscribed
to those events explicitly with some Allow-Event in the INVITE. 

I know many people will hate this idea but, I do agree with Christer
that subscribing to an event package "just in case" when it normally
is not used is quite a huge overhead and explain why people just
use INFO instead.

> I still strongly think it would be much better to describe 
> the issues/advantages/disadvantages with BOTH INFO and 
> events, and study what possible needs to defined related to 
> negotiation etc, instead of just ignoring the real world and 
> providing flexibility to people using SIP for their applications...

I think the idea above would address this and avoid the INFO pitfalls.

---

From: Dean Willis <[email-masked]>
Date: Wed, 10 Oct 2007 23:19:47 -0500

> to those events explicitly with some Allow-Event in the INVITE.

Hmm. In-dialog event notification using INVITE as an explicit  
subscription trigger. That works, mostly.

Other people would argue that the semantics are better preserved with  
a a new SIP method that is defined to carry whatever sort of blob  
we're talking about in the specific context of the application usage.  
We'd then add that method name to the list of supported methods given  
in the Allow header field. Of course, this will eventually give us  
"Really Big" Allow header fields, which means the negotiation  
mechanism is broken. We need an easier way for one end to ask "Hey,  
do you understand this?".

Others would say that the we're better off defining a session  
protocol designed to transport the blobs in question, along with SDP  
extensions to negotiate this protocol, NAT-traversal hooks to allow  
us to talk about the connectivity of the blob-transferral protocol,  
then do a reINVITE exchange to add the new blob-session to the  
existing session.

Yet others would say that we already have a blob-transferral protocol  
(MSRP), along with the nat traversal hooks and SDP extensions needed  
to negotiate it, and should therefore push the problem out one layer  
of protocol and make it an MSRP problem. This begs the question of  
how MSRP negotiates as to whether the context and content are agreed  
on both ends, which AFAIK it does little better at than INFO.

So what's the difference?

All (assuming we figure out the MSRP context negotiation problem)  
explicitly declare the understanding of and the desire to receive  
messages within this dialog/session that contain the data we've  
defined and assure that the application context (the "what do I do  
with this stuff" problem) is mutually understood.

The differences are that one approach is the extension of an  
application protocol to support a new application, while two others  
are extensions of existing transport protocols (SIP, MSRP) to carry  
new payloads in contexts determined by the applications. The last one  
implies the development of an all-new transport protocol (or perhaps  
the modification of some other protocol like RTP) as well as  
extension to our descriptive protocol (SDP). These are very different  
things, and part of the reason that SIP has gotten more complex than  
I would like is that we haven't been operating with a clear  
understanding of these differences.

Personally, I think that we've got a lot of complexity there that we  
didn't really need. If SIP had been designed from the ground-up as a  
transport protocol for arbitrary messages and the application were a  
function of the message content, we'd have a much clearer model of  
what to do. But it wasn't built that way, so now we need some guiding  
principles on when each sort of approach is appropriate. Without it,  
we're just going to go around in circles on the "Is INFO harmful, and  
if so why?" carousel.

Since I can't leave it hanging there, I'd like to propose some rules  
of thumb:

1) If INFO had context negotiation, we'd have a complete protocol and  
would quite possibly only need new SIP method types if there was a  
need for a fundamental change to the SIP state machine. Even without  
INFO, we have the same functionality available, albeit at the  
overhead of an additional dialog. So, I suggest we only introduce new  
SIP methods if there's a need to change the underlying machine. If  
we're just moving new data in application contexts, we can do that  
without changing SIP itself. I really don't want to keep the SIP WG  
around just so we can specify a new SIP method for each application  
somebody dreams up.

2) Since SIP can provide for the transport of arbitrary data and  
application context, we should only use "session" transport of the  
data when that dataflow itself has fundamentally different  
characteristics -- essentially, when it is a long-lived and  
relatively continues flow, aka a "stream". Quite possibly, this  
should extend to only dataflows that have the properties of RTP --  
time sensitive, relatively loss insensitive, and so bulky we need  
them to be as end-to-end as we can even if it means building more  
infrastructure to make that happen. And yes, I think MSRP is a  
misguided effort -- by the time we've built MSRP relays and all the  
extra cruft, we've duplicated SIP's message proxy operation, ICE,  
GRUU, STUN-relay, and so on. Personally, I'm not even sure that this  
level of separation is a good idea. Coaxial signaling and media have  
great advantages for firewall traversal. But we have what we have. In  
short, use RTP/MSRP for "sessions", and SIP event payloads (or  
contextually-adapted INFO) for everything else.

3) There is no rule 3.

--
Dean

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 11 Oct 2007 11:55:22 -0500

Hi Dean,

Can you tell me what is the difference between "contextually-adapted
INFO", and a "subscription embedded in the INVITE, with the NOTIFY
using the same dialog"? I don't see any advantage to the INFO approach.

It seems to me we already have a mechanism for asking for asynchroous
information with subscriptions. Why not use that?

> Sent: Wednesday, October 10, 2007 21:20
> Cc: Christer Holmberg; IETF SIP List
> >> (d) they think it's a waste of resources to establish multiple 
> >> additional subscription dialogs (there may be other type 
> of data than 
> >> DTMF they are willing to receive) which in many cases may 
> not even be 
> >> used during the call (it can not be assumed that the one 
> sending the 
> >> subscription always knows exactly when it will receive 
> events). Maybe 
> >> DTMF is not the best example in the world (my fault - I 
> should have 
> >> been more generic), but I am sure there could be events 
> which would 
> >> not be used in a very high percentage of all calls, but still the 
> > Maybe a way to subscribe to packages within an INVITE 
> dialog would be 
> > suitable. You then would get the NOTIFYs withind the 
> dialog, and they 
> > wouldn't be out-of-the-blue because you would have 
> subscribed to those 
> > events explicitly with some Allow-Event in the INVITE.
> >
> 
> Other people would argue that the semantics are better 
> preserved with a a new SIP method that is defined to carry 
> whatever sort of blob we're talking about in the specific 
> context of the application usage.  
> We'd then add that method name to the list of supported 
> methods given in the Allow header field. Of course, this will 
> eventually give us "Really Big" Allow header fields, which 
> means the negotiation mechanism is broken. We need an easier 
> way for one end to ask "Hey, do you understand this?".
> 
> protocol designed to transport the blobs in question, along 
> with SDP extensions to negotiate this protocol, NAT-traversal 
> hooks to allow us to talk about the connectivity of the 
> blob-transferral protocol, then do a reINVITE exchange to add 
> the new blob-session to the existing session.
> 
> Yet others would say that we already have a blob-transferral 
> protocol (MSRP), along with the nat traversal hooks and SDP 
> extensions needed to negotiate it, and should therefore push 
> the problem out one layer of protocol and make it an MSRP 
> problem. This begs the question of how MSRP negotiates as to 
> whether the context and content are agreed on both ends, 
> which AFAIK it does little better at than INFO.
> 
> 
> All (assuming we figure out the MSRP context negotiation 
> problem) explicitly declare the understanding of and the 
> desire to receive messages within this dialog/session that 
> contain the data we've defined and assure that the 
> application context (the "what do I do with this stuff" 
> problem) is mutually understood.
> 
> application protocol to support a new application, while two 
> others are extensions of existing transport protocols (SIP, 
> MSRP) to carry new payloads in contexts determined by the 
> applications. The last one implies the development of an 
> all-new transport protocol (or perhaps the modification of 
> some other protocol like RTP) as well as extension to our 
> descriptive protocol (SDP). These are very different things, 
> and part of the reason that SIP has gotten more complex than 
> Personally, I think that we've got a lot of complexity there 
> that we didn't really need. If SIP had been designed from the 
> ground-up as a transport protocol for arbitrary messages and 
> the application were a function of the message content, we'd 
> have a much clearer model of what to do. But it wasn't built 
> that way, so now we need some guiding principles on when each 
> sort of approach is appropriate. Without it, we're just going 
> to go around in circles on the "Is INFO harmful, and if so 
> why?" carousel.
> 
> Since I can't leave it hanging there, I'd like to propose 
> some rules of thumb:
> 
> 1) If INFO had context negotiation, we'd have a complete 
> protocol and would quite possibly only need new SIP method 
> types if there was a need for a fundamental change to the SIP 
> state machine. Even without INFO, we have the same 
> functionality available, albeit at the overhead of an 
> additional dialog. So, I suggest we only introduce new SIP 
> methods if there's a need to change the underlying machine. 
> If we're just moving new data in application contexts, we can 
> do that without changing SIP itself. I really don't want to 
> keep the SIP WG around just so we can specify a new SIP 
> method for each application somebody dreams up.
> 
> 2) Since SIP can provide for the transport of arbitrary data 
> and application context, we should only use "session" 
> transport of the data when that dataflow itself has 
> fundamentally different characteristics -- essentially, when 
> it is a long-lived and relatively continues flow, aka a 
> "stream". Quite possibly, this should extend to only 
> dataflows that have the properties of RTP -- time sensitive, 
> relatively loss insensitive, and so bulky we need them to be 
> as end-to-end as we can even if it means building more 
> infrastructure to make that happen. And yes, I think MSRP is 
> a misguided effort -- by the time we've built MSRP relays and 
> all the extra cruft, we've duplicated SIP's message proxy 
> operation, ICE, GRUU, STUN-relay, and so on. Personally, I'm 
> not even sure that this level of separation is a good idea. 
> Coaxial signaling and media have great advantages for 
> firewall traversal. But we have what we have. In short, use 
> RTP/MSRP for "sessions", and SIP event payloads (or

---

From: Dean Willis <[email-masked]>
Date: Thu, 11 Oct 2007 14:31:59 -0500

> using the same dialog"? I don't see any advantage to the INFO  

One might argue that the second is a means of implementing the first.

INFO, as written, lacks contextual negotiation. You're proposing to  
replace the method name with NOTIFY and use the event-package  
framework for content and context expression, using a header-field in  
the INVITE request to engage context negotiation. It seems to me like  
that would work. There's nothing "implicit" about it, and it is no  
worse for overhead than using Supported or Allow. It also has the  
advantage of letting us reuse an existing registration framework,  
IANA process, and specification review process under RFC 3427. Very  
tidy, I think I like it.

I would argue that it would be nice to have an extension mechanism  
that allows a UA to be asked "Do you support this specific  
extension?" without the UA having to encode every extension it  
supports in every request it sends, but that's a different issue.

> information with subscriptions. Why not use that?

As you pointed out, the current mechanism adds a dialog overhead. It  
also raises issues with event-stream correlation that can be a bit of  
a challenge depending on the application's API and threading model.  
Your suggested workaround for in-dialog notification relieves these  
issues, so it may be better than the existing mechanism for a number  
of use cases. More importantly, it is no worse than NOTIFY for those  
use cases (barring the small increase in request size for context  
negotiation).

--
Dean

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 11 Oct 2007 14:51:21 -0500

Looks like we are in agreement. Your paraphrasing of my
proposal is accurate.

Let's wait for other opinions. 

> Sent: Thursday, October 11, 2007 12:32
> Subject: Francois' counter to INFO (was Re: What are we 
> arguing about when we say INFO?)
> 
> 
> INFO, as written, lacks contextual negotiation. You're 
> proposing to replace the method name with NOTIFY and use the 
> event-package framework for content and context expression, 
> using a header-field in the INVITE request to engage context 
> negotiation. It seems to me like that would work. There's 
> nothing "implicit" about it, and it is no worse for overhead 
> than using Supported or Allow. It also has the advantage of 
> letting us reuse an existing registration framework, IANA 
> process, and specification review process under RFC 3427. 
> Very tidy, I think I like it.
> 
> I would argue that it would be nice to have an extension 
> mechanism that allows a UA to be asked "Do you support this 
> specific extension?" without the UA having to encode every 
> extension it supports in every request it sends, but that's a 
> different issue.
> 
> 
> As you pointed out, the current mechanism adds a dialog 
> overhead. It also raises issues with event-stream correlation 
> that can be a bit of a challenge depending on the 
> application's API and threading model.  
> Your suggested workaround for in-dialog notification relieves 
> these issues, so it may be better than the existing mechanism 
> for a number of use cases. More importantly, it is no worse 
> than NOTIFY for those use cases (barring the small increase 
> in request size for context negotiation).
> 
> --
> Dean
> 
> 
>

---

From: Jeroen van Bemmel <[email-masked]>
Date: Fri, 12 Oct 2007 00:17:41 +0200

Francois,

"Why not use that?" is the wrong question. It should be "Why do THEY 
(the people out there) use or don't use { KPML, INFO, RFC2833, <some 
proprietary solution>, ... }"

It is not up to us - the people participating in these IETF mailinglists 
- to decide what gets used. We simply don't have any say in that.

 In my limited perception of the world, people use INFO because it's 
better known by them, supported by some devices, simpler to use, and low 
overhead - you don't pay a performance penalty unless a key press (for 
example) actually happens, which in some cases is rare (like for certain 
telephony applications). People tend to think along the lines of "it's 
defined in an RFC, therefore standard, seems supported by others (at 
least by the list of devices on my mandatory interop list) -> ok to use" 
and then add an item to their "supported standards" list on the product 
data sheet

"We" can argue that it's wrong to use INFO, that it's lacking 
contextually-adapted negotiations mechanisms, etc. but the reaction will 
simply be: "What are you talking about, contextual bla-bla, it's working 
fine for US and our purposes".

Pandorra's box that is INFO has been opened. It's out there, and there's 
no stopping it. Let's go solve some real issues now

Regards,
Jeroen

Francois Audet wrote:
>> established - just 
>>>> in case.

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Fri, 12 Oct 2007 01:54:10 +0200

There is one major downside to this.

If we are sending stuff in the dialog, it really ought to have some
relation to the dialog, not just be included there because the dialog
happened to exist.....then you end up with people wanting to route the
dialog to a centralised point where you can extract this piggy-backed
information ... Then you end up with a stimulus protocol between this UE
and this centralised server where the dialog contains absolutely no
knowledge of the state of the session.

Providing an in dialog mechanism makes it much harder to to stop this
happening. 

Regards

Keith

> Sent: Thursday, October 11, 2007 5:20 AM
> To: Francois Audet
> Cc: IETF SIP List; Christer Holmberg

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 11 Oct 2007 19:08:37 -0500

Yes, I agree.

> From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
> Sent: Thursday, October 11, 2007 16:54
> To: Dean Willis; Audet, Francois (SC100:3055)
> If we are sending stuff in the dialog, it really ought to 
> have some relation to the dialog, not just be included there 
> because the dialog happened to exist.....then you end up with 
> people wanting to route the dialog to a centralised point 
> where you can extract this piggy-backed information ... Then 
> you end up with a stimulus protocol between this UE and this 
> centralised server where the dialog contains absolutely no 
> Providing an in dialog mechanism makes it much harder to to 
> stop this happening. 
> 
> Regards
> 
> Keith
> 
> preserved with 
> methods given 
> > mechanism is broken. We need an easier way for one end to 
> ask "Hey, do 
> > you understand this?".
> > 
> > Others would say that the we're better off defining a 
> session protocol 
> > designed to transport the blobs in question, along with SDP 
> extensions 
> > to negotiate this protocol, NAT-traversal hooks to allow us to talk 
> > about the connectivity of the blob-transferral protocol, then do a 
> > reINVITE exchange to add the new blob-session to the 
> existing session.
> > 
> > of protocol and make it an MSRP problem. This begs the 
> question of how 
> > MSRP negotiates as to whether the context and content are agreed on 
> > both ends, which AFAIK it does little better at than INFO.
> > 
> >

---

From: Salvatore Loreto <[email-masked]>
Date: Fri, 12 Oct 2007 10:06:26 +0300

see my comments in line

Sal

> IANA process, and specification review process under RFC 3427. Very  

the proposal is interesting. 
However there should be cases where you need to send whatever
information in both directions, or cases where when you send an
information via Notify you need to receive back some information (e.g.
the fact that you receive a 200Ok as answer to the Notify it is not
enough).
How do you think your proposal should work in those cases ? perhaps with
2 subscription one in each direction? 

> supports in every request it sends, but that's a different issue.

that is also something nice. Are you thinking a mechanism like an OPTION
that instead to be general just asks for a specific extension?

---

From: "Michael Procter" <[email-masked]>
Date: Fri, 12 Oct 2007 06:27:12 -0700

> IANA process, and specification review process under RFC 3427. Very

One area that would need defining very carefully is the question of
subscription usage lifetimes.  Tying them to the lifetime of the invite
usage that caused them sounds quite tidy, and would prevent a flurry of
NOTIFY/state=terminated messages straight after a BYE.  No doubt there
are scenarios when this is less than helpful though.  Similarly, rules
on if/when resubscription is necessary would need to be agreed, rather
than leaving it to 'implementor's discretion'.

Interestingly, I was thinking about a related problem recently and
wondered if some sort of multi-event subscribe might help with the
many-dialogs problem that some people are starting to see.  Francois'
approach gives a related solution in the scenario where there is a call
dialog in existence between the relevant endpoints.

Regards,

Michael

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 12 Oct 2007 09:50:00 -0500

> information in both directions, or cases where when you send 
> an information via Notify you need to receive back some 
> information (e.g.
> the fact that you receive a 200Ok as answer to the Notify it 
> is not enough).

Yes.

---

From: "Brian Stucker" <[email-masked]>
Date: Fri, 12 Oct 2007 11:32:38 -0500

> Sent: Thursday, October 11, 2007 2:32 PM
> Subject: [Sip] Francois' counter to INFO (was Re: What are we 

I'm missing something here.

When I send a SUBSCRIBE I'm saying the following, "For the resource
identified by the request-URI, I'd like to synchronize with a particular
state machine for X seconds with the state data encoded in format Y."
The other end can accept or reject the request as a whole, there is no
offer/answer negotiation going on.

If we were to trigger a subscription based upon the INVITE that takes
care of targeting the resource and the duration of interest and leaves
out identifying the particular state machine you want to synchronize
with and how you want to encode the state data.

Can't I identify the state machine I want to synchronize with using a
supported header and the encoding using the accept header, specifying
the pair-values that are legal in an IETF document? Isn't this what
RFC-3312 did, and although integrated differently into the protocol
because the state machine being synchronized was SIP itself what
RFC-3262 does?

Regards,
Brian

---

From: Dean Willis <[email-masked]>
Date: Fri, 12 Oct 2007 11:45:00 -0500

> Providing an in dialog mechanism makes it much harder to to stop this

That's back to the question of  "Is SIP an application protocol or a  
transport protocol"?

Should the SIP-layer software be aware of and coupled to the state of  
the application that's using SIP?

If so, then the proper design model is to build a new SIP request  
method for every new piece of application functionality.

So for example, DTMF: Using this model of SIP extension, we might  
define a new "DTMF" method. It would look just like DTMF-over-INFO,  
except the name of the method would be DTMF. It clearly resolves the  
INFO-context question, because now we KNOW we're getting dialog- 
related DTMF over it, and we know what to do with it. We know what we  
can transport in DTMF-requests, because the RFC that defines the DTMF  
extension method will also define exactly what payload format to use.

This too is a clean solution to the problem, although it embodies a  
different design philosophy than the same-dialog NOTIFY.

This leads back to my question: What is the right extension modality  
for SIP? Until we have an answer here, we're going to keep going back  
and forth on this. MAKE A DECISION, PEOPLE!

Now for the bad news: People are still having this argument about  
HTTP (we had it during XCAP in the GET/PUT vs POST debate) even  
though the real world has proven dramatically by example that HTTP is  
a transport protocol and is protocol-wise completely decoupled from  
the state of the application (see AJAX as an example).

--
Dean

---

From: "Brian Stucker" <[email-masked]>
Date: Fri, 12 Oct 2007 12:02:32 -0500

> Sent: Friday, October 12, 2007 11:45 AM
> To: DRAGE, Keith (Keith)
> Cc: IETF SIP List; Audet, Francois (SC100:3055); Christer Holmberg
> > information ... Then you end up with a stimulus protocol 
> between this 
> > UE and this centralised server where the dialog contains 
> absolutely no 
> stop this 
> That's back to the question of  "Is SIP an application 
> protocol or a transport protocol"?
> 
> Should the SIP-layer software be aware of and coupled to the 
> state of the application that's using SIP?
> 
> If so, then the proper design model is to build a new SIP 
> request method for every new piece of application functionality.

You forgot about supported.

> 
> So for example, DTMF: Using this model of SIP extension, we 
> might define a new "DTMF" method. It would look just like 
> DTMF-over-INFO, except the name of the method would be DTMF. 
> It clearly resolves the INFO-context question, because now we 
> KNOW we're getting dialog- related DTMF over it, and we know 
> what to do with it. We know what we can transport in 
> DTMF-requests, because the RFC that defines the DTMF 

INVITE
Supported: foo
Allow: INFO
Accept: application/foo

200 OK
Supported: foo
Allow: INFO
Accept: application/foo

...

INFO
Content-Type: application/foo
[DTMF]

Where is this broken?
> 
> This too is a clean solution to the problem, although it 
> embodies a different design philosophy than the same-dialog NOTIFY.
> 
> This leads back to my question: What is the right extension 
> modality for SIP? Until we have an answer here, we're going 
> to keep going back and forth on this. MAKE A DECISION, PEOPLE!

You can't feasibly make a clean one. There will always be SDP vs.
non-SDP extension modalities.

> 
> Now for the bad news: People are still having this argument 
> about HTTP (we had it during XCAP in the GET/PUT vs POST 
> debate) even though the real world has proven dramatically by 
> example that HTTP is a transport protocol and is 
> protocol-wise completely decoupled from the state of the 
> application (see AJAX as an example).
> 
> --
> Dean
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 12 Oct 2007 13:56:46 -0400

> Content-Type: application/foo

This can work if there is an RFC defining the foo option that specifies 
that when both parties support foo then:
- the UAC may use INFO to send information using
   Content-Type application/foo and Content-Disposition: (TBD)
- the circumstances triggering the UAC to send are ...
- the expected actions of the UAS upon receiving are ...

Because this uses an option, and a new option can only be defined via an 
RFC, this technique is only available (legally) when an RFC will be 
approved. (Of course people have been known to invent new options 
without an RFC, but that is non-conforming usage.)

	Paul

---

From: "Sumit Garg" <[email-masked]>
Date: Fri, 12 Oct 2007 14:19:49 -0400

Agreed.

Basically there can be 3 scenario:

1. A---------------C (the signaling and media path ) --->2833 is best.

2. A---------------B (the signaling and media path ) 
   C which is a proxy, and  in neither path needs the DTMF
(SUBSCRIBE/NOTIFY is best)

3. A---------------C------------B (signaling path)
   A--------------------B         (media path)
   C needs the DTMF events, cannot use 2833 and SUBSCRIBE/NOTIFY is okay
 but not necessarily the best approach due to the overhead of additional
dialogs (whose duration is tightly linked to the INVITE dialog). INFO
definitely looks attractive here.

Similarly, the recent draft on rtcp-summary defines a complex
SUBCRIBE/NOTIFY mechanism, which again covers all scenarios gracefully.
However, for scenario 1 and 3 some other mechanism would be better.

I see the need for being able to implicitly SUBSCRIBE for certain events
in the INVITE/200 OK itself. Whether we get those notifications in an
INFO or a NOTIFY does not matter that much. I could even use the RTCP
summary if it was in the BYE/200 (where it logically belongs).

-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: Brian Stucker [mailto:[email-masked]] 
Sent: Friday, October 12, 2007 1:03 PM
To: Dean Willis; DRAGE, Keith (Keith)
Cc: IETF SIP List; Francois Audet; Christer Holmberg
Subject: RE: What are we arguing about when we say INFO? (was Re: [Sip]
INFO)

> except the name of the method would be DTMF.
> It clearly resolves the INFO-context question, because now we KNOW 
> we're getting dialog- related DTMF over it, and we know what to do 
> with it. We know what we can transport in DTMF-requests, because the 
> RFC that defines the DTMF extension method will also define exactly 
> what payload format to use.

INVITE
Supported: foo
Allow: INFO
Accept: application/foo

200 OK
Supported: foo
Allow: INFO
Accept: application/foo

...

INFO

Where is this broken?

> 
> Now for the bad news: People are still having this argument about HTTP

> (we had it during XCAP in the GET/PUT vs POST
> debate) even though the real world has proven dramatically by example 
> that HTTP is a transport protocol and is protocol-wise completely 
> decoupled from the state of the application (see AJAX as an example).
> 
> --
> Dean
> 
>

---

From: "Brian Stucker" <[email-masked]>
Date: Fri, 12 Oct 2007 13:43:40 -0500

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Friday, October 12, 2007 12:57 PM
> Cc: Dean Willis; DRAGE, Keith (Keith); IETF SIP List; Audet, 
> Francois (SC100:3055); Christer Holmberg
> This can work if there is an RFC defining the foo option that 
> specifies that when both parties support foo then:
> Because this uses an option, and a new option can only be 
> defined via an RFC, this technique is only available 
> (legally) when an RFC will be approved. (Of course people 
> have been known to invent new options without an RFC, but 
> that is non-conforming usage.)

That seems like more of a legal loophole for defining event header
values than anything else. There's only one currently IANA registered
event header value that is not associated with an RFC and I doubt that
one is going to live for very long in light of RTCP-XR.

Are you advocating not having to have an RFC for an event header as a
positive thing? If so, then isn't this equivalent to a vote for leaving
INFO alone?

Regards,
Brian

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 12 Oct 2007 15:36:50 -0400

Brian Stucker wrote:
> values than anything else.

Event types and sip option tags are separate namespaces with different 
registration ruies:
- event types: Informational RFC approved by the IESG
- option tags: Publication of standards track (section 27.1)

So the bar is slightly lower for event types.

> There's only one currently IANA registered

No, I'm not advocating it as a good thing. I am acknowledging that 
people will do it for proprietary reasons, but that if they later come 
forward and try to get the usage formally approved then there is a bar 
to get over.

You can publish a informational rfc for your proprietary event type 
without any consensus of the wg, etc. But getting a standards track rfc 
approved for an option tag will require the wg to bless your approach.

	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 12 Oct 2007 17:54:08 -0400

Yeah, that's what I meant when I said in an earlier email:
"But I think that is something that could be standardized away if we needed to.  One way could be to define an Event package type model for it.  One could argue Info is essentially a Notify, except in a subscription implicitly created by, and tied to the dialog from, an Invite."

But Adam didn't seem to like it.  Not sure why. Adam?

-hadriel

> Sent: Wednesday, October 10, 2007 7:14 PM
> To: Christer Holmberg; Dean Willis
> Cc: IETF SIP List

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 12 Oct 2007 19:22:31 -0400

> From: Sumit Garg [mailto:[email-masked]]
> Sent: Friday, October 12, 2007 2:20 PM
> To: Brian Stucker; Dean Willis; DRAGE, Keith (Keith)

Even for scenario 2.  In scenario 2 such a proxy was in the path for at least the Invite, in order to know about the session.  So even if it wasn't record-routing it may be better for proxy C to do subscribe/notify, but for A and B it will be worse, as they now have an additional dialog... for each proxy C in the Invite's path that wants the information.  And if A or B are gateways or servers handling lots of sessions, that's a difference.

-hadriel

---

From: Salvatore Loreto <[email-masked]>
Date: Sat, 13 Oct 2007 11:08:59 +0300

> > 2 subscription one in each direction? 

OK, I agree on this.
But maybe should be interesting a mechanism to discriminate when you
need 2 subscription one in each direction, when one it is enough and in
the case of only one subscription the possibility to choose in which
direction you want to start it.

---

From: Adam Roach <[email-masked]>
Date: Sat, 13 Oct 2007 10:28:21 -0500

Answering a little bit of your scenario and a little bit of Francois':

   1. Support must be explicit. Everything described so far makes
      indication of the ability to receive an INVITE (or NOTIFY in
      Francois' case) implicit in circumstances where such an
      implication can be accidental. There are legitimate situations in
      which any of the proposed heuristics used to perform such an
      implication may legitimately exist and yet not mean that the
      recipient is requesting INFO (or NOTIFY) requests.

   2. Dialog re-use causes problems. Having multiple usages within a
      dialog causes all kinds of confusing interactions between the
      usages. Even the ones that are well documented are seldom
      implemented correctly. (e.g., if I send a re-INVITE in a dialog
      that is shared with a SUBSCRIBE and get a 481, what is gone? The
      INVITE usage or the dialog? What it it's a 480? A 500? Even if
      _you_ know where to look it up, will implementors? Even if they
      do, are the rules sufficiently labyrinthine that the chances of
      misimplementation are high?) The "pushing my buttons" comment came
      from your implication that INFO was basically the same as NOTIFY
      in this context -- which is imperfect in myriad ways. For example:
      such a statement would mean that the INFO usage survives the
      termination of the INVITE dialog
      (draft-ietf-sipping-dialogusage-06, section 4.2). Yes, it's
      probably not what you meant, but (except at the most superficial
      level) it's so far away from what you might actually want as to be
      a very poor starting point.

Can this be salvaged? Yes -- and Dean's earlier proposal for INFO 
packages does so by making such things explicit. There's another 
question about whether it's worth salvaging, and I think that's a little 
less cut-and-dried (despite my strong opinion on the topic) -- but I'm 
boggled by the extreme pushback to making this negotiation explicit in 
the face of clear examples of how things break when we don't.

/a

(For the record: "Allow-Event" in an INVITE has very well defined 
semantics -- it means, "if you send me a SUBSCRIBE for this event 
package, I can send NOTIFYs". It is exactly backwards from the meaning 
"I can receive NOTIFYs of this type".)

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 13 Oct 2007 22:23:15 -0400

List-From [email-masked] Sat Oct 13 22:25:24 2007
From: Hadriel Kaplan <[email-masked]>
To: Salvatore Loreto <[email-masked]>, Francois Audet
	<[email-masked]>
Date: Sat, 13 Oct 2007 22:23:15 -0400
Subject: RE: [Sip] Francois' counter to INFO (was Re: What are we arguing
	about when we say INFO?)
	<[email-masked]! orp.norte
	l!!	.com>	!
	! ! ! ! < 8F6 5	DB 2	 7-41E D-42F 3-	[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Accept-Language: en-US
acceptlanguage: en-US
Cc: IETF SIP List <[email-masked]>, Dean Willis <[email-masked]>,
	Christer Holmberg <[email-masked]>

You make it sound like there is some extra signaling involved in the subscriptions.  I thought we were talking about *implicit* subscriptions.  The only extra "signaling" would be event package negotiation exchange, presumably in headers in the Invite and responses.  Then a Notify for the events.  Or really instead of a NOTIFY, it could be a new method called "Invite-based Notification Function Output" or "INFO" for short. :)

Or do you just mean the negotiation needs to support both the concept of a uni and bi-directional implicit subscription?

-hadriel

> From: Salvatore Loreto [mailto:[email-masked]]
> Sent: Saturday, October 13, 2007 4:09 AM
> To: Francois Audet
> Cc: IETF SIP List; Christer Holmberg; Dean Willis
> Subject: RE: [Sip] Francois' counter to INFO (was Re: What are we arguing
> about when we say INFO?)
>
>
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 13 Oct 2007 22:13:52 -0400

You make it sound like there is some extra signaling involved in the subscr=
iptions.  I thought we were talking about *implicit* subscriptions.  The on=
ly extra "signaling" would be event package negotiation exchange, presumabl=
y in headers in the Invite and responses.  Then a Notify for the events.  O=
r really instead of a NOTIFY, it could be a new method called "Invite-based=
 Notification Function Output" or "INFO" for short. :)

Or do you just mean the negotiation needs to support both the concept of a =
uni and bi-directional implicit subscription?

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 13 Oct 2007 22:13:52 -0400

Howdy,
Inline...

> Sent: Saturday, October 13, 2007 11:28 AM
> To: Hadriel Kaplan
> Cc: Francois Audet; IETF SIP List
> Subject: Re: What are we arguing about when we say INFO? (was Re: [Sip]
> INFO)
>
>       indication of the ability to receive an INVITE

I assume you mean INFO, not INVITE?

> (or NOTIFY in

I didn't mean to imply there wouldn't be explicit indication of INFO support for specific event packages.  I was saying that's what's missing now and would have to be standardized.

>       INVITE usage or the dialog?

The dialog, as before, and also the subscription, since the subscription would be tied to the invite's dialog.  They would share fate.

>       What it it's a 480? A 500? Even if
>       probably not what you meant, but (except at the most [email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]!!
	.com> ! ! < 8F6 5	DB 2	7-41E	D-42F 3-	[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Accept-Language: en-US
acceptlanguage: en-US
Cc: IETF SIP List <[email-masked]>, Francois Audet <[email-masked]>

Howdy,
Inline...

> Sent: Saturday, October 13, 2007 11:28 AM
> To: Hadriel Kaplan
> Cc: Francois Audet; IETF SIP List
> Subject: Re: What are we arguing about when we say INFO? (was Re: [Sip]
> INFO)
>
>       indication of the ability to receive an INVITE

I assume you mean INFO, not INVITE?

> (or NOTIFY in

I didn't mean to imply there wouldn't be explicit indication of INFO support for specific event packages.  I was saying that's what's missing now and would have to be standardized.

>       INVITE usage or the dialog?

The dialog, as before, and also the subscription, since the subscription would be tied to the invite's dialog.  They would share fate.

>       What it it's a 480? A 500? Even if

Right, it's not what I meant. :)

> the face of clear examples of how things break when we don't.

I don't think anyone is pushing back against making negotiation explicit.

> "I can receive NOTIFYs of this type".)

Yes I agree... didn't say otherwise. :)

-hadriel

al
>       a very poor starting point.

Right, it's not what I meant. :)

> the face of clear examples of how things break when we don't.

I don't think anyone is pushing back against making negotiation explicit.

> "I can receive NOTIFYs of this type".)

Yes I agree... didn't say otherwise. :)

-hadriel

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 14 Oct 2007 17:03:42 +0200

>You make it sound like there is some extra signaling involved 
>in the subscriptions.  I thought we were talking about 
>*implicit* subscriptions.  The only extra "signaling" would 
>be event package negotiation exchange, presumably in headers 
>in the Invite and responses.  Then a Notify for the events.  
>Or really instead of a NOTIFY, it could be a new method 
>called "Invite-based Notification Function Output" or "INFO" 
>for short. :)

YES! :)

Regards,

Christer

> > Subject: RE: [Sip] Francois' counter to INFO (was Re: What are we 
> > > > information via Notify you need to receive back some 
> information 
> > > > (e.g.
> > > > the fact that you receive a 200Ok as answer to the Notify it is 
> > > > not enough).
> > need 2 subscription one in each direction, when one it is 
> enough and 
> > in the case of only one subscription the possibility to choose in 
> > which direction you want to start it.
> >
> >
> >
> >

---

Date: Sun, 14 Oct 2007 17:01:44 +0200

ntial,  proprietary,  copyrighted  and/or legally

---

Date: Sun, 14 Oct 2007 17:01:44 +0200

---

Date: Sun, 14 Oct 2007 17:01:44 +0200

---

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

Hi, 

[Christer] The questions you ask in your e-mail I think we need to get
an answer to in any case, no matter what/if we do with INFO. My opinions
in-line.

>>information ... Then you end up with a stimulus protocol between this 
>>UE and this centralised server where the dialog contains absolutely no

transport protocol"?

[Christer] No.

>If so, then the proper design model is to build a new SIP request
method for every new piece of application 
>functionality.

[Christer] No. That is unflexible, doesn't help innovation and
deployments of applications, and considering the time it takes to get
stuff through the IETF process (there would be lots of discussions about
the application itself, which has nothing to do with the SIP protocol
and how it is used )it probably would mean that people would use
non-standard mechanisms anyway.

Our job is to provide tools for people doing applications.
 
>embodies a different design philosophy than the same-dialog NOTIFY.

[Christer] I don't think we need a DTMF method. We may solve one issue,
but tomorrow there may a new one...
 
>to keep going back and forth on this. MAKE A DECISION, PEOPLE!

[Christer] My question is: are we really talking about SIP extension
here?

Yes, in order to make INFO work (or if we would do something related to
in-dialog notifications), we may have to do something. But, after that
is done, we don't need to extend anything. People using INFO (or
something else) may have to register whatever packages/content-types etc
etc, but that is not an extension of the protocol.

Regards,

Christer

>example that 	<[email-masked]>
From: "Christer Holmberg" <[email-masked]>
To: "Dean Willis" <[email-masked]>,
	"DRAGE, Keith (Keith)" <[email-masked]>
Cc: IETF SIP List <[email-masked]>, Francois Audet <[email-masked]>

Hi, 

[Christer] The questions you ask in your e-mail I think we need to get
an answer to in any case, no matter what/if we do with INFO. My opinions
in-line.

>>information ... Then you end up with a stimulus protocol between this 
>>UE and this centralised server where the dialog contains absolutely no

transport protocol"?

[Christer] No.

>If so, then the proper design model is to build a new SIP request
method for every new piece of application 
>functionality.

[Christer] No. That is unflexible, doesn't help innovation and
deployments of applications, and considering the time it takes to get
stuff through the IETF process (there would be lots of discussions about
the application itself, which has nothing to do with the SIP protocol
and how it is used )it probably would mean that people would use
non-standard mechanisms anyway.

Our job is to provide tools for people doing applications.
 
>embodies a different design philosophy than the same-dialog NOTIFY.

[Christer] I don't think we need a DTMF method. We may solve one issue,
but tomorrow there may a new one...
 
>to keep going back and forth on this. MAKE A DECISION, PEOPLE!

[Christer] My question is: are we really talking about SIP extension
here?

Yes, in order to make INFO work (or if we would do something related to
in-dialog notifications), we may have to do something. But, after that
is done, we don't need to extend anything. People using INFO (or
something else) may have to register whatever packages/content-types etc
etc, but that is not an extension of the protocol.

Regards,

Christer

>example that 	<[email-masked]>
From: "Christer Holmberg" <[email-masked]>
To: "Dean Willis" <[email-masked]>,
	"DRAGE, Keith (Keith)" <[email-masked]>
Cc: IETF SIP List <[email-masked]>, Francois Audet <[email-masked]>

Hi, 

[Christer] The questions you ask in your e-mail I think we need to get
an answer to in any case, no matter what/if we do with INFO. My opinions
in-line.

>>information ... Then you end up with a stimulus protocol between this 
>>UE and this centralised server where the dialog contains absolutely no

transport protocol"?

[Christer] No.

>If so, then the proper design model is to build a new SIP request
method for every new piece of application 
>functionality.

[Christer] No. That is unflexible, doesn't help innovation and
deployments of applications, and considering the time it takes to get
stuff through the IETF process (there would be lots of discussions about
the application itself, which has nothing to do with the SIP protocol
and how it is used )it probably would mean that people would use
non-standard mechanisms anyway.

Our job is to provide tools for people doing applications.
 
>embodies a different design philosophy than the same-dialog NOTIFY.

[Christer] I don't think we need a DTMF method. We may solve one issue,
but tomorrow there may a new one...
 
>to keep going back and forth on this. MAKE A DECISION, PEOPLE!

[Christer] My question is: are we really talking about SIP extension
here?

Yes, in order to make INFO work (or if we would do something related to
in-dialog notifications), we may have to do something. But, after that
is done, we don't need to extend anything. People using INFO (or
something else) may have to register whatever packages/content-types etc
etc, but that is not an extension of the protocol.

Regards,

Christer

>example that 	<[email-masked]>
From: "Christer Holmberg" <[email-masked]>
To: "Dean Willis" <[email-masked]>,
	"DRAGE, Keith (Keith)" <[email-masked]>
Cc: IETF SIP List <[email-masked]>, Francois Audet <[email-masked]>

Hi, 

[Christer] The questions you ask in your e-mail I think we need to get
an answer to in any case, no matter what/if we do with INFO. My opinions
in-line.

>>information ... Then you end up with a stimulus protocol between this 
>>UE and this centralised server where the dialog contains absolutely no

transport protocol"?

[Christer] No.

>If so, then the proper design model is to build a new SIP request
method for every new piece of application 
>functionality.

[Christer] No. That is unflexible, doesn't help innovation and
deployments of applications, and considering the time it takes to get
stuff through the IETF process (there would be lots of discussions about
the application itself, which has nothing to do with the SIP protocol
and how it is used )it probably would mean that people would use
non-standard mechanisms anyway.

Our job is to provide tools for people doing applications.
 
>embodies a different design philosophy than the same-dialog NOTIFY.

[Christer] I don't think we need a DTMF method. We may solve one issue,
but tomorrow there may a new one...
 
>to keep going back and forth on this. MAKE A DECISION, PEOPLE!

[Christer] My question is: are we really talking about SIP extension
here?

Yes, in order to make INFO work (or if we would do something related to
in-dialog notifications), we may have to do something. But, after that
is done, we don't need to extend anything. People using INFO (or
something else) may have to register whatever packages/content-types etc
etc, but that is not an extension of the protocol.

Regards,

Christer

---

Date: Sun, 14 Oct 2007 17:01:37 +0200

---

Date: Sun, 14 Oct 2007 17:01:37 +0200

---

Date: Sun, 14 Oct 2007 17:01:37 +0200

---

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

Hi, 

>>advantage of letting us reuse an existing registration framework, IANA

>One area that would need defining very carefully is the 
>question of subscription usage lifetimes.  Tying them to the 
>lifetime of the invite usage that caused them sounds quite 
>tidy, and would prevent a flurry of NOTIFY/state=terminated 
>messages straight after a BYE.

[Christer] Maybe these notifications could be sent in the BYE? And/or,
maybe we could define a "dialog" value for subscription usage lifetime?

I haven't thought about this proposal in detail yet, but we would also
need to take the the dialog-reuse spec (which proposes NOT to mix dialog
usages) into consideration. But, if we somehow could bind the
subscription lifetime to the dialog lifetime I think that at least some
of the issues in that spec would be solved.

Regards,

Christer

a02-mxc01.citel.com>
From: "Christer Holmberg" <[email-masked]>
To: "Michael Procter" <[email-masked]>,
	"Dean Willis" <[email-masked]>,
	"Francois Audet" <[email-masked]>
Cc: IETF SIP List <[email-masked]>

Hi, 

>>advantage of letting us reuse an existing registration framework, IANA

>One area that would need defining very carefully is the 
>question of subscription usage lifetimes.  Tying them to the 
>lifetime of the invite usage that caused them sounds quite 
>tidy, and would prevent a flurry of NOTIFY/state=terminated 
>messages straight after a BYE.

[Christer] Maybe these notifications could be sent in the BYE? And/or,
maybe we could define a "dialog" value for subscription usage lifetime?

I haven't thought about this proposal in detail yet, but we would also
need to take the the dialog-reuse spec (which proposes NOT to mix dialog
usages) into consideration. But, if we somehow could bind the
subscription lifetime to the dialog lifetime I think that at least some
of the issues in that spec would be solved.

Regards,

Christer

a02-mxc01.citel.com>
From: "Christer Holmberg" <[email-masked]>
To: "Michael Procter" <[email-masked]>,
	"Dean Willis" <[email-masked]>,
	"Francois Audet" <[email-masked]>
Cc: IETF SIP List <[email-masked]>

Hi, 

>>advantage of letting us reuse an existing registration framework, IANA

>One area that would need defining very carefully is the 
>question of subscription usage lifetimes.  Tying them to the 
>lifetime of the invite usage that caused them sounds quite 
>tidy, and would prevent a flurry of NOTIFY/state=terminated 
>messages straight after a BYE.

[Christer] Maybe these notifications could be sent in the BYE? And/or,
maybe we could define a "dialog" value for subscription usage lifetime?

I haven't thought about this proposal in detail yet, but we would also
need to take the the dialog-reuse spec (which proposes NOT to mix dialog
usages) into consideration. But, if we somehow could bind the
subscription lifetime to the dialog lifetime I think that at least some
of the issues in that spec would be solved.

Regards,

Christer

a02-mxc01.citel.com>
From: "Christer Holmberg" <[email-masked]>
To: "Michael Procter" <[email-masked]>,
	"Dean Willis" <[email-masked]>,
	"Francois Audet" <[email-masked]>
Cc: IETF SIP List <[email-masked]>

Hi, 

>>advantage of letting us reuse an existing registration framework, IANA

>One area that would need defining very carefully is the 
>question of subscription usage lifetimes.  Tying them to the 
>lifetime of the invite usage that caused them sounds quite 
>tidy, and would prevent a flurry of NOTIFY/state=terminated 
>messages straight after a BYE.

[Christer] Maybe these notifications could be sent in the BYE? And/or,
maybe we could define a "dialog" value for subscription usage lifetime?

I haven't thought about this proposal in detail yet, but we would also
need to take the the dialog-reuse spec (which proposes NOT to mix dialog
usages) into consideration. But, if we somehow could bind the
subscription lifetime to the dialog lifetime I think that at least some
of the issues in that spec would be solved.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 14 Oct 2007 17:35:00 -0400

> of the issues in that spec would be solved.

The lifetime of a dialog isn't an independent variable - it ends when 
the last dialog usage ends.

If you are really talking about implicit *subscriptions*, then you 
either must explicitly end them, or else define their *implicit* end in 
terms of something that has an explicit endpoint.

I expect that you are talking about something that either shares the 
invite dialog usage, or else a distinct dialog usage that implicitly 
starts and stops concurrently with the invite dialog usage.

	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 15 Oct 2007 09:07:35 +0200

Hi, 

>>need to take the the dialog-reuse spec (which proposes NOT to mix 
>>dialog usages) into consideration. But, if we somehow could bind the 
>>subscription lifetime to the dialog lifetime I think that at least 
>>some of the issues in that spec would be solved.
> 
>The lifetime of a dialog isn't an independent variable - it 
>ends when the last dialog usage ends.
> 
>If you are really talking about implicit *subscriptions*, 
>then you either must explicitly end them, or else define 
>their *implicit* end in terms of something that has an 
>explicit endpoint.
> 
>I expect that you are talking about something that either 
>shares the invite dialog usage, or else a distinct dialog 
>usage that implicitly starts and stops concurrently with the 
>invite dialog usage.

Yes. I'd like to call it "invite dialog subscriptions", or something
like that...

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 15 Oct 2007 09:24:12 +0200

Hi, 

Inline

>>       that is shared with a SUBSCRIBE and get a 481, what 
>>       is gone? The INVITE usage or the dialog?
> 
>The dialog, as before, and also the subscription, since the 
>subscription would be tied to the invite's dialog.  They 
>would share fate.

[Christer] I agree. I am not even sure we should call it a subscription
dialog, but a invite dialog subscription.

We also need to remember that there is a difference in how an invite
dialog and subscription dialog are created.

Due to the forking rules for SUBSCRIBE, the receival of a NOTIFY can
create a subscription dialog. An invite dialog is always created by a
responses (provisional or final), and I don't think we want to change
that.

>>       What it it's a 480? A 500? Even if  _you_ know where to look it
up, will implementors? 
>>       Even if they do, are the rules sufficiently labyrinthine that
the 
>>       chances of misimplementation are high?) The "pushing my
buttons" 
>>       comment came from your implication that INFO was basically the 
>>       same as NOTIFY in this context -- which is imperfect in myriad
ways. 
>>       For example:

[Christer] Good :) If we only have one usage, the invite usage,
everthing else would share the fate of the INVITE dialog. For example,
when the 200 OK is received, and all other early dialogs are terminated,
all "invite dialog subscriptions" related to those dialogs are also
automatically terminated.

>>question about whether it's worth salvaging, and I think that's a 
>>little less cut-and-dried (despite my strong opinion on the topic) -- 
>>but I'm boggled by the extreme pushback to making this negotiation 
>>explicit in the face of clear examples of how things break when we
don't.

>Yes I agree... didn't say otherwise. :)

[Christer] One issue with the subscription mechanism is that when A is
interested to receive events from B it sends a subscription to B. There
is basically no good way for A to tell B "Hey, I have some events I
would like to send you (if you support them), so please subscribe to
them". For some applications B KNOWS it will have to subscribe to
certain events from A, but in some cases B may again subscribe to events
"just in case". I think it would be useful if A somehow could indiate
which events it expects B to subscribe to for this specific call.

Regards,

Christer

---

From: Eric Burger <[email-masked]>
Date: Mon, 15 Oct 2007 07:00:28 -0500

Under what circumstances would A know what B needs, without B explicitly
signaling B's needs to A?

On 10/15/07 3:24 AM, "Christer Holmberg" <[email-masked]>
wrote:
[snip]

---

From: Eric Burger <[email-masked]>
Date: Mon, 15 Oct 2007 07:42:10 -0500

Dialog termination is where I see the most potential for confusion.  I would
also offer these problems are not insurmountable.  However, I would be
curious to find out if solving these problems does not reconstruct RFC 3265
in its full glory.

Let us take two scenarios for the easy case of transporting user stimulus.
In the first case, the user presses a button and hangs up.  Because of
normal Internet routing, the INFO (Invite-based Notification Function Output
;-) message arrives after the BYE arrives.  What to do?  What if the button
pressed was "don't launch missiles?"

In the second case, the application is using digit maps, because the
application developer realizes that 1100 bytes of SIP headers to transport
one byte of user stimulus information is stupid.  The device buffers some
digits, but the user hangs up.  What does the endpoint do?  Does it send the
collected digits?  Does it eat the collected digits?  Any argument other
than an explicit negotiation (like KPML does) is not going to work in the
general case.  This is because if we say, for DTMF, "always send buffered
digits," then what we are really saying is, "always send what you have
before the dialog terminates."  I could easily envision packages that would
have tons of state that is immediately irrelevant at dialog termination.
Dumping tons of bytes on the network again totally defeats the "We want this
because it is lightweight" argument.

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 15 Oct 2007 16:18:20 +0200

Hi,

It's not about A knowing what B "needs" - it's about A telling B that
there may be some information he is interested in sending - IF B wants
it.

Regards,

Christer 

> Sent: 15. lokakuuta 2007 15:00
> To: Christer Holmberg
> Cc: IETF SIP List
> Under what circumstances would A know what B needs, without B 
> explicitly signaling B's needs to A?
> 
> 
> > interested to receive events from B it sends a subscription to B. 
> > There is basically no good way for A to tell B "Hey, I have some 
> > events I would like to send you (if you support them), so please 
> > subscribe to them". For some applications B KNOWS it will have to 
> > subscribe to certain events from A, but in some cases B may again 
> > subscribe to events "just in case". I think it would be useful if A 
> > somehow could indiate which events it expects B to 
> subscribe to for this specific call.
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 15 Oct 2007 11:24:26 -0400

Eric Burger wrote:
> A few times I have seen a comment stating the endpoint interested in
> potentially receiving DTMF notifications may not know whether or not it
> needs DTMF. As such, the endpoint would be forced to always issue a
> SUBSCRIBE, even if it will not be interested in DTMF.
> 
> Could someone please describe a scenario in which the endpoint does NOT
> KNOW, a'priori, it will be interested in DTMF?
> 
> All the ones I can think of, like supplemental dial digits, ACD, register
> recall, and return to application are all known to the AS or Proxy driving
> the interaction.
> 
> What else is out there?

I think I have heard that SIP-H.323 GWs fall into this category.

(As well as gateways to some other more proprietary protocols that shall 
remain unnamed here.)

	Paul

> On 10/10/07 12:20 PM, "Christer Holmberg" <[email-masked]>
> wrote:
> 
>> Hi,
>>
>> (d) they think it's a waste of resources to establish multiple additional
>> subscription dialogs (there may be other type of data than DTMF they are
>> willing to receive) which in many cases may not even be used during the call
>> (it can not be assumed that the one sending the subscription always knows
>> exactly when it will receive events). Maybe DTMF is not the best example in
>> the world (my fault - I should have been more generic), but I am sure there
>> could be events which would not be used in a very high percentage of all
>> calls, but still the additional subscription dialog(s) would have to be
>> I still strongly think it would be much better to describe the
>> issues/advantages/disadvantages with BOTH INFO and events, and study what
>> possible needs to defined related to negotiation etc, instead of just ignoring
>> the real world and providing flexibility to people using SIP for their
>> applications...
>>  
>> Regards,
>>  
>> Christer
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>>

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 15 Oct 2007 13:12:36 -0500

My take is that we were talking about an implicit "start" and "end"
based
on the life of the INVITE dialog usage.

> Sent: Sunday, October 14, 2007 14:35
> To: Christer Holmberg
> Cc: Michael Procter; Dean Willis; Audet, Francois 
> (SC100:3055); IETF SIP List
> Subject: Re: [Sip] Francois' counter to INFO (was Re: What 
> are we arguing aboutwhen we say INFO?)
> 
> 
> 
> Christer Holmberg wrote:
> 
> > dialog

---

From: Jeroen van Bemmel <[email-masked]>
Date: Mon, 15 Oct 2007 20:52:45 +0200

Eric,

It's not that the "receiver" of DTMF events does not know it is 
interested, it's that the SUBSCRIBE/NOTIFY model forces the receiver to 
always subscribe, even if in 99% of the calls the other side is not 
expected to press any key during mid-call.

For example, there exist call center applications in which pressing a 
digit (say '1') indicates that the caller is annoying and should be 
placed on a blacklist. In this scenario the DTMF event is rare; INFO 
would be more efficient in this case (if supported of course).

In other scenario's (such as IVR systems) DTMF events are common; then 
SUBSCRIBE/NOTIFY may make more sense (overhead becomes less significant 
compared to total)

Regards,
Jeroen

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 15 Oct 2007 15:21:17 -0400

> Sent: Monday, October 15, 2007 7:49 AM
> To: Christer Holmberg; Hadriel Kaplan
> Cc: IETF SIP List
> Subject: Unsolicited NOTIFY/INFO versus Solicited State Update
>

A PSTN gateway has no idea what the PSTN-side call goes to or came from.  It may or may not need DTMF.  That PSTN GW has to subscribe for every call if it (or the other end) doesn't do 2833, regardless if any DTMF get pressed.  The same for a SIP-H.323 gateway, a Skype-SIP gateway, etc. (for H.323 in particular the probability of 2833 support is very low)

And even for a SIP AS that knows it needs DTMF, for some applications a KPML model will be more efficient than INFO, for others less... much less.

-hadriel

---

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

> pressed was "don't launch missiles?"

And what happens if the Bye gets to the far end before a 2833 event?  Improbable but not impossible.  I would expect an application providing a "don't launch missiles" type user input to provide a "missile launch order confirmed" that the user would wait to hear before hanging up.  ;)

> because it is lightweight" argument.

I'm not sure whether whomever writes a info-dtmf event package someday would define it to support digit maps or not... my guess is they would not.  But even if they did, I would assume the digits would be discarded in such a case, and defined to do so.  So what?  The user hung up, without pressing a sequence of digits that matched a map.  What's wrong with discarding the digits?

-hadriel

---

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

Hi, 

>Dialog termination is where I see the most potential for 
>confusion.  I would also offer these problems are not 
>insurmountable.  However, I would be curious to find out if 
>solving these problems does not reconstruct RFC 3265 in its 
>full glory.
> 
>In the first case, the user presses a button and hangs up.  
>Because of normal Internet routing, the INFO (Invite-based 
>Notification Function Output
>;-) message arrives after the BYE arrives.  What to do?  What 
>if the button pressed was "don't launch missiles?"
>
>In the second case, the application is using digit maps, 
>because the application developer realizes that 1100 bytes of 
>SIP headers to transport one byte of user stimulus 
>information is stupid.  The device buffers some digits, but 
>the user hangs up.  What does the endpoint do?  Does it send 
>the collected digits?  Does it eat the collected digits?  Any 
>argument other than an explicit negotiation (like KPML does) 
>is not going to work in the general case.  This is because if 
>we say, for DTMF, "always send buffered digits," then what we 
>are really saying is, "always send what you have before the 
>dialog terminates."  I could easily envision packages that 
>would have tons of state that is immediately irrelevant at 
>dialog termination.
>Dumping tons of bytes on the network again totally defeats 
>the "We want this because it is lightweight" argument.

In both your examples: after the dialog is terminated, all data (e.g.
buffered digits) and late messages (INFO not to launch missiles) will be
discarded. That is normal SIP behavior.

And, if you are going to use INFO to prevent world war III I THINK you
would wait for the 200 OK before sending BYE :)

Regards,

Christer

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 16 Oct 2007 11:14:12 +0300

> which events it expects B to subscribe to for this specific call.

I fully agree. 
I do think it should be useful if we could discriminate somehow the
following three cases 
- A is only interested to receive events from B
- A is interested to receive events from B, but A is also interested to
send events to B (A ask B to subscribe)
- A is not interested to receive events from B, but A wants send events
to B

regards
Sal

---

From: Dean Willis <[email-masked]>
Date: Tue, 16 Oct 2007 15:50:02 -0500

> offer/answer negotiation going on.

Mostly. Except that you're ALSO saying "And I expect the data  
transmitted to me as a result of this subscription to have the  
meaning (aka semantic)  specified by the specific event package named  
in the subscription." That's more than saying "Please send me jpeg  
images".

And with Francois' proposal, you're saying that you'd like to  
synchronize with that same state machine, as it applies to the  
current dialog, for the duration of the current dialog, with the  
state data encoded as indicated by the event package and to have the  
meaning specified by the event package.

> with and how you want to encode the state data.

Huh? No you still have to say which event package you're talking about.

> because the state machine being synchronized was SIP itself what

Not quite sure of the relationship to 3312. It seems to me that RFC  
3312 negotiates a fixed set of preconditions with explicit values,  
whereas INFO (and events) encompasses a much broader range. That's  
why RFC 3265 adds the event-package name and registry process.

-_
Dean

---

From: Dean Willis <[email-masked]>
Date: Tue, 16 Oct 2007 15:55:58 -0500

> You forgot about supported.

Well, it's entirely possible that Supported and Accept will get  
damned big. I'd still like to have a query-for-specific or "opt in"  
model rather than a blanket "here's everything I can possibly deal  
with" model for declaration of extensions. RFC 3265 meets that  
requirement.

>> extension method will also define exactly what payload format to use.

But the MIME people aren't going to let you register a new MIME type  
for "foo" that is specific to each application semantic that might  
possibly use "foo".

> Content-Type: application/foo

Broken in its usage of MIME.

Let's say we have something (not DTMF) that needs to transport jpg  
images that are used as soft-key overlays. To do what you're  
suggesting, we'd need a new MIME-type registration that says "This is  
just like jpeg, except that it is only useful for keypad overlays".  
The MIME folks would birth kittens.

> non-SDP extension modalities.

Yeah, that's true.

But maybe we narrow it down to SDP vs non-SDP instead of SDP vs SIP  
method vs MIME type vs event-package vs MSRP vs whatever.

--
Dean

---

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

> summary if it was in the BYE/200 (where it logically belongs).

I think you mean "explicitly subscribe", not "implicitly subscribe.  
If you've said (in the INVITE or in the 200 OK) which events you're  
hoping to see, that's explicit.

Explicit is Good. It means never having to guess.

--
Dean

---

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

>      recipient is requesting INFO (or NOTIFY) requests.

I don't see this, in Francois' proposal at least. If an INVITE  
request contains

Supported: In-Dialog-Events
Accept-Event-Packages: DTMF

(syntax is negotiable, of course)

then this is explicitly saying "You can send me events of the DTMF  
event package related to this dialog and I am prepared to deal with  
them". It's pretty much everything that a SUBSCRIBE has

I'd suggest further it doesn't really need to generate an initial  
NOTIFY, depending on the event package.

--
Dean

---

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

On Oct 14, 2007, at 4:35 PM, Paul Kyzivat wrote:

>> some
> The lifetime of a dialog isn't an independent variable - it ends  
> when the last dialog usage ends.
>
> either must explicitly end them, or else define their *implicit*  
> end in terms of something that has an explicit endpoint.
>
> I expect that you are talking about something that either shares  
> the invite dialog usage, or else a distinct dialog usage that  
> implicitly starts and stops concurrently with the invite dialog usage.

I believe we're talking about something that explicitly shares the  
INVITE dialog usage. Once a BYE transaction has been processed, it's  
over with. Yeah, you get all the usual dialog-usage termination race  
conditions (like BYE overlaps) but that's just the way it is with  
dialogs. Heck, that's the way it is with any session-oriented  
protocol, even TCP.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Tue, 16 Oct 2007 20:45:52 -0500

> 2 subscription one in each direction?

Yes, although I prefer to think of it (in this example) as each end  
having independently declared a willingness to receive events of the  
given package within the current INVITE-bounded dialog.

It might also be reasonable to envision two different event packages,  
designed to work together.

> that instead to be general just asks for a specific extension?

Yes, I think that would do the trick.

Maybe it's just me, but I find the process of including fully- 
populated Supported and Allow header fields in every request to be a  
bit daunting. Not to mention repetitious, bandwidth and CPU  
consumptive, and so on. Especially if we adopt the SIP-is-an- 
application-protocol model that requires us to add a new method for  
every payload type. Note that I have no idea how many UAs actually  
comply with RFC 3261 on this particular point.

SUBSCRIBE gives us something that will do the job. Without preceding  
contact, we can ask for a subscription to a package, and get an error  
response if it isn't there.

This is a nice property: It keeps us from having to advertise every  
event package to which we might possibly accept a subscription in  
every message we send.

--
dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 16 Oct 2007 22:22:13 -0400

> designed to work together.

Yeah, IMHO this shouldn't really be Subscriptions with a capital "S", as in rfc 3265, with Subscription state and initial Notifies and all.  It's really just info-event-package negotiation.

> consumptive, and so on.

I don't see how OPTIONS helps in reducing any of that.  You'd have to send one for every call.  That's more work than a list in a header, no?

> response if it isn't there.

And with this new model, you'd not get the info-event-package in responses for the INVITE, and know the same.  Well... you'd know for this INVITE-dialog the far end does not support info-event foo.  It may for other INVITE-dialogs, but that's arguably more flexible than SUBSCRIBE.

> event package to which we might possibly accept a subscription in

We're only talking about event packages which make sense for INVITE-dialog piggy-backing.  This wouldn't apply to things like presence, reg-event, etc.  Although I'm not sure how that would be documentable, other than defining something new and distinct from rfc3265 event packages.

-hadriel

---

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

> Sent: Tuesday, October 16, 2007 3:56 PM
> Cc: DRAGE, Keith (Keith); IETF SIP List; Audet, Francois 
> (SC100:3055); Christer Holmberg
> Well, it's entirely possible that Supported and Accept will 
> get damned big. I'd still like to have a query-for-specific 
> or "opt in"  
> model rather than a blanket "here's everything I can possibly 
> deal with" model for declaration of extensions. RFC 3265 
> meets that requirement.
> 
> >>
> But the MIME people aren't going to let you register a new 
> MIME type for "foo" that is specific to each application 
> semantic that might possibly use "foo".
> 
> > 200 OK
> > Supported: foo
> > Allow: INFO
> > Accept: application/foo
> >
> > ...
> >
> > INFO
> Let's say we have something (not DTMF) that needs to 
> transport jpg images that are used as soft-key overlays. To 
> do what you're suggesting, we'd need a new MIME-type 
> registration that says "This is just like jpeg, except that 
> it is only useful for keypad overlays".  

I think you may have misunderstood my example here. I'm postulating that
you don't change the MIME type (jpeg) you change the supported/required
header value.

---

From: Dean Willis <[email-masked]>
Date: Wed, 17 Oct 2007 13:38:27 -0500

> you don't change the MIME type (jpeg) you change the supported/ 

I think that conflicts with the way Supported and Require work. They  
both purely say "Can support these options at any time", not "I  
expect you to use this particular option's handling for this  
particular message"

Let's say you support jpeg for image-mapped touch screen and jpeg for  
storing in my pone book and displaying with caller ID. You'd indicate  
support for both in "Supported" and would not reject a request with  
Require for both.

I send you a jpeg. How do I tell you whether to put it on your screen  
as an image map or store it in your phone book?

--
Dean

---

From: "Brian Stucker" <[email-masked]>
Date: Wed, 17 Oct 2007 14:51:04 -0500

> Sent: Wednesday, October 17, 2007 1:38 PM
> > I think you may have misunderstood my example here. I'm postulating 
> > that you don't change the MIME type (jpeg) you change the 
> supported/ 
> > required header value.
> 
> 
> I think that conflicts with the way Supported and Require 
> work. They both purely say "Can support these options at any 
> time", not "I expect you to use this particular option's 
> handling for this particular message"
> 
> Let's say you support jpeg for image-mapped touch screen and 
> jpeg for storing in my pone book and displaying with caller 
> ID. You'd indicate support for both in "Supported" and would 
> not reject a request with Require for both.
> 
> I send you a jpeg. How do I tell you whether to put it on 
> your screen as an image map or store it in your phone book?
> 

You're right. I see the difference now.

Thanks,
Brian

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 18 Oct 2007 11:48:07 +0200

Hi, 

>>that you don't change the MIME type (jpeg) you change the supported/ 
>>required header value.
> 
> 

If the application on the receiving side (or the person your're talking
to) has asked you to send a jpeg, it most likely knows what to do it.
This is similar to when the receiver subscribes to an "jpeg event". The
one sending the jpeg may not know what the receiver is going to do with
it, but the one subscribing to the event knows.

If you send a jpeg just "out of the blue", you may not know what the
receiver is going to do with it. The receiving end may prompt the user
what to do, it may do something by default, etc. That is an
implementation issue - not a SIP protocol issue. SIP is simply used to
transport the jpeg. That is the whole purpose of INFO - sending data
which is not related to the SIP session itself.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 18 Oct 2007 11:58:03 +0200

> >both purely say "Can support these options at any time", not 
> "I expect 
> >you to use this particular option's handling for this particular 
> >message"
> > 
> jpeg for 
> your screen 
> This is similar to when the receiver subscribes to an "jpeg 
> event". The one sending the jpeg may not know what the 
> receiver is going to do with it, but the one subscribing to 
> the event knows.
> 
> If you send a jpeg just "out of the blue", you may not know 
> what the receiver is going to do with it. The receiving end 
> may prompt the user what to do, it may do something by 
> default, etc. That is an implementation issue - not a SIP 
> protocol issue. SIP is simply used to transport the jpeg. 
> That is the whole purpose of INFO - sending data which is not 
> related to the SIP session itself.

I guess I should say "SIP core" instead of "SIP session".

Regards,

Christer

---

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

inline

> it, but the one subscribing to the event knows.

In pretty much all the cases under discussion it is not a matter of 
asking a specific question that has one answer, and the mechanisms under 
discussion are not equipped for that. Rather it is a matter of 
expressing an interest in being notified of a class of things if and 
when they happen or come available.

And in Dean's case an interest has been expressed in events serving two 
purposes: touch screen maps and caller pictures. It just happens that 
both are represented by the same data type.

Matching the delivered information to the particular requested "event 
type" is in fact thw problem we are trying to solve. How are you 
imagining that this matching is taking place?

	Paul

---

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

> From: Christer Holmberg [mailto:[email-masked]]
>

But I can have multiple jpegs available: one for a snapshot of me for caller-id display, one for my company logo for vendor-id display, one I give out for a contact/buddy-icon of me, etc.  If you subscribe to me with an event of "jpeg", which jpeg do you want?  I don't know which to give you.  I would need to know what you want it for.  You need to use distinct event types to ask/subscribe for, like "caller-id-pic", "company-logo", "buddy-icon".  And since you can subscribe to multiples, I need to tell you which type I'm giving you a jpeg for.

-hadriel

---

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

> it, but the one subscribing to the event knows.

What if the receiving side has asked for jpegs foor two different  
functionalities in the same dialog? How does it know which treatment  
to apply to a given jpeg?

The answer is: It looks at the event package wrapping the jpeg.  
Without that function (which INFO doesn't currently have, and that  
that's what is broken), it just doesn't know.

--
Dean

---

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

Is it the gateway is doing DTMF -> H.245 mapping, or is it just for doing
compressed codec transport?

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

>>>> >>> RFC 2833 when it got implemented and (c) KPML didn't exist at that >>>>
time.
>> > 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: Eric Burger <[email-masked]>
Date: Thu, 18 Oct 2007 11:21:04 -0400

If the other end does not do 2833, than anything we do here is NOT going to
work.  This is because the other end will have to be modified to do whatever
we decide to do here (like INFO packages).  At that point, it could do 2833.
In fact, if the argument is how to support low power / low capability
devices, I would offer 2833 is insanely easier than anything in the SIP
layer.

On 10/15/07 12:21 PM, "Hadriel Kaplan" <[email-masked]> wrote:

> A PSTN gateway has no idea what the PSTN-side call goes to or came from.  It
> may or may not need DTMF.  That PSTN GW has to subscribe for every call if it
> (or the other end) doesn't do 2833, regardless if any DTMF get pressed.  The
> same for a SIP-H.323 gateway, a Skype-SIP gateway, etc. (for H.323 in
> particular the probability of 2833 support is very low)
> 
> And even for a SIP AS that knows it needs DTMF, for some applications a KPML
> model will be more efficient than INFO, for others less... much less.
> 
> -hadriel
>

---

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

Eric Burger wrote:
> Is it the gateway is doing DTMF -> H.245 mapping, or is it just for 
> doing compressed codec transport?

I know next to nothing about H.323. My understanding is that it thinks 
DTMF must travel in the signaling path for H.323, and I gather that 
means using H.245.

	Paul

>     additional
>     >  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
> 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: Hadriel Kaplan <[email-masked]>
Date: Thu, 18 Oct 2007 15:24:29 -0400

How does the number of seats matter?
Without a single button being pushed, KPML needs a Sub/200/Notify/200 to create the subscription, and a Notify/200 to tear it down.  6 messages.
The call needed an Invite/1xx/200/ACK and then Bye/200.  6 Messages.
Both create state for a dialog.

So basically we're talking about DOUBLE the number of messages and state, without a button even being pressed.  Now I know I'm not counting all the messages for REFER transfers, which are popular in call-centers, but call-transfers need new KPML subscribes too.

-hadriel

> Sent: Thursday, October 18, 2007 11:18 AM
> To: Jeroen van Bemmel
> Cc: IETF SIP List
> Subject: Re: [Sip] Unsolicited NOTIFY/INFO versus Solicited State Update
>
> I would buy the efficiency argument if we were talking about 100,000 seat
> call centers.  However, even for a 10,000 seat call center, we are talking
> about a pretty trivial number of messages compared to the total
> interaction.
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 18 Oct 2007 22:30:45 +0200

Hi,

>when they happen or come available.

I am not objecting to that.

>both are represented by the same data type.

I agree to that also. But, even in the subscription case it is not the SIP core protocol which indicates what to do with the data - it's the event type, or some information element within the event.

Regards,

Christer

        Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 18 Oct 2007 22:43:45 +0200

Hi,
 
>>If the application on the receiving side (or the person your're 
>>talking to) has asked you to send a jpeg, it most likely knows what to do it.
>>This is similar to when the receiver subscribes to an "jpeg event". 
>>The one sending the jpeg may not know what the receiver is going to do 
>>with it, but the one subscribing to the event knows.
>
>

INFO itself is not the problem - INFO simply carries the MIME. The problem, if there is one (depends on the use-case and what you are carrying), is that you don't provide enough information in the MIME (maybe Content-Disposition is not enough etc).

NOTIFY doesn't solve this problem either - NOTIFY simply carries the event package. The what-to-do is defiend by the event package, or by some information within the event package.

One question: do you think there should be a separate event for every possible way a receiver may process the jpeg?

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 18 Oct 2007 17:23:35 -0400

> One question: do you think there should be a separate event for every possible way a receiver may process the jpeg?

If there are different possible uses, and there is reason why the sender 
and the receiver need to agree on the use, then yes. If the different 
uses are strictly a matter of local preference, then no.

In the case at hand, it may be that I just send you jpegs. If I happen 
to send one that is my picture, you will (perhaps) recognize it as me 
and decide to put it in your address book. And if I happen to send you a 
key map then maybe you will install it on your touch screen phone. If 
that is my only expectation, then fine.

But if I expect that when I send you a jpeg of a key map that it will 
automatically be installed on your phone for the remaining duration of 
our call, then it is important that your device understand that.

	Paul

---

From: Eric Burger <[email-masked]>
Date: Thu, 18 Oct 2007 18:01:45 -0400

Ooooooh.  That¹s right.  Six messages.  Instead of...??? Well?

We are not talking about wireless networks here. Baseband networking sends
the bits, whether they are being used or not.

What I was saying is I would buy the efficiency argument IIF the example is
for a network where that matters.

I am offering that double the number of messages means we go from 1%
utilization to 2%?  Who cares?

And yes, this is from the chair of lemonade, where we care VERY MUCH about
efficiency.  However, that is a very different, very limited environment.
In fact, so far the only excuse for "not worth doing a proper subscription"
has been the H.323 gateway, which clearly will be on the broadband side of a
wired network.

On 10/18/07 3:24 PM, "Hadriel Kaplan" <[email-masked]> wrote:

> Without a single button being pushed, KPML needs a Sub/200/Notify/200 to
> create the subscription, and a Notify/200 to tear it down.  6 messages.
> So basically we're talking about DOUBLE the number of messages and state,
> without a button even being pressed.  Now I know I'm not counting all the
> messages for REFER transfers, which are popular in call-centers, but
> call-transfers need new KPML subscribes too.
> 
> -hadriel
> 
>

---

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

> Sent: Thursday, October 18, 2007 6:02 PM
> To: Hadriel Kaplan
> Cc: IETF SIP List

You said: "However, even for a 10,000 seat call center, we are talking about a pretty trivial number of messages compared to the total interaction."
By "total interaction", I assumed you meant from a SIP signaling perspective.  Doubling the number of SIP messages is more than a "trivial number" compared to the total number of SIP messages.  Or at least, I wouldn't mind that kind of "trivial" increase to my salary. ;)

> the bits, whether they are being used or not.

Absolutely.  And we're not talking about IP routers or Ethernet switches either.
I'm talking about SIP servers.  You know, those things you say are ancient concepts: stateful proxies, or app servers, or b2bua's, or PBXs/call-managers, etc.  I know not everyone thinks those things should exist.  No one's forcing them on you.  But they do exist.  And doubling the number of SIP messages and state has an impact on them... a cost which does not need to be incurred.

-hadriel

---

From: Eric Burger <[email-masked]>
Date: Thu, 18 Oct 2007 20:07:59 -0400

>>> a cost which does not need to be incurred.
... Unless you want to make sure you interoperate in all situations, not
just your controlled call center.

I would offer one could ALWAYS do a much more efficient protocol for a
closed environment.  We spend a lot of overhead to make sure all the corner
cases work.  This is one of those corner cases.

On 10/18/07 7:18 PM, "Hadriel Kaplan" <[email-masked]> wrote:

> You said: "However, even for a 10,000 seat call center, we are talking about a
> pretty trivial number of messages compared to the total interaction."
> By "total interaction", I assumed you meant from a SIP signaling perspective.
> Doubling the number of SIP messages is more than a "trivial number" compared
> to the total number of SIP messages.  Or at least, I wouldn't mind that kind
> of "trivial" increase to my salary. ;)
> 
> 
> I'm talking about SIP servers.  You know, those things you say are ancient
> concepts: stateful proxies, or app servers, or b2bua's, or PBXs/call-managers,
> etc.  I know not everyone thinks those things should exist.  No one's forcing
> them on you.  But they do exist.  And doubling the number of SIP messages and
> state has an impact on them... a cost which does not need to be incurred.
> 
> -hadriel
> 
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 18 Oct 2007 21:03:53 -0400

> just your controlled call center.

I don't mean to be flippant, but as far as I can tell INFO-dtmf has had a better track record of interoperability than KPML.  At least in the sense of (a) if you did it and the far-end did it, does it work, and (b) how many devices do it.  It's an unfair comparison, because it's been around longer, and at least one very popular vendor had it deployed widely early and documented it on their website and many others were simply forced to do what they did to interoperate.

Having said that, there is more than one flavor out there, and there is no negotiation.  Both of those issues can be fixed with an RFC.  They *are* fixed with KPML, but the cost is too high, and the solution too complicated for the problem, IMO.

-hadriel

---

From: [email-masked] (Juha Heinanen)
Date: Fri, 19 Oct 2007 07:54:25 +0300

> utilization to 2%?  Who cares?

it is not only network utilization, but also doubling the number of
messages the proxies need to route.  i start to get really worried, if
this kind of subscribe/notify complexity is introduced for each call.

-- juha