[asterisk-bugs] [JIRA] (ASTERISK-26143) res_rtp_asterisk: One way audio when transcoding

[Etienne Allovon (JIRA)]

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

Etienne Allovon edited comment on ASTERISK-26143 at 3/22/17 11:35 AM:
----------------------------------------------------------------------

I update the issue with log from 13.14.0 on some precisions following some tests. 

The bug is still present in 13.14.0. An this really is a annoying bug since it means that asterisk is no longer transcoding a call with two different codecs (!)

Attached is 
- sip.conf and extensions.conf to reproduce the problem
- and full log with problem and without problem (core set debug 5, core set verbose 5, sip set debug on, rtp set debug on)

Given I authorize codecA and codecB in asterisk general section in sip.conf
Given I force sipPeerA to codecA
Given I force sipPeerB to codecB
Given sipPeerA calls B *and* given sipPeerA announces boths codecA and codecB in SDP

Then, the bug appears : sipPeerA doesn't hear sipPeerB
{noformat}
         -<-  codecA  ->-          ->- codecB ->- 
sipPeerA                  asterisk               sipPeerB
         -<- *codecB* -<-          -<- codecB -<- 
{noformat}

The problem is that asterisk sends RTP 

Note that there are 2 ways of 'solving'/masking the problem :
- add option {{t}} (or, I guess, any feature option like {{ThH...}}) in dial (see exten 121009 in {{ASTERISK-26143-extensions.conf}}) : in this case, 
- configure sipPeerA to *only* advertise codecA. In this case, asterisk doesn't think it can send RTP 

Additionnal notes :
- between full log with {{t}} option in Dial an without {{t}} option in Dial one of the differences is that with {{t}} option it uses simple_bridge instead of native_bridge
- when it doesn't work, RTP logs show that it sends it to sipPeerA in mode P2P {{res_rtp_asterisk.c: Sent RTP P2P packet to 10.32.5.151:11784 (type 09, len 000160)}}




was (Author: etienne_pf):
I update the issue with log from 13.14.0 on some precisions following some tests. 

The bug is still present in 13.14.0. An this really is a annoying bug since it means that asterisk is no longer transcoding a call with two different codecs (!)

Attached is 
- sip.conf and extensions.conf to reproduce the problem
- and full log with problem and without problem (core set debug 5, core set verbose 5, sip set debug on, rtp set debug on)

Given I authorize codecA and codecB in asterisk general section in sip.conf
Given I force sipPeerA to codecA
Given I force sipPeerB to codecB
Given sipPeerA calls B **and** given sipPeerA announces boths codecA and codecB in SDP

Then, the bug appears : sipPeerA doesn't hear sipPeerB
{noformat}
         -<-  codecA  ->-          ->- codecB ->- 
sipPeerA                  asterisk               sipPeerB
         -<- *codecB* -<-          -<- codecB -<- 
{noformat}

The problem is that asterisk sends RTP 

Note that there are 2 ways of 'solving'/masking the problem :
- add option {{t}} (or, I guess, any feature option like {{ThH...}}) in dial (see exten 121009 in {{ASTERISK-26143-extensions.conf}}) : in this case, 
- configure sipPeerA to *only* advertise codecA. In this case, asterisk doesn't think it can send RTP 

Additionnal notes :
- between full log with {{t}} option in Dial an without {{t}} option in Dial one of the differences is that with {{t}} option it uses simple_bridge instead of native_bridge
- when it doesn't work, RTP logs show that it sends it to sipPeerA in mode P2P {{res_rtp_asterisk.c: Sent RTP P2P packet to 10.32.5.151:11784 (type 09, len 000160)}}



> res_rtp_asterisk: One way audio when transcoding
> ------------------------------------------------
>
>                 Key: ASTERISK-26143
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26143
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_rtp_asterisk
>    Affects Versions: 13.7.2, 13.9.1, 13.11.0
>         Environment: Ubuntu 12.04 x86_64, Ubuntu 14.04 x86_64, Yocto 1.5 i686
>            Reporter: Henning Holtschneider
>            Assignee: Unassigned
>         Attachments: ASTERISK-26143-extensions.conf, ASTERISK-26143-full-without-t-NOK, ASTERISK-26143-full-with-t-OK, ASTERISK-26143-sip.conf, call-g711-to-g722-ok.txt, call-g722-to-g711-unsupported-payload.txt
>
>
> This is essentially the same issue as ASTERISK-25197, but that issue has been closed due to inactivity and I am not the original reporter.
> I tried both Asterisk 13.7.2 and 13.9.1 on different machines with different Linux environments with the same result:
> When making a call with a higher-quality codec to a destination with a lower-quality codec, e.g. G.722 to ALAW, Asterisk tries to set up a native bridge, fails to decode the lower-quality RTP coming from the called party and the line is silent at the caller's end.
> Setting up the call with a lower-quality codec to a called party with a higher-quality codec works fine.
> I tried with codecs ALAW, G.722 and G.729 all with the same result. I made calls between chan_sip peers and between chan_sip peers and PJSIP endpoints all with the same result.



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