[Sip-implementors] Is RFC 2833 a MUST in sending DTMF?

[Hasini Gunasinghe]

Hi All,

In my sip soft phone application, I send DTMF using RFC 2976 (through sip
info message). That works fine and it is related to the SIP stack of our
application.
My questions are:
1). In implementing the DTMF sending functionality, is it a must that we
provide both implementations as in RFC 2976 and RFC 2833?
I mean...if I only implement RFC 2976, can there be problems when
communicating a server or application who has implemented RFC 2833.
2). Which method is more preferred in the context of a SIP Soft phone
application? and Why?

Thank you.
regards,
Hasini.

[Iñaki Baz Castillo]

Post by Hasini Gunasinghe
Hi All,
In my sip soft phone application, I send DTMF using RFC 2976 (through sip
info message). That works fine and it is related to the SIP stack of our
application.
1). In implementing the DTMF sending functionality, is it a must that we
provide both implementations as in RFC 2976 and RFC 2833?
I mean...if I only implement RFC 2976, can there be problems when
communicating a server or application who has implemented RFC 2833.
2). Which method is more preferred in the context of a SIP Soft phone
application? and Why?

AFAIK some PSTN gateways expect DTMF via RFC2833 but ufortunatelly
I've not found one of these yet.
You probably could live with an application just sending INFO and no
RFC2833, just need to check if your media servers also allow SIP INFO
(voicemail server, conference servers...). The most common SIP servers
do allow SIP INFO, so you could just implement it.

[Johansson Olle E]

Post by Hasini Gunasinghe
2). Which method is more preferred in the context of a SIP Soft phone
application? and Why?

Remember that SIP and RTP sometimes travels different paths. For many
applications, it is important that DTMF is timed with the rest of the
audio. Sending DTMF without timestamps and in a different signalling
path totally removes the relation to the audio stream.

My experience is that very few carriers now support SIP Info.

Note that RFC 2976 just is a generic description of the SIP info
method. The way you carry DTMF is proprietary and specified by Cisco.
Nortel seems to have added their own extensions. DTMF over SIP info is
not an IETF specification.

Regards
/Olle

[Maxim Sobolev]

Post by Johansson Olle E
audio. Sending DTMF without timestamps and in a different signalling
path totally removes the relation to the audio stream.

Well, arguably not much relation to audio stream is really needed for
DTMF applications. Relative events ordering, not absolute timestamps, is
what important here and it is provided reliably by the CSeq in SIP INFO.

I think technically SIP INFO delivery method is superior to RFC2833
(DTMF is a signaling, not media after all, so that it should take
signaling path), however, as it has been correctly mentioned here, there
is no common standard and much weaker support across different
implementations.

Regards,

[Dale Worley]

Post by Iñaki Baz Castillo
AFAIK some PSTN gateways expect DTMF via RFC2833 but ufortunatelly
I've not found one of these yet.

The sipX open-source PBX uses RFC 2833 exclusively. We've found that
all SIP phones support RFC 2833. Many PSTN gateways do also, including
Audiocodes, Patton, Mediatrix, Vegastream, and Cisco.

Dale

[Johansson Olle E]

Post by Dale Worley

Post by Iñaki Baz Castillo
AFAIK some PSTN gateways expect DTMF via RFC2833 but ufortunatelly
I've not found one of these yet.

The sipX open-source PBX uses RFC 2833 exclusively. We've found that
all SIP phones support RFC 2833. Many PSTN gateways do also,
including
Audiocodes, Patton, Mediatrix, Vegastream, and Cisco.

Actually, some Cisco engineers told me they've abandond SIP info dtmf
a year ago...

The only upside I see is that it's easier to debug DTMF in the SIP
channel than deep down in RTP.
Otherwise, RFC2833 is the way to go. There is actually a replacement
now, but not even
Dale mentioned that...

http://www.rfc-editor.org/rfc/rfc4733.txt

Obsoletes 2833. Note that this RFC is dated December 2006.

I think that one of the problems is this part:

"The telephone-event payload defined in this specification is highly
compressed. A change in value of just one bit can result in a major
change in meaning as decoded at the receiver. Thus, message integrity
MUST be provided for the telephone-event payload type. To meet the
need for protection both of confidentiality and integrity, compliant
implementations SHOULD implement the Secure Real-time Transport
Protocol (SRTP) [7]."

