[asterisk-bugs] [JIRA] (ASTERISK-26736) PJSIP: one way audio

[Joshua Colp (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-26736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Joshua Colp closed ASTERISK-26736.
----------------------------------

    Resolution: Duplicate

A change has gone into the 13 and 14 branches which should resolve this issue already. You can test using those branches or wait for the next release. If the problem is still not resolved on those please provide new log information including console output, SIP traffic (pjsip set logger on), RTP (rtp set debug on), and configuration.

> PJSIP: one way audio
> --------------------
>
>                 Key: ASTERISK-26736
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26736
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_pjsip
>    Affects Versions: 13.13.1, 14.2.1
>         Environment: Centos 6 64bit
> FreePBX 13.0.190.7
>            Reporter: Michael Maier
>
> Given is the following incoming call:
> caller via trunk from ISP: INVITE:   g722/alaw/ulaw
> trunk definition:                             g722/alaw/ulaw/...
> Asterisk def. for extension:            INVITE alaw/ulaw/... (g722 is not allowed)
> Gigaset C610IP: g722/alaw/ulaw   g722 is allowed
> Result: one way audio! What's happening (I've got a trace!)
> Between C610IP and Asterisk: alaw.
> Asterisk tells to ISP via 200 OK SDP: g722/alaw/ulaw but does send alaw rtp! ISP sends g722 (as advertised by 200 OK). 
> Effect: Caller couldn't hear me, but I could hear him. No reinvite from caller appears!
> Quick fix was to allow g722 for the extension C610IP in asterisk: change from alaw/ulaw/... to g722/alaw/ulaw/...
> Internally I easily can reproduce this special behavior between two extensions every time:
> Gigaset C610IP:                      g722/alaw/ulaw
> extension 1 def. in Asterisk:    g722/alaw/ulaw
> extension 2 def. in Asterisk:    g722/alaw/gsm
> extension 2/Zoiper:                  gsm/alaw
> Now, lets call C610IP to Zoiper:
> C610IP INVITE:                             g722/alaw/ulaw
> Asterisk INVITE to Zoiper:             g722/alaw/gsm
> Zoiper 200 OK SDP:                     g711/gsm
> Asterisk 200 OK SDP to C610IP:  g722/alaw/ulaw
> RTP-streams between Asterisk and Zoiper: both alaw.
> RTP-streams between Asterisk and C610IP: from Asterisk to C610IP: alaw
>                                                                       from C610IP to Asterisk: g722
> => C610IP can't handle two different RTP-types at the same time, therefore it sends a reinvite to force Asterisk to send g722, two. Which is done subsequently by Asterisk to "repair" the situation.
> What's the problem?
> Pjsip on the one hand advertises codecs which aren't reflected by asterisk on the other hand (or vice versa): advertising g722 but sending alaw isn't a good idea, because obviously not each UA is able to cover this situation.
> Besides that, it isn't a good idea to use 2 different codecs between two UAs, if there is a common codec both UAs know off and which would prevent unnecessary transcoding.
> Shouldn't it be like this:
> Asterisk never should advertise a codec that is known to be not a common codec? This means related to the second example above: Asterisk shouldn't advertise g722 in the 200 OK because it correctly does not want to have g722 but alaw to prevent transcoding.
> Related to the first example (real one way audio situation), the problem most probably wouldn't have occurred if Asterisk wouldn't have sent g722/alaw/ulaw in the 200 OK to the ISP but alaw/ulaw or just alaw.



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