Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage?

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Fri, 1 Jun 2007 22:19:32 +0200

(As WG chair)

Is anyone out there interested in pursuing this?

If we did something, it would probably be an update to RFC 3427, and I don't see an awful lot of WG resources being consumed if we did, i.e. no impact on our existing workload.

However, if we wrote it, would anybody that matters respect it? Does it solve any current issues?

Regards

Keith

> -----Original Message-----
> From: Spencer Dawkins [mailto:[email-masked]] 
> Sent: Thursday, May 31, 2007 9:01 PM
> To: Dean Willis
> Cc: DRAGE, Keith (Keith); Jon Peterson; ext Cullen Jennings
> Subject: Re: [Sip] INFO message belongs only to INVITE dialog usage?
> 
> Hi, Dean,
> 
> > However, RFC 2976 is considered to be somewhat 
> underspecified, and so  
> > far the only place we've further specified its usage is in the  
> > context of transporting binary data for telephony protocol 
> tunelling.  
> > We have a standing consensus to NOT use it for arbitrary 
> data at this  
> > time. If we were to start using it, we'd need to do something like  
> > the event-packages model for INFO. So don't use it, and you 
> won't  have to deal with this . .
> > .
> 
> This is my understanding also, which makes me wonder why 
> http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.html
> didn't advance - I remember the early 00s as a time of 
> frantic IETF movement, so maybe things have settled down 
> enough to confirm the consensus?
> 
> I am more comfortable if we nail down consensus when we can, 
> rather than pointing people to Jonathan's expired individual 
> draft for support.
> 
> Other than changing Jonathan's contact information from 
> Dynamicsoft, were there other updates required? :-)
> 
> Thanks,
> 
> Spencer 
> 
> 
> 

_______________________________________________
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: [email-masked]
Date: Sat, 2 Jun 2007 23:15:09 -0400

From: "DRAGE, Keith \(Keith\)" <[email-masked]>

   (As WG chair)

What is "this"?  Do people think it would be genuinely helpful to
finish "this"?

   If we did something, it would probably be an update to RFC 3427,
   and I don't see an awful lot of WG resources being consumed if we
   did, i.e. no impact on our existing workload.

   However, if we wrote it, would anybody that matters respect it?
   Does it solve any current issues?

   Regards

   Keith

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Sun, 3 Jun 2007 21:25:55 +0200

Hi,

I don't think it would be very helpful - at least not if it's supposed to "forbid" things which are largely depoloyed already (and have been so for a number of years already).

Regards,

Christer 

> From: [email-masked] [mailto:[email-masked]] 
> Sent: 3. kesäkuuta 2007 6:15
> To: [email-masked]
> What is "this"?  Do people think it would be genuinely 
> helpful to finish "this"?
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: Robert Sparks <[email-masked]>
Date: Mon, 4 Jun 2007 09:23:09 -0500

I've been getting a lot of offline questions asking for the "right"  
way to carry information related to the
session-usage (often information that's being tunneled around from  
companion or gatewayed protocols).

What we've got sitting around right now is probably not enough if we  
don't want a new wave of things using INFO. We
need at least an easily findable explanation of why with a pointer to  
which other tools would be better considered
for different types of applications.

RJS

---

From: Robert Sparks <[email-masked]>
Date: Mon, 4 Jun 2007 10:04:32 -0500

Just to polish a rough spot in the thread:

>> So my, question is:
>>    Can INFO message  belong to other usages, besides INVITE, such  
>> are  SUBSCRIBE  or REFER?
>>
>
>
> There was IIRC no intent in the writing of RFC 2976 to restrict  
> INFO to occurring within an INVITE dialog usage. So it could  
> technically be used outside of one, including in non-dialog cases.

Somebody may have pointed this out already, but 2976 _does_ prevent  
the use of INFO outside a dialog - bottom of
page 4:

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

>
> However, RFC 2976 is considered to be somewhat underspecified, and  
> so far the only place we've further specified its usage is in the  
> tunelling. We have a standing consensus to NOT use it for arbitrary  
> data at this time. If we were to start using it, we'd need to do  
> something like the event-packages model for INFO. So don't use it,  
> and you won't have to deal with this . . .
>
>
> --
> Dean
>
>

---

From: Robert Sparks <[email-masked]>
Date: Mon, 4 Jun 2007 10:09:26 -0500

INFO was written before there _WAS_ anything but an INVITE dialog  
usage (called a call-leg at the time), so any
discussion of its use in other contexts (like SUBSCRIBE) will  
necessarily be in another document.

I remember a strong consensus around it only being allowed in the  
context of an INVITE usage, but can't find
definitive text in any later document this morning. Can anyone else?

On May 31, 2007, at 10:20 AM, Paul Kyzivat wrote:

> My understanding is consistent with what dialogusage says - INFO is  
> specific to the INVITE dialog usage. But off the top of my head I  
> can't recall where that is specified.
>
> 	Paul
>
> Nina Garaca wrote:
>> Hi all,
>> I have read rfc2976 - The SIP INFO Method, but I haven't really  
>> understood that INFO message belongs only to INVITE dialog usage,  
>> which however draft-ietf-sipping-dialogusage-04 claims in its part  
>> 5.3:
>>      5.3. Matching requests to usages
>>   For many mid-dialog requests, identifying the usage they belong  
>> to is
>>   obvious.  A dialog can have at most one invite usage, so any  
>> INVITE,
>>   UPDATE, PRACK, ACK, CANCEL, BYE, or INFO requests belong to it.
>> So my, question is:
>> Thanks in advance,
>> Nina.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 07 Jun 2007 15:31:43 -0400

What do you mean by 'information related to the session usage'?

I'll also take this opportunity to remind people of the reasons I think 
moving forward with more INFO usages is a bad idea:

http://www.jdrosen.net/papers/draft-rosenberg-sip-info-harmful-00.txt

-Jonathan R.

Robert Sparks wrote:

> I've been getting a lot of offline questions asking for the "right"  way 
> to carry information related to the
>> If we did something, it would probably be an update to RFC 3427,  and 
>> I don't see an awful lot of WG resources being consumed if we  did, 
>> i.e. no impact on our existing workload.
>>
>>> http://www.jdrosen.net/papers/draft-rosenberg-sip-info- harmful-00.html

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Robert Sparks <[email-masked]>
Date: Thu, 7 Jun 2007 22:08:59 -0700

> What do you mean by 'information related to the session usage'?

Ugh - that's what the parenthetical below way trying to talk about.
Stuff like digits in INFO (which we say should be done with KPML  
instead).
Stuff like capturing data out of a protocol on the other side of a  
gateway an tunneling it to
either an application or to another gateway.
Stuff like data out of the media channel (collected an an IVR  
perhaps) that needs to be passed
to an application server that's not on the media path.
More stuff than I think it will be worth trying to build clarity  
around for this conversation.

My point was to _agree_ with what's in sip-info-harmful (you see that  
Dean also called that out early in the thread)
and to note that we don't have the reasoning that's there stated  
strongly enough in an easy to stumble across place
and without that, people are going to continue to find new ways to  
fill the tubes with INFO requests.
(We need _more_ than just what's in your draft - we also need  
guidance for people who are wanting to do new
things with INFO that points them to what we consider sane  
alternatives instead.)

RjS

>
> I'll also take this opportunity to remind people of the reasons I  
> think moving forward with more INFO usages is a bad idea:
>
>> I've been getting a lot of offline questions asking for the  
>> "right"  way to carry information related to the
>> session-usage (often information that's being tunneled around  
>> from  companion or gatewayed protocols).
>> What we've got sitting around right now is probably not enough if  
>> we  don't want a new wave of things using INFO. We
>> need at least an easily findable explanation of why with a pointer  
>> to  which other tools would be better considered
>>> and I don't see an awful lot of WG resources being consumed if  
>>> we  did, i.e. no impact on our existing workload.
>>>

---

From: Spencer Dawkins <[email-masked]>
Date: Fri, 08 Jun 2007 06:34:21 -0500

Hi, Robert/Jonathan,

> Stuff like data out of the media channel (collected an an IVR  perhaps) 
> that needs to be passed
> More stuff than I think it will be worth trying to build clarity  around 
> for this conversation.
>
> and to note that we don't have the reasoning that's there stated  strongly 
> enough in an easy to stumble across place
> and without that, people are going to continue to find new ways to  fill 
> the tubes with INFO requests.

Two separate issues, both important...

> (We need _more_ than just what's in your draft - we also need

Jonathan may remember that I asked about his draft in discussions about the 
hitchhiker's guide. The answsr was, of course, that we didn't have a 
reasonable reference to the draft, so couldn't tell people who were trying 
to learn about SIP "don't go there" (until, of course, they "go there" and 
submit draft-newbie-sip-whatever-over-info-00).

So at the very least, we need an RFC number that's not in the draft now!

> things with INFO that points them to what we consider sane  alternatives 
> instead.)

