[Freeswitch-users] BEARERCAPABILITY_NOTAVAIL with 1.6.6 on Debian 8

Tue May 31 19:14:01 MSD 2016

media_mix_inbound_outbound_code=true

https://freeswitch.org/confluence/display/FREESWITCH/Codec+Negotiation#CodecNegotiation-MixingMedia/Codecsondifferentlegs(transcoding) <https://freeswitch.org/confluence/display/FREESWITCH/Codec+Negotiation#CodecNegotiation-MixingMedia/Codecsondifferentlegs(transcoding)>

> On May 31, 2016, at 9:41 AM, Kim Rostgaard Christensen <krc at retrospekt.dk> wrote:
> 
> We've had a sort-a breakthrough:
> 
> If we override the codec string
> originate loopback/5900/default &bridge({absolute_codec_string='PCMA,PCMU'}sofia/gateway/gw/number)
> 
> We can get the gateway to accept our call. This is most like due to them not supporting L16 - which makes the BEARERCAPABILITY_NOTAVAIL make sense. Yay!
> 
> SDP then becomes:
> 
> v=0
> o=FreeSWITCH 1464414375 1464414376 IN IP4 192.168.1.4
> s=FreeSWITCH
> c=IN IP4 192.168.1.4
> t=0 0
> m=audio 24744 RTP/AVP 8 101
> a=rtpmap:8 PCMA/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=ptime:20
> 
> And everything is fine. Sound comes through, and connection is stable.
> 
> This raises two questions:
> 
> 1. We would really like the default behaviour to use PCMA/8000 for outbound bridged channels.
> How do we go about this?
> 
> 2. Is this intended that a minor release should have such large impact on the SDP and, if so, can anyone elaborate on this?
> 
> Best
> Kim
> 
> 
> On 2016-05-27 16:32, Kim Rostgaard Christensen wrote:
>> We finally got around to getting a SIP trace.
>> 
>> The only difference we can find is in the SDP
>> 
>> 1.6.2:
>> 
>> v=0 
>> o=FreeSWITCH 1464328347 1464328348 IN IP4 192.168.1.3 
>> s=FreeSWITCH 
>> c=IN IP4 192.168.1.3 
>> t=0 0 
>> m=audio 28898 RTP/AVP 102 103 9 0 8 3 101 13 104 105 
>> a=rtpmap:102 L16/8000 
>> a=rtpmap:103 opus/48000/2 
>> a=fmtp:103 useinbandfec=1; usedtx=1; maxaveragebitrate=30000; maxplaybackrate=48000; ptime=20; minptime=20; maxptime=20; samplerate=48000; sprop-stereo=1 
>> a=rtpmap:9 G722/8000 
>> a=rtpmap:0 PCMU/8000 
>> a=rtpmap:8 PCMA/8000 
>> a=rtpmap:3 GSM/8000 
>> a=rtpmap:101 telephone-event/8000 
>> a=fmtp:101 0-16 
>> a=rtpmap:13 CN/8000 
>> a=rtpmap:104 telephone-event/48000 
>> a=fmtp:104 0-16 
>> a=rtpmap:105 CN/48000 
>> a=ptime:20 
>> 
>> 1.6.8:
>> 
>> v=0 
>> o=FreeSWITCH 1464330840 1464330841 IN IP4 192.168.1.4 
>> s=FreeSWITCH 
>> c=IN IP4 192.168.1.4 
>> t=0 0 
>> m=audio 28118 RTP/AVP 102 101 13 
>> a=rtpmap:102 L16/8000 
>> a=rtpmap:101 telephone-event/8000 
>> a=fmtp:101 0-16 
>> a=rtpmap:13 CN/8000 
>> a=ptime:20 
>> 
>> 
>> Any hints?
>> 
>> 
>> On 2016-02-10 18:16, Thomas Løcke wrote:
>>> Hi Ken,
>>> 
>>> It doesn't work from our dialplan either:
>>> 
>>> <extension name="foobar" continue="true">
>>>       <condition field="destination_number" expression="^external_transfer_(\d+)$">
>>>         <action application="set" data="ringback=${dk-ring}"/>
>>>         <action application="ring_ready" />
>>>         <action application="bridge" data="[fifo_music=default]sofia/gateway/${default_trunk}/$1"/>
>>>         <action application="hangup"/>
>>>       </condition>
>>>     </extension>
>>> 
>>> That works swimmingly with 1.6.2, but fails with BEARERCAPABILITY_NOTAVAIL with 1.6.6.
>>> 
>>> 
>>> 2016-02-10 18:07 GMT+01:00 Ken Rice <krice at freeswitch.org <mailto:krice at freeswitch.org>>:
>>> I doubt that was ever an intended feature... why not just send the A leg out and park the bleg just reverse your notation there
>>> 
>>> On Wed, Feb 10, 2016 at 10:48 AM, Thomas Løcke < <mailto:thomas.granvej6 at gmail.com>thomas.granvej6 at gmail.com <mailto:thomas.granvej6 at gmail.com>> wrote:
>>> Hi all,
>>> 
>>> Using 1.6.2 this works from fs_cli and dialplan:
>>> 
>>> originate loopback/park/default &bridge(sofia/gateway/server/xxxxxxxx)
>>> 
>>> Using 1.6.6 it fails with BEARERCAPABILITY_NOTAVAIL.
>>> 
>>> 
>>> _________________________________________________________________________
>>> Professional FreeSWITCH Consulting Services: 
>>> consulting at freeswitch.org <mailto:consulting at freeswitch.org>
>>> http://www.freeswitchsolutions.com <http://www.freeswitchsolutions.com/>
>>> 
>>> Official FreeSWITCH Sites
>>> http://www.freeswitch.org <http://www.freeswitch.org/>
>>> http://confluence.freeswitch.org <http://confluence.freeswitch.org/>
>>> http://www.cluecon.com <http://www.cluecon.com/>
>>> 
>>> FreeSWITCH-users mailing list
>>> FreeSWITCH-users at lists.freeswitch.org <mailto:FreeSWITCH-users at lists.freeswitch.org>
>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users <http://lists.freeswitch.org/mailman/listinfo/freeswitch-users>
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users <http://lists.freeswitch.org/mailman/options/freeswitch-users>
>>> http://www.freeswitch.org <http://www.freeswitch.org/>
> 
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services: 
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
> 
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://confluence.freeswitch.org
> http://www.cluecon.com
> 
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20160531/9fc800fb/attachment-0001.html