[Sip-implementors] SIP - DTMF transfer using RFC2833

Discussion:

Sylvester, Prasanth (NSN - IN/Bangalore)

2014-08-11 08:46:27 UTC

Hi Team,

Good day,
In our deployment, MSS - SBC (Session border Controller) - IVR System
MSS/MGW (.242) ---------> (.10) SBC (.9) ----------> IVR (10.58.2.20)
RFC2833 is configured on all ends,

I see MSS is sending the DTMF as RTP Events to SBC
402 3.845469000 10.33.64.242 10.33.1.10 RTP EVENT 58 Payload type=RTP Event, DTMF One 1

SBC is sending DTMF as RTP Events to IVR system
403 3.845471000 10.33.13.9 10.58.2.20 RTP EVENT 58 Payload type=RTP Event, DTMF One 1

However, when IVR system receives it, they get it as
551 88.724062 10.33.13.9 10.58.2.20 RTP 60 PT=DynamicRTP-Type-96, SSRC=0x81346A0C, Seq=169, Time=30560, Mark

Please help me understand what PT=DynamicRTP-Type-96 in passing DTMF?

Sylvester, Prasanth

Sylvester, Prasanth (NSN - IN/Bangalore)

2014-08-11 08:30:51 UTC

Permalink

Henning Christiansen

2014-08-12 09:18:25 UTC

Permalink

Mybe this is a matter of "interpretation" only.

Are you logging the packets with Wireshark? Wireshark only displays the
DTMF events as "DTMF events" if the original INVITE request (defining the
RFC2833 payload type, here: 96) was logged in the beginning.
If you start Wireshark after INVITE/OK was passed between both sides, the
tool does not know how to interpret the RTP packets and uses a
"transparent" mode for displaying the packets.

Mit freundlichen Gr??en

Henning Christiansen

-----Urspr?ngliche Nachricht-----
Von: sip-implementors-bounces at lists.cs.columbia.edu
[mailto:sip-implementors-bounces at lists.cs.columbia.edu] Im Auftrag von
Sylvester, Prasanth (NSN - IN/Bangalore)
Gesendet: Montag, 11. August 2014 10:31
An: sip-implementors at lists.cs.columbia.edu
Betreff: [Sip-implementors] SIP - DTMF transfer using RFC2833

Hi Team,

Good day,
In our deployment, MSS - SBC (Session border Controller) - IVR System
MSS/MGW (.242) ---------> (.10) SBC (.9) ----------> IVR (10.58.2.20)
RFC2833 is configured on all ends,

I see MSS is sending the DTMF as RTP Events to SBC
402 3.845469000 10.33.64.242 10.33.1.10 RTP EVENT 58
Payload type=RTP Event, DTMF One 1

SBC is sending DTMF as RTP Events to IVR system
403 3.845471000 10.33.13.9 10.58.2.20 RTP EVENT 58
Payload type=RTP Event, DTMF One 1

However, when IVR system receives it, they get it as
551 88.724062 10.33.13.9 10.58.2.20 RTP 60
PT=DynamicRTP-Type-96, SSRC=0x81346A0C, Seq=169, Time=30560, Mark

Please help me understand what PT=DynamicRTP-Type-96 in passing DTMF?

Sylvester, Prasanth

Joel Gerber

2014-08-12 11:23:44 UTC

Permalink

I'd be curious to know what the RTP Payload Identifier is for the MSS->SBC and SBC->IVR. I'm guessing they are PT 110. I've seen certain versions of Wireshark that do not properly dynamically decode RTP Event packets when their payload type isn't 110. I usually end up having to "Decode As" RTP packets that don't match. You can also go into your preferences and change the parameter for "RTP Event", named "Payload Type for RFC2833 RTP Events" (rtpevent.event_payload_type_value), but this won't help you when you have multiple payload types for RTP Events in the same capture file.

Now, as to why this is happening, I'm slightly puzzled. You're saying that the SBC (.9) is sending to your IVR (10.58.2.20) and Wireshark is auto-decoding this, but when it's received by your IVR, Wireshark is not decoding them (properly). Based on this, the payload type is different when leaving the SBC then when it is received by the IVR. This should not be possible. So, are all of these packets in the same pcap? Or were these captured into multiple pcaps? If it's the latter, then I expect the same thing that Henning Christiansen is, that the packet capture that received the RTP event (the IVR) might be missing some signaling information. Did you have to "Decode As" the RTP packets in the last hop? If so, did you "Decode As" RTP instead of RTP event?