It would be OK with me if we ALSO had this type of guidance ("don't look 
HERE, look over THERE") available ("stated strongly enough in an easy to 
stumble across place"), but if coming up with that guidance takes more than 
about a week, I don't see a lot of reason to hold up on "don't go there" 
while we explore alternatives.

<rant>If we don't progress stuff like this, we can't be surprised when the 
experts spend all their time explaining the same stuff over and over again, 
onlist. New participants don't want to repeat old bad ideas. They have 
plenty of opportunities to come up with NEW bad ideas. This is a SIP 
community responsibility, not just Jonathan's and not just the chairs' 
responsibility. Jonathan did his part (in 2003), and Dean points to this 
draft about once a month. We need to find a way to move past 
lather-rinse-repeat about long-time semi-documented consensus.

IMO. Of course.

</rant>

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Fri, 8 Jun 2007 13:42:34 +0200

Hi,

People are implementing INFO usages WITHOUT submitting draft-newbie-sip-whatever-over-info-00.

And, when looking at which companies are doing it, it can be discussed whether all of them can be considered being "SIP newbies"... But, that's another issue.

Regards,

Christer

> Sent: 8. kesäkuuta 2007 14:34
> To: Robert Sparks; Jonathan Rosenberg
> Cc: [email-masked]
> > gateway an tunneling it to either an application or to another 
> > gateway.
> > perhaps) that needs to be passed to an application server 
> that's not 
> > on the media path.
> > Dean also called that out early in the thread) and to note that we 
> > don't have the reasoning that's there stated  strongly enough in an 
> > easy to stumble across place and without that, people are going to 
> > continue to find new ways to  fill the tubes with INFO requests.
> 
> Jonathan may remember that I asked about his draft in 
> discussions about the hitchhiker's guide. The answsr was, of 
> course, that we didn't have a reasonable reference to the 
> draft, so couldn't tell people who were trying to learn about 
> SIP "don't go there" (until, of course, they "go there" and 
> > guidance for people who are wanting to do new things with INFO that 
> > points them to what we consider sane  alternatives
> > instead.)
> 
> It would be OK with me if we ALSO had this type of guidance 
> ("don't look HERE, look over THERE") available ("stated 
> strongly enough in an easy to stumble across place"), but if 
> coming up with that guidance takes more than about a week, I 
> don't see a lot of reason to hold up on "don't go there" 
> <rant>If we don't progress stuff like this, we can't be 
> surprised when the experts spend all their time explaining 
> the same stuff over and over again, onlist. New participants 
> don't want to repeat old bad ideas. They have plenty of 
> opportunities to come up with NEW bad ideas. This is a SIP 
> responsibility. Jonathan did his part (in 2003), and Dean 
> points to this draft about once a month. We need to find a 
> way to move past lather-rinse-repeat about long-time 
> semi-documented consensus.
> 
> IMO. Of course.
> 
> </rant>
> 
> > RjS
> >
> >>

---

From: "Steve Langstaff" <[email-masked]>
Date: Fri, 8 Jun 2007 05:48:47 -0700

Maybe "sip-info-harmful" should be the first "WCP" (Worst Current Practice) document?  

> From: Christer Holmberg (JO/LMF) 
> [mailto:[email-masked]] 
> Sent: 08 June 2007 12:43
> To: Spencer Dawkins; Robert Sparks; Jonathan Rosenberg
> Cc: [email-masked]
> Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage?
> 
> 
> Hi,
> 
> And, when looking at which companies are doing it, it can be 
> discussed whether all of them can be considered being "SIP 
> newbies"... But, that's another issue.
> 
> Regards,
> 
> Christer
> 
> 
>  
> 
> > Jonathan may remember that I asked about his draft in discussions 
> > about the hitchhiker's guide. The answsr was, of course, that we 
> > didn't have a reasonable reference to the draft, so couldn't tell 
> > people who were trying to learn about SIP "don't go there" 
> (until, of 
> > course, they "go there" and submit 
> > draft-newbie-sip-whatever-over-info-00).
> > 
> > It would be OK with me if we ALSO had this type of guidance ("don't 
> > look HERE, look over THERE") available ("stated strongly 
> enough in an 
> > easy to stumble across place"), but if coming up with that guidance 
> > takes more than about a week, I don't see a lot of reason 
> to hold up 
> > on "don't go there"
> surprised when 
> > the experts spend all their time explaining the same stuff over and 
> > over again, onlist. New participants don't want to repeat old bad 
> > ideas. They have plenty of opportunities to come up with NEW bad 
> > ideas. This is a SIP community responsibility, not just 
> Jonathan's and 
> > not just the chairs'
> > responsibility. Jonathan did his part (in 2003), and Dean points to 
> > this draft about once a month. We need to find a way to move past 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments on the application of sip
> > 
> 
>

---

From: Robert Sparks <[email-masked]>
Date: Fri, 8 Jun 2007 06:54:38 -0700

Spencer - I can't tell if you thought I was saying to hold moving  
info-harmful forward until
we had better answers or not - I wasn't. I'm saying we aren't done  
just by moving it forward.
It will help on its own, but we'll have to get to the guidance part  
quickly for it to really help much.

RjS

On Jun 8, 2007, at 4:34 AM, Spencer Dawkins wrote:

>> My point was to _agree_ with what's in sip-info-harmful (you see  
>> that Dean also called that out early in the thread)
>> and without that, people are going to continue to find new ways  
>> to  fill the tubes with INFO requests.
>
> people who were trying to learn about SIP "don't go there" (until,  
> of course, they "go there" and submit draft-newbie-sip-whatever- 
> over-info-00).
>
> look HERE, look over THERE") available ("stated strongly enough in  
> an easy to stumble across place"), but if coming up with that  
> guidance takes more than about a week, I don't see a lot of reason  
> to hold up on "don't go there" while we explore alternatives.
>
> <rant>If we don't progress stuff like this, we can't be surprised  
> when the experts spend all their time explaining the same stuff  
> over and over again, onlist. New participants don't want to repeat  
> old bad ideas. They have plenty of opportunities to come up with  
> NEW bad ideas. This is a SIP community responsibility, not just  
> Jonathan's and not just the chairs' responsibility. Jonathan did  
> his part (in 2003), and Dean points to this draft about once a  
> month. We need to find a way to move past lather-rinse-repeat about  
> long-time semi-documented consensus.
>
> IMO. Of course.
>
> </rant>
>
>> RjS
>>
>>>
>>> I'll also take this opportunity to remind people of the reasons  
>>> I  think moving forward with more INFO usages is a bad idea:
>>>

---

From: "Gilad Shaham" <[email-masked]>
Date: Fri, 8 Jun 2007 15:04:24 +0100

Many people are still under the impression that DTMF should/can be done with INFO.
For example: http://www.vonage-forum.com/ftopic5305.html
I'm not even sure how many people are aware of RFC 4730 as it's quite new. However, RFC 4730 does not explain why DTMF should be done by event notification rather than INFO. This feature was missing for a long time in SIP so many implementations already have INFO with DTMF (I won't provide links for that, but it's easy to find via any popular search engine).

I also seem to remember a company, with a lot of experience with SIP that offered a few years ago to do floor control with INFO. Basically anyone who wants to do something proprietary without thinking about it too much will go for INFO. Since RFC 3265 came out things have improved because many realize event packages are a better solution. However, INFO is still considered a viable candidate for many of these solutions because it seems as an option SIP provides and perhaps even endorses. I assume it's because the INFO concept is very simple.

Unfortunately INFO is required for SIP-T, therefore there is a valid usage.

The options I see are:
1. Provide BCP (or WCP as stated below) for INFO.
2. Deprecate the current RFC and define INFO for SIP-T only.
3. Find another solution for SIP-T and wipe out INFO from SIP.
4. Find more cases that mandate INFO (are there any?) and redefine its scope.

Gilad

> From: Steve Langstaff [mailto:[email-masked]]
> Sent: Friday, June 08, 2007 3:49 PM
> To: Christer Holmberg (JO/LMF); Spencer Dawkins; Robert Sparks; Jonathan
> Rosenberg
> Cc: [email-masked]

---

From: Diego B <[email-masked]>
Date: Fri, 08 Jun 2007 17:09:00 +0300

Hi;
Don't forget that most Media Servers Control protocols
use SIP info to carry their XML payload to control the media server.

Regards
Diego B

Gilad Shaham wrote:
>>>>> Ugh - that's what the parenthetical below way trying to
>>>>>           
>>> talk about.
>>>       
>>>>> Stuff like capturing data out of a protocol on the other
>>>>>           
>>> side of a
>>>       
>>>>> My point was to _agree_ with what's in sip-info-harmful
>>>>>           
>>>> (you see that
>>>>         
>>>>> Dean also called that out early in the thread) and to
>>>>>           
>>> note that we
>>>       
>>>>> don't have the reasoning that's there stated  strongly
>>>>>           
>>> enough in an
>>>       
>>>>> easy to stumble across place and without that, people are
>>>>>           
>>> going to
>>>       
>>>>> guidance for people who are wanting to do new things with
>>>>>           
>>> INFO that
>>>       
>>>>>> I'll also take this opportunity to remind people of the
>>>>>>             
>>> reasons I
>>>

---

From: Spencer Dawkins <[email-masked]>
Date: Fri, 08 Jun 2007 16:33:56 -0500

Hi, Robert,

> we had better answers or not - I wasn't.

My bad. It wasn't obvious to me from your otherwise-excellent note whether 
you were thinking of two separate documents.

I just wanted to make sure we would do something soon (at least measured in 
IETF years). Given that saying "don't go there" has taken four years since 
Jonathan's last update, I was concerned that saying "don't look here, look 
over there" would take more time than I was willing to spend continuing to 
point to an expired draft.

I have pointed this out previously in private e-mail, but 
http://www.ietf.org/internet-drafts/draft-melanchuk-mediactrl-framework-00.txt 
is having to put forward its own analysis of "why not INFO" in Section 5 
("SIP Usage"), because Tim doesn't have anything we can refer to except an 
expired individual draft. I'd rather rely on a document done here than text 
in the MEDIACTRL framework document, just because I think the larger SIP 
community would look at text done here more closely than in a MEDIACTRL 
draft.

IMO, of course.

> I'm saying we aren't done  just by moving it forward.

Ack.

> quickly for it to really help much.

Double Ack.

> RjS

Thanks for clarifying (so that I'm now clear :-).

Spencer

---

From: Dean Willis <[email-masked]>
Date: Fri, 8 Jun 2007 19:44:01 -0500

> long-time semi-documented consensus.

Schrodinger's cat is out of the bag and off eating mice somewhere.

SIP is a transport protocol. INFO is its freight carrier. People have  
used it and will use it in ways that make us queasy. The only thing  
to do is to produce some guidelines about documenting those "ways"  
and provide both registration and peer-negotiation for "ways" so that  
we don't have a meltdown. Much like we did for event packages.

--
Dean

---

From: "Rafferty, James" <[email-masked]>
Date: Fri, 8 Jun 2007 11:01:48 -0400

I like the idea of being clear where SIP INFO belongs (arguably only for
use with SIP-T) and then having a BCP which identifies common places
where SIP INFO is being used today, and then references the preferred
practice (typically not using SIP INFO) or work in progress (for
example, the mediactrl work) which will result in new practices.  

The problem from a manufacturer's standpoint is that customers have
existing products (for example, gateways) that use SIP INFO for DTMF
passage and they insist on having compatibility with these bad practices
built into other products, thus perpetuating the cycle of bad practice.
A BCP might at least point the preferred way out of this mess.   

James

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Tue, 12 Jun 2007 14:14:06 +0200

Hi,

>I like the idea of being clear where SIP INFO belongs 
>(arguably only for use with SIP-T) and then having a BCP 
>which identifies common places where SIP INFO is being used 
>today, and then references the preferred practice (typically 
>not using SIP INFO) or work in progress (for example, the 
>mediactrl work) which will result in new practices.  
> 
>The problem from a manufacturer's standpoint is that 
>customers have existing products (for example, gateways) that 
>use SIP INFO for DTMF passage and they insist on having 
>compatibility with these bad practices built into other 
>products, thus perpetuating the cycle of bad practice.

Normally, when we produce BCP type of documents, it's because there is a
problem out there (people implement specs in different, uninteroperable,
ways etc).

Are we aware of real-life problems with using INFO for DTMF (or whatever
else it's used for)? People have been doing it for a while (if we wanted
to restrict something, it should have been done years ago...), it's
fairly simple to implement - and it seems to work.

The only problem is that much of the INFO usages are not defined in
RFCs, but that's not always the fault of the implementors...

Regards,

Christer

---

From: "Gilad Shaham" <[email-masked]>
Date: Tue, 12 Jun 2007 13:42:02 +0100

Comments inline.

Cheers,
Gilad

> Sent: Tuesday, June 12, 2007 3:14 PM
> To: Rafferty, James; Gilad Shaham; Steve Langstaff; Spencer Dawkins;
> Robert Sparks; Jonathan Rosenberg
> Cc: [email-masked]

Do we need DTMF via INFO for some kind of functionality KPML (or RFC
2833) does not provide? I'm not aware of such a case.

One description of a problem with INFO can be found in this historical
chat:
http://www1.ietf.org/mail-archive/web/sipping/current/msg04455.html

The explanation from the expired draft is as follows:

Under this proposal, a User Agent MUST NOT send signaled digits or
telephone-events using the INFO method if the event was ever represented
as a tone (as media). Only signals originated as pure signaling MAY
generate an INFO method. Failure to heed this requirement will result in
double-detection of digits/events. 

If INFO is used incorrectly by a pair of PSTN gateways (for example),
the source gateway may detect a digit, send an INFO request which is
lost, and retransmit that request. The target gateway would send the
original in-band tone to the PSTN when the audio media arrives, later
when the INFO arrives, the target gateway would render the same tone
again. It is quite likely that the INFO will arrive after the media tone
has been played (especially if multiple intermediaries are involved);
the same digit would be played out again and this will frequently cause
systems in the PSTN to detect the same digit signaled twice. 

> RFCs, but that's not always the fault of the implementors...

I think the implementors knew this was not standard or at most in very
early draft mode when they implemented it.

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Tue, 12 Jun 2007 14:55:40 +0200

Hi, 

>2833) does not provide? I'm not aware of such a case.

Regarding 2833, I guess the main idea of sending DTMFs out-of-band (no
matter if you use INFO or something else) is when you send them to an
entity which does not have media access.

>Under this proposal, a User Agent MUST NOT send signaled 
>digits or telephone-events using the INFO method if the event 
>was ever represented as a tone (as media). Only signals 
>originated as pure signaling MAY generate an INFO method. 
>Failure to heed this requirement will result in 
>If INFO is used incorrectly by a pair of PSTN gateways (for 
>example), the source gateway may detect a digit, send an INFO 
>request which is lost, and retransmit that request. The 
>target gateway would send the original in-band tone to the 
>PSTN when the audio media arrives, later when the INFO 
>arrives, the target gateway would render the same tone again. 
>It is quite likely that the INFO will arrive after the media 
>tone has been played (especially if multiple intermediaries 
>are involved); the same digit would be played out again and 
>this will frequently cause systems in the PSTN to detect the 
>same digit signaled twice. 

You can always mess up if you use things incorrectly. I don't think that
is INFO specific.

Regards,

Christer

> I think the implementors knew this was not standard or at 
> most in very early draft mode when they implemented it.
> 
> > 
> > Regards,
> > 
> > Christer
>

---

From: "Gilad Shaham" <[email-masked]>
Date: Tue, 12 Jun 2007 14:29:07 +0100

Hi,

Here is another major problem with INFO - there is no header that states
the purpose of INFO.
The event header in subscriptions helps identify an event package.
Therefore an implementation can easily detect if this event package is
supported or not. With INFO it is much harder to detect the purpose of
this INFO message. Currently AFAIK the content-type in INFO implicitly
denotes this.

If you are aiming towards a solution that keeps INFO for more usages, I
would say that we need to resolve this issue first.

I also think it would be a burden on implementors to do both KPML and
INFO. Wouldn't it be easier for the implementors that did INFO to switch
to KPML instead of the entire industry doing both?

Gilad

> Sent: Tuesday, June 12, 2007 3:56 PM
> To: Gilad Shaham; Rafferty, James; Steve Langstaff; Spencer Dawkins;

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Tue, 12 Jun 2007 15:53:34 +0200

Hi, 

>Here is another major problem with INFO - there is no header 
>that states the purpose of INFO.
>Therefore an implementation can easily detect if this event 
>package is supported or not. With INFO it is much harder to 
>detect the purpose of this INFO message. Currently AFAIK the 
>content-type in INFO implicitly denotes this.

If I send a DTMF digit, the purpose is to send a DTMF digit :)