And in the Appendix covering changes from RFC2833:
"The Security Considerations section is updated to mention the
requirement for protection of integrity. More importantly, it makes
implementation of SRTP [7] mandatory for compliant implementations,
without specifying a mandatory-to-implement method of key distribution."

I haven't seen any UAs claiming to be 4733 compliant. We're working on
Asterisk to get SRTP in there soon, but there is still a lot of work
to do with TLS and SRTP. And there should propably be some kind of
negotiation here and alert to the user if we can't secure DTMF and
have to downgrade to 2833...
Any comments on this?

/O

[Maxim Sobolev]

Post by Hasini Gunasinghe
Hi All,
In my sip soft phone application, I send DTMF using RFC 2976 (through sip
info message). That works fine and it is related to the SIP stack of our
application.
1). In implementing the DTMF sending functionality, is it a must that we
provide both implementations as in RFC 2976 and RFC 2833?
I mean...if I only implement RFC 2976, can there be problems when
communicating a server or application who has implemented RFC 2833.
2). Which method is more preferred in the context of a SIP Soft phone
application? and Why?

In short, the RFC2833 is de-facto standard for the out-of-band DTMF
delivery now. Therefore, if your application is expected to interoperate
with the third-party SIP/RTP stacks then it's better to support it, as
SIP INFO method support across industry is much narrower.

Regards,

[Scott Lawrence]

Post by Hasini Gunasinghe
Hi All,
In my sip soft phone application, I send DTMF using RFC 2976 (through sip
info message). That works fine and it is related to the SIP stack of our
application.
1). In implementing the DTMF sending functionality, is it a must that we
provide both implementations as in RFC 2976 and RFC 2833?
I mean...if I only implement RFC 2976, can there be problems when
communicating a server or application who has implemented RFC 2833.
2). Which method is more preferred in the context of a SIP Soft phone
application? and Why?

Others have already made the case for 2833 support.

I'll just point out that you can test your support for that (and a lot
of other SIP capabilities) at our public interoperability test site.
See

http://interop.sipxecs.org

[Attila Sipos]

there is one disadvantage to RFC 4733.
They have removed the hookflash (Flash) notification.
In RFC2833 Flash was in Table 1:

Event encoding (decimal)
_________________________
0--9 0--9
* 10
# 11
A--D 12--15
Flash 16

Maybe it's not a big deal but it's strange that it was removed.

Operationally, I don't see many other differences between 2833 and 4733.
So an RFC2833 implementation would interop well (even if communicating with
a rfc4733 device)

Regards,
Attila



-----Original Message-----
From: sip-implementors-bounces at lists.cs.columbia.edu [mailto:sip-implementors-bounces at lists.cs.columbia.edu] On Behalf Of Johansson Olle E
Sent: 26 January 2009 16:58
To: sip-implementors at lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Is RFC 2833 a MUST in sending DTMF?

Post by Dale Worley

Post by Iñaki Baz Castillo
AFAIK some PSTN gateways expect DTMF via RFC2833 but ufortunatelly
I've not found one of these yet.

The sipX open-source PBX uses RFC 2833 exclusively. We've found that
all SIP phones support RFC 2833. Many PSTN gateways do also,
including Audiocodes, Patton, Mediatrix, Vegastream, and Cisco.

Actually, some Cisco engineers told me they've abandond SIP info dtmf a year ago...

The only upside I see is that it's easier to debug DTMF in the SIP channel than deep down in RTP.
Otherwise, RFC2833 is the way to go. There is actually a replacement now, but not even Dale mentioned that...

http://www.rfc-editor.org/rfc/rfc4733.txt

Obsoletes 2833. Note that this RFC is dated December 2006.

I think that one of the problems is this part:

"The telephone-event payload defined in this specification is highly compressed. A change in value of just one bit can result in a major change in meaning as decoded at the receiver. Thus, message integrity MUST be provided for the telephone-event payload type. To meet the need for protection both of confidentiality and integrity, compliant implementations SHOULD implement the Secure Real-time Transport Protocol (SRTP) [7]."

