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

[Michael Maier (JIRA)]

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

Michael Maier commented on ASTERISK-26736:
------------------------------------------

Thanks for the patch. The patch fixes the above described problem partly:
Fixed is the difference between PJSIP on the one hand and Asterisks own rtp-part sending on the other hand. This means: Asterisk now uses the codec accordingly the primary codec in the 200 OK SDP sent to the caller: Now, Asterisk uses the same codec as the caller (g722).

The second part of the bug report is not addressed by this patch: Asterisk / PJSIP should not send g722 in the 200 OK SDP to the caller as codec at all, because callee doesn't support it. Asterisk now has to transcode between them although there is a common codec (alaw), which both UAs support w/o transcoding.
The patch unfortunately went the wrong way to resolve the "difference" problem: Asterisks decision without this change to use alaw to C610IP was correct. But the 200 OK SDP w/o removing g722 was wrong. The 200 OK SDP from Asterisk to 610IP should contain as codecs alaw/ulaw and not g722/alaw/ulaw - because alaw is the preferred codec in this case, if one of the UAs doesn't support g722 to prevent transcoding.

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