>If you are aiming towards a solution that keeps INFO for more 
>usages, I would say that we need to resolve this issue first.

I am just trying to figure out what the problem really is.

Regards,

Christer

>I also think it would be a burden on implementors to do both 
>KPML and INFO. Wouldn't it be easier for the implementors 
>that did INFO to switch to KPML instead of the entire 
>industry doing both?

> > >telephone-events using the INFO method if the event was ever 
> > >represented as a tone (as media). Only signals originated as pure 
> > >signaling MAY generate an INFO method.
> > >again.
> > >It is quite likely that the INFO will arrive after the 
> media tone has 
> > >been played (especially if multiple intermediaries are 
> involved); the 
> > >same digit would be played out again and this will 
> frequently cause 
> > > I think the implementors knew this was not standard or at most in 
> > > very early draft mode when they implemented it.
> > >
> > > >
> > > > Regards,
> > > >
> > > > Christer
> > >
>

---

From: Diego B <[email-masked]>
Date: Tue, 12 Jun 2007 19:46:23 +0200

Inline

> Here is another major problem with INFO - there is no header that states
If the conte-type is correct, the payload is a DTMF digit. No needs for 
a special header.
> supported or not. 
You can state in the Accept header that you support the content-type for 
the DTMF paylod ( application/dtmf or application/dtmf-relay )
> With INFO it is much harder to detect the purpose of
So, why is harder ?
> would say that we need to resolve this issue first.
I do not see any issue here
> to KPML instead of the entire industry doing both?
INFO is very easy to implement. So I dont't see any problem to keep the 
INFO implementation
until KPML is adopted. Or maybe keep both.
Diego B
>>>> Are we aware of real-life problems with using INFO for DTMF (or
>>>>         
>> whatever
>>     
>>>> else it's used for)? People have been doing it for a while (if we
>>>>         
>> wanted
>>     
>>> One description of a problem with INFO can be found in this
>>>       
> historical
>   
>>> chat:
>> You can always mess up if you use things incorrectly. I don't think
>>     
> that
>   
>> is INFO specific.
>>
>> Regards,
>>
>> Christer
>>
>>
>>
>>     
>>>
>>>
>>>       
>>>> The only problem is that much of the INFO usages are not defined
>>>>         
> in
>

---

From: Dean Willis <[email-masked]>
Date: Tue, 12 Jun 2007 15:25:12 -0500

> I am just trying to figure out what the problem really is.

This is ancient, badly written in a hurry, and full of errors, but it  
might help:

http://www.softarmor.com/wgdb/docs/draft-willis-sip-infopackage-00.txt

--
Dean

---

From: "Gilad Shaham" <[email-masked]>
Date: Tue, 12 Jun 2007 22:57:04 +0100

In my opinion, content-type is not good enough. What would one do if it
is Multipart-Mixed?
We are talking about something general, right? What if the same content
type is to be used for 2 different info usages?

Christer asked if there are real life problems with using INFO for DTMF,
I think it's one of the problems today with INFO in general. I'm sure it
can be solved (e.g., the old draft Dean sent), but it still requires
change in the spec.

Returning to the question, "why not do INFO for DTMF?". Let's assume
there are good solutions to all the problems one can find with INFO for
DTMF then:
1. It might be different than existing implementations therefore
implementors that already have it will still need to change their
implementation.
2. It might simply provide a subset/same functionality KPML provides.

Regards,
Gilad

> From: Diego B [mailto:[email-masked]]
> Sent: Tuesday, June 12, 2007 8:46 PM
> To: Gilad Shaham
> Cc: Christer Holmberg (JO/LMF); [email-masked]; Rafferty, James; Steve
> Langstaff
usages, I

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Wed, 13 Jun 2007 11:26:20 +0200

Hi Dean,

Thanks for the document. I have read it before, but had forgotten about it.

Now, the first issue is how we know that the receiver supports the Content-Type of the body sent in INFO. There are ways to solve that, and it is not an INFO specific problem.

The second issue is regarding the "SIP protocol rules", and I guess that is one thing which causes confusion. 

For example, if someone wants to send a DTMF tone he sends an INFO with the DTMF tone. The receiver will determine whether it's needed for anything (e.g. a robot asking for your PIN code) or not (e.g. if you're talking to a person and pressed a button by misstake). What "SIP protocol rules" do you need for that? The application will determine what/if it does with the received information.

Regards,

Christer

> From: Dean Willis [mailto:[email-masked]] 
> Sent: 12. kesäkuuta 2007 23:25
> To: Christer Holmberg (JO/LMF)
> Cc: SIP IETF
> >> If you are aiming towards a solution that keeps INFO for 
> more usages, 
> >> I would say that we need to resolve this issue first.
> >
> This is ancient, badly written in a hurry, and full of 
> errors, but it might help:
>

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Wed, 13 Jun 2007 11:33:35 +0200

Hi, 

>In my opinion, content-type is not good enough. What would 
>one do if it is Multipart-Mixed?
>We are talking about something general, right? What if the 
>same content type is to be used for 2 different info usages?

The application you're currently using should know what to do with it.

>Christer asked if there are real life problems with using 
>INFO for DTMF, I think it's one of the problems today with 
>INFO in general. I'm sure it can be solved (e.g., the old 
>draft Dean sent), but it still requires change in the spec.

What real-life problems are there with using INFO for DTMF?

Regards,

Christer

