Summary: | ASTERISK-24841: ConfBridge: Strange sampling rates chosen when channels have multiple native formats | ||||
Reporter: | Matt Jordan (mjordan) | Labels: | |||
Date Opened: | 2015-03-02 13:13:44.000-0600 | Date Closed: | 2015-04-10 18:32:34 | ||
Priority: | Major | Regression? | |||
Status: | Closed/Complete | Components: | Applications/app_confbridge | ||
Versions: | Frequency of Occurrence | ||||
Related Issues: |
| ||||
Environment: | Attachments: | ||||
Description: | 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@16000)->(g722@16000) ReadTranscode: Yes (g722@16000)->(slin@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@8000)->(ulaw@8000) ReadTranscode: Yes (ulaw@8000)->(slin@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. | ||||
Comments: | By: Joshua C. Colp (jcolp) 2015-03-07 10:53:49.155-0600 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. By: Richard Mudgett (rmudgett) 2015-04-09 16:16:57.908-0500 Patches on reviewboard: https://reviewboard.asterisk.org/r/4609/ Also: https://reviewboard.asterisk.org/r/4600/ https://reviewboard.asterisk.org/r/4605/ |