[Freeswitch-users] problems with bridging a call, looks like transcoding is disabled
Roman Kudinov
roman.kudinov at novelapp.com
Tue Feb 16 20:53:41 MSK 2016
Hi Brian,
I saw this variable but looks like used it the wrong way. Thanks for the
help, the codecs negotiation works properly now!
16.02.2016 19:16, Brian West:
> This topic was talked about on the list in the past week:
> https://freeswitch.org/jira/browse/FS-8321
>
> "BEHAVIOR CHANGE Add variable media_mix_inbound_outbound_codecs to mix
> inbound and outbound codecs"
>
> /b
>
> On Tue, Feb 16, 2016 at 6:40 AM, Roman Kudinov
> <roman.kudinov at novelapp.com <mailto:roman.kudinov at novelapp.com>> wrote:
>
> Hi all,
>
> I have a problem with bridging a call. My FS 1.6.6 is setup to
> bridge calls from RTMP-based source (using mod_rtmp) to a SIP gateway.
> I have two branches in the dial plan.
>
> 1) One works through mod_conference which calls an outbound number
> using conference_set_auto_outcall
>
> 2) Another works by the direct bridging of incoming rtmp call into
> outbound SIP call.
>
> Whilst the first branch works just fine, the second one does not.
> They both use the same sofia profiles, SIP gateways and outbound
> SIP numbers.
> They both are called from the same RTMP source. Here are the
> snippet of codes.
>
> ================== This one works ====================================
> > <extension name="conference_set_auto_outcall">
> > <condition field="destination_number" expression="123">
> > <action application="answer"/>
> > <action application="set"
> data="conference_auto_outcall_caller_id_name=$${effective_caller_id_name}"/>
> > <action application="set"
> data="conference_auto_outcall_caller_id_number=$${effective_caller_id_number}"/>
> > <action application="set"
> data="conference_auto_outcall_profile=default"/>
> > <action application="conference_set_auto_outcall"
> data="{ignore_early_media=true}sofia/gateway/sip_profile/number"/>
> > <action application="conference"
> data="$1+flags{moderator|endconf|mute}"/>
> > </condition>
> > </extension>
> ===================================================
>
> ================ This one does not work ================
> > <extension name="phone_only_session">
> > <condition field="destination_number" expression="456">
> > <action application="set" data="ignore_early_media=true"/>
> > <action application="set"
> data="absolute_codec_string=PCMU,PCMA,opus"/>
> > <action application="bridge"
> data="sofia/gateway/sip_profile/number"/>
> > </condition>
> > </extension>
> ========================
>
> I'd like to outline that they use the same SIP profiles, they are
> called from the same RTMP-source (they differs by the
> destination_number), they
> call the same SIP number.
> I turned on SIP tracing on and found that the call that is
> initiated by mod_conference offers the codecs according to
> outbound_codec_prefs set
> in vars.xml, here is the piece of log:
> > m=audio 18684 RTP/AVP 0 102 103 104 105 8 101 106 108 110
> > a=rtpmap:0 PCMU/8000
> > a=rtpmap:102 SPEEX/8000
> > a=rtpmap:103 SPEEX/16000
> > a=rtpmap:104 SPEEX/32000
> > a=rtpmap:105 opus/48000/2
> > a=fmtp:105 useinbandfec=1; maxaveragebitrate=30000;
> maxplaybackrate=48000; ptime=20; minptime=10; maxptime=40
> > a=rtpmap:8 PCMA/8000
> > a=rtpmap:101 telephone-event/8000
> > a=fmtp:101 0-16
> > a=rtpmap:106 telephone-event/16000
> > a=fmtp:106 0-16
> > a=rtpmap:108 telephone-event/32000
> > a=fmtp:108 0-16
> > a=rtpmap:110 telephone-event/48000
> > a=fmtp:110 0-16
> > a=ptime:20
>
> But the directly bridged call offers incoming codec only, e.g. speex
> > m=audio 24972 RTP/AVP 102 101
> > a=rtpmap:102 SPEEX/16000
> > a=rtpmap:101 telephone-event/16000
> > a=fmtp:101 0-16
> > a=ptime:20
>
> I tried everything I could imagine. I set absolute_codec_string in
> the dialplan (you can see it in the above snippet).
> I explicitly set
> > <X-PRE-PROCESS cmd="set"
> data="outbound_codec_prefs=PCMU,G722,OPUS,PCMA"/>
> in vars.xml
>
> I tried to change
> > <param name="inbound-codec-negotiation" value="generous"/>
> from generous to greedy
>
> I tried with true/false in the following parameters in
> internal.xml and
> external.xml SOFIA profiles
> > <param name="inbound-late-negotiation" value="false"/>
> > <param name="inbound-zrtp-passthru" value="false"/>
> Nothing changes.
>
> Moreover the direct bridging worked fine on FS 1.4.7, it offered
> PCMU and Speex codecs to SIP.
> I've upgraded to FS 1.6.6 and now it doesn't work. It looks like I
> missed an important setting that makes "bridge" application to work in
> proxy media mode.
> I checked I don't have neither bypass or proxy words in vars.xml,
> sofia.conf.xml, internal.xml, external.xml, public.xml or they are
> commented.
>
> Does anybody have any ideas about the reason for such behavior?
>
>
> Thanks,
> Roman
>
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org <mailto: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
> <mailto: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
>
>
>
>
> --
>
> */Brian West/*
> brian at freeswitch.org <mailto:brian at freeswitch.org>
>
>
> */Twitter: @FreeSWITCH , @briankwest/*
> http://www.freeswitchbook.com
> http://www.freeswitchcookbook.com
>
> Got Bugs? Report them here <https://freeswitch.org/jira>! | Reddit:
> /r/freeswitch <https://www.reddit.com/r/freeswitch>
>
> *T:*+19184209001 | *F:*+19184209002 | *M:*+1918424WEST (9378)
> *iNUM:*+883 5100 1420 9001 | *ISN:*410*543 | *Skype:*briankwest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20160216/fc09b70c/attachment.html
Join us at ClueCon 2016 Aug 8-12, 2016
More information about the FreeSWITCH-users
mailing list