> > > Therefore an implementation can easily detect if this 
> event package
> is
> > > supported or not.
> > > With INFO it is much harder to detect the purpose of this INFO 
> > > message. Currently AFAIK the content-type in INFO
> implicitly
> > > denotes this.
> > >
> > >
> > So, why is harder ?
> > >> Regarding 2833, I guess the main idea of sending DTMFs 
> out-of-band
> (no
> > >> matter if you use INFO or something else) is when you 
> send them to
> an
> > >>> request which is lost, and retransmit that request. The target 
> > >>> gateway would send the original in-band tone to the 
> PSTN when the 
> > >>> audio media arrives, later when the INFO arrives, the target 
> > >>> gateway would render the same tone again.
> media tone 
> > >>> has been played (especially if multiple intermediaries are 
> > >>> involved); the same digit would be played out again and 
> this will 
> > >>> frequently cause systems in the PSTN to detect the same digit 
> > >>> signaled twice.
> > >>>

---

From: Dale Worley <[email-masked]>
Date: Wed, 13 Jun 2007 13:30:21 -0400

There's a lot of talk about INFO and KPML.  But people should be aware
that most SIP phone systems in the field use RTP (RFC 4733) to
transmit DTMF digits.

Dale

---

From: [email-masked]
Date: Wed, 13 Jun 2007 13:38:20 -0400

From: "Christer Holmberg (JO/LMF)" <[email-masked]>

There is an ambiguity in what Content-Type means: "what sort of media
does this encoded data represent" vs. "what you should do with this
data".  I don't think there are any cases in current SIP
implementations where this is a practical problem.  I expect that in
most cases where "what you should do with this data" is not completely
implied by "what sort of media this represents", the situation will be
complex enough that the applications will define extension headers to
disambiguate the situation, define extension media types to carry the
"intention", or more likely, represent the data as an XML structure
which explicitly states the intended action.

Dale

---

From: Dean Willis <[email-masked]>
Date: Wed, 13 Jun 2007 13:08:17 -0500

> Thanks for the document. I have read it before, but had forgotten  

Probably a healthy response ;-).

>
> Now, the first issue is how we know that the receiver supports the  
> Content-Type of the body sent in INFO. There are ways to solve  
> that, and it is not an INFO specific problem.
>

beyond "does it understand the content type?", we have the question  
"does it understand what you want it to do with the content?"

> The second issue is regarding the "SIP protocol rules", and I guess  
> that is one thing which causes confusion.
>
> For example, if someone wants to send a DTMF tone he sends an INFO  
> with the DTMF tone. The receiver will determine whether it's needed  
> for anything (e.g. a robot asking for your PIN code) or not (e.g.  
> if you're talking to a person and pressed a button by misstake).  
> What "SIP protocol rules" do you need for that? The application  
> will determine what/if it does with the received information.

"Spray and pray" is fun for kids in street gangs but well-aimed fire  
is far more efficient and much safer for  innocent bystanders.

Staying with the use of DTMF/INFO as an example (which, I'd like to  
add, has been deprecated even if I did originally endorse or maybe  
even coinvent it) . . .

Before you send a DTMF/INFO, you really need to know that the  
recipient understands DTMF/INFO in general and the specific encoding  
of DTMF in INFO that you're using (there have been multiple encodings  
proposed). Otherwise you wouldn't even bother sending it unless  
you're a hopeless optimist, trying to impress your homies with the  
size of your packet-slinger, or just plain stoopid.

And beyond just understanding your encoding of DTMF/INFO, you need to  
know that the recipient you are sending it to is likely to do  
something useful with that INFO, and that this "something useful" is  
what you intend it to do when you send it.

Now, for DTMF/INFO the "something useful" is pretty straightforward  
-- take the tone sequences and either use them as input to a local  
application or mix them back into the media stream.

Other possible uses for INFO (and there have been many proposed) are  
not generally so clear. For example, if I send you an INFO containing  
a JPEG file, what are you supposed to do with it? Project the  image  
onto the wall? Use it is a keyboard map? Use it as a voiceprint graph  
for spectral comparison with my media stream as a means of performing  
a MITM detection? (hey, I think I just invented something . . .) Or  
something entirely different?

What is wrong with INFO as currently specified is that we have no way  
of answering these questions. Content-disposition and content-type  
just aren't rich enough for the range of possibilities.

So we either have to rigorously NOT use INFO for anything new (and it  
is currently defined only for telephony tunneling), or extend it to  
be able to differentiate usages.  My personal feeling is that the  
wild INFO cat has leapt out of the bag and run off to have kittens,  
so we're better off giving those kittens names and vaccinations than  
we are trying to convince people not to pet the cat.

--
Dean

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Wed, 13 Jun 2007 21:47:02 +0200

Hi, 

>>Content-Type of the body sent in INFO. There are ways to 
>>solve that, and it is not an INFO specific problem.
>
> 
"does it understand what you want it to do with the 
>content?"

Yes.

>>What "SIP protocol rules" do you need for that? The 
>>application will determine what/if it does with the received
information.
> 
> 
>"Spray and pray" is fun for kids in street gangs but 
>well-aimed fire is far more efficient and much safer for  
>innocent bystanders.

I don't think an application will trigger INFOs in a spray and pray
matter. You will only send media server control messages if you are
communicating with a media server control application that understands
them.

>Staying with the use of DTMF/INFO as an example (which, I'd 
>like to add, has been deprecated even if I did originally 
>endorse or maybe even coinvent it) . . .

It hasn't been deprecated outside out on the field.

>recipient understands DTMF/INFO in general and the specific 
>encoding of DTMF in INFO that you're using (there have been 
>multiple encodings proposed).

Yes, and you know that if you receive an indication from the other party
that he supports application/my-dtmf (or whatever value is used).

And, if we would have standardized one encoding, maybe there wouldn't be
multiple ones out there...

>Otherwise you wouldn't even bother sending it unless you're a hopeless
optimist, trying 
>to impress your homies with the size of your packet-slinger, or just
plain stoopid.

I totally agree.

>And beyond just understanding your encoding of DTMF/INFO, you 
>need to know that the recipient you are sending it to is 
>likely to do something useful with that INFO, and that this 
>"something useful" is what you intend it to do when you send it.

Yes, but you wouldn't send it unless you have a reason to think the
receiver is going to do something with it, e.g. if you have been asked
to give your PIN code. 

I don't understand why people think that applications would start
sending all kind of INFOs "just for fun", without any logic behind. I
have never seen that happen in real world deployments. I wouldn't start
sending UPDATEs and/or re-INVITEs just for fun either, eventhough there
is nothing preventing me from doing it.

Just because you CAN doesn't mean you WILL :)
 
>-- take the tone sequences and either use them as input to a 
>local application or mix them back into the media stream.
> 
>Other possible uses for INFO (and there have been many 
>proposed) are not generally so clear. For example, if I send 
>you an INFO containing a JPEG file, what are you supposed to 
>do with it? Project the image onto the wall? Use it is a 
>keyboard map? Use it as a voiceprint graph for spectral 
>comparison with my media stream as a means of performing a 
>MITM detection? (hey, I think I just invented something . . 
>.) Or something entirely different?

That depends on the application. For example, the application may tell
you that a JPEG file has arrived, and ask what you want to do with it.
You may choose to project it, use it as a keyboard map, or whatever.

But, again, I don't think anyone is going to send you the JPEG file
"just like that", without any reason.

>What is wrong with INFO as currently specified is that we 
>have no way of answering these questions. Content-disposition 
>and content-type just aren't rich enough for the range of 
>possibilities.

I don't think we need to answer those questions, because they are
application specific.

What we need to answer is the question how to indicate what
Content-Types the receiver supports, and is willing to receive for a
given session. 

What we also should care about is to make sure that the Content-Types
are standardized, so that we don't have multiple, uninteroperable,
mechanisms doing the same thing out there.

>So we either have to rigorously NOT use INFO for anything new 
>(and it is currently defined only for telephony tunneling), 
>or extend it to be able to differentiate usages.  My personal 
>feeling is that the wild INFO cat has leapt out of the bag 
>and run off to have kittens, so we're better off giving those 
>kittens names and vaccinations than we are trying to convince 
>people not to pet the cat.

I agree with you.

I think that INFO is an easy and useful tool, and the market seems to
think the same thing.

Regards,

Christer

---

From: "Gilad Shaham" <[email-masked]>
Date: Wed, 13 Jun 2007 22:48:29 +0100

Hi,

Comments inline

> Sent: Wednesday, June 13, 2007 10:47 PM
> To: Dean Willis
> Cc: SIP IETF

Don't we need something that indicates to each UA what types of INFOs
the other UA should get? I still don't agree there is a 1:1 relationship
between content type and info purpose.

> It hasn't been deprecated outside out on the field.

That depends on what "it" means, there are several old drafts for this
single functionality, for example one proposed to send MGCP in the body.
Another proposed a specific body. There are probably more. So is our
approach to document and standardize any proprietary implementation for
this? Even when we have alternatives?

> Just because you CAN doesn't mean you WILL :)
Is the assumption that INFO is triggered by user and not by something in
the flow? Let's say I invent INFO that sends information on voice
quality in a call every X seconds. How does one indicate this
will/should be sent?

> "just like that", without any reason.

What if each is sent for a different reason and not just one picture is
sent? How do you tell the application "the reason"?

> mechanisms doing the same thing out there.
I tend to feel it's not enough.

> >people not to pet the cat.
This is not your everyday kitten. This big cat bites and scratches. Or
maybe I've taken the metaphor too far...

Really - other than SIP-T, I don't understand so far what necessary
usages INFO has that do not have other viable/better alternatives. Just
because some company X did something and perhaps even company Y mimicked
it, who said it's a good idea. For any new usage I think of for INFO I
find a better solution in SUBSCRIBE-NOTIFY...

Just like INFO should not be sent just for the heck of it, INFO usages
should not be invented just because it's possible.

> I think that INFO is an easy and useful tool, and the market seems to

I agree it's easy. Can it ease some implementation?

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 13 Jun 2007 19:13:32 -0400

See 
http://www.ietf.org/internet-drafts/draft-camarillo-sip-body-handling-01.txt

Content-Disposition is another part of the puzzle, as is use of headers 
that refer to body parts using cid: URIs. And the method is another 
criterion.

As a more difficult example, what do you suppose you should do if you 
receive an INFO message in a dialog, with a content-type of text/plain 
and a content-disposition of "render"? How would that handling differ 
from what you would do if it was a MESSAGE but otherwise the same?

