Saúl Ibarra Corretgé wrote: > Well, those 2 things just can't happen at the same time :-S If you are > not in the media path and DTMF tones are not sent to you there is very > little you can do there IMHO.
That is true if DTMF is carried in the media and not in signaling. I fail to understand why DTMF delivery methods in signaling path are not as stabilized as RFC 2833/4733 is. There are many use cases where nice features can be enabled with events while dedicated event detector is not feasible in media path. Worley, Dale R (Dale) <dwor...@avaya.com> wrote: > You can arrange for the middlebox to relay the RTP between the endpoints. > But the general rule for "middlebox services" is "Don't *do* that!" The > Internet works best in an end-to-end mode. I couldn't agree more on end-to-end principle, that's what I look to maintain. Let's not think of the "middlebox" as a service (or intervention?) by proxy/ITSP/operator, but rather a signaling feature. Or just forget the whole analogy, maybe it wasn't succesful in the first place. Let's say I want to have incoming media delivered straight to my RTP capable household appliance (loudspeakers, TV, playstation), while signaling is handled entirely by mobile device. IMHO in that case unnecessary complexity is introduced if media device needs to provide notifies rather than just concentrate on audio/video capabilities. -- Mikko _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
