[Freeswitch-dev] DTMF dropped due to remote party re-starting packet numbers from 0 for each digit
Hi, A 3rd-party is sending each RFC2833 DTMF digit with a new SSRC and starts the packet sequence numbering at ZERO for each new digit. I can see, in switch_rtp.c: handle_rfc2833(), that FS makes a note (in the session) of the last DTMF packet it processed, then drops any subsequent packets with a sequence number less than that. My questions are: 1. Is the remote-party compliant with relevant RFCs when they set a new SSRC for each DTMF digit? 2. Is the remote party compliant with relevant RFCs when they re-start packet sequence numbers from 0 for each DTMF digit? 3. Looking at the source for handle_rfc2833(), I can't see any setting which could be used to force FS to 'tolerate' the above behaviour 4. If I alter handle_rfc2833(), to cope with that behaviour, am I likely to run into problems with other remote systems (E.G. possibly ending up with duplicate digits) Thanks, Andy
Hi Andy - I think: 1 - more not non-compliant, if you see what I mean; 2 - probably, given the change in SSRC 3 - nor could I 4 - I suspect that accepting packets with any sequence number immediately after a change of SSRC should be safe, and it looks like a reasonably straightforward change to handle_rfc2833 to cope with this situation. --Dave On Mon, Jan 18, 2021 at 12:02 PM Andy Newlands <andynewlands@gmail.com> wrote:
Hi,
A 3rd-party is sending each RFC2833 DTMF digit with a new SSRC and starts the packet sequence numbering at ZERO for each new digit.
I can see, in switch_rtp.c: handle_rfc2833(), that FS makes a note (in the session) of the last DTMF packet it processed, then drops any subsequent packets with a sequence number less than that.
My questions are:
1. Is the remote-party compliant with relevant RFCs when they set a new SSRC for each DTMF digit? 2. Is the remote party compliant with relevant RFCs when they re-start packet sequence numbers from 0 for each DTMF digit? 3. Looking at the source for handle_rfc2833(), I can't see any setting which could be used to force FS to 'tolerate' the above behaviour 4. If I alter handle_rfc2833(), to cope with that behaviour, am I likely to run into problems with other remote systems (E.G. possibly ending up with duplicate digits)
Thanks,
Andy _________________________________________________________________________
The FreeSWITCH project is sponsored by SignalWire https://signalwire.com Enhance your FreeSWITCH install with disruptive priced SMS and PSTN services. Build your next product on our scalable cloud platform.
Join our online community to chat in real time https://signalwire.community
Professional FreeSWITCH Services sales@freeswitch.com https://freeswitch.com
Official FreeSWITCH Sites https://freeswitch.com/oss https://freeswitch.org/confluence https://cluecon.com
FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev https://freeswitch.com
Thanks,David. It's always good to have someone else's view. That's encouraging. I'll give that a try. If it works, I wonder if it would be in order to submit the 'fix' as a PR. FYI (for those who may care): this issue relates to Mitel's ACD Softphone. Kind regards, Andy On Mon, 18 Jan 2021 at 17:55, David Knell <david.knell@telng.com> wrote:
Hi Andy -
I think: 1 - more not non-compliant, if you see what I mean; 2 - probably, given the change in SSRC 3 - nor could I 4 - I suspect that accepting packets with any sequence number immediately after a change of SSRC should be safe, and it looks like a reasonably straightforward change to handle_rfc2833 to cope with this situation.
--Dave
On Mon, Jan 18, 2021 at 12:02 PM Andy Newlands <andynewlands@gmail.com> wrote:
Hi,
A 3rd-party is sending each RFC2833 DTMF digit with a new SSRC and starts the packet sequence numbering at ZERO for each new digit.
I can see, in switch_rtp.c: handle_rfc2833(), that FS makes a note (in the session) of the last DTMF packet it processed, then drops any subsequent packets with a sequence number less than that.
My questions are:
1. Is the remote-party compliant with relevant RFCs when they set a new SSRC for each DTMF digit? 2. Is the remote party compliant with relevant RFCs when they re-start packet sequence numbers from 0 for each DTMF digit? 3. Looking at the source for handle_rfc2833(), I can't see any setting which could be used to force FS to 'tolerate' the above behaviour 4. If I alter handle_rfc2833(), to cope with that behaviour, am I likely to run into problems with other remote systems (E.G. possibly ending up with duplicate digits)
Thanks,
Andy _________________________________________________________________________
The FreeSWITCH project is sponsored by SignalWire https://signalwire.com Enhance your FreeSWITCH install with disruptive priced SMS and PSTN services. Build your next product on our scalable cloud platform.
Join our online community to chat in real time https://signalwire.community
Professional FreeSWITCH Services sales@freeswitch.com https://freeswitch.com
Official FreeSWITCH Sites https://freeswitch.com/oss https://freeswitch.org/confluence https://cluecon.com
FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev https://freeswitch.com
_________________________________________________________________________
The FreeSWITCH project is sponsored by SignalWire https://signalwire.com Enhance your FreeSWITCH install with disruptive priced SMS and PSTN services. Build your next product on our scalable cloud platform.
Join our online community to chat in real time https://signalwire.community
Professional FreeSWITCH Services sales@freeswitch.com https://freeswitch.com
Official FreeSWITCH Sites https://freeswitch.com/oss https://freeswitch.org/confluence https://cluecon.com
FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev https://freeswitch.com
participants (2)
-
Andy Newlands
-
David Knell