You can pick out special cases and say "duh - what else could you do 
with DTMF digits"? But when you sit down to program a UA you need to 
come up with well defined algorithms to decide this stuff. As UAs get 
more and more sophisticated in the range of things they can do it will 
get more and more important to have semantics be well defined.

My problem with INFO is precisely because it has no semantics of how it 
should be processed, or how body parts that it carries should be 
processed differently than if the same parts were in some other message.

If there is some header and/or body part that should be processed the 
same, regardless of what message it is delivered in, then I have no 
problem with using INFO to convey it. But I don't think we have any of 
those.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 13 Jun 2007 19:36:38 -0400

> communicating with a media server control application that understands

How does my phone know it is communicating with a media server that 
understands INFO for conveying DTMF? The thing I call may indicate 
support of INFO because it supports qsig tunneling.

> multiple ones out there...

We currently have no way to say "I support mime-type foo for use with 
disposition bar and method baz", but in reality that is going to be the 
situation. I support sdp for disposition "session" in the methods that 
convey o/a. But I don't support sdp in MESSAGE or INFO. I support 
text/plain with content-type "render" in MESSAGE, but not for other 
dispositions and other message types.

Getting an indication of support for application/my-dtmf is useful *if* 
you know that the UA sending it to you always uses it the same ways you 
do. You can only know that if you control it, or if all the uses of that 
type are standardized.

> is nothing preventing me from doing it.

Lets go back to my phone. *It* doesn't know that I have been asked to 
give my PIN code, even though I do. All my phone knows is that I have 
pressed one of the buttons on the keypad. It may reasonably infer that I 
want *something* to be done with them, and probably that I want them 
sent to the other end in some way. It has no idea *how* (or *if*) the 
other end is prepared to receive them.

For instance, it may have indicated support for a mime type that my 
phone knows how to use to encode DTMF. But its possible it was really 
trying to say that it would support that type in a NOTIFY (sent or 
received).

I will agree that if you have N different ways that you are able to send 
DTMF, and if the other party has indicated support for *something* that 
is consistent with one of them and not with any of the others, then you 
might reasonably decide to try that one. But it is still a somewhat iffy 
proposition. We would be much better served defining something more 
deterministic.

	Paul

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Thu, 14 Jun 2007 11:19:47 +0200

Hi, 

>>communicating with a media server control application that 
>>understands them.
> 
>How does my phone know it is communicating with a media 
>server that understands INFO for conveying DTMF? The thing I 
>call may indicate support of INFO because it supports qsig tunneling.

It should also indicate support (using the Accept header) of the
content-type which is used to transport the media control messages.
 
>>>Before you send a DTMF/INFO, you really need to know that the
recipient understands DTMF/INFO in general and the 
>>>specific encoding of DTMF in INFO that you're using (there have been 
>>Yes, and you know that if you receive an indication from the other
party that he supports application/my-dtmf (or whatever 
>value is used).
>> 
>>And, if we would have standardized one encoding, maybe there wouldn't 
>>be multiple ones out there...
> 
>We currently have no way to say "I support mime-type foo for 
>use with disposition bar and method baz", but in reality that 
>is going to be the situation. I support sdp for disposition 
>"session" in the methods that convey o/a. But I don't support 
>sdp in MESSAGE or INFO. I support text/plain with content-type "render"
in MESSAGE, but not for other 
>dispositions and other message types.

You don't have any way to say "I support mime-type SDP for use with
disposition bar and method baz" either - that we specify elsewhere.

And, if we define a DTMF mime-type, we should of course also say in
which SIP message it can be used etc. But, again, we should not specify
the applications that are going to use it.

Also, since INFO is not supposed to affect the SIP session, we can also
put restrictions on which disposition values are to be used etc.

So, of course there is some work to do, but that's not a reason to
reject something. If everything was done and ready, there would be no
need for the SIP WG :)

>Getting an indication of support for application/my-dtmf is 
>useful *if* you know that the UA sending it to you always 
>uses it the same ways you do. You can only know that if you 
>control it, or if all the uses of that type are standardized.

It's up to the applications to make sure that the DTMFs are sent and
intepreted. If the receiving application has not asked for DTMFs, and
the sender still sends them, the receiver should simply discard them.
It's part of the application logic - not the SIP protocol. The SIP
protocol defines information elements to indicate what content types you
support, what actions to take if the content type is not supported etc.
But, again: we don't specify what the applicatons are going to do with
information.

It's similar to when you use RFC2833 for sending DTMFs. The only thing
you do, as part of the offer/answer procedure, is agreeing that both
endpoints support RFC2833 - but you do not specify what the endpoints
are going to do with the tones, when they will be sent etc.

>>receiver is going to do something with it, e.g. if you have 
>>been asked to give your PIN code.
>> 
>>sending all kind of INFOs "just for fun", without any logic 
>>behind. I have never seen that happen in real world deployments. I
wouldn't 
>>start sending UPDATEs and/or re-INVITEs just for fun either, 
>>eventhough there is nothing preventing me from doing it.
> 
>Lets go back to my phone. *It* doesn't know that I have been 
>asked to give my PIN code, even though I do. All my phone 
>knows is that I have pressed one of the buttons on the 
>keypad. It may reasonably infer that I want *something* to be 
>done with them, and probably that I want them sent to the 
>other end in some way. It has no idea *how* (or *if*) the 

I think what you are talking about is how you will design your SIP
phone.

For example, on my table phone, if I during a call want to send DTMF
tones I have to first press one button to "active" DTMF, and then any
button I sent is sent as DTMF. If I am asked to give my PIN code, but do
not active DTMF, nothing will happen when I press the buttons.

On my GSM phone, however, I don't need to active DTMF. If I am asked to
give my PIN code, I simply press buttons and they are sent as DTMF
tones.

>For instance, it may have indicated support for a mime type 
>that my phone knows how to use to encode DTMF. But its 
>possible it was really trying to say that it would support 
>that type in a NOTIFY (sent or received).

IF there are missing parts in the negotiation mechanism, we need to fix
that.

Something like:

Accept: application/my-dtmf;method=INFO

OR, in the draft defining the content type, we specify that content type
X can only be sent using this and that method. I belive we do the same
thing for SDP.

But, so far we haven't been interested in looking into these issues. We
just say that using INFO is against the spirit of SIP, it causes all
kind of problems etc etc.

My intention is not to "promote" the usage of INFO. My issue is that the
market has found and deployed an easy and effective way of doing things
using INFO, without breaking the protocol, and what worries me is that
instead of trying to help the market (e.g. by standardizing the content
types, providing negotiation mechanism to achieve interoperability), and
in that way indirectly help them to come up with new SIP applications,
we simply tell them that what they are doing (and have been doing for
years) is wrong, that they are breaking SIP, etc etc etc.

And, if we really wanted to restrict the usage of INFO, it should have
been done a long time ago - not years after the INFO RFC is published
and people have deployed usages of it.

Anyway, I guess we can go on with this discussion forever. Maybe we
should find some time in Chicago and sit down and discuss this?

Regards,

Christer

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 14 Jun 2007 10:32:52 +0100

Christer,

Slightly aside from the main direction of the discussion, but what about
security? I send my audio using SRTP, and would expect DTMF to receive
exactly the same protection. The signalling may or may not be end-to-end
secured, depending on which of the current and future key management
methods are used. Maybe SIPS has to be used, but we all know the
limitations of that (e.g., if I receive an INVITE request to my SIPS
URI, can I be sure all hops are secured?). I am sure the IETF would not
want to endorse a mechanism that opens up a security hole that is not
present with an existing mechanism for doing the same thing (RFC 2833).

John

> Sent: 14 June 2007 10:20
> To: Paul Kyzivat
> Cc: SIP IETF; Dean Willis

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Thu, 14 Jun 2007 11:41:18 +0200

Hi John,

I hear what you are saying, but I don't see how this is specific to DTMF and INFO. 

Doesn't this affect all I kind of sensitive information that you want to transport over SIP?

Regards,

Christer

