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.ger...@corp.eastlink.ca] Sent: Tuesday, August 12, 2014 4:54 PM To: Sylvester, Prasanth (NSN - IN/Bangalore); sip-implementors@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.ger...@corp.eastlink.ca T: 519.786.1241 -----Original Message----- From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Sylvester, Prasanth (NSN - IN/Bangalore) Sent: August-11-14 4:31 AM To: sip-implementors@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 _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
