Hi, >>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". When you indicate the stuff you support in an OPTIONS response, I agree it's "I can support this format". But, if I in an INVITE response indicate support of a certain content type I think that can also be seen as "When/if you are going to send me X, please use 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. In most cases, yes, and my intention is not to promote people to use a signaling-based solution instead of 2833. We could even make very strong recommendations to always use 2833, when possible. (However, in theory you could also have a signalling gateway, without access to media, which sends the DTMFs using a signaling-based solution since the protocol "on the other side" also does it.) >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. The application may not necessarily know that I am going to send him anything, and then it will have to ask "just in case". >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. That is an advantage, yes. ...eventhough I wonder how many proxies you actually would be able to "skip" in real life scenarios. You may have routes established using Path and/or Service-Route, for example. >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 have exactly the same problem with SUB/NOT, if you BOTH subscribbe to the DTMF event AND inciate support of 2833 in your SDP. So, the solution is: you indicate EITHER support of 2833 OR the signaling-based mechanism (whatever it is). >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. I am not sure I understand that. Even if I use SUB/NOT I don't know exactly when the DTMF event will come (if it will come), and I could still also receive 2833 while the subscription is active. >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. Well, obviously people using INFO do not need the subscriber to be able to "push" the digitmap. But, if I am asked to give 4 digits I may implement a user interface which allows me to enter the digits before they are sent in a single INFO (assuming the INFO based mechanism allows it). >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? >From a functional perspective I am pretty sure they are sufficient. And, I am not saying that all INFO usages are good, and that you couldn't use a better (both from a functionality and complexity perspective) alternative. Regards, Christer _______________________________________________ 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
