[Sip] My two cents on the INFO question

[Jonathan Rosenberg <[e-mail]>]

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
[e-mail]
http://www.jdrosen.net                         PHONE: [phone]
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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip