[asterisk-bugs] [JIRA] (ASTERISK-24518) Avaya Asterisk sip trunk DTMF mis negotiated

[Michael L. Young (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-24518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=223979#comment-223979 ] 

Michael L. Young edited comment on ASTERISK-24518 at 12/10/14 11:44 AM:
------------------------------------------------------------------------

One thing that might be causing a difference would be this patch: ASTERISK-23279.  Asterisk now respects the requested RTP mapping as of version 11.9.

I am noticing in the packet capture that when DTMF is being sent to Asterisk, the Avaya system is using a different sequence numbering base for DTMF.  With the above mentioned change in mind, could it be that the Avaya system handles RTP dynamic payload type 127 differently than type 101 as far as sequence numbers are concerned?  Now that Asterisk is respecting payload 127 instead of negotiating 101, that could be causing the issue you are having.  It might be good to compare a pcap from the Avaya to a box running Asterisk 11.5.1 to see what it is doing with the sequence number to see if that is the case or not.

According to RFC2833 in section 3.1:
{quote}
DTMF digits and named telephone events are carried as part of the
   audio stream, and MUST use the same sequence number and time-stamp
   base as the regular audio channel to simplify the generation of audio
   waveforms at a gateway. The default clock frequency is 8,000 Hz, but
   the clock frequency can be redefined when assigning the dynamic
   payload type.
{quote}

I just thought I would throw this out there... since the sequence numbers are different, that might be why Asterisk is ignoring those packets.  Just a theory that has been kicking around in my head.


was (Author: elguero):
One thing that might be causing a difference would be this patch: ASTERISK-23279.  Asterisk now respects the requested RTP mapping as of version 11.9.

I am noticing in the packet capture that when DTMF is being sent to Asterisk, the Avaya system is changing the sequence number for those streams.  With the above mentioned change in mind, could it be that the Avaya system handles RTP dynamic payload type 127 differently than type 101 as far as sequence numbers are concerned?  Now that Asterisk is respecting payload 127 instead of negotiating 101, that could be causing the issue you are having.  It might be good to compare a pcap from the Avaya to a box running Asterisk 11.5.1 to see what it is doing with the sequence number to see if that is the case or not.

According to RFC2833 in section 3.1:
{quote}
DTMF digits and named telephone events are carried as part of the
   audio stream, and MUST use the same sequence number and time-stamp
   base as the regular audio channel to simplify the generation of audio
   waveforms at a gateway. The default clock frequency is 8,000 Hz, but
   the clock frequency can be redefined when assigning the dynamic
   payload type.
{quote}

I just thought I would throw this out there... since the sequence numbers are different, that might be why Asterisk is ignoring those packets.  Just a theory that has been kicking around in my head.

> Avaya Asterisk sip trunk DTMF mis negotiated
> --------------------------------------------
>
>                 Key: ASTERISK-24518
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-24518
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/app_read
>    Affects Versions: 11.12.0
>         Environment: Centos 6.4
>            Reporter: Jonathan White
>            Assignee: Rusty Newton
>         Attachments: capture201412061210.pcap, full
>
>
> I am upgrading from Asterisk ver 11.5.1 to 11.12.0
> An existing sip trunk is built from an Avaya Session Manager V6 to Asterisk
> rfc2833 is configured in sip.conf
> Asterisk V 11.5.1 negotiates and receives DTMF correctly (RTP type 101)
> Asterisk V 11.12.0 Does not receive DTMF but shows (RTP type 127)
> The Sip.conf and rtp.conf files are the same. There is no change to the Avaya configuration
> I have tried auto and inband in the sip.conf to see if I can match type 127 but this does not work either.



--
This message was sent by Atlassian JIRA
(v6.2#6252)