Subject: [Sipping] comments on draft-burger-sip-info-00

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 13 Jul 2007 16:16:23 -0400

I think this is good, and agree with what it has to say.

My main comment is that I think we need some additional text in there 
that focuses specifically on DTMF. It seems that most folks in the 
industry believe that INFO is the IETF solution for that and are shocked 
to learn its not true and that there are issues with it. I think it 
would be good to document the issues, including:

1. confusion resulting from DTMF being sent in rfc2833 and INFO
2. no way to signal whether the far end wants to receive DTMF via INFO; 
it may be getting it via rfc2833 and that is fine for most cases
3. proxies seeing INFO message load when they don't care about it
4. no way to pass digit maps so that you end up sending every digit in 
its own INFO or guess at the maps, so its inefficient
5. security issues in case the DTMF is containing calling card info or 
credit cards - rfc2833 along with SRTP is much more secured

and so on.

I like how section 3 says what you SHOULD do instead of INFO. I think 
more guidance is needed here, in particular on helping understand when 
is the right time to use a separate SIP-setup control channel ala MSRP 
vs. in the dialog via a new method vs. a new dialog via something like 
SUB/NOT.

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

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

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Mon, 16 Jul 2007 13:43:50 +0200

Hi,

I have a number off issues with the draft, and I think it's extremely
un-objective.

- I disagree with the statement in chapter 1 regarding the "context for
interpreting". The context is associated with the content type.

- I disagree with the statement in chapter 1 regarding not negotiation
method. You can indicate what content types you support.

- I disagree with the stamement in chapter 1 saying that something would
work only in limited or controlled networks. I am not really sure what a
controlled network means in this context, though. Of course some people
may have implemented something which only works between certain nodes,
or in certain networks, but that's a separate issue (and not even
specific to INFO).

- I don't understand the statement in chapter 1 saying "Likewise, a
routing proxy, such as the 3GPP IMS S-CSCF, will not expect to receive
media server control messages.". A routing proxy most likely wouldn't
care about media server control messages, so I don't understand the
"will not expect" thing.

- I don't understand the statement in chapter 2, saying "a DTMF digit
type could be for user stimulus, post-dial digit collection, simple
transport of a
digit (no signaling context), or a mistake.". How is that specfic to
INFO? I can press a DTMF button "by mistake" no matter what mechanism I
use to transport it...

Now, these are issues Eric and I have agree to discuss off-line in
Chicago.

