Subject: Re: [Sip] INFO

From: "Eric Burger" <[email-masked]>
Date: Mon, 10 Sep 2007 06:08:23 -0700

Brian Stucker Says:
   I'm not really sure what your point was
   here unless you are against people
   writing down a common way of using
   a protocol amongst themselves

Actually, I have no problem with "people writing down a common way of using a protocol". One would offer that is the work of the IETF. However, the key phrase I have a problem with is, "amongst themselves." The IETF makes protocols for everybody, not just members of the garden club. The garden club can do whatever they want inside their garden. The IETF has no right nor interest in mandating what goes on inside their garden.

Some gardeners ask the IETF for advice. Some do not. Sometimes, when the IETF sees a gardener about to spray a known, highly toxic poison, that is likely to spray outside the garden and harm innocent children, then the IETF does have the obligation to step up.

In my mind, INFO for DTMF falls into the, "it is not an Internet protocol, but you can do whatever you want in your playground, so long as your fences are good and you will still play with me. P.S., do not claim you are using Internet protocols, because you are not."

P-Preferred-Service is an example of something that falls into "the toxic substance that will bleed through, so do not even think of using it" category.

--
Sent from my wireless e-mail device. Sorry if terse.  We all need lemonade: see <http://www.standardstrack.com/ietf/lemonade> for what lemonade is.

----- Original Message -----
From: Brian Stucker <[email-masked]>
To: Eric Burger; Peili Xu <[email-masked]>
Cc: sip <[email-masked]>
Sent: Sun Sep 09 21:43:18 2007
Subject: RE: [Sip] INFO

> -----Original Message-----
> From: Eric Burger [mailto:[email-masked]] 
> Sent: Thursday, August 30, 2007 5:03 PM
> To: Peili Xu
> Cc: sip
> Subject: Re: [Sip] INFO
> 
> Saying, "OK for interworking" does not really say anything.  
> If I come up with a really broken method for interworking, 
> saying that it is for interworking does not make it correct.
> 
> The problem is, how do the endpoints know they will be able 
> to communicate?
> For the ISUP/Q.sig/DPNSS/mumble case, the endpoints know they 
> will be able to interoperate because they know a'priori: they 
> are configured to work.
> However, this means that the devices must be in the same 
> administrative domain and configured properly.

...or all of your UAs come from the same vendor or set of vendors that
have agreed previously to support said mechanism, or you buy one of
Hadriel's magic boxes to fix it for you.

I realize the same could be said for any protocol scheme, but it's a
very real fact in the case of how INFO works today, especially for DTMF.
There's really only a few widely deployed schemes running around out
there for DTMF via INFO. If we're complaining about using INFO for DTMF
because of negotiation issues, I think that's a very solvable problem
without deprecating INFO.

> 
> Said in a different manner, INFO works fine for 
> non-inter-network use.  

It works fine for inter-network use as well depending upon what you are
trying to use it for. Take for instance trying to figure out if a
session is still alive by periodically sending an INFO to the other
endpoint. I know we have a session timer mechanism defined, but many
endpoints don't support it (yet). Even getting back an error response,
depending upon the response code, may mean that the session is still
alive (success). The point of the usage wasn't to convey anything, and
so no negotiation was necessary. SIP was all you needed.

> It would be hard for the IETF to say, 
> "Here is a non-IETF use.  We will not use it.  You cannot use 
> it with anyone else.  You cannot use it between 
> manufacturers, unless you get them to agree to this use."  
> That is a bit more of what we call the toxic waste warning 
> that accompanies 3GPP specifications...
> 
> 

You could say this for a lot of things. For instance, point me to the
IETF use of SIP to do call forwarding.

You can't use SIP between manufacturers unless you get them to agree to
implement it correctly either. I'm not really sure what your point was
here unless you are against people writing down a common way of using a
protocol amongst themselves.

:)

Regards,
Brian

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

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

---

From: "Brian Stucker" <[email-masked]>
Date: Mon, 10 Sep 2007 13:46:00 -0500

> Sent: Monday, September 10, 2007 8:08 AM
> To: Stucker, Brian (RICH1:AR00)
> Cc: [email-masked]
> Subject: Re: [Sip] INFO
> 
> Brian Stucker Says:
> Actually, I have no problem with "people writing down a 
> common way of using a protocol". One would offer that is the 
> work of the IETF. However, the key phrase I have a problem 
> with is, "amongst themselves." The IETF makes protocols for 
> everybody, not just members of the garden club. The garden 
> club can do whatever they want inside their garden. The IETF 
> has no right nor interest in mandating what goes on inside 
> their garden.

True, but it's not a club. Those disclaimers are to limit reproduction
of the material by other SDOs without permission. You don't have to be a
member of the garden club to use the protocols written by the garden
club, such as they are. Whether you want to or not is another matter
entirely.

[SNIP]

> In my mind, INFO for DTMF falls into the, "it is not an 
> Internet protocol, but you can do whatever you want in your 
> playground, so long as your fences are good and you will 
> still play with me. P.S., do not claim you are using Internet 
> protocols, because you are not."

Only because they happen to not be written down as an IETF document,
which, as I suggested earlier, may be the solution to the problem.

> 
> P-Preferred-Service is an example of something that falls 
> into "the toxic substance that will bleed through, so do not 
> even think of using it" category.

So then I would be most interested to hear your thoughts on the
following:

The first sentence in section 2 in your draft states:

	"There is no programmatic way of determining what the content of
an INFO request means."

You could say the same is true for an INVITE. To the 'User-Agent's point
of view, an [INVITE] just appears'. Without a negotiation mechanism such
as SDP, is this INVITE conveying an conference call, a user-to-user
gaming session, or what? We can't programmatically determine what an
INVITE with no SDP means. So if I'm following your argument here wrt
INFO, the analogous solution would be to deprecate INVITE unless it
always has SDP.

But wait, there's more... Again, using your line of thought for INFO,
SDP may not be good enough:

	"However, as we learned in the messaging community [7], relying
upon the MIME type alone is not sufficient to determine the context of
the message. Clearly, as shown in the previous paragraph [which
describes using the MIME type of an INFO as a negotiation mechanism],
the message content relates to the message context. However, it is quite
easy to imagine situations where the same content type has multiple
meanings for a User Agent."

