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

[Asterisk Team (JIRA)]

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

Asterisk Team commented on ASTERISK-26736:
------------------------------------------

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

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