> From: Elwell, John [mailto:[email-masked]] 
> Sent: 14. kesäkuuta 2007 12:33
> Slightly aside from the main direction of the discussion, but 
> what about security? I send my audio using SRTP, and would 
> expect DTMF to receive exactly the same protection. The 
> signalling may or may not be end-to-end secured, depending on 
> which of the current and future key management methods are 
> used. Maybe SIPS has to be used, but we all know the 
> limitations of that (e.g., if I receive an INVITE request to 
> my SIPS URI, can I be sure all hops are secured?). I am sure 
> the IETF would not want to endorse a mechanism that opens up 
> a security hole that is not present with an existing 
> mechanism for doing the same thing (RFC 2833).
> 
> John
> 
> server that 
> > >disposition bar and method baz", but in reality that is 
> going to be 
> > >the situation. I support sdp for disposition "session" in 
> the methods 
> > >that convey o/a. But I don't support sdp in MESSAGE or INFO. I 
> > >support text/plain with
> > content-type "render"
> > which SIP message it can be used etc. But, again, we should not 
> > specify the applications that are going to use it.
> > 
> > Also, since INFO is not supposed to affect the SIP session, we can 
> > also put restrictions on which disposition values are to be 
> used etc.
> > 
> > >Getting an indication of support for application/my-dtmf is useful 
> > >*if* you know that the UA sending it to you always uses it 
> the same 
> > >ways you do. You can only know that if you control it, or 
> if all the 
> > >uses of that type are standardized.
> > 
> > protocol defines information elements to indicate what 
> content types 
> > you support, what actions to take if the content type is 
> not supported 
> > etc.
> > >>receiver is going to do something with it, e.g. if you have been 
> > >>asked to give your PIN code.
> > >> 
> > >>sending all kind of INFOs "just for fun", without any 
> logic behind. 
> > >>I have never seen that happen in real world deployments. I
> > wouldn't
> > >pressed one of the buttons on the keypad. It may reasonably infer 
> > >that I want *something* to be done with them, and probably that I 
> > >want them sent to the other end in some way. It has no 
> idea *how* (or 
> > >*if*) the other end is prepared to receive them.
> > 
> > button I sent is sent as DTMF. If I am asked to give my PIN 
> code, but 
> > do not active DTMF, nothing will happen when I press the buttons.
> > 
> > On my GSM phone, however, I don't need to active DTMF. If I 
> am asked 
> > to give my PIN code, I simply press buttons and they are 
> sent as DTMF 
> > tones.
> > 
> > IF there are missing parts in the negotiation mechanism, we need to 
> > fix that.
> > 
> > Something like:
> > 
> > OR, in the draft defining the content type, we specify that content 
> > type X can only be sent using this and that method. I 
> belive we do the 
> > same thing for SDP.
> > 
> > But, so far we haven't been interested in looking into 
> these issues. 
> > We just say that using INFO is against the spirit of SIP, it causes 
> > all kind of problems etc etc.
> > 
> > My intention is not to "promote" the usage of INFO. My 
> issue is that 
> > the market has found and deployed an easy and effective way 
> of doing 
> > things using INFO, without breaking the protocol, and what 
> worries me 
> > is that instead of trying to help the market (e.g. by standardizing 
> > the content types, providing negotiation mechanism to achieve 
> > interoperability), and in that way indirectly help them to come up 
> > with new SIP applications, we simply tell them that what they are 
> > doing (and have been doing for

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 14 Jun 2007 10:53:29 +0100

Christer,

Yes, it affects all information, but in the case of DTMF we already have a mechanism for securing it, SRTP. So why attempt to standardise a new mechanism for transporting DTMF that introduces security issues that are already solved with the existing mechanism?

John 

> Sent: 14 June 2007 10:41
> To: Elwell, John

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Thu, 14 Jun 2007 12:02:13 +0200

Hi, 

>Yes, it affects all information, but in the case of DTMF we 
>already have a mechanism for securing it, SRTP. So why 
>attempt to standardise a new mechanism for transporting DTMF 
>that introduces security issues that are already solved with 
>the existing mechanism?

Then, why did we do KPML?

I am personally not saying people should use one solution instead of another. I think the issue is that the market has seen a need for out-of-band transport of DTMF tones, one reason being that all entities using DTMF do not have access to the media. If you don't agree to that requirement I think this is the wrong place to discuss it :)

Regards,

Christer

> > Doesn't this affect all I kind of sensitive information 
> that you want 
> > to transport over SIP?
> > 
> > Regards,
> > 
> > Christer
> > 
> >  
> > 
> > > Slightly aside from the main direction of the discussion, 
> but what 
> > > about security? I send my audio using SRTP, and would 
> expect DTMF to 
> > > receive exactly the same protection. The signalling may 
> or may not 
> > > be end-to-end secured, depending on which of the current 
> and future 
> > > key management methods are used. Maybe SIPS has to be 
> used, but we 
> > > all know the limitations of that (e.g., if I receive an INVITE 
> > > request to my SIPS URI, can I be sure all hops are 
> secured?). I am 
> > > sure the IETF would not want to endorse a mechanism that 
> opens up a 
> > > security hole that is not present with an existing mechanism for 
> > > doing the same thing (RFC 2833).
> > > 
> > > John
> > >

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Thu, 14 Jun 2007 12:43:45 +0200

Hi, 

A small addition regarding the does-your-phone-knows-that-it-shall-generate-DTMF-when-you-press-a-button: wouldn't you have exactly the same problem no matter whether you use INFO, RFC2833 or some other mechanism to transport the DTMF tones?

Regards,

Christer

> Sent: 14. kesäkuuta 2007 12:20
> To: Paul Kyzivat
> understands 
> It should also indicate support (using the Accept header) of 
> the content-type which is used to transport the media control 
> messages.
>  
> use with 
> going to be the 
> You don't have any way to say "I support mime-type SDP for 
> use with disposition bar and method baz" either - that we 
> specify elsewhere.
> 
> And, if we define a DTMF mime-type, we should of course also 
> say in which SIP message it can be used etc. But, again, we 
> should not specify the applications that are going to use it.
> 
> Also, since INFO is not supposed to affect the SIP session, 
> we can also put restrictions on which disposition values are 
> to be used etc.
> 
> So, of course there is some work to do, but that's not a 
> reason to reject something. If everything was done and ready, 
> there would be no need for the SIP WG :)
> 
> useful *if* 
> >do. You can only know that if you control it, or if all the uses of 
> >that type are standardized.
> 
> It's up to the applications to make sure that the DTMFs are 
> sent and intepreted. If the receiving application has not 
> asked for DTMFs, and the sender still sends them, the 
> receiver should simply discard them.
> It's part of the application logic - not the SIP protocol. 
> The SIP protocol defines information elements to indicate 
> what content types you support, what actions to take if the 
> content type is not supported etc.
> But, again: we don't specify what the applicatons are going 
> to do with information.
> 
> It's similar to when you use RFC2833 for sending DTMFs. The 
> only thing you do, as part of the offer/answer procedure, is 
> agreeing that both endpoints support RFC2833 - but you do not 
> specify what the endpoints are going to do with the tones, 
> when they will be sent etc.
> 
> behind. I 
> >>have never seen that happen in real world deployments. I
> wouldn't 
> asked to 
> >pressed one of the buttons on the keypad. It may reasonably 
> infer that 
> >I want *something* to be done with them, and probably that I 
> want them 
> I think what you are talking about is how you will design 
> your SIP phone.
> 
> For example, on my table phone, if I during a call want to 
> send DTMF tones I have to first press one button to "active" 
> DTMF, and then any button I sent is sent as DTMF. If I am 
> asked to give my PIN code, but do not active DTMF, nothing 
> will happen when I press the buttons.
> 
> am asked to give my PIN code, I simply press buttons and they 
> are sent as DTMF tones.
> 
> IF there are missing parts in the negotiation mechanism, we 
> need to fix that.
> 
> Something like:
> 
> OR, in the draft defining the content type, we specify that 
> content type X can only be sent using this and that method. I 
> belive we do the same thing for SDP.
> 
> But, so far we haven't been interested in looking into these 
> issues. We just say that using INFO is against the spirit of 
> SIP, it causes all kind of problems etc etc.
> 
> My intention is not to "promote" the usage of INFO. My issue 
> is that the market has found and deployed an easy and 
> effective way of doing things using INFO, without breaking 
> the protocol, and what worries me is that instead of trying 
> to help the market (e.g. by standardizing the content types, 
> providing negotiation mechanism to achieve interoperability), 
> and in that way indirectly help them to come up with new SIP 
> applications, we simply tell them that what they are doing 
> (and have been doing for
> And, if we really wanted to restrict the usage of INFO, it 
> should have been done a long time ago - not years after the 
> INFO RFC is published and people have deployed usages of it.
> 
> Anyway, I guess we can go on with this discussion forever. 
> Maybe we should find some time in Chicago and sit down and 
> discuss this?
> 
> Regards,
> 
> Christer
> 
>

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 14 Jun 2007 13:21:44 +0100

Christer,

In-line.

John 

> Sent: 14 June 2007 11:02
[JRE] KPML addresses a different problem space, i.e., an application server that doesn't necessarily have any audio and/or DTMF capability.

> 
> I am personally not saying people should use one solution 
> instead of another. I think the issue is that the market has 
> seen a need for out-of-band transport of DTMF tones, one 
> reason being that all entities using DTMF do not have access 
> to the media. 
[JRE] KPML addresses this space.  Because it establishes a dialog for the purpose, KPML can ensure that SIPS is used, even if SIPS is not used for the INVITE-initiated dialog. Why do we need a different solution?

> If you don't agree to that requirement I think 
> this is the wrong place to discuss it :)
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> 
> > > I hear what you are saying, but I don't see how this is 
> specific to 
> > > DTMF and INFO.
> > > 
> > > reason to
> > > > sent and
> > > > to do with
> > > > only thing
> > > your SIP
> > > > send DTMF
> > > > should have

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Thu, 14 Jun 2007 14:38:02 +0200

Hi John 

>>I am personally not saying people should use one solution instead of 
>>another. I think the issue is that the market has seen a need for 
>>out-of-band transport of DTMF tones, one reason being that all 
>>entities using DTMF do not have access to the media.
>[JRE] KPML addresses this space.  Because it establishes a 
>dialog for the purpose, KPML can ensure that SIPS is used, 
>even if SIPS is not used for the INVITE-initiated dialog.
>Why do we need a different solution?

The problem is that the INFO solution was implemented BEFORE KPML was finalized.

I also believe that many people think it's easier do handle it in a single dialog, without having to establish and associate two separate ones. But, that's just my guessing (I have personally never had to make the decisson which solution to implement based on technical arguments).

Regards,

Christer