So if the content relates to the message context, and the content and
type can be ambiguous, such as the INVITE contains SDP, or the SDP
contains an audio stream (is it a conference or is it a podcast or what)
or worse, SDP that contains content types that are not well-known, then
clearly SIP and SDP are not enough to correctly identify what the User
Agent is to do with this request. Hence, a mechanism such as
P-Preferred-Service rears it's ugly head.

As a result, if I understand you correctly, rather than correct the
negotiation problem (more like just write it down because it's already
being neogitated out there in the wild in many cases) and let the UAs
deal with it, you'd rather deprecate the whole thing in favor of
something else. Correct?

Also, your list of examples is missing one usecase that KPML definitely
does not address (but session timers does): INFO is used to detect if a
call is still alive.

Cheers,
Brian

---

From: Eric Burger <[email-masked]>
Date: Thu, 20 Sep 2007 16:14:36 -0400

1. INFO for keep alive? That¹s a new one. Everyone I know uses OPTIONS. Oh
well. Maybe we should resurrect the PING method.

2. INVITE discussion is a non-sequitur.  INVITE fully specifies a
negotiation framework.  INVITE without SDP is an invitation for you to start
the negotiation.

3. The semantics of the media are totally orthogonal to the INVITE
negotiation.  C.f. the LONG discussion on P-Asserted-Service.

4. The semantics of an INFO body is critical.  The stack needs to know how
to process the body or where to pass the message to.  Right now, there is no
mechanism for doing that.  Content-type does not work.