Joel Gerber
Network Specialist
Network Operations
Eastlink
E: Joel.Gerber at corp.eastlink.ca T: 519.786.1241
-----Original Message-----
From: sip-implementors-bounces at lists.cs.columbia.edu [mailto:sip-implementors-bounces at lists.cs.columbia.edu] On Behalf Of Sylvester, Prasanth (NSN - IN/Bangalore)
Sent: August-11-14 4:31 AM
To: sip-implementors at lists.cs.columbia.edu
Subject: [Sip-implementors] SIP - DTMF transfer using RFC2833

Hi Team,

Good day,
In our deployment, MSS - SBC (Session border Controller) - IVR System MSS/MGW (.242) ---------> (.10) SBC (.9) ----------> IVR (10.58.2.20)
RFC2833 is configured on all ends,

I see MSS is sending the DTMF as RTP Events to SBC
402 3.845469000 10.33.64.242 10.33.1.10 RTP EVENT 58 Payload type=RTP Event, DTMF One 1

SBC is sending DTMF as RTP Events to IVR system
403 3.845471000 10.33.13.9 10.58.2.20 RTP EVENT 58 Payload type=RTP Event, DTMF One 1

However, when IVR system receives it, they get it as
551 88.724062 10.33.13.9 10.58.2.20 RTP 60 PT=DynamicRTP-Type-96, SSRC=0x81346A0C, Seq=169, Time=30560, Mark

Please help me understand what PT=DynamicRTP-Type-96 in passing DTMF?

Sylvester, Prasanth

Sylvester, Prasanth (NSN - IN/Bangalore)

2014-08-12 11:57:09 UTC

Permalink

Hi Joel,

You are the man!

It was wireshark's issue. Changed it to 96 (in preference) & we are good.

Thanks a lot.

Sylvester, Prasanth
+91 959 198 7272

-----Original Message-----
From: ext Joel Gerber [mailto:Joel.Gerber at corp.eastlink.ca]
Sent: Tuesday, August 12, 2014 4:54 PM
To: Sylvester, Prasanth (NSN - IN/Bangalore); sip-implementors at lists.cs.columbia.edu
Subject: RE: SIP - DTMF transfer using RFC2833

I'd be curious to know what the RTP Payload Identifier is for the MSS->SBC and SBC->IVR. I'm guessing they are PT 110. I've seen certain versions of Wireshark that do not properly dynamically decode RTP Event packets when their payload type isn't 110. I usually end up having to "Decode As" RTP packets that don't match. You can also go into your preferences and change the parameter for "RTP Event", named "Payload Type for RFC2833 RTP Events" (rtpevent.event_payload_type_value), but this won't help you when you have multiple payload types for RTP Events in the same capture file.

Now, as to why this is happening, I'm slightly puzzled. You're saying that the SBC (.9) is sending to your IVR (10.58.2.20) and Wireshark is auto-decoding this, but when it's received by your IVR, Wireshark is not decoding them (properly). Based on this, the payload type is different when leaving the SBC then when it is received by the IVR. This should not be possible. So, are all of these packets in the same pcap? Or were these captured into multiple pcaps? If it's the latter, then I expect the same thing that Henning Christiansen is, that the packet capture that received the RTP event (the IVR) might be missing some signaling information. Did you have to "Decode As" the RTP packets in the last hop? If so, did you "Decode As" RTP instead of RTP event?

Joel Gerber
Network Specialist
Network Operations
Eastlink
E: Joel.Gerber at corp.eastlink.ca T: 519.786.1241
-----Original Message-----
From: sip-implementors-bounces at lists.cs.columbia.edu [mailto:sip-implementors-bounces at lists.cs.columbia.edu] On Behalf Of Sylvester, Prasanth (NSN - IN/Bangalore)
Sent: August-11-14 4:31 AM
To: sip-implementors at lists.cs.columbia.edu
Subject: [Sip-implementors] SIP - DTMF transfer using RFC2833

Hi Team,

Good day,
In our deployment, MSS - SBC (Session border Controller) - IVR System MSS/MGW (.242) ---------> (.10) SBC (.9) ----------> IVR (10.58.2.20)
RFC2833 is configured on all ends,

I see MSS is sending the DTMF as RTP Events to SBC
402 3.845469000 10.33.64.242 10.33.1.10 RTP EVENT 58 Payload type=RTP Event, DTMF One 1

SBC is sending DTMF as RTP Events to IVR system
403 3.845471000 10.33.13.9 10.58.2.20 RTP EVENT 58 Payload type=RTP Event, DTMF One 1

However, when IVR system receives it, they get it as
551 88.724062 10.33.13.9 10.58.2.20 RTP 60 PT=DynamicRTP-Type-96, SSRC=0x81346A0C, Seq=169, Time=30560, Mark

Please help me understand what PT=DynamicRTP-Type-96 in passing DTMF?

Sylvester, Prasanth