[asterisk-bugs] [JIRA] (ASTERISK-24841) ConfBridge: Strange sampling rates chosen when channels have multiple native formats

[Joshua Colp (JIRA)]

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

Joshua Colp commented on ASTERISK-24841:
----------------------------------------

This problem occurs because the bridge_softmix module is currently configured to only accept signed linear at 8000Hz. When a channel with multiple native formats (g722 and ulaw) is joined the code determines the best path is from ulaw to signed linear at 8000Hz and vice versa. The raw format is changed to ulaw and ulaw is sent to the remote endpoint. When the channel actually reaches bridge_softmix it determines that, based on the raw format, it should use 8000Hz and continues doing so.

> ConfBridge: Strange sampling rates chosen when channels have multiple native formats
> ------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-24841
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-24841
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/app_confbridge
>            Reporter: Matt Jordan
>
> Say we have two PJSIP channels who are configured with {{allow=!all,g722,ulaw,alaw}}. When two or more channels enter into a ConfBridge configured with this - and when their native format capabilities are allowed to represent the joint capabilities of the offered SDP + the endpoint's configuration - ConfBridge and/or {{bridge_softmix}} makes some poor decisions on the transcoding paths made.
> Note that this was introduced in r432195 in {{res_pjsip_sdp_rtp}}.
> For example, the following is what "core show channels" outputs for the two channels *without the specified revision applied*
> {noformat}
> *CLI> core show channel PJSIP/201-00000002 
>  -- General --
>            Name: PJSIP/201-00000002
>            Type: PJSIP
>        UniqueID: 1425319590.8
>        LinkedID: 1425319590.8
>       Caller ID: 54321
>  Caller ID Name: Kram
> Connected Line ID: (N/A)
> Connected Line ID Name: (N/A)
> Eff. Connected Line ID: (N/A)
> Eff. Connected Line ID Name: (N/A)
>     DNID Digits: (N/A)
>        Language: en
>           State: Up (6)
>   NativeFormats: (g722)
>     WriteFormat: slin16
>      ReadFormat: slin16
>  WriteTranscode: Yes (slin at 16000)->(g722 at 16000)
>   ReadTranscode: Yes (g722 at 16000)->(slin at 16000)
>  Time to Hangup: 0
>    Elapsed Time: 0h0m27s
>       Bridge ID: b118cb8b-bfcd-4418-9b6d-e9404e3593c5
>  --   PBX   --
>         Context: default
>       Extension: 100
>        Priority: 1
>      Call Group: 0
>    Pickup Group: 0
>     Application: ConfBridge
>            Data: hello
>  Call Identifer: [C-00000002]
>       Variables:
> BRIDGEPVTCALLID=YMNZlXZqaVp9OAGcaXEKZPq6kzK6TAX6
> BRIDGEPEER=PJSIP/202-00000003
>   CDR Variables:
> level 1: calledsubaddr=
> level 1: callingsubaddr=
> level 1: dnid=
> level 1: clid="Kr
> level 1: src=543
> level 1: dst=100
> level 1: dcontext=def
> level 1: channel=PJS
> level 1: dstchannel=PJS
> level 1: lastapp=Con
> level 1: lastdata=hel
> level 1: start=142
> level 1: answer=142
> level 1: end=0.0
> level 1: duration=26
> level 1: billsec=26
> level 1: disposition=1
> level 1: amaflags=3
> level 1: uniqueid=142
> level 1: linkedid=142
> level 1: sequence=2
> {noformat}
> The other involved channel looks mostly the same, just with different identifiers.
> Here is what "core show channels" displays *with the revision applied*
> {noformat}
> *CLI> core show channel PJSIP/201-00000000 
>  -- General --
>            Name: PJSIP/201-00000000
>            Type: PJSIP
>        UniqueID: 1425319903.2
>        LinkedID: 1425319903.2
>       Caller ID: 54321
>  Caller ID Name: Kram
> Connected Line ID: (N/A)
> Connected Line ID Name: (N/A)
> Eff. Connected Line ID: (N/A)
> Eff. Connected Line ID Name: (N/A)
>     DNID Digits: (N/A)
>        Language: en
>           State: Up (6)
>   NativeFormats: (g722|ulaw|alaw)
>     WriteFormat: slin
>      ReadFormat: slin
>  WriteTranscode: Yes (slin at 8000)->(ulaw at 8000)
>   ReadTranscode: Yes (ulaw at 8000)->(slin at 8000)
>  Time to Hangup: 0
>    Elapsed Time: 0h0m44s
>       Bridge ID: 1b81ebed-d41f-4294-891a-77f68c1e5042
>  --   PBX   --
>         Context: default
>       Extension: 100
>        Priority: 1
>      Call Group: 0
>    Pickup Group: 0
>     Application: ConfBridge
>            Data: hello
>  Call Identifer: [C-00000000]
>       Variables:
> BRIDGEPVTCALLID=CFtt3zKX2rmJH45IV.nrG5vGX2z.hcxZ
> BRIDGEPEER=PJSIP/202-00000001
>   CDR Variables:
> level 1: calledsubaddr=
> level 1: callingsubaddr=
> level 1: dnid=
> level 1: clid="Kr
> level 1: src=543
> level 1: dst=100
> level 1: dcontext=def
> level 1: channel=PJS
> level 1: dstchannel=PJS
> level 1: lastapp=Con
> level 1: lastdata=hel
> level 1: start=142
> level 1: answer=142
> level 1: end=0.0
> level 1: duration=44
> level 1: billsec=44
> level 1: disposition=1
> level 1: amaflags=3
> level 1: uniqueid=142
> level 1: linkedid=142
> level 1: sequence=0
> {noformat}
> Notice that the bad version has slin instead of slin16 as the read and write formats on the channel and has slin->ulaw as the transcode instead of slin16->g722.



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