5. "Just write it down": Agreed, and there has already been a framework for
doing INFO negotiation (Dean's document).  I was about to go there, until I
realized that it would be identical to SUB/NOT.

6. Rough work group consensus was NOT to create an INFO negotiation
mechanism.  If you can convince the chairs otherwise, I'd be happy to submit
a negotiation mechanism.

7. The argument that we have to extend INFO to do negotiation because we
need to protect the existing INFO-based DTMF implementations is totally
bogus.  If we create a negotiation mechanism, those existing implementations
have to be fixed.  If they have to be fixed, any reason not to fix them with
something that already works and won't suck down work group and RFC Editor
time?

8. Who in their right mind would use KPML for keep alive?  You can always
subscribe to anything with an expires of zero.  It is still silly in any
event [sic].

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 20 Sep 2007 22:58:39 -0500

> Sent: Thursday, September 20, 2007 3:15 PM
> 1. INFO for keep alive? That¹s a new one. Everyone I know 
> uses OPTIONS. Oh well. Maybe we should resurrect the PING method.

Well, you don't know Jack then. Jack uses INFO. :P

Seriously, there are people out there using it this way. No negotiation is required. I'm not defending it, I'm just letting you know that there are a number boxes out there hammering away with INFO requests to see if a dialog is still active. Ask around and I'm sure you'll find people who have at least seen this done even if they don't generate the requests themselves.

Honestly, I think we should all be using RFC-4028 and not OPTIONS or INFO for this purpose. If you want to put that in your draft, I'll happily support that.

> 
> 2. INVITE discussion is a non-sequitur.  INVITE fully 
> specifies a negotiation framework.  INVITE without SDP is an 
> invitation for you to start the negotiation.

Ok, so I send you an OPTIONS or an INVITE first to see what content-types/mechanisms you might support for DTMF transport. You tell me what you support, and then I use that mechanism (might be INFO digits). What's the difference? If I send you something you don't like or understand you can reject it. Sounds like a negotiation framework already exists.

> 
> 3. The semantics of the media are totally orthogonal to the 
> INVITE negotiation.  C.f. the LONG discussion on P-Asserted-Service.
> 
> 4. The semantics of an INFO body is critical.  The stack 
> needs to know how to process the body or where to pass the 
> message to.  Right now, there is no mechanism for doing that. 
>  Content-type does not work.

So where do you think the stack sends SDP content types? You're making the claim here that the content-type can't be used to determine the semantics, or that the stack can't figure out how to handle it and must just simply choke and die because it was conveyed in an INFO instead of an INVITE. I'm probing to find the justification for that assertion.

> 
> 5. "Just write it down": Agreed, and there has already been a 
> framework for doing INFO negotiation (Dean's document).  I 
> was about to go there, until I realized that it would be 
> identical to SUB/NOT.
> 
> 6. Rough work group consensus was NOT to create an INFO 
> negotiation mechanism.  If you can convince the chairs 
> otherwise, I'd be happy to submit a negotiation mechanism.

I don't remember it going down quite that way and I was at the mic expressing support. Perhaps I misunderstood the question that prompted the vote, but I interpreted it as meaning we didn't think one was NECESSARY. Big difference in my mind. Acknowledge the uses as they exist today, encourage people to look elsewhere for the future. I thought that was what we said at the last meeting. You're arguing that INFO w/ DTMF is broken because there's no negotiation mechanism. Sending DTMF with a given content-type and expecting the other side to reject that content type if it does not understand it is a basic tenet of SIP. You can clearly tell if the other side understands or not unless it is not paying attention to what it's being sent.

> 
> 7. The argument that we have to extend INFO to do negotiation 
> because we need to protect the existing INFO-based DTMF 
> implementations is totally bogus.  If we create a negotiation 
> mechanism, those existing implementations have to be fixed.  
> If they have to be fixed, any reason not to fix them with 
> something that already works and won't suck down work group 
> and RFC Editor time?

I'm not asking to fix anything. Honestly, I think the vast majority of implementations are moving on to 2833/4733 to convey DTMF digits and to a great extent that makes the discussion somewhat moot in my mind.

Whether this document exists or not will not affect INFO-based DTMF implementations. The horse is out of the barn and way down the road on that one. You've made some assertions in your arguments that I believe need some substantiation. You've said that the content-type is not enough to figure out what is going on at all. I disagee. I think a content type that says "I'm sending you DTMF digits in a particular format" is every bit as robust as the content-type that conveys MWI for instance, and a heck of a lot more specific than SDP is. We have done quite well with SDP for some time in getting things to work, so I don't understand why simply writing down: hey, this content-type means DTMF digits is not a valid way forward to closing the books on that implementation. We can even say things like "please don't do this in the future" but unless we can clearly show WHY people shouldn't do this in the future that uses logic that can also clarify the things that we DO want them to do in the future, I don't see how this can be successful.

It appears arbitrary to say DTMF in INFO is bad because it relies on content-type settings to identify it as such when we do not require a P-Asserted-Service header in every INVITE to clarify the SDP that lies within.

I think you may be confusing my questioning of your arguments as a declaration of support for using INFO for a particular purpose. I honestly don't care if another INFO is ever generated by any SIP stack anywhere ever again for any purpose personally. I'm looking for consistent arguments that can be applied to problems outside of INFO so when the next bad idea (tm) comes along we can clearly point to this document and say "you're trying to do X which we can clearly show is bad and does not align to the things we think are good." I haven't read such an argument yet.

> 
> 8. Who in their right mind would use KPML for keep alive?  
> You can always subscribe to anything with an expires of zero. 
>  It is still silly in any event [sic].

True. I completely agree. I didn't write that last statement correctly. I was intending to point out that INFO was being used this way. KPML has nothing to do with it.

> common way of 
> >> using a protocol". One would offer that is the work of the IETF. 
> >> However, the key phrase I have a problem with is, "amongst 
> >> themselves." The IETF makes protocols for everybody, not 
> just members 
> >> of the garden club. The garden club can do whatever they 
> want inside 
> >> their garden. The IETF has no right nor interest in mandating what 
> >> goes on inside their garden.
> > 
> > of the material by other SDOs without permission. You don't 
> have to be 
> > a member of the garden club to use the protocols written by 
> the garden 
> >> In my mind, INFO for DTMF falls into the, "it is not an Internet 
> >> protocol, but you can do whatever you want in your playground, so 
> >> long as your fences are good and you will still play with 
> me. P.S., 
> >> do not claim you are using Internet protocols, because you 
> are not."
> > 
> into "the 
> >> toxic substance that will bleed through, so do not even think of 
> >> using it" category.
> > 
> >         "There is no programmatic way of determining what 
> the content 
> > of an INFO request means."
> > 
> > You could say the same is true for an INVITE. To the 'User-Agent's 
> > point of view, an [INVITE] just appears'. Without a negotiation 
> > mechanism such as SDP, is this INVITE conveying an 
> conference call, a 
> > user-to-user gaming session, or what? We can't programmatically 
> > determine what an INVITE with no SDP means. So if I'm 
> following your 
> > argument here wrt INFO, the analogous solution would be to 
> deprecate 
> > INVITE unless it always has SDP.
> > 
> >         "However, as we learned in the messaging community [7], 
> > relying upon the MIME type alone is not sufficient to determine the 
> > context of the message. Clearly, as shown in the previous paragraph 
> > [which describes using the MIME type of an INFO as a negotiation 
> > mechanism], the message content relates to the message context. 
> > However, it is quite easy to imagine situations where the 
> same content 
> > type has multiple meanings for a User Agent."
> > 
> > contains an audio stream (is it a conference or is it a podcast or 
> > what) or worse, SDP that contains content types that are not 
> > well-known, then clearly SIP and SDP are not enough to correctly 
> > identify what the User Agent is to do with this request. Hence, a 
> > mechanism such as P-Preferred-Service rears it's ugly head.
> > 
> > Also, your list of examples is missing one usecase that KPML 
> > definitely does not address (but session timers does): INFO 
> is used to 
> > detect if a call is still alive.
> > 
> > Cheers,
> > Brian
> > 
> 
> 
> 
> Notice:  This email message, together with any attachments, 
> may contain information  of  BEA Systems,  Inc.,  its 
> subsidiaries  and  affiliated entities,  that may be 
> confidential,  proprietary,  copyrighted  and/or legally 
> privileged, and is intended solely for the use of the 
> individual or entity named in this message. If you are not 
> the intended recipient, and have received this message in 
> error, please immediately return this by email and then delete it.
>

---

From: "Raj Jain" <[email-masked]>
Date: Fri, 21 Sep 2007 06:50:26 -0400

Regarding usage of INFO for keep-alive, below is trace captured on a machine
running a very popular IM/voice client. This client sends an INFO to its
server every 3 minutes. 

The funny thing is that the client supports session-timers (notice
Supported: timer in the trace) but it still uses INFO instead of reINVITE or
UPDATE for keep-alive :-) 

Transmission Control Protocol, Src Port: 1571 (1571), Dst Port: 5061 (5061),
Seq: 3269, Ack: 3321, Len: 384
Session Initiation Protocol
    Request-Line: INFO sip:XXX.XXX.XXX.XXX:5061;transport=tcp SIP/2.0
    Message Header
        From:
<sip:[email-masked]:5061>;tag=71c0d48-0-13bb-28cd57-3284bd2c-28cd57
        To: <sip:[email-masked]:5061>
        Call-ID: [email-masked]
        CSeq: 3 INFO
        Via: SIP/2.0/TCP
XXX.XXX.XXX.XXX:5051;branch=z9hG4bK-28cd57-9f621dd0-31f65a45
        Max-Forwards: 70
        Supported: timer
        Content-Length: 0

Thanks,
Raj

> From: Brian Stucker [mailto:[email-masked]] 
> Sent: Thursday, September 20, 2007 11:59 PM
> To: Eric Burger
> Cc: [email-masked]
> Subject: RE: [Sip] INFO
> 
>  
> 
> > 1. INFO for keep alive? That¹s a new one. Everyone I know uses 
> > OPTIONS. Oh well. Maybe we should resurrect the PING method.
> 
> Seriously, there are people out there using it this way. No 
> negotiation is required. I'm not defending it, I'm just 
> letting you know that there are a number boxes out there 
> hammering away with INFO requests to see if a dialog is still 
> active. Ask around and I'm sure you'll find people who have 
> at least seen this done even if they don't generate the 
> requests themselves.
> 
> Honestly, I think we should all be using RFC-4028 and not 
> OPTIONS or INFO for this purpose. If you want to put that in 
> your draft, I'll happily support that.
> 
> > 
> > negotiation framework.  INVITE without SDP is an invitation 
> for you to 
> > start the negotiation.
> 
> Ok, so I send you an OPTIONS or an INVITE first to see what 
> content-types/mechanisms you might support for DTMF 
> transport. You tell me what you support, and then I use that 
> mechanism (might be INFO digits). What's the difference? If I 
> send you something you don't like or understand you can 
> reject it. Sounds like a negotiation framework already exists.
> 
> > 
> needs to know 
> > how to process the body or where to pass the message to.  
> Right now, 
> > there is no mechanism for doing that.
> So where do you think the stack sends SDP content types? 
> You're making the claim here that the content-type can't be 
> used to determine the semantics, or that the stack can't 
> figure out how to handle it and must just simply choke and 
> die because it was conveyed in an INFO instead of an INVITE. 
> I'm probing to find the justification for that assertion.
> 
> > 
> was about 
> > to go there, until I realized that it would be identical to SUB/NOT.
> > 
> > mechanism.  If you can convince the chairs otherwise, I'd 
> be happy to 
> > submit a negotiation mechanism.
> 
> I don't remember it going down quite that way and I was at 
> the mic expressing support. Perhaps I misunderstood the 
> question that prompted the vote, but I interpreted it as 
> meaning we didn't think one was NECESSARY. Big difference in 
> my mind. Acknowledge the uses as they exist today, encourage 
> people to look elsewhere for the future. I thought that was 
> what we said at the last meeting. You're arguing that INFO w/ 
> DTMF is broken because there's no negotiation mechanism. 
> Sending DTMF with a given content-type and expecting the 
> other side to reject that content type if it does not 
> understand it is a basic tenet of SIP. You can clearly tell 
> if the other side understands or not unless it is not paying 
> attention to what it's being sent.
> 
> > 
> > 7. The argument that we have to extend INFO to do 
> negotiation because 
> > we need to protect the existing INFO-based DTMF implementations is 
> > totally bogus.  If we create a negotiation mechanism, those 
> existing 
> > implementations have to be fixed.
> > If they have to be fixed, any reason not to fix them with something 
> > that already works and won't suck down work group and RFC 
> Editor time?
> 
> I'm not asking to fix anything. Honestly, I think the vast 
> majority of implementations are moving on to 2833/4733 to 
> convey DTMF digits and to a great extent that makes the 
> discussion somewhat moot in my mind.
> 
> Whether this document exists or not will not affect 
> INFO-based DTMF implementations. The horse is out of the barn 
> and way down the road on that one. You've made some 
> assertions in your arguments that I believe need some 
> substantiation. You've said that the content-type is not 
> enough to figure out what is going on at all. I disagee. I 
> think a content type that says "I'm sending you DTMF digits 
> in a particular format" is every bit as robust as the 
> content-type that conveys MWI for instance, and a heck of a 
> lot more specific than SDP is. We have done quite well with 
> SDP for some time in getting things to work, so I don't 
> understand why simply writing down: hey, this content-type 
> means DTMF digits is not a valid way forward to closing the 
> books on that implementation. We can even say things like 
> "please don't do this in the future" but unless we can 
> clearly show WHY people shouldn't do this in the future that 
> uses logic that can also clarify the things that we DO want 
> them to do in the future, I don't see how this can be successful.
> 
> It appears arbitrary to say DTMF in INFO is bad because it 
> relies on content-type settings to identify it as such when 
> we do not require a P-Asserted-Service header in every INVITE 
> to clarify the SDP that lies within.
> 
> I think you may be confusing my questioning of your arguments 
> as a declaration of support for using INFO for a particular 
> purpose. I honestly don't care if another INFO is ever 
> generated by any SIP stack anywhere ever again for any 
> purpose personally. I'm looking for consistent arguments that 
> can be applied to problems outside of INFO so when the next 
> bad idea (tm) comes along we can clearly point to this 
> document and say "you're trying to do X which we can clearly 
> show is bad and does not align to the things we think are 
> good." I haven't read such an argument yet.
> 
> > 
> True. I completely agree. I didn't write that last statement 
> correctly. I was intending to point out that INFO was being 
> used this way. KPML has nothing to do with it.
> 
> > 
> > 
> > Notice:  This email message, together with any attachments, may 
> > contain information  of  BEA Systems,  Inc.,  its 
> subsidiaries  and  
> > affiliated entities,  that may be confidential,  proprietary,  
> > copyrighted  and/or legally privileged, and is intended 
> solely for the 
> > use of the individual or entity named in this message. If 
> you are not 
> > the intended recipient, and have received this message in error, 
> > please immediately return this by email and then delete it.
> > 
> 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: Adam Roach <[email-masked]>
Date: Mon, 24 Sep 2007 10:26:17 -0500

On 9/20/07 10:58 PM, Brian Stucker wrote:
> You've made some assertions in your arguments that I believe need some substantiation. You've said that the content-type is not enough to figure out what is going on at all. I disagee. I think a content type that says "I'm sending you DTMF digits in a particular format" is every bit as robust as the content-type that conveys MWI for instance, and a heck of a lot more specific than SDP is. 

The problem isn't _in_ that direction. The problem is: how do I say "I 
am capable of receiving DTMF digits in an INFO message"?

The "Accept" header-field lets you say you understand the syntax, but 
doesn't convey what contexts it makes sense in.

The "Allow" header-field lets you say you can process INFO for some 
mime-types, but doesn't let you say which ones.

There is no current mechanism that lets you tie the semantics together, 
the way that event packages do. I've shown, in previous messages, how 
this can lead to ambiguity and consequent interoperability failure.

To be clear: I don't really care much whether we come up with INFO 
packages or whether we formally deprecate INFO, but the current 
situation is untenable.

> I'm looking for consistent arguments that can be applied to problems outside of INFO so when the next bad idea (tm) comes along we can clearly point to this document and say "you're trying to do X which we can clearly show is bad and does not align to the things we think are good." I haven't read such an argument yet.
>   

The argument you're looking for is part of Jonathan's service 
identification draft -- INFO, as currently defined, is a "Do What I 
Mean" method. For proper behavior, it requires either a closed-garden 
approach or implementations that can perform mind reading.

INFO with packages is a "Do What I Say" method. The arguments against it 
are weaker, but mostly resolve to this: Why would you send INFO, a 
message with no inherent semantics, with a package header that gives the 
intended meaning? The method itself is ostensibly what gives the message 
its intended meaning. These cases all cry out for a new method, and the 
IANA charges the same amount to register a new SIP method as they would 
to register a new INFO package. ;)

