[asterisk-dev] BUGFIX: main/rtp.c bridge_p2p_rtp_write() fix inbound payload type validity check

[Tony Redstone]

Hi,

Could anyone comment on how I should go about getting this fix into
asterisk?  I raised an issue on bugs.digium.com (#12955) but it
doesn't appear to have attracted any interest.

Regards,
Tony

On Fri, Jun 20, 2008 at 5:03 PM, Tony Redstone
<tony.redstone at googlemail.com> wrote:
> Hi,
>
> After experiencing some upstream DTMF detection issues caused by RTP
> audio and RTP telephony-event packets having different SSRC ids when
> passing calls with rfc2833 signalling through an asterisk 1.4 box (sip
> to sip), I believe I've tracked down the issue to the following bit of
> code near the start of bridge_p2p_rtp_write():
>
>       /* If the payload coming in is not one of the negotiated ones
> then send it to the core, this will cause formats to change and the
> bridge to break */
>       if (!bridged->current_RTP_PT[payload].code)
>               return -1;
>
> The issue is that the code doesn't seem to match the comment.  The
> value of "payload" is from the incoming RTP packet and the (struct
> ast_rtp *) bridged structure is for the outbound leg so attempting to
> lookup the incoming payload type in the outbound payload type array
> doesn't seem to make sense.  I think the code should read:
>
>       /* If the payload coming in is not one of the negotiated ones
> then send it to the core, this will cause formats to change and the
> bridge to break */
>       if (!rtp->current_RTP_PT[payload].code)
>               return -1;
>
> (where rtp is the ast_rtp struct for the inbound leg)
>
> Now the code matches the comment and also my DTMF detection problem is
> resolved.  The issue occurs with 1.4 and 1.6 (but not 1.2 which uses
> substantially different bridging code).
>
> Does this fix make sense?    A patch and full explanation of the DTMF
> detection problem are listed below.
>
> Regards,
> Tony
>
> --- main/rtp.c.orig     2008-05-14 22:32:00.000000000 +0100
> +++ main/rtp.c  2008-06-20 15:48:44.000000000 +0100
> @@ -1063,7 +1063,7 @@
>        rtpPT = ast_rtp_lookup_pt(rtp, payload);
>
>        /* If the payload coming in is not one of the negotiated ones then
> send it to the core, this will cause formats to change and the bridge
> to break */
> -       if (!bridged->current_RTP_PT[payload].code)
> +       if (!rtp->current_RTP_PT[payload].code)
>                return -1;
>
>        /* If the payload is DTMF, and we are listening for DTMF - then feed
> it into the core */
>
>
>
> For those interested, the reason DTMF detection can be impacted is as
> follows: A Thomson Speedtouch 780WL router with SIP functionality is
> configured to make calls through an asterisk 1.4 box.  The speedtouch
> router uses rtp payload type 97 for telephony-event.  Asterisk,
> however, uses 101 for telephony-event.  When a call is originated from
> the speedtouch router out through the asterisk 1.4 box to an upstream
> SIP trunk, DTMF detection does not work (with an IVR application
> further upstream).  If the speedtouch router is replaced with a unit
> which uses payload type 101 for telephony-event, it works.  After
> debugging with wireshark, the issue is because since the speedtouch
> uses 97 for telephony-event, when a DTMF tone is rfc2833 signalled
> from the speedtouch, the code above attempts and fails to locate
> payload type 97 in the outbound bridged payload type array (which
> logically would be expected) and therefore returns -1 and rtp
> processing returns to ast_rtp_read().  ast_rtp_senddigit_begin() is
> eventually called to insert the DTMF into the RTP stream.  At first
> glance, this still looks okay but the asterisk regenerated DTMF was
> not being detected further upstream.  This was because the SSRC id
> used for the RTP audio and for the RTP DTMF events is now different.
> For the RTP audio, the bridging code effectively copies the SSRC id
> from the inbound leg whereas the SSRC id for RTP DTMF event is
> asterisk's locally generated SSRC id.  Therefore, the upstream IVR
> application (for example, a British Telecom call centre number) is not
> processing the DTMF events (even though it is almost certainly
> receiving them).  By making the change above, the bridging code now
> uses the same SSRC id for both RTP audio and RTP DTMF and the upstream
> IVR application works.
>