[Freeswitch-dev] DTMF dropped due to remote party re-starting packet numbers from 0 for each digit

[Andy Newlands]

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 at 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 at 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 at 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 at 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 at 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 at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> https://freeswitch.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20210119/0dd41bea/attachment.html>