And in the Appendix covering changes from RFC2833:
"The Security Considerations section is updated to mention the requirement for protection of integrity. More importantly, it makes implementation of SRTP [7] mandatory for compliant implementations, without specifying a mandatory-to-implement method of key distribution."

I haven't seen any UAs claiming to be 4733 compliant. We're working on Asterisk to get SRTP in there soon, but there is still a lot of work to do with TLS and SRTP. And there should propably be some kind of negotiation here and alert to the user if we can't secure DTMF and have to downgrade to 2833...
Any comments on this?

/O

[Govardhana Sankanna Nagendraprasad]

Hi All,

What should be the behavior of UAS upon receiving a INVITE request with a timer option in the supported header, a valid Session-Expires value and a Min-SE with a value lower than the configured value of UAS.

UAC ---- INVITE with x:120 and Min-SE: 90 -----> UAS ( Configured
Min-Se: 100)


Please let us know the behavior of UAS. Should UAS respond with positive(200 ok for INVITE) or negative (421 for INVITE)response.

Thanks and Regards,
Govardhan


"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error,please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."

[Victor Pascual Ávila]

On Wed, Jan 28, 2009 at 1:56 PM, Govardhana Sankanna Nagendraprasad

Post by Hasini Gunasinghe
Hi All,
What should be the behavior of UAS upon receiving a INVITE request with a timer option in the supported header, a valid Session-Expires value and a Min-SE with a value lower than the configured value of UAS.
UAC ---- INVITE with x:120 and Min-SE: 90 -----> UAS ( Configured
Min-Se: 100)
Please let us know the behavior of UAS. Should UAS respond with positive(200 ok for INVITE) or negative (421 for INVITE)response.

The UAS should accept the request, optionally reduce the value of the
Session-Expires header to 100 and copy it into the 200 response.

[Rohit Aggarwal]

Hi

Since the Session-Expires value (120) in INVITE request is higher than the minimum interval defined by the UAS' local policy (100), UAS does not need to reject the request with a failure response.

It can send 2xx with a Session-Expires value that is "less than or equal to the value received from UAC" but "not lower than the Min-SE or 90 seconds".

Refer RFC 4028 :: Section 9 UAS Behavior
If an incoming request contains a Supported header field with a value
'timer' and a Session Expires header field, the UAS MAY reject the
INVITE request with a 422 (Session Interval Too Small) response if
the session interval in the Session-Expires header field is smaller
than the minimum interval defined by the UAS' local policy. When
sending the 422 response, the UAS MUST include a Min-SE header field
with the value of its minimum interval. This minimum interval MUST
NOT be lower than 90 seconds.

If the UAS wishes to accept the request, it copies the value of the
Session-Expires header field from the request into the 2xx response.

The UAS response MAY reduce its value but MUST NOT set it to a
duration lower than the value in the Min-SE header field in the
request, if it is present; otherwise the UAS MAY reduce its value but
MUST NOT set it to a duration lower than 90 seconds. The UAS MUST
NOT increase the value of the Session-Expires header field.


Regards
Rohit Aggarwal
Aricent

-----Original Message-----
From: sip-implementors-bounces at lists.cs.columbia.edu [mailto:sip-implementors-bounces at lists.cs.columbia.edu] On Behalf Of Govardhana Sankanna Nagendraprasad
Sent: Wednesday, January 28, 2009 6:26 PM
To: sip-implementors at lists.cs.columbia.edu
Subject: [Sip-implementors] If Local Min-Se is greater than the Remote Min-Se

Hi All,

What should be the behavior of UAS upon receiving a INVITE request with a timer option in the supported header, a valid Session-Expires value and a Min-SE with a value lower than the configured value of UAS.

UAC ---- INVITE with x:120 and Min-SE: 90 -----> UAS ( Configured
Min-Se: 100)


Please let us know the behavior of UAS. Should UAS respond with positive(200 ok for INVITE) or negative (421 for INVITE)response.

Thanks and Regards,
Govardhan


"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error,please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."

_______________________________________________
Sip-implementors mailing list
Sip-implementors at lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error,please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."

[Dale Worley]

Post by Attila Sipos
there is one disadvantage to RFC 4733.
They have removed the hookflash (Flash) notification.

That seems very strange, given how common it is to use Flash as a
signaling trigger.

Dale