On 10/22/07 12:03 PM, Sanjay Sinha (sanjsinh) wrote:
Regarding concern of whether proxies in the middle of signaling path
will pass this NOTIFY along or not, the endpoints can exchange their
addresses as part of this event package negotiation, like c line in SDP.
So dtmf signaling will be sent end-to-end and will not traverse a proxy
that has added itself in signaling path with a RR header.
Say, I'm liking this idea. Perhaps we can encode the events with RTP
headers as well, instead of using SIP. Most SBCs will let RTP through
(and they may block peer-to-peer sip), so this has a really high chance
of making it end-to-end.
Just as a strawman, perhaps we could actually include an indication of
the event types in the SDP itself. For example, if we wanted to use
payload type number 100 to signal DTMF tones (events 0 through 15) and
the dial and ringing tones (assuming as an example that these were
defined as events with codes 66 and 70, respectively), we could include
the following description in the SDP body:
m=audio 12346 RTP/AVP 100
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15,66,70
That should keep any meddlesome middleboxes out of the way altogether.
/a
_______________________________________________
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