I also have comments (some of which I've already given before) on

>1. confusion resulting from DTMF being sent in rfc2833 and INFO 

I believe you have the same problem with KPML, and the solution is to
use only one mechanism to send the DTMF.

>2. no way to signal whether the far end wants to receive DTMF via INFO;

The far end indicates what content types it supports for this session.

>it may be getting it via rfc2833 and that is fine for most cases 

Fine. Then you don't indicate support for the content types used with
the INFO solution

>3. proxies seeing INFO message load when they don't care about it

That is a potential issues, yes, but you MAY end up with exactly the
same proxy path using KPML. It depends on the network architecture and
routing mechanisms.

And, with KPML you will end up with multiple dialogs. Whether that is a
problem or not is for each one to decide, but I think it's fair to
document that, and possible issues related to it.

That is a limitation, yes, but it may not be required by everyone. And,
it could be solved using a content type parameter.

The security issue is not specific to DTMF, and using that argument we
should send everything sensitive on the media plane. Also, in some
environments the security may be provided other ways.

>and so on.

I don't have anything against documenting and discussing different
issues. But we shall be fair, and look at issues with ALL alternatives.

The document doesn't say anything about WHY people are using INFO in the
first place. It only says that "people think it's an IETF way of doing
things", without considering that fact that there could be issues with
other mechanisms why people are not using them.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 16 Jul 2007 08:58:41 -0400

> method. You can indicate what content types you support.

Can you lay out the negotiation strategy you have in mind that uses 
Accept for use of INFO, and that results in a mutual agreement on which 
DTMF technique will be used,among all those possible?

	Thanks,
	Paul

---

From: Dean Willis <[email-masked]>
Date: Mon, 16 Jul 2007 12:24:32 -0500

> interpreting". The context is associated with the content type.

Content type is, as I have repeatedly argued, completely insufficient  
for interpretation of context in the general case. What, for example,  
does it mean when an INFO shows up with a wav file attached? Play it?  
Record it? Parse it using speech recognition and pass it to a command  
processor?

> method. You can indicate what content types you support.

Since we don't know what a specific content type means from an  
application perspective, indicating content type does not provide for  
negotiation.

> or in certain networks, but that's a separate issue (and not even

If all YOUR applications understand what wav in INFO means, then your  
application is likely to work. But when you send one to MY  
application, which understands wav in INFO to mean something else, it  
isn't going to work.

> care about media server control messages, so I don't understand the

Fair enough. It's more a "doesn't care about and doesn't want to be  
burdened with". Frankly, I find this argument to be a pretty weak  
justification against INFO approaches, since obviously event based  
approaches would pose an even higher load on the S-CSCF.

> INFO? I can press a DTMF button "by mistake" no matter what  

So which sub-application do you feed that digit to? With RFC 2833,  
there's only one application context possible. With KPML, there are  
many. With event models, there are also many.

I suppose that if we wanted to limit ourselves to a single context,  
then INFO would be a reasonable approach. Many people don't seem to  
want that limitation, and 2833 already seems adequate for the single- 
context model, so why invent another one?

--
Dean

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Tue, 17 Jul 2007 12:33:29 +0200

Hi, 

>>- I disagree with the statement in chapter 1 regarding the "context 
>>for interpreting". The context is associated with the content type.
>>
> 
>Content type is, as I have repeatedly argued, completely 
>insufficient for interpretation of context in the general 
>case. What, for example, does it mean when an INFO shows up 
>with a wav file attached? Play it?  
>Record it? Parse it using speech recognition and pass it to a 
>command processor?

The dialog (you can't send INFOs out-of-dialog, as far as I know) will
be associated with an application, and if the application doesn't know
what to do with it, it can promt the user: "You have now received a
file. What do you want to do with it? Save it? Play it? Display it?
Delete it?". 

In other cases the application does know what to do with the
information, so there is no need for promting. For example, if the data
is used for video control, and the application does video control, it
will use the data for video control.

I don't think what-to-do-with-the-file question is INFO specific.

Having said that, I have never said that INFO is the best option for
everything. Especially when we talk about file transfer type of
applications, or in general when lots of data is to be sent, I'm the
first one to agree that there most likely are more suitable mechanisms.

But, when we talk about DTMF, video control, ISUP etc, I don't see that
as file transfer (it's more application control data) , and the size of
the data sent is relatively small.

> 
>Since we don't know what a specific content type means from 
>an application perspective, indicating content type does not 
>provide for negotiation.

The application knows what it uses the data for - the SIP protocol
doesn't need to know.

>>- I disagree with the stamement in chapter 1 saying that something 
>>would work only in limited or controlled networks. I am not really 
>>sure what a controlled network means in this context, though. Of 
>>course some people may have implemented something which only works 
>>between certain nodes, or in certain networks, but that's a 
>>separate issue (and not even specific to INFO).
> 
>If all YOUR applications understand what wav in INFO means, 
>then your application is likely to work. But when you send 
>one to MY application, which understands wav in INFO to mean 
>something else, it isn't going to work.

See my first comment in this reply.

>Fair enough. It's more a "doesn't care about and doesn't want 
>to be burdened with". Frankly, I find this argument to be a 
>pretty weak justification against INFO approaches, since 
>obviously event based approaches would pose an even higher 
>load on the S-CSCF.
> 
>>
>>transport of a digit (no signaling context), or a mistake.". How is 
>>that specfic to INFO? I can press a DTMF button "by mistake" no matter

>>what mechanism I use to transport it...
> 
>So which sub-application do you feed that digit to? With RFC 
>2833, there's only one application context possible. With 
>KPML, there are many. With event models, there are also many.

I am not sure I understand the application context issue. I pass the
digit to the application which is associated with the dialog.

>I suppose that if we wanted to limit ourselves to a single 
>context, then INFO would be a reasonable approach. Many 
>people don't seem to want that limitation, and 2833 already 
>seems adequate for the single- context model, so why invent 
>another one?

Again, I can't say why people prefear INFO to 2833, but one reason is
that the receiver (or the sender) of the DTMF does not have access to
the media plane.

Regards,

Christer

---

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

Hi, 

>Can you lay out the negotiation strategy you have in mind 
>that uses Accept for use of INFO, and that results in a 
>mutual agreement on which DTMF technique will be used,among 
>all those possible?

I indicate what DTMF content type I support, you indicate what you
support, and then we use something that both support.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 17 Jul 2007 09:15:51 -0400

Christer,

Its not that the *sip protocol* needs to understand the content, but 
*both* UAs need to agree on what it means. Lacking any common 
specification of what the meaning is, what is the point of sending 
something? There are many things like this where the protocol doesn't 
*care* but the meaning is defined so that the endpoints will understand.

This kind of vague "its ok as long as we both agree" works in closed 
environments where all the participants are homogeneous. But it doesn't 
work in general.

In the case of DTMF, if there are multiple ways it might be sent, then 
there is need for a negotiation:
- UA1: here are the different ways I could send DTMF - X,Y,Z
- UA2: please send DTMF using method Y

(And that negotiation may need to go on in the other direction too.)

The Accept header isn't capable of saying what can be sent, so it 
doesn't play into such a negotiation very well.

	Paul

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Tue, 17 Jul 2007 15:47:53 +0200

Please note that this is an author draft submitted with a "sip" tag not
a "sipping" tag, and for which agenda time for a discussion on what to
charter in this area has been allocated in the SIP WG.

If you want this discussion taken into account in the SIP WG
deliberations, you may want to transfer this discussion to [email-masked].

This does not preclude raising issues of concern to SIPPING on the
SIPPING list.

Regards

Keith 

> -----Original Message-----
> From: Christer Holmberg (JO/LMF) 
> [mailto:[email-masked]] 
> Sent: Tuesday, July 17, 2007 11:33 AM
> To: Dean Willis
> Cc: IETF Sipping List
> Subject: RE: [Sipping] comments on draft-burger-sip-info-00
> 
> 
> Hi, 
> 
> insufficient 
> The dialog (you can't send INFOs out-of-dialog, as far as I 
> know) will be associated with an application, and if the 
> application doesn't know what to do with it, it can promt the 
> user: "You have now received a file. What do you want to do 
> with it? Save it? Play it? Display it?
> Delete it?". 
> 
> information, so there is no need for promting. For example, 
> if the data is used for video control, and the application 
> does video control, it will use the data for video control.
> 
> Having said that, I have never said that INFO is the best 
> option for everything. Especially when we talk about file 
> transfer type of applications, or in general when lots of 
> data is to be sent, I'm the first one to agree that there 
> most likely are more suitable mechanisms.
> 
> But, when we talk about DTMF, video control, ISUP etc, I 
> don't see that as file transfer (it's more application 
> control data) , and the size of the data sent is relatively small.
> 
> The application knows what it uses the data for - the SIP 
> protocol doesn't need to know.
> 
> then your 
> application, 
> >which understands wav in INFO to mean something else, it 
> isn't going to 
> >work.
> 
> I am not sure I understand the application context issue. I 
> pass the digit to the application which is associated with the dialog.
> 
> Again, I can't say why people prefear INFO to 2833, but one 
> reason is that the receiver (or the sender) of the DTMF does 
> not have access to the media plane.
> 
> Regards,
> 
> Christer
> 
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Tue, 17 Jul 2007 16:14:25 +0200

Hi, 

>specification of what the meaning is, what is the point of 
>sending something? There are many things like this where the 
>protocol doesn't *care* but the meaning is defined so that the
endpoints will 
>understand.
>
>This kind of vague "its ok as long as we both agree" works in 
>closed environments where all the participants are 
>homogeneous. But it doesn't work in general.

One would of course need a standard document defining each content type,
and what type information is carried init.

The whole idea is to get people to bring their usages to IETF, so that
they can be documented.
 
>In the case of DTMF, if there are multiple ways it might be 
>sent, then there is need for a negotiation:
>The Accept header isn't capable of saying what can be sent, 
>so it doesn't play into such a negotiation very well.

In most cases I am pretty sure the client can send what it can receive,
unless the client really knows that it will never have to send something
(for example a server which only receives DTMFs).

Regards,

Christer

---

From: Dean Willis <[email-masked]>
Date: Tue, 17 Jul 2007 11:44:55 -0500

> file. What do you want to do with it? Save it? Play it? Display it?

And how does the receiver know what the sender intended?

Assume you're taking to my "phone" application. You send digits.  
Should those be rendered to me, or fed into the user interface of a  
phone-based game we happen to be playing?

The classic questions of detective work always apply to interpreting  
any message: who, what, how, where, when, and why.

Neither I nor my phone should have to do detective work to deduce  
what your INFO means.

--
Dean

---

From: "Ganesan Sam-W00184" <[email-masked]>
Date: Tue, 17 Jul 2007 13:26:30 -0400

Yes, INFO has become a catch-all and I/we have been guilty of using it
as such as well.  It would be good to disambiguate the various use
cases.  Accept does not have the semantic richness to accommodate the
kind of negotiations that become necessary immediately.  From the draft
it is also clear that the INFO method does not either(which is where
this discussion started anyway).  I most certainly would be loath to
almost have to do something like 3264 for media types to agree on how I
transport DTMF between the 2 end points.

As was touched upon in an earlier thread on this, protocol cannot
interpret the application developer's or the user's intent; the protocol
can only provide the richness an extensibility that can then be put to
use.  I agree with Eric that it does not provide the un-ambiguous
richness needed for the end points to interpret the data that arrives
with the packet in the right context.

Sam
___
Sam Ganesan
Advanced Technology Group
Motorola
55 Hayden Avenue, Suite 3000
Lexington, MA 02124
781-372-8160
[email-masked]

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Tuesday, July 17, 2007 9:16 AM
To: Christer Holmberg (JO/LMF)
Cc: IETF Sipping List; Dean Willis
Subject: Re: [Sipping] comments on draft-burger-sip-info-00

Christer,

	Paul

> information, so there is no need for promting. For example, if the 
> data is used for video control, and the application does video 
> control, it will use the data for video control.
> 
> But, when we talk about DTMF, video control, ISUP etc, I don't see 
> that as file transfer (it's more application control data) , and the 
> size of the data sent is relatively small.
> 

>>> between certain nodes, or in certain networks, but that's a separate

>>> issue (and not even specific to INFO).

>>> media server control messages.". A routing proxy most likely 
>>> wouldn't care about media server control messages, so I don't 
>>> understand the "will not expect" thing.
>>> - I don't understand the statement in chapter 2, saying "a DTMF 
>>> digit type could be for user stimulus, post-dial digit collection, 
>>> simple transport of a digit (no signaling context), or a mistake.". 
>>> How is that specfic to INFO? I can press a DTMF button "by mistake" 
>>> no matter
> 

> This list is for NEW development of the application of SIP Use 
> [email-masked] for questions on current sip Use 
> [email-masked] for new developments of core SIP
> 

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

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 17 Jul 2007 18:17:04 -0500

This document says "Lastly, this document formally restricts the use of
INFO to that
described by RFC 3372 [4]".

This would imply ISUP only.

In reality it should be restricted to the 2 use cases of RFC 3204
instead, i.e., ISUP and QSIG.

My 2 cents.

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Wed, 18 Jul 2007 12:17:35 +0200

Hi, 

>Should those be rendered to me, or fed into the user 
>interface of a phone-based game we happen to be playing?

How do you solve it with 2833? 

How do you solve it with KPML?

You could even have the same problem with normal voice, e.g. if the game
is controlled using voice recognition. Shall the received voice be fed
to the speaker, or fed to the game application?

In some cases it may not matter if the data is fed to multiple
applications. But, if you do need to dispatch data so specific
applications you either need some kind of application reference, or you
handle the dispatching locally in your device (the game application can
tell it wants DTMFs, and/or the device chooses - either automatically or
manually - which application will get the data etc). Or you use
different SIP sessions.

In other cases you will not have the problem. For example, videoControl
messages would normally be fed to a video control application, and
nowhere else.

Regards,

Christer

---

From: "Jesske, R" <[email-masked]>
Date: Wed, 18 Jul 2007 16:10:46 +0200

Dear all,
I'm concerned about the discussion here and the aim of the draft to restrict the use of INFO only to SIP-T and Q-SIG.

If you now change restrict the RFC2976 you will tear down each implementation already done based on RFC2976. Like for DTMF that is broadly used within the world. So you are against backward compatibility?

The draft is claiming that INFO has to be routed over each proxy where the INVITE is routed to. I do not know what's the problem with that. A proxy forwards and the question is how much load will this cause. UA's can sent re-INVITES or REGISTER, RE-REGISTER a couple of times and nobody claims that.
INFO is used for UA to UA communication so is this not proper enough that at least the UA's will know what to do with the MIME?
INFO is ideal to sent information that has to correlate with the Dialog using other mechanisms like an 2nd stream like http or a MESSAGE or a other control protocol can not fulfil this. Even it could be get lost when you want to traverse several SIP domains or if you interwork with the PSTN/ISDN.  

The Example of DTMF for INFO can only be done at mid dialog.

Using KPML --> We have minimum 4 more Messages. No additional Load?

Best Regards

Roland

> -----Ursprüngliche Nachricht-----
> Von: Christer Holmberg (JO/LMF) 
> Gesendet: Mittwoch, 18. Juli 2007 12:18
> An: Dean Willis
> Cc: IETF Sipping List
> Betreff: RE: [Sipping] comments on draft-burger-sip-info-00
> 
> 
> 
> Hi, 
> 
> know) will

---

From: [email-masked]
Date: Wed, 18 Jul 2007 11:58:17 -0400

From: "Jesske, R" <[email-masked]>

   I'm concerned about the discussion here and the aim of the draft to
   restrict the use of INFO only to SIP-T and Q-SIG.

   If you now change restrict the RFC2976 you will tear down each
   implementation already done based on RFC2976. Like for DTMF that is
   broadly used within the world. So you are against backward
   compatibility?

What uses -- interoperable uses, that is -- is INFO put to?
(Proprietary or non-interoperable uses don't matter, since they will
continue to work and will continue to be non-interoperable.)

Dale

---

From: Dean Willis <[email-masked]>
Date: Wed, 18 Jul 2007 11:32:15 -0500

On Jul 18, 2007, at 5:17 AM, Christer Holmberg (JO/LMF) wrote:

>>>> command

I don't think I can without negotiating separate streams. 2833 is  
also inadequate as a general solution to this problem. It works where  
it works, but its expressivity is constrained.

> How do you solve it with KPML?

separate subscriptions.

> to the speaker, or fed to the game application?

Quite true, and this constrains the design of applications.

> messages would normally be fed to a video control application, and

This is very analogous to the way that web browsers traditionally  
handle MIME content. For each MIME type, a "helper" program is  
registered to process inputs of that type. This works mostly, but I'm  
often getting stuff opened with the wrong application and having to  
sort it out manually.

It's a lot harder to do that sort of manual "sorting out" on a real- 
time multimedia flow into a device that may have a tightly  
constrained user interface.

--
Dean

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Wed, 18 Jul 2007 20:34:49 +0200

Hi,

>it works, but its expressivity is constrained.

You could have multiple streams, but how does the sender which remote application a specific stream is associated to?

>>How do you solve it with KPML?

How does the sender know which remote application a specific subscription is associated to?

>>You could even have the same problem with normal voice, e.g. if the game is controlled using voice recognition. Shall the received voice be fed

Therefor I think it's unfair to claim that this issue would be something unique for INFO.

>>In some cases it may not matter if the data is fed to multiple applications. But, if you do need to dispatch data so specific
>>applications you either need some kind of application reference, or  you handle the dispatching locally in your device (the game application 
>>can tell it wants DTMFs, and/or the device chooses - either automatically or manually - which application will get the data etc). Or you use
>>different SIP sessions.
>>
>>In other cases you will not have the problem. For example,  videoControl messages would normally be fed to a video control application, and
>>nowhere else.
>

We also need to separate the type of data that would be sent.
 
One type is "attachment" type of content, similar to what you normally get in e-mails (word files, picture files etc). These types are normally not used to control applications, or even not always even associated with a specific, and things won't "fail" if the receiver doesn't do what the sender "wanted". 
 
Another type is "application control" type of content, for example protocol messages (ISUP, videoControl, DTMF etc). These types are normally based on some protocol, and used to control applications, and can in many cased be automatically dispatched to the appropriate application. Again, you and I don't always need to have the same application software, but the applications need to understand the protocol
 
Attachment contents are normally relatively large. And, as I said before, there may be better and more effective ways than INFO for those.
 
Regards,
 
Christer

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 18 Jul 2007 15:30:53 -0400

> How does the sender know which remote application a specific subscription is associated to?

A long time ago Jonathan published a draft on this subject - something 
about user interaction where each element that required a particular 
sort of interaction subscribed and provided context about itself. I 
don't recall what the draft was called - I'm sure it expired years ago.

	Paul

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Thu, 19 Jul 2007 09:00:58 +0200

Hi, 

>A long time ago Jonathan published a draft on this subject - 
>something about user interaction where each element that 
>required a particular sort of interaction subscribed and 
>provided context about itself. I don't recall what the draft 
>was called - I'm sure it expired years ago.

Ok.

In any way, at the moment it looks to me that this is a generic issue,
not something unique to INFO.

Regards,

Christer