/a

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 25 Sep 2007 13:10:38 +0200

Hi, 

>your draft, I'll happily support that.

I am not defending the usage of INFO for this either, but I see no reason why we should forbid things which are absolutely harmless. Let's focus on real issues instead.

>>2. INVITE discussion is a non-sequitur.  INVITE fully specifies a negotiation framework.  INVITE without SDP is an invitation 
>>for you to start the negotiation.
> 
>>3. The semantics of the media are totally orthogonal to the INVITE negotiation.  C.f. the LONG discussion on P-Asserted-Service.
>> 
>>4. The semantics of an INFO body is critical.  The stack needs to know how to process the body or where to pass the message to.  
>>Right now, there is no mechanism for doing that. Content-type does not work.
> 

I agree.

Regarding the question how to know where to pass the message internally. I think that is an implementation issue, and you have to deal with that also if using other mechanisms.

>>5. "Just write it down": Agreed, and there has already been a framework for doing INFO negotiation (Dean's document).  I 
>>was about to go there, until I realized that it would be identical to SUB/NOT.
>> 
>>6. Rough work group consensus was NOT to create an INFO negotiation mechanism.  If you can convince the chairs otherwise, I'd 
>>be happy to submit a negotiation mechanism.
> 

My understanding of what was decided at the mic was that we were going to continue the discussions. Eric's draft was going to be used as base for the work, but that does not mean we agreed to everything which is said in the draft.

>>7. The argument that we have to extend INFO to do negotiation because 
>>totally bogus.  If we create a negotiation mechanism, those existing 
>>that already works and won't suck down work group and RFC Editor time?
> 

We seem to be concentrating on DTMF, but I think we should be more generic.

The question is whether we should allow INFO as a mechanism (limited, maybe) to transport information. The answer seems to be "No, you can use subscription events.". But, there are reasons why people don't want to use that.

Regards,

Christer

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Wed, 26 Sep 2007 12:45:33 -0400

Hey Adam,
Comments inline...

> From: Adam Roach [mailto:[email-masked]]
> Sent: Monday, September 24, 2007 11:26 AM
> 

When you say "doesn't convey what contexts it makes sense in", in what way
do you mean that if the topic is DTMF?  Do you mean because it doesn't
specify which methods it's acceptable in (e.g., INFO)?  Or do you mean
because it won't indicate that an INFO with DTMF is only acceptable in the
context of an Invite-based dialog, for example?  

I ask because the argument of "not conveying context semantics" has come up
a few times, and I'm trying to figure out if the problem is one that can be
solved by standardization, or if the problem is something bigger.  When I
think of "context", I think of it in a bigger sense than protocol syntax,
and more of application semantics.  But DTMF has no such semantics at the
UAC.  The UAC has no idea what a button push means from an application
perspective, beyond just "the user pressed #".  There is a protocol issue,
though, in terms of "if and how do I tell someone the user pressed #".  But
I think that's something that can be solved.

> this can lead to ambiguity and consequent interoperability failure.

I agree with you, but that problem already exists today.  There are plenty
of cases where there are constraints on the combination of method+mime that
cannot be described with Accept and Allow headers.  There are devices which
won't accept Invites or re-Invites without application/sdp, and there are
devices which don't accept Options with mime types they do accept Invites
with, etc.  (You can call them broken I guess)  What does it mean for an
application/sdp mime body to be in a Message method, or in a Bye?

I also think for this dtmf case, we can define the usage for
application/dtmf such that it is tied to a specific method, in specific
session contexts. (or not) 

> packages or whether we formally deprecate INFO, but the current

I guess that's the $64k question: is the current situation untenable?  If we
think rfc2833 will ultimately become ubiquitous and address the application
needs, then we don't need to worry about this.  There are devices that
already convert 2833 to Info and vice versa, and they'll be happy to keep
doing so for the short term.  If we think 2833 is not going to solve this
problem ultimately, or the application usage for dtmf is not possible by
2833 for all cases, then I think we need a solution.  KPML isn't it, IMHO.

-hadriel

---

From: Adam Roach <[email-masked]>
Date: Wed, 26 Sep 2007 13:35:54 -0500

On 9/26/07 11:45 AM, Hadriel Kaplan wrote:
> do you mean that if the topic is DTMF?

This isn't just about DTMF; it's about INFO in general.

>   Do you mean because it doesn't
> specify which methods it's acceptable in (e.g., INFO)? 

That's the symptom I'm trying to illustrate, yes. Note that this isn't 
the underlying cause per se; it's a symptom of the cause. The root cause 
is that one must infer intention from an INFO, and Content-Type isn't 
sufficient for this purpose.

> solved by standardization, or if the problem is something bigger.

I think it can be solved by standardization -- however, I'm not sure 
that standardization within the framework of INFO is the right approach.

> cannot be described with Accept and Allow headers.

But the difference is that those methods have inherent semantics that 
constrain things in a way that avoids the problem. "INVITE" means "I'm 
trying to start a session." The MIME types that make sense in this 
context are only those which support description of a session. "MESSAGE" 
means "I'm sending content for rendering." Only those MIME types which 
can be rendered make sense in a MESSAGE. SUBSCRIBE and NOTIFY have 
inherent semantics, and the only MIME types that make sense are those 
which describe resource state.

Note that all of those MIME types are completely disjoint. There is no 
overlap, because the methods mean radically different things. So, for 
example, if a UA advertises support for INVITE and for 
"application/pidf+xml", it's trivial to figure out that they cannot go 
together -- there is a semantic mismatch.

"INFO" means... well... it doesn't mean *ANY*thing. It means "here's 
some stuff, now you guess what you're supposed to do with it." So, it is 
conceivable that INFO could carry content that describes a session, or 
contains renderable content (DTMF!), or describes the state of a 
resource. Because these content types necessarily make sense in the 
context of other methods that may be supported, it is impossible to tell 
whether they make sense in an INFO. So, if a UA advertises support for 
INFO and for "image/jpeg", it's not as clear whether they support them 
in conjunction with each other. Maybe you think you can use this to 
update your user icon in my buddy list... maybe it's just there because 
I can receive them in MESSAGE requests. It's impossible to tell, because 
INFO *has* *no* *inherent* *meaning*. In theory, every MIME type 
imaginable "makes sense" in an INFO.

> session contexts. (or not)

I'll concede that there *might* be ways to band-aid the situation for 
DTMF as a point solution, but it's not obvious that all the problems can 
be worked around. No one has even put enough thought into the issues to 
put together an internet-draft describing an INFO DTMF solution (at 
least, as far as I can recall). (n.b.: I'm not encouraging such a draft; 
I'm just saying that proponents of what you're proposing has been 
profoundly apathetic about it for nearly a decade).

However, the problems with INFO in general -- that is, when looking at 
the problem without DTMF blinders on -- are intractable without some 
kind of explicit indication of intended meaning. And, at the risk of 
sounding like a broken record, intended meaning should be conveyed by 
method type; that's what the method type is for.

> needs, then we don't need to worry about this.

Again, this isn't solely about DTMF. It's about INFO. The underlying 
problem is that INFO doesn't mean anything, and overloading Content-Type 
in an attempt to give it meaning causes ambiguity.

/a

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Wed, 26 Sep 2007 16:34:05 -0400

> Sent: Wednesday, September 26, 2007 2:36 PM
> 

Well, the way I read the INFO rfc would make application/sdp inappropriate
for INFO.  But there's no question it's a catch-all method.  But that's the
*point* of INFO I thought - it was going to leave the semantics up to future
headers or bodies to define.  But it did not have the full notion of event
packages.

> method type; that's what the method type is for.

But it is and it isn't.  I send you an Invite because I want to create a
session with you, but the type of session is in the body.  I Subscribe for
event/state change information from you, but the details about what-for are
in the event package.  Subscribe as a method doesn't tell you squat really.
So I want to send you Info relating to a session but the details about what
info are in the content-type.  Now I agree that content-type is really not
the appropriate header for such generically, specifically because it
describes the body content, which may be ambiguous with usage of the body.
"application/dtmf" I do NOT think is ambiguous, but "image/jpeg" sure would
be.

But I think that is something that could be standardized away if we needed
to.  One way could be to define an Event package type model for it.  One
could argue Info is essentially a Notify, except in a subscription
implicitly created by, and tied to the dialog from, an Invite.

-hadriel

---

From: Adam Roach <[email-masked]>
Date: Wed, 26 Sep 2007 15:52:44 -0500

> describes the body content, which may be ambiguous with usage of the body.

Thank you! That's the key point I'm trying to make.

> One

Now you're just *trying* to push my buttons. :)

There are certain predictable objections that I would raise to such a 
characterization; take them as given.

The key point here is that NOTIFY will inherently be associated with an 
event package, which provides enough information for the recipient to 
know what to do with the body. INFO, lacking such information, is 
ambiguous. And, as before, the hardest problem isn't interpreting what 
is sent to you; it is indicating what *can* be sent to you.

/a

---

From: "Brian Stucker" <[email-masked]>
Date: Wed, 26 Sep 2007 17:35:32 -0500

> Sent: Wednesday, September 26, 2007 3:53 PM
> To: Hadriel Kaplan
> Cc: Stucker, Brian (RICH1:AR00); [email-masked]
> Subject: Re: [Sip] INFO
> 
> > So I want to send you Info relating to a session but the 
> details about 
> > what info are in the content-type.  Now I agree that 
> content-type is 
> > really not the appropriate header for such generically, 
> specifically 
> > because it describes the body content, which may be 
> ambiguous with usage of the body.
> >   
> 

And I agree with your key point then if this is what you were trying to
draw out earlier to me.
> There are certain predictable objections that I would raise 
> to such a characterization; take them as given.

Noted.

> 
> The key point here is that NOTIFY will inherently be 
> associated with an event package, which provides enough 
> information for the recipient to know what to do with the 
> body. INFO, lacking such information, is ambiguous. And, as 
> before, the hardest problem isn't interpreting what is sent 
> to you; it is indicating what *can* be sent to you.

Yes, INFO is different in that respect from NOTIFY. You don't expect a
NOTIFY for something you never explicitly sent a request for that scoped
it to an event package...except REFER. But the semantics of REFER are
such that it's implied.

I think the key point being made on the other side is that there's
nothing special about an event package. It is an identifier that
disambiguates the NOTIFY. In some cases other header values could serve
the same purpose (i.e. content-type w/ DTMF).

---

From: Adam Roach <[email-masked]>
Date: Wed, 26 Sep 2007 17:50:24 -0500

> the same purpose (i.e. content-type w/ DTMF). 

But that's a point solution that puts a band-aid on INFO for precisely 
one use case and leaves it broken for others. It doesn't scale to other 
uses for INFO.

That points to really only two sane approaches: either (a) come up with 
an unambiguous differentiator for various INFO usages (in the style of 
event packages), or (b) grandfather current approaches (band-aids and 
all) and forbid any other applications of INFO.

Eric's document basically takes the second approach, grandfathering all 
uses of INFO that are currently published in an RFC or an active 
internet-draft, and forbidding any others. The list is not long; I'll 
replicate it here:

  1. RFC 3372

You want more than that, you really need packages.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Sep 2007 21:55:34 -0400

First, I agree 100% with what Adam has said.

I just wanted to comment on one issue which is peripheral to the 
discussion of INFO but is directly relevant to the issue of semantics of 
sip messages in general.

> application/sdp mime body to be in a Message method, or in a Bye?

To the last question, it first depends on what the Content-Disposition 
is. In spite of Gonzalo's draft on the subject, most people continue to 
ignore this. But it really needs to be a key part of decision about the 
semantics of message bodies.

If an application/sdp body has content-disposition of "session", and it 
is in an INVITE, UPDATE, PRACK, or responses to those, then it is the 
description of the session for this invite, subject to the offer/answer 
rules.

Note that the *default* content-disposition for a body of type 
application/sdp is "session" if it is found in one of the above 
contexts. Otherwise the normal default disposition of "render" applies.

So an application/sdp body without a content-disposition in a MESSAGE 
should be rendered. Of course there are issues of how or if it can be 
rendered, but that is what it should mean.

If you put an application/sdp body in a MESSAGE and explicitly specified 
a disposition of "session" then of course it shouldn't be rendered. 
There is no defined meaning for a body with disposition of session in a 
MESSAGE, so presumably it should be considered an error or ignored.

	Paul

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Wed, 26 Sep 2007 21:51:32 -0400

> Sent: Wednesday, September 26, 2007 4:53 PM
> To: Hadriel Kaplan
> Cc: 'Brian Stucker'; [email-masked]
> Subject: Re: [Sip] INFO
> 

Ahh, but the key point I was trying to make is for the one use case I care
about, namely application/dtmf, it is not ambiguous.  It is no more
ambiguous than kpml.  The only ambiguity right now is I can't tell if you'll
accept it and want it.  That's a solvable problem. :)

> Now you're just *trying* to push my buttons. :)

dtmf buttons? :)  But, no, I wasn't trying to push your buttons.

