<div dir="ltr"><div><div>Thanks for your answer Vallimamod,<br><br>You can see our dialplan bellow:<br>We tried these commands "rtp auto adjust, etc ...", but the issue continues.<br><br>is there a way to show if FS knows when the call is natted or not ? FYI we have an opensips of front for SIP, but RTP is send directly to FS.<br><br></div>SIP call --> Opensips (nat detection) --> FS<br></div>RTP flow ------------------------------------------> FS<br><div><div><div><div><div><br><span style="font-family:monospace,monospace"><condition field="${destinationAuthorized}" expression="^yes$" break="never"><br>         <action application="export" data="codec_string=${ep_codec_string}"/><br>         <action application="export" data="sip_h_X-cid=${uuid}"/><br>         <action application="set" data="hangup_after_bridge=true"/><br>          <action application="set" data="ignore_early_media=false"/><br>          <action application="set" data="ignore_display_updates=true"/><br>          <action application="set" data="inherit_codec=true"/><br>          <action application="set" data="fax_enable_t38=false"/><br>          <action application="export" data="suppress_cng=true"/><br>          <action application="set" data="disable_rtp_auto_adjust=false"/><br>          <action application="set" data="rtp_auto_adjust_threshold=1"/><br>          <action application="set" data="rtp_manual_rtp_bugs=accept_any_packets"/><br>          <action application="unset" data="sip_h_X-Username"/><br>          <action application="bridge" data="<br>          {<br>              sip_invite_params=user=phone,<br>              sip_cid_type=none,<br>              ignore_display_updates=true,<br>               sip_contact_user=${caller_id_number}<br>          }<br>          sofia/internal/${destination_number}@${distributor(LISTINTERNAL ${sofia(profile internal gwlist down)})}"/></span><br><br></div><div>Thanks in advance<br></div><div><div><div><br></div></div></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2018-04-19 11:35 GMT+02:00 Vallimamod Abdullah <span dir="ltr"><<a href="mailto:vma@vallimamod.org" target="_blank">vma@vallimamod.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
To my knowledge, it is the default beahviour for freeswitch to wait for incoming rtp from nated endpoints before starting to transmit.<br>
<br>
You can explicitely force it with the profile param disable-rtp-auto-adjust=false.<br>
You can also play with the channel variable rtp_auto_adjust_threshold which defines the number of rtp packets to wait for initially (default is 10 iirc)<br>
<br>
Best Regards,<br>
-- <br>
Vallimamod Abdullah<br>
SIP Solutions<br>
<a href="http://linkedin.com/in/vallimamod" rel="noreferrer" target="_blank">linkedin.com/in/vallimamod</a><br>
.<br>
<div><div class="h5"><br>
> On 19 Apr 2018, at 10:31, Mickael Hubert <<a href="mailto:mickael@winlux.fr">mickael@winlux.fr</a>> wrote:<br>
> <br>
> Hi list, <br>
> I'd like to know if there's a way to tell FS to wait for RTP reception before sending any RTP packet ? <br>
> We're facing a problem regarding early media with a PBX, NATed behind a dumb router : actually, if FS first sends RTP to the PBX, without waiting for RTP coming from the PBX, there's no audio. In some cases (related to the provider we use behind FS to establish call to the PSTN) FS isn't the 'first-shooter' of the RTP flow, and everything works fine, but when FS is the first to send RTP, it doesn't work... <br>
> Because we can't change anything at our providers configs, we'd like to know if FS can "delay" RTP sending until it receives some RTP from the calling party.<br>
>  <br>
> The schematic is following :<br>
> PBX ===> FS ===> ...voice backbone... ===> Providers<br>
> (FS is acting as an SBC)<br>
>  <br>
> Thanks for your help, <br>
> <br>
<br>
<br>
</div></div>______________________________<wbr>______________________________<wbr>_____________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com" rel="noreferrer" target="_blank">http://www.<wbr>freeswitchsolutions.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" rel="noreferrer" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://confluence.freeswitch.org" rel="noreferrer" target="_blank">http://confluence.freeswitch.<wbr>org</a><br>
<a href="http://www.cluecon.com" rel="noreferrer" target="_blank">http://www.cluecon.com</a><br>
<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.<wbr>freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" rel="noreferrer" target="_blank">http://lists.freeswitch.org/<wbr>mailman/listinfo/freeswitch-<wbr>users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" rel="noreferrer" target="_blank">http://lists.<wbr>freeswitch.org/mailman/<wbr>options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" rel="noreferrer" target="_blank">http://www.freeswitch.org</a></blockquote></div><br></div>