[Home]

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-0600Date Closed:2015-04-10 18:32:34
Priority:MajorRegression?
Status:Closed/CompleteComponents:Applications/app_confbridge
Versions:Frequency of
Occurrence
Related
Issues:
is caused byASTERISK-24812 ARI: Creating channels through /channels resource always uses SLIN, which results in unneeded transcoding
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/