> is sent to you; it is indicating what *can* be sent to you.

Sure, but we could (if we had to) define the same concept for INFO as
sub-not has in that regard.

-hadriel

---

From: Adam Roach <[email-masked]>
Date: Wed, 26 Sep 2007 23:30:00 -0500

> sub-not has in that regard.

Which is what. I've been saying. This. Whole. Time.

Perhaps the confusion here arises because I've _also_ been pointing out 
why this is Bad Idea for a _different_ set of reasons (which are 
admittedly more philosophical than practical), but at least it makes the 
INFO situation tenable.

/a

---

From: "Steve Langstaff" <[email-masked]>
Date: Thu, 27 Sep 2007 02:33:14 -0700

> You don't 
> expect a NOTIFY for something you never explicitly sent a 
> request for that scoped it to an event package...except 
> REFER.

Unsolicited simple message summary?

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 27 Sep 2007 06:49:20 -0500

> From: Steve Langstaff [mailto:[email-masked]] 
> Sent: Thursday, September 27, 2007 4:33 AM
> To: Stucker, Brian (RICH1:AR00); Adam Roach; Hadriel Kaplan
> Cc: [email-masked]
> Subject: RE: [Sip] INFO
> 
> request for 
> > that scoped it to an event package...except REFER.
> 

Those are a bad idea (tm). I'll have my handy unsolicited MWI script
ready to send those notifications to phones to make their MWI lights on
blink like christmas tree lights. I've done it before to prove my point
to people that implicit subscriptions that are not associated with any
existing dialog are not good.

