[Freeswitch-users] 180/183 not passed through sip profiles

Fri Oct 27 11:53:05 UTC 2017

Hi,

Not sure that it will help, but I think something similar was discussed
here:

http://lists.freeswitch.org/pipermail/freeswitch-users/2012-May/083985.html

I would recommend you to set ignore_early_media inside bridge something
like this:

<action application="bridge"
data="{ignore_early_media=true}sofia/test-int/1001 at somebox,sofia/test-int/1000 at somehost"/>

Additionally you can try to send 180 or 183 for all calls or execute it
based on event(please check freeswitch events), never tried though, but it
may work.

Off cause you can try to move to one profile only...

With kind regards,

Jurijs

On Fri, Oct 27, 2017 at 12:39 PM, Grant Bagdasarian <gb at cm.nl> wrote:

> That’s actually not true, the other FS instance uses bypass-media true.
>
>
>
> *From:* FreeSWITCH-users [mailto:freeswitch-users-
> bounces at lists.freeswitch.org] *On Behalf Of *Grant Bagdasarian
> *Sent:* vrijdag 27 oktober 2017 11:36
>
> *To:* FreeSWITCH Users Help <freeswitch-users at lists.freeswitch.org>
> *Subject:* Re: [Freeswitch-users] 180/183 not passed through sip profiles
>
>
>
> Hi Mirko,
>
>
>
> I’ll try that.
>
>
>
> To answer Alexandr Popov’s comment, we also have a FS instance running
> with just a single sip profile that also does a bridge to an endpoint on
> the internet, but uses SIP-ALG provided by our firewall, which works just
> fine. Not sure if this is related to multiple sip profiles. That’s the only
> difference between the two.
>
>
>
> Regards,
>
>
>
> Grant
>
>
>
> *From:* FreeSWITCH-users [mailto:freeswitch-users-
> bounces at lists.freeswitch.org
> <freeswitch-users-bounces at lists.freeswitch.org>] *On Behalf Of *Mirko
> Brankovic
> *Sent:* vrijdag 27 oktober 2017 11:30
> *To:* FreeSWITCH Users Help <freeswitch-users at lists.freeswitch.org>
> *Subject:* Re: [Freeswitch-users] 180/183 not passed through sip profiles
>
>
>
> Hi,
>
> Have you tried with bridge_early_media=false, since in pproxy_mode
> everything that has to do with live media will fail?
>
>
>
> --mirko
>
>
>
> On Fri, Oct 27, 2017 at 9:45 AM, Grant Bagdasarian <gb at cm.nl> wrote:
>
> Hi,
>
>
>
> We’re using a freeswitch which bridges calls between two networks: private
> and public. The server has two interfaces. The calls originate from the
> private network and are bridged using the public sip profile.
>
> For some reason I cannot get the 180 and 183 messages passed back from the
> outbound leg to the inbound leg when sending calls over the public sip
> profile.
>
>
>
> Both sip profiles have been set with:
>
>     <param name="inbound-bypass-media" value="false"/>
>
>     <param name="inbound-proxy-media" value="true"/>
>
>
>
> The below dialplan is hit when a call arrives on the LAN(private)
> interface of the freeswitch.
>
>
>
> <?xml version="1.0" encoding="utf-8"?>
>
> <include>
>
>   <context name="local">
>
>     <extension name="route_to_public">
>
>       <condition field="destination_number" expression="(\d+)$"
> require-nested="false">
>
>         <action application="set" data="bridge_early_media=true" />
>
>         <action application="set" data="hangup_after_bridge=true"/>
>
>         <action application="set" data="continue_on_fail=false"/>
>
>         <action application="set" data="ignore_early_media=false"/>
>
>         <action application="set" data="sip_copy_custom_headers=false" />
>
>         <action application="set" data="sip_ignore_reinvites=false"/>
>
>
>
>         <action application="set" data="effective_caller_id_
> number=${translate(${caller_id_number} To_International)}" />
>
>         <action application="set" data="effective_caller_id_
> name=${translate(${caller_id_number} To_International)}" />
>
>         <action application="set" data="destination_number_
> translated=${translate(${destination_number} To_International)}"/>
>
>         <action application="bridge" data="sofia/gateway/${distributor(public_gws
> ${sofia(profile public_eth1 gwlist down)})}/${destination_number_translated}"
> />
>
>       </condition>
>
>     </extension>
>
>   </context>
>
> </include>
>
>
>
> Any ideas why the 180/183 are not relayed from outbound leg back to
> inbound leg? A trace shows these messages do arrive on the outbound leg.
>
>
>
> Grant Bagdasarian
>
> Developer
>
> +31765727054
>
> cm.com
>
>
>
>
> _________________________________________________________________________
> 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
>
>
>
>
>
> --
>
> Regards,
>
> Mirko
>
> _________________________________________________________________________
> 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/20171027/df0c5063/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 4981 bytes
Desc: not available
URL: <http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20171027/df0c5063/attachment-0001.png>