Subject: [Sip] My two cents on the INFO question

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 02 Dec 2007 23:00:04 -0500

Well, I finally had a chance to catch up on this topic - reading both 
Eric's and Hadriel's drafts and most (though not all) of the enormous 
number of messages on this topic.

I personally do not think there is a good definition yet of what the 
problem is that we are trying to solve.

There has been lots of general discussion about INFO usages but for the 
most part, DTMF is the only real concrete one that has come to the 
table. My big worry is that the DTMF "problem" is in fact much bigger 
than just adding negotiation to INFO. Indeed, in a very real sense, 
defining a new INFO package and INFO framework will just add yet ANOTHER 
mechanism to the list of things standardized for DTMF (2833, KPML, 
existing non-standard INFO, unsolicited NOTIFY, and now INFO package). 
The real problem IMHO is that we lack clear guidance on when each of 
these applies and when it doesn't. We have no baseline standard that 
everyone has to implement, and we have no framework for negotiating 
amongst these very different things. I simply do not see how defining an 
INFO framework solves that problem.

What are the actual use cases where DTMF-over-INFO is the 'right' thing? 
The only one I've seen mentioned was the 323 gateway case. Are there 
others? Is that the only use case that this whole mess would actually 
address?

Another big worry is that, if we did have this INFO framework, we would 
be adding another mechanism to an already-long list of ways to handle UA 
to UA signaling. Is it clear what the different areas of applicability 
are for rfc3265 vs. setting up a separate control session vs. new 
methods vs. UPDATE w/ headers vs. the new INFO framework? I don't think 
is clear at all.

To give an example, Hadriel raised a potential new usage of the INFO 
framework for exchanging pictures or vcard in the middle of the call. 
However, we already have a mechanism for doing that via Call-Info. 
Indeed, Call-Info has the benefit of having a "purpose" attribute, which 
defines the context for the URL being exchange. So, would the right way 
to exchange vcards to send an UPDATE with Call-Info? Or send INFO with 
Info-Event: vcard along with the vcard content in the body?

I'm not opposed to a new info framework in principle, but I think its 
not at all clear that, if we defined such a framework, we'd be solving 
any real interoperability problems.

My 2 cents,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com

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

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 3 Dec 2007 14:03:53 +0100

Hi Jonathan,
 
If we do NOT this, it is not going to help interoperability either. People will continue using INFO in their own way (even if we go ahead with Eric's proposal), and the same discussion will come up at some point again (it's similar to the discussion on early media :). Yes, then we can say "it's not an IETF problem", but what good will that make for interoperability?
 
If we go ahead with this there will of course still be non-standard implementations out there, but at least it will allow for people to use a standardized mechanism.
 
Now, regarding the issue when it's more appropriate to use mechanism X rather than mechanism Y,  I think that is something we SHALL work on - no matter what we do with the Info Event draft - and I think it would be very useful to document. I do NOT think it's part of the Info-Event draft, however, but rather something more generic, where we collect and describe the difference mechanisms of doing things, the cons and prefs, etc. Then people won't have to try to look for different mechanism separately, and then try to compare them on their own.
 
But, as we have discussed, two of the main reasons why people use INFO instead of NOTIFY is because they can use the existing invite dialog (you CAN do that with NOTIFY also, but as we know there are lots of issues with that - which is the reason we recommend not to do it), and you don't have to assume the remote entity will know everything you may want to send to him (he will have to subscribe before you can send anything). INFO often also works better with B2BUAs, uses standard SIP mid-dialog routing etc. 
 
Regarding DTMF, I agree that it has been the most obvious example, but there are also other usages people are looking into. I won't speculate about the most obvious DTMF-over-INFO (or DTMF-out-of-band in general) use-cases. Interworking with H.323 is certainly one use-case, another one is interworking with H.324m (in which case there MAY also be other type of information that you want to send), but people also use it for "pure" SIP-to-SIP communciations.
 
Thank You very much for your comments!
 
Regards,
 
Christer

________________________________

Lähettäjä: Jonathan Rosenberg [mailto:[email-masked]]
Lähetetty: ma 3.12.2007 5:00
Vastaanottaja: IETF SIP List
Aihe: [Sip] My two cents on the INFO question

My 2 cents,
Jonathan R.

--
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net <http://www.jdrosen.net/>                          PHONE: (408) 902-3084
http://www.cisco.com <http://www.cisco.com/>

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 3 Dec 2007 13:47:54 -0500

Jonathan,
Thanks for the feedback - comment inline...

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Sunday, December 02, 2007 11:00 PM
> To: IETF SIP List
> Subject: [Sip] My two cents on the INFO question
>

Huh.  I thought that was clear.  Sorry if the draft wasn't clear on that.  We currently have an in-invite-dialog method defined (INFO) that many people use, but it's "broken" because it's missing a standardized way to negotiate or discover supported uses for INFO, a standardization process for defining packages for it, and signaling what package the specific INFO request is carrying/notifying.  That's the problem draft-kaplan-sip-info-events is trying to address.

Whether INFO actually needs to be fixed or instead needs to be abandoned is almost a separate issue.  Is that what you're asking?

At the last IETF you said "we should work on things that are broken in the real world".  DTMF is broken in the real world (sometimes), except right now SBCs "fix" this issue to make it interop.  I don't mind them doing that forever, but even fixing it is fraught with problems.

> existing non-standard INFO, unsolicited NOTIFY, and now INFO package).

My short answer to your question is "I don't know".  I don't know if standardizing INFO will succeed in attracting implementation by vendors which currently do non-standard in-dialog INFO/NOTIFY for DTMF.  I don't know if this will reduce the interop issues.  I don't know if given enough time, those vendors would go implement KPML anyway.

I *do* believe that there is a price to be paid for KPML above that of INFO, and that price will keep people doing INFO/NOTIFY.  I *do* know there is a need for signaling-plane DTMF.  I *do* know that there is no current standard for INFO-based DTMF.  I do believe that if we do not offer a standardized way of doing DMTF in INFO, then the set of {2833, KPML, application/dtmf-relay INFO, application/dtmf INFO, application/dtmf-event Notify, etc.} will not get smaller.  The hope is it gets down to {2833, KPML, INFO}.

We can piss up a rope and outlaw the most popular way to do signaling-plane DTMF.  Or we can account for gravity.

> others? Is that the only use case that this whole mess would actually

DTMF-over-INFO is the 'right' thing to do when the other side asks to receive it.  You'd ask to receive it if you're a UA in the call path that wants to get DTMF in an Invite dialog in the signaling plane.  It's not just h323.  It's MGCP too.  And apparently a bunch of app-servers and PSTN gateways that continue to use INFO/NOTIFY today.

> methods vs. UPDATE w/ headers vs. the new INFO framework? I don't think

I think that could be worked on, with one extreme result being to limit INFO to only DTMF.

-hadriel