Regards,
Brian

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 27 Sep 2007 06:46:09 -0500

> Sent: Wednesday, September 26, 2007 5:50 PM
> Cc: Hadriel Kaplan; [email-masked]
> Subject: Re: [Sip] INFO
> 
> > disambiguates the NOTIFY. In some cases other header values could 
> > serve the same purpose (i.e. content-type w/ DTMF).
> >   
> 
> But that's a point solution that puts a band-aid on INFO for 
> precisely one use case and leaves it broken for others. It 
> doesn't scale to other uses for INFO.
> 
> That points to really only two sane approaches: either (a) 
> come up with an unambiguous differentiator for various INFO 
> usages (in the style of event packages), or (b) grandfather 
> current approaches (band-aids and
> Eric's document basically takes the second approach, 
> grandfathering all uses of INFO that are currently published 
> in an RFC or an active internet-draft, and forbidding any 
> others. The list is not long; I'll replicate it here:
> 
>   1. RFC 3372
> 

Expand that list to include application/dtmf and I think you'll largely
end the debate.

---

From: Adam Roach <[email-masked]>
Date: Thu, 27 Sep 2007 08:16:45 -0500

> Expand that list to include application/dtmf and I think you'll largely

It wouldn't be fair to ask you to show me the IANA registration for that 
MIME type, so I won't -- but the practical problem here is that no one 
has even *tried* formalizing this mechanism.

To be clear, I would argue against standardizing such an approach (but 
that discussion is tangential to this one, and would only distract). My 
point is: even if someone wants to support your position, there's 
nothing for them to support; there's not even an individual draft -- not 
even an *expired* one -- documenting the INFO usage you're promoting.

/a

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 27 Sep 2007 15:40:54 +0200

Hi,

> Sent: 27. syyskuuta 2007 16:17
> To: Brian Stucker
> Cc: [email-masked]
> Subject: Re: [Sip] INFO
> 
> Brian Stucker wrote:
> grandfathering 
> >> all uses of INFO that are currently published in an RFC or 
> an active 
> > Expand that list to include application/dtmf and I think you'll 
> > largely end the debate.
> >   
> 
> It wouldn't be fair to ask you to show me the IANA 
> registration for that MIME type, so I won't -- but the 
> practical problem here is that no one has even *tried* 
> formalizing this mechanism.
> 
> To be clear, I would argue against standardizing such an 
> approach (but that discussion is tangential to this one, and 
> would only distract). My point is: even if someone wants to 
> support your position, there's nothing for them to support; 
> there's not even an individual draft -- not even an *expired* 
> one -- documenting the INFO usage you're promoting.

I actually DO think there was a DTMF-using-INFO draft at some point - a
long time ago.

Now, that draft probably did not address all the issues we have
discussed, so I am pretty sure it wouldn't be very useful at this point.

In any case, I still wonder whether writing a DTMF-using-INFO draft is a
good starting point. I still think we should look at the whole thing
from a more generic perspective first: what are the issues we would need
to work on in order to make the usage of INFO better.

Regards,

Christer

---

From: Adam Roach <[email-masked]>
Date: Thu, 27 Sep 2007 09:13:12 -0500

> I actually DO think there was a DTMF-using-INFO draft at some point - a

Really?

http://www.google.com/search?q=site%3Atools.ietf.org+%22application%2Fdtmf%22

...and, lest there be any confusion about how far back that archive goes:

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

/a

---

From: [email-masked]
Date: Thu, 27 Sep 2007 10:39:04 -0400

From: Adam Roach <[email-masked]>

   Really?

ORLY?

I'm not sure what that search does, but it doesn't turn up the
document you're looking for, viz.:
http://tools.ietf.org/html/draft-ietf-mmusic-sip-info-method-00, which
proposed a new SIP method "INFO" to carry DTMF digits and such
information:

    Abstract

    This document proposes an extension to the Session Initiation
    Protocol.  This extension adds the INFO method to the SIP protocol.
    The intent of the INFO method is to allow for the carrying of session
    related control information that is generated during a session.
    Examples of such session control information are ISUP/ISDN signaling
    messages and DTMF digits used to control telephony services.

Dale

---

From: Adam Roach <[email-masked]>
Date: Thu, 27 Sep 2007 09:59:55 -0500

> proposed a new SIP method "INFO" to carry DTMF digits and such

It gives DTMF as an _example_ of the kind of information that might be 
carried by INFO. It doesn't give even the remotest amount of technical 
detail about how one might do so.

At the time, there was an ensuing debate about the appropriateness of 
using INFO in this way, in which we developed a consensus that INFO 
really isn't the right tool for the job.

Unfortunately, when the naive answer is also the wrong answer, it seems 
impossible to ever put a decision to bed -- which is why we now hear the 
slow "clack... clack... clack" of the whole working group going up the 
initial slope of the "DTMF in INFO argument" roller coaster for the 
hojillionth time. Hold on tightly; it's not a fun ride...

/a

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 27 Sep 2007 10:03:05 -0500

> Expand that list to include application/dtmf and I think you'll

It would be a lovely thing for this debate to end. Perhaps we could refocus 
with that aim in mind. Since I'm Eric's instigator, I'm asking that we 
remember how we got here.

In MEDIACTRL, we found ourselves Yet Again Explaining The Non-Use of INFO, 
with general handwaving based on Jonathan's long-expired individual draft. 
Jonathan is a smart guy, but One Long-Expired Individual Draft Does Not 
Equal Consensus In SIP.

I asked about advancing the long-expired draft, but it's old enough that we 
couldn't just WGLC it in SIP without changes. Eric took the lead on writing 
a draft that COULD (in theory) be WGLCed in SIP - that's what's under 
discussion.

>From the Abstract

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

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

If someone wants to generate a draft on application/dtmf, and there is SIP 
consensus to publish that draft, and to add application/dtmf to the 
grandfathered list in Eric's draft, MEDIACTRL would still have a SIP 
consensus draft that gets the INFO-or-not-INFO discussion out of the 
MEDIACTRL draft, where it does not belong. IMO.

Thanks,

Spencer

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 27 Sep 2007 10:22:32 -0500

And, here's another very old one:

http://quimby.gnus.org/internet-drafts/draft-choudhuri-sip-info-digit-00
.txt

Abstract:
   This document describes the mechanism how SIP INFO method can be used
   by applications that require mid session signaling for transport and 
   collection of DTMF digits.

Regards,
Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, September 27, 2007 9:39 AM
To: [email-masked]
Subject: Re: [Sip] INFO

   Really?

ORLY?

http://www.google.com/search?q=site%3Atools.ietf.org+%22application%2Fdt
mf%22

   ...and, lest there be any confusion about how far back that archive
goes:

I'm not sure what that search does, but it doesn't turn up the document
you're looking for, viz.:
http://tools.ietf.org/html/draft-ietf-mmusic-sip-info-method-00, which
proposed a new SIP method "INFO" to carry DTMF digits and such
information:

    Abstract

    The intent of the INFO method is to allow for the carrying of
session

Dale

_______________________________________________
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: Adam Roach <[email-masked]>
Date: Thu, 27 Sep 2007 11:05:20 -0500

> http://quimby.gnus.org/internet-drafts/draft-choudhuri-sip-info-digit-00

Aha! Thanks. I conflated "using application/dtmf" with "transporting 
DTMF in info", which is a somewhat broader category. My read is that 
Hadriel and Brian were promoting a specific solution (application/dtmf), 
which may well not be the case.

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

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

/a

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 27 Sep 2007 11:26:03 -0500

> Sent: Thursday, September 27, 2007 8:17 AM

I'm not promoting anything, I think the issue is fairly moot as many
devices support 2833/4733.

I'm trying to be practical here.

I wasn't aware that nobody had even bothered to register for the MIME
type, that's pretty sad. I just don't buy the argument that you can't
figure out what to do with this usage based on the information sent.
Getting an INFO you don't understand is no worse than getting any other
message or content type you don't understand. Plus, if you don't
understand it, the guy sending it (in this case) is clearly going to get
the angry call from the customer because they can't get their DTMF
buttons to work on their device.

Not having any documentation for it, in a very twisted (and not
recommended) way, even further proves this point because folks are using
it without having to be told much about how it works!

Not the way we want to operate though.

Regards,
Brian

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Thu, 27 Sep 2007 15:21:09 -0400

Wow, that is sad.  I was sure there was some draft somewhere.
To be clear, though, it's not literally "application/dtmf" that I'm talking
about - that's just an example I was using to encompass the concept.  The
most popular one is "application/dtmf-relay" I think, but there are like at
least 4 different mime types for dtmf out there.

-hadriel

> Sent: Thursday, September 27, 2007 10:13 AM
> To: Christer Holmberg
> Cc: [email-masked]; Brian Stucker
> Subject: Re: [Sip] INFO
>

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Thu, 27 Sep 2007 15:21:10 -0400

> Sent: Thursday, September 27, 2007 12:05 PM
> 

I'm not advocating anything (yet).  Eric's draft makes the case that Info is
bad for several reasons, one of which is that the message has no context and
no negotiation mechanism.  I'm saying that's fixable.  I am only thinking of
dtmf, because that's the most common use case I see of Info (other than
sip-t), and it was the main use case example in Eric's draft.

At the last IETF meeting the question was raised (by Jonathan I think) along
the lines of "is there a real-world reason INFO keeps getting used, as
opposed to the already standardized approaches?"  I think there are
real-world reasons people use Info vs. KPML.  As far as I can see, KPML is a
rarity.  Obviously there's also 2833/4733.  Plenty of devices do 2833.
Unfortunately, plenty of devices don't too, and there are apps which can't
use 2833 architecturally and need dtmf in SIP.  

-hadriel

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Thu, 27 Sep 2007 15:21:09 -0400

-hadriel

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Thu, 27 Sep 2007 15:21:10 -0400

-hadriel