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

["Christer Holmberg" <[e-mail]>]

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:[e-mail]]
Lähetetty: ma 3.12.2007 5:00
Vastaanottaja: IETF SIP List
Aihe: [Sip] My two cents on the INFO question



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 <http://www.jdrosen.net/>                          PHONE: [phone]
http://www.cisco.com <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




_______________________________________________
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