inline.
Christer Holmberg (JO/LMF) wrote:
I am also confused that people seem to think that INFOs will start flying around for no reason, without the sender having any clue about whether the receiver will understand them or not. As we have discussed, there ARE mechanisms in SIP to negotiate what content types etc entities support. Yes, MAYBE we need to extend that (e.g. being able to indicate which methods can be used to carry a specific content type), if what we have is not enough. But, to me that is not the same thing has having "tons of problem".
There is a big difference between, "I can support this format", and "I am interested in having you send me events in this format". This is why we didn't go with the INFO method for DTMF. Since DTMF would already be arriving at the UAS in the form of 2833, the primary entities needing signaling-based solutions are applications not on the media path. But, we only want to send such signaling when there is an application that is interested. This is exactly what SUB/NOT is for - to ask for notifications of events.
Furthermore, by using a separate dialog we could have the notifications sent just to the interested application server, so that the proxies on the path of the original dialog don't need to see INFO messages flying by if they weren't interested.
Consider further the other UA in the call. If it supports both DTMF-over-INFO and RFC2833, what does it mean to get both? If you generate DTMF on receipt of INFO, you stand a real risk of generating double DTMF which is very bad. You avoid this problem if you only send DTMF over signaling when asked; this way the thing getting the rfc2833 doesn't ask for it.
Using SUB/NOT also allowed the application to customize when it would get a notification. So for example an app that needed each digit as it was pressed could get them immediately. One only needing them after some pattern was matched could only get it then. This was also a perfect match for SUB/NOT.
So there are serious technical limitations to carrying DTMF over INFO. Sure, it can 'work', but it is very suboptimal and can cause problems.
As for a general INFO usage, my opinion is unchanged on this. We have numerous methods for extending SIP by adding new headers and methods and event packages. Can you demonstrate a use case where one of these extensibility mechanisms is not sufficient for some use case?
-Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems [EMAIL PROTECTED] FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 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 PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