> > > > > > >>>specific encoding of DTMF in INFO that you're 
> using (there
> > > > > > have been

---

From: "Gilad Shaham" <[email-masked]>
Date: Thu, 14 Jun 2007 16:03:16 +0100

Christer, 
I think I'm starting to see your point...

It sounds to me as if you are saying something equivalent to the following:
INFO is a notification for some type of implicit subscription on an INVITE dialog.
(geez, I hope my interpretation doesn't sound stupid)

For example, instead of establishing a new dialog for receiving DTMF notifications, the INFO is used in order to send events on the INVITE dialog without requiring a new subscription usage on the dialog (meaning, the implicit subscription ends with the BYE, unlike explicit subscriptions which are a different usage).

Is this interpretation acceptable?

Only thing part I feel is missing is actually stating which "subscriptions" the UAs want to receive/support and the previous discussion on content-type vs. another header to indicate the purpose of the INFO message.

If DTMF on INFO does become a known RFC, I think for the very least it should adopt the body from the KPML syntax rather than a proprietary one, but that's another issue.

Regards,
Gilad

> From: Christer Holmberg (JO/LMF) [mailto:[email-masked]]
> Sent: Thursday, June 14, 2007 3:38 PM
> To: Elwell, John
> Cc: SIP IETF
> I also believe that many people think it's easier do handle it in a single
> dialog, without having to establish and associate two separate ones. But,
> that's just my guessing (I have personally never had to make the decisson
> which solution to implement based on technical arguments).
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 Jun 2007 13:04:51 -0400

If you start down this path (I'd rather not), then rather than 
considering INFO to be a notification of an implicit subscription you 
might was well use NOTIFY for an implicit subscription. Just as there is 
a lot of use of INFO in the wild, there is also a lot of use of NOTIFY 
without SUBSCRIBE. I find it pretty difficult viewing INFO as an 
implicit NOTIFY.

	Paul

---

From: [email-masked]
Date: Thu, 14 Jun 2007 13:51:45 -0400

From: Paul Kyzivat <[email-masked]>

   If you start down this path (I'd rather not), then rather than 
   considering INFO to be a notification of an implicit subscription you 
   might was well use NOTIFY for an implicit subscription.

In particular, NOTIFY is labeled with an event-type, so the recipient
knows whether or not it knows how to process the event.

Dale

---

From: "Gilad Shaham" <[email-masked]>
Date: Thu, 14 Jun 2007 22:36:37 +0100

I never said that I endorse it...

Neither am I saying that INFO is implicit NOTIFY. I'm saying INFO's
functionality is notification on INVITE dialog usage without
subscription.

I agree it's an odd way to look at it (hence my comment on stupidity),
but here is the analogy (bear with me):
Suppose an implementation requires information during the lifetime of
the INVITE dialog, something related to the call itself. The normal way
of doing this is implementing an event package, something that holds the
call-id, remote-tag and local-tag of the INVITE dialog to which it
references.
One could say that this is a lot of work, why not send the information
on the INVITE dialog itself? Hence INFO roles into the game.
It _does_ the same functionality from user's perspective. Implementers
will find it much easier to do and it seems as a legitimate method for
communicating this information.

Of course it's not possible to say which INFO messages to receive as
opposed to event notification which are specified in the subscription.
Hence the implicit subscription (or lack of explicit subscription).
Furthermore, as Dale pointer out, there is nothing similar to Event
header, only the content-type tells what type of notification is this. I
already said this is a problem with INFO, but some disagree and say that
content-type is enough to hold the same information.

That's at least my understanding of what's proposed here:
KPML provides information on DTMF events that occur during the lifetime
of the INVITE dialog. The events are sent in NOTIFY and the event
package itself refers to the invite dialog with call-id, remote-tag and
local-tag. One could say that the same information can be passed in INFO
and it's easier to implement. No one subscribes to this information,
somehow the subscription is implicit.

If the logic of the analogy is correct, I think it has implications on
INFO.

> Sent: Thursday, June 14, 2007 8:52 PM
> To: [email-masked]

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Fri, 15 Jun 2007 06:24:14 +0200

Hi Gilad,

I hear what you are saying, and if you really want to compary INFO to implicit NOTIFY, you should also remember that in some cases INFO messages will be sent in both directions, so doesn't that mean you would have TWO subscriptions (one for each direction)? But, in order to avoid unecessary discussions I agree with Paul that we  shouldn't continue onto that path :)
 
A couple of other comments, though:

First, you say "Of course it's not possible to say which INFO messages to receive". If you indicate which content types you support, you know what you COULD receive in INFO (if someone sends you something you haven't indicated support for it's a protocol error).

Second, in an earlier mail you said that if we want to use INFO we should still use the XML format as specified in KPML. The INFO implementations I've seen do not use XML. E.g. Cisco seems to simply send something like "Signal= 1 Duration= 160". I am not sure, but I think there was a draft on that a long time ago. Personally I think't it's a little "overkill" to send an XML body just in order to provide a DTMF digit (and possibly additional duration information). But, as some people say about SIP messages: size doesn't matter :)

Regards,

Christer

> From: Gilad Shaham [mailto:[email-masked]] 
> Sent: 15. kesäkuuta 2007 0:37
> To: Paul Kyzivat
> Cc: [email-masked]; Christer Holmberg (JO/LMF); [email-masked]
> Neither am I saying that INFO is implicit NOTIFY. I'm saying 
> INFO's functionality is notification on INVITE dialog usage 
> without subscription.
> 
> I agree it's an odd way to look at it (hence my comment on 
> stupidity), but here is the analogy (bear with me):
> Suppose an implementation requires information during the 
> lifetime of the INVITE dialog, something related to the call 
> itself. The normal way of doing this is implementing an event 
> package, something that holds the call-id, remote-tag and 
> local-tag of the INVITE dialog to which it references.
> One could say that this is a lot of work, why not send the 
> information on the INVITE dialog itself? Hence INFO roles 
> into the game.
> It _does_ the same functionality from user's perspective. 
> Implementers will find it much easier to do and it seems as a 
> legitimate method for communicating this information.
> 
> Of course it's not possible to say which INFO messages to 
> receive as opposed to event notification which are specified 
> in the subscription.
> Furthermore, as Dale pointer out, there is nothing similar to 
> Event header, only the content-type tells what type of 
> notification is this. I already said this is a problem with 
> INFO, but some disagree and say that content-type is enough 
> to hold the same information.
> 
> KPML provides information on DTMF events that occur during 
> the lifetime of the INVITE dialog. The events are sent in 
> NOTIFY and the event package itself refers to the invite 
> dialog with call-id, remote-tag and local-tag. One could say 
> that the same information can be passed in INFO and it's 
> easier to implement. No one subscribes to this information, 
> If the logic of the analogy is correct, I think it has 
> implications on INFO.
> 
>

---

From: "Gilad Shaham" <[email-masked]>
Date: Fri, 15 Jun 2007 06:34:20 +0100

Hi Christer,

See inline.

Thanks,
Gilad

> Sent: Friday, June 15, 2007 7:24 AM
> To: Gilad Shaham; Paul Kyzivat
> Cc: [email-masked]; [email-masked]
> I hear what you are saying, and if you really want to compary INFO to
> implicit NOTIFY, you should also remember that in some cases INFO messages
> will be sent in both directions, so doesn't that mean you would have TWO
> subscriptions (one for each direction)? But, in order to avoid unecessary
> discussions I agree with Paul that we  shouldn't continue onto that path
> :)

I agree there are cases where there are 2 actual subscriptions. One unfortunate implication of this implicit subscription.
I don't think we should draft a proposal for implicit subscription - certainly not. I fear we are already on that path. We went on that path as soon as INFO was allowed. We just didn't say so, but effectively we implemented this functionality. If I'm right then I cannot understand how one can oppose implicit subscriptions and endorse extended usage of INFO at the same time. If I'm wrong it means that there is some kind of additional functionality of INFO which I missed.
I prefer that someone would show me what's basically wrong with the analogy or my conclusions instead of why implicit subscriptions are a bad idea.

> First, you say "Of course it's not possible to say which INFO messages to
> receive". If you indicate which content types you support, you know what
> you COULD receive in INFO (if someone sends you something you haven't
> indicated support for it's a protocol error).

Yeah, it possible, same discussion as before regarding content-type and info type applies.
 
> 
> Second, in an earlier mail you said that if we want to use INFO we should
> still use the XML format as specified in KPML. The INFO implementations
> I've seen do not use XML. E.g. Cisco seems to simply send something like
> "Signal= 1 Duration= 160". I am not sure, but I think there was a draft on
> that a long time ago. Personally I think't it's a little "overkill" to
> send an XML body just in order to provide a DTMF digit (and possibly
> additional duration information). But, as some people say about SIP
> messages: size doesn't matter :)
> 

I don't like the idea that multiple formats will be defined in RFCs for the same functionality. Maybe it's just me, but I think that in this case "the more that merrier" does not apply.

---

From: Dean Willis <[email-masked]>
Date: Fri, 15 Jun 2007 01:04:04 -0500

> the applications that are going to use it.

But MIME types aren't just defined for SIP. There's a whole slew of
protocols that can use any of the thousands of definede MIM types for
millions of different reasons. SIP is just one protocol among many.

> give my PIN code, I simply press buttons and they are sent as DTMF

But what happens when your GSM phone receives a JPEG image? How about
when it receives a Symbian executable stored in a ZIP file?

> Accept: application/my-dtmf;method=INFO

Well, we agree it's broken. We're just debating the mechanism, and
whether it's worth fixing. You and I seem to think it's worth fixing,
others would just rather say "If it hurts' don't do it!".

> X can only be sent using this and that method. I belive we do the same

Once again, content types are defined more broadly than SIP.

> kind of problems etc etc.

Not at all. I've said we need a registry of usage contexts that defines
what specific content types and dispositions mean within that context
usage. Lacking that, the safe thing is not to use INFO. I think Paul has
said exactly the same thing, and that's pretty much what Jonathan has
said -- although I think Jonathan is leaning more towards the "since
defining these usages is hard, let's not use INFO" model.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Fri, 15 Jun 2007 01:08:39 -0500

Gilad Shaham wrote:

> It sounds to me as if you are saying something equivalent to the
> following: INFO is a notification for some type of implicit
> subscription on an INVITE dialog. (geez, I hope my interpretation
> doesn't sound stupid)
> 
. . .
> Only thing part I feel is missing is actually stating which
> "subscriptions" the UAs want to receive/support and the previous
> discussion on content-type vs. another header to indicate the purpose
> of the INFO message.

I agree quite completely on this interpretation of the problem with INFO.

--
Dean

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Fri, 15 Jun 2007 13:29:17 +0200

Hi, 

>But MIME types aren't just defined for SIP. There's a whole 
>slew of protocols that can use any of the thousands of 
>definede MIM types for millions of different reasons. SIP is 
>just one protocol among many.

I don't think we need to say very much about different content types
themselves. Because, again, the transport data itself is not directly
related to the SIP session, but to the application above.

I think we should focus more on whether we need some generic rules when
sending application data over SIP, e.g. Whether some content disposition
values are not allowed etc.

>>On my GSM phone, however, I don't need to active DTMF. If I am asked 
>>to give my PIN code, I simply press buttons and they are sent as DTMF 
>>tones.
> 
>But what happens when your GSM phone receives a JPEG image? 
>How about when it receives a Symbian executable stored in a ZIP file?

I don't know - I've only had my phone for a few months, so I'm still in
the how-to-use-the-phone-book stage :). 

But, in any case, I think that is a question for the people implementing
the phone applications, and not for the people specifying the protocol
used to transport the image.

fix that.
>Well, we agree it's broken. We're just debating the 
>mechanism, and whether it's worth fixing. You and I seem to 
>think it's worth fixing, others would just rather say "If it 
>hurts' don't do it!".

If something needs to be fixed, I definately think we should do it.
 
>>type X can only be sent using this and that method. I belive we do the

>>But, so far we haven't been interested in looking into these issues. 
>Not at all. I've said we need a registry of usage contexts 
>that defines what specific content types and dispositions 
>mean within that context usage. Lacking that, the safe thing 
>is not to use INFO. I think Paul has said exactly the same 
>thing, and that's pretty much what Jonathan has said -- 
>although I think Jonathan is leaning more towards the "since 

That's probably because people have different opinions about what needs
to be defined and registered. I still think that we do NOT need to
register how the applications work and what they are actually going to
do with the application data sent/received over SIP.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 15 Jun 2007 08:23:28 -0400

> defining these usages is hard, let's not use INFO" model.

I'm a little closer to the Jonathan position. I don't necessarily object 
to clarifying the use of INFO for some purpose, if that is the best way 
to do something.

But in the case of DTMF work was already done. INFO was proposed and 
rejected in favor of SUB/NOT. Somebody has to make a case that the 
existing solution isn't good enough, and that another one is needed.

Now I know that INFO is in use out there, by products of my own company 
among others. Those are *legacy* things. AFAIK they were done before the 
KPML solution was devised. We don't necessarily standardize them just 
because they are out there. People will implement them as needed.

	Paul

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Fri, 15 Jun 2007 15:52:19 +0200

Hi, 

>>>We just say that using INFO is against the spirit of SIP, 
>>>it causes all kind of problems etc etc.
>> 
>>Not at all. I've said we need a registry of usage contexts that 
>>defines what specific content types and dispositions mean within that 
>>context usage. Lacking that, the safe thing is not to use INFO. I 
>>think Paul has said exactly the same thing, and that's pretty much 
>>what Jonathan has said -- although I think Jonathan is leaning more 
>>towards the "since defining these usages is hard, let's not 
>>use INFO" model.
> 
>I'm a little closer to the Jonathan position. I don't 
>necessarily object to clarifying the use of INFO for some 
>purpose, if that is the best way to do something.
> 
>But in the case of DTMF work was already done. INFO was 
>proposed and rejected in favor of SUB/NOT. Somebody has to 
>make a case that the existing solution isn't good enough, and 
>that another one is needed.

It really depends on what you mean by "good enough". It's not always the
technically best solution that "wins". 

Thanks to the porn industry VHS "won" over Betamax, eventhough Betamax
was supposed to be technically superior, and the SIP industry seems to
(I don't have numbers to back that up, but it is the impression I have
got) have chosen INFO over KPML :) 

