I have looked on the wiki and only found passing reference to RFC 4733 in the SRTP section. RFC4733 = RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals. This obsoletes RFC2833. http://www.ietf.org/rfc/rfc4733.txt Richard Lamkin Mettoni Group UK richard.lamkin@mettoni.com ************************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. http://www.mettoni.com Mettoni Ltd Registered in England and Wales: 4485956 9400 Garsington Road, Oxford Business Park, Oxford, OX4 2HN *************************************************************************
It should... very few differences were added to 4733. /b On Apr 23, 2009, at 9:50 AM, Richard Lamkin wrote:
I have looked on the wiki and only found passing reference to RFC 4733 in the SRTP section.
RFC4733 = RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals. This obsoletes RFC2833. http://www.ietf.org/rfc/rfc4733.txt
Richard Lamkin Mettoni Group UK richard.lamkin@mettoni.com
Brian West brian@freeswitch.org -- Meet us at ClueCon! http://www.cluecon.com
rfc 4733 attempts (and fails miserably) to clarify rfc2833. It doesn't "really" change anything of any real substnace. Our handling of these packets tries very hard to be strict in what we send and loose in what we accept and we tend to interoperate pretty well with most endpoints. That being said, there are some very broken endpoints out there (such as sonus) that require special hacks, some are automatic, some require settings. All that being said, we should be very compliant with both 2833 and 4733, although you will generally see references in settings refer to 2833. Mike On Apr 23, 2009, at 10:50 AM, Richard Lamkin wrote:
I have looked on the wiki and only found passing reference to RFC 4733 in the SRTP section.
RFC4733 = RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals. This obsoletes RFC2833. http://www.ietf.org/rfc/rfc4733.txt
Richard Lamkin Mettoni Group UK richard.lamkin@mettoni.com
************************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. http://www.mettoni.com
Mettoni Ltd Registered in England and Wales: 4485956 9400 Garsington Road, Oxford Business Park, Oxford, OX4 2HN ************************************************************************* _______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Michael Jerris wrote:
rfc 4733 attempts (and fails miserably) to clarify rfc2833. It doesn't "really" change anything of any real substnace. Our handling of these packets tries very hard to be strict in what we send and loose in what we accept and we tend to interoperate pretty well with most endpoints. That being said, there are some very broken endpoints out there (such as sonus) that require special hacks, some are automatic, some require settings. All that being said, we should be very compliant with both 2833 and 4733, although you will generally see references in settings refer to 2833. RFC4733 largely tries to clarify RFC2833 for the DTMF features. However, for most other signal it is very incompatible with RFC2833.
Steve
I should clarify that we support the dtmf tones plus flash but no other tones at this time. Mike On Apr 23, 2009, at 11:17 AM, Steve Underwood wrote:
Michael Jerris wrote:
rfc 4733 attempts (and fails miserably) to clarify rfc2833. It doesn't "really" change anything of any real substnace. Our handling of these packets tries very hard to be strict in what we send and loose in what we accept and we tend to interoperate pretty well with most endpoints. That being said, there are some very broken endpoints out there (such as sonus) that require special hacks, some are automatic, some require settings. All that being said, we should be very compliant with both 2833 and 4733, although you will generally see references in settings refer to 2833. RFC4733 largely tries to clarify RFC2833 for the DTMF features. However, for most other signal it is very incompatible with RFC2833.
participants (4)
-
Brian West
-
Michael Jerris
-
Richard Lamkin
-
Steve Underwood