[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.
----------------------------------


The behavior you are asking for has been asked for a few times in the past, and it is not something to be done in PJSIP. It is a core change required to convey that information across upon answer. Right now the caller doesn't know what the callee actually negotiated. Each side is done independently. If you'd like to discuss how to implement it that can be done on the asterisk-dev mailing list. We currently don't accept feature requests such as that on the issue tracker though.

> 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)