Whether it's because of compability issues, or because it's more simple
to implement and deploy (it's not only about your local parser, but also
issues related to having separate dialogs etc), or whether people don't
think that DTMF sending fits the event subscription concept in the first
place, or whether KPML simply was the right thing at the wrong time, I
don't know.

>Now I know that INFO is in use out there, by products of my 
>own company among others. Those are *legacy* things. AFAIK 
>they were done before the KPML solution was devised. We don't 
>necessarily standardize them just because they are out there. 
>People will implement them as needed.

The problem is that it seems like the number of implementations is still
growing. It's becoming a de facto standard.

But, no matter what we do with DTMF, I still support the idea to look
into whether we somehow clarify the generic usage of INFO.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 15 Jun 2007 10:58:08 -0400

> into whether we somehow clarify the generic usage of INFO.

There is a big difference between specific additional uses, defined on a 
one-by-one basis, and *generic* usage.

I don't know how to view generic usage as anything but an explicit move 
to support SIP as a tunneling protocol. And I think that is something 
that many people here *don't* want it to become.

Opening it that way would pose many of the same issues that the 
Service-ID did.

	Paul

---

From: Robert Sparks <[email-masked]>
Date: Fri, 15 Jun 2007 12:10:07 -0300

I see what Gilad is saying and think its a useful way to think about  
the space (at least when SIP-T like problems are trying to use INFO).
(and that does not mean I like it or that I think we should promote  
anything like implicit subscriptions going forward - quite the opposite)
Mostly, it gives us a good place to look for how we recommend we  
solve those particular problems.

Thanks for sharing that insight Gilad!

RjS

---

From: Dean Willis <[email-masked]>
Date: Fri, 15 Jun 2007 12:43:53 -0500

On Jun 15, 2007, at 9:58 AM, Paul Kyzivat wrote:

>
> There is a big difference between specific additional uses, defined  
> on a one-by-one basis, and *generic* usage.
>
> I don't know how to view generic usage as anything but an explicit  
> move to support SIP as a tunneling protocol. And I think that is  
> something that many people here *don't* want it to become.
>

I'd argue we already used that can of worms for fishing when we did  
RFC 3265. Event packages provide a nice way of using SIP as a  
transport protocol, wrapped up with nice safety padding so one is  
less likely to hurt one's self using them and so that the application  
using the transported data is properly isolated from the SIP state  
machine.

The real question is whether there's a real requirement to do the  
same thing for INFO.

As has been pointed out, it's possible to do anything that you can do  
with INFO by doing a set of subscriptions (possibly MANY  
subscriptions) in parallel to an INVITE dialog usage. Especially  
since GRUU gives us a way to make the subscription endpoints the same  
as the INVITE endpoints.

So we're just talking about efficiency here, not functionality.

With what we've been talking about with INFO, it should be possible  
to declare support for many different INFO usages within a single  
INVITE dialog. This has the potential to make the INFO approach  
substantially more message-efficient than SUBSCRIBE/NOTIFY, which in  
most cases is going to require at least one subscription in each  
direction, and in some cases many subscriptions in each direction.

The real question -- aside from the officially-sanctioned PSTN  
transport and the unsanctioned (and NOT GOING TO BE SANCTIONED BY  
THIS WG) DTMF are any applications being developed that need this  
sort of efficiency?

My personal feeling is that if it is available, INFO will be used.  
Sometimes wisely, sometimes unwisely. But I can imagine myriad  
applications that could usefully accompany a multimedia session with  
little snippets of data being schlepped back and forth. I can also  
imagine doing the same thing with a parallel MSRP session.

--
Dean

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Fri, 15 Jun 2007 23:00:01 +0200

Hi, 

>>There is a big difference between specific additional uses, defined on

>>a one-by-one basis, and *generic* usage.
>>
>less likely to hurt one's self using them and so that the 
>application using the transported data is properly isolated from the
SIP state  
>The real question is whether there's a real requirement to do the  

I think INFO pretty much already does the same thing. It is written that
it shall not affect the SIP state.

>since GRUU gives us a way to make the subscription endpoints 
>the same as the INVITE endpoints.
> 

My understanding (maybe it's because of my background in H.248) of an
subscribed event is that something somewhere triggers an event which I
have requested to be informed about.

In most cases I don't think that sending DTMFs between two SIP entities
fits that concept. If two applications are exchaning data I don't
understand why I, as the caller, have to tell the other party to send me
a registration so that I can send him the data. The subscription is not
used in order to be informed about detected events, but in order to be
able to send data.

BUT, if I e.g. control a media server using SIP, I could use an event
registration to request to be informed about DTMFs detected on a media
stream. In that case the DTMF may not be seen as data exchanged between
two applications (and may not even be directly associated with another
SIP dialog), but more as an indication.

But, maybe that's more of a conceptual discussion than functional...

>direction, and in some cases many subscriptions in each direction.

Exactly - subscriptions which you MAY end up never using, but which in
many cases still will consume SOME resources.

>imagine doing the same thing with a parallel MSRP session.

I am sure all mechanisms we define have their pros and cons, and it's
difficult for us to say that a specific application must use a specific
mechanism etc. Our job is to define the tools for the application
developers, and hopefully they will then be able to choose the most
efficient tool, based on the characteristics, efficiency etc of the
tools.

And, I doubt anyone would use INFO for a real-time chat type of
applications, with lots of relatively small messages, since it would
overload intermediates. But, it's difficult for us to draw a clear line
on what people can do and can't.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 15 Jun 2007 17:09:33 -0400

> on what people can do and can't.

A large well known company with a colorful flag already uses MESSAGE 
within a dialog for this. The performance implications would be 
identical with INFO.

	Paul

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Fri, 15 Jun 2007 23:45:13 +0200

Hi, 

>>applications, with lots of relatively small messages, since 
>>it would overload intermediates. But, it's difficult for us to draw a
clear 
>>line on what people can do and can't.
> 
>A large well known company with a colorful flag already uses 
>MESSAGE within a dialog for this. The performance 
>implications would be identical with INFO.

Ok, so I guess someone WOULD use something similar for reat-time chat :)
I don't remember what the MESSAGE RFC says about it.

One question is: was MSRP available, and support deployed, when this
company implemented it?

Regards,

Christer

---

From: "Gilad Shaham" <[email-masked]>
Date: Sat, 16 Jun 2007 06:15:50 +0100

Hi,

See Inline

Gilad

> used in order to be informed about detected events, but in order to be

You do not tell the other party to send registration so you can send him
data. The other party asks for this data and you send it or vise versa.

Some of us are saying that the lack of ability in SIP to state which
INFO messages each ends wants to receive, it is a major drawback. As
long as new RFCs don't focus on INFO, this problem is usually limited,
but if we use INFO more broadly it's a real issue.

> But, maybe that's more of a conceptual discussion than functional...

I'm not sure I understand what you mean, but it sounds to me as if you
are describing a solution to the issue of specifying which INFOs are
required. 

> many cases still will consume SOME resources.

And if it would have been possible to subscribe to many different event
packages in a single message, would that be an equivalent solution?
 
> efficient tool, based on the characteristics, efficiency etc of the

Right. Currently if extended usage of INFO is needed, it's not well
defined and there are several problems to resolve.

We might have been taking this conversation to the wrong direction.
If some feel that SUBSCRIBE/NOTIFY might be too complex in some
situations, I think we should discuss it outside the context of INFO.
INFO is just one solution to this problem. If the best solution in this
case would turn out to be INFO, we will be more motivated to fix its
problems.

I don't see a reason to "reverse engineer" a proprietary solution that
some vendors took that involved INFO at the time. We need a problem
definition. Whether or not the end solution will be similar to the
vendor's solution is irrelevant.

---

From: Dean Willis <[email-masked]>
Date: Sat, 16 Jun 2007 13:41:28 -0500

Christer Holmberg (JO/LMF) wrote:

> overload intermediates.

Well, personally, I might. I think that MESSAGE could well have been an
INFO usage. Instead, we developed a protocol extension that confused
what was happening  at the SIP level (transport) with an application
function (Presenting data to the user). It was bad design.

Once all the proxies that don't have to be there for something like NAT
traversal have dropped out, the only intermediaries being loaded are the
ones that need to be loaded in order to make the communication work at
all. When one brings in the performance gains of SIPSEC (proxies no
longer parse, decrypt, or encrypt messages once a CONNECT completes),
it's actually a pretty efficient approach.

--
Dean