<div dir="ltr"><div>Hello,</div><div><br></div><div>Days ago, I banged on a similar issue with Debian Buster's asterisk (16.2):</div><div>my box had two interfaces (one North and one South) both with private addresses</div><div>when relaying calls from South to North, my box used South Address for media handling.</div><div><br></div><div>Upgrading to 16.7.0 without changing configuration, immediately solved the issue.<br></div><div><br></div><div>I didn't have time to dig into this (ie reading Changelogs or debugging step by step).</div><div>I don't think my config was perfect either but if I had to implement anything on Debian Buster again, I'll prepare myself to spend some times on this.</div><div><br></div><div>My 0.01 cent<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le lun. 13 janv. 2020 à 15:51, Benoit Panizzon <<a href="mailto:benoit.panizzon@imp.ch">benoit.panizzon@imp.ch</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Joshua<br>
<br>
Thank you for your reply.<br>
<br>
Indeed, Ubuntu only ships with this old version. Upgraded to 16.2. via<br>
PPA. Problem persisted.<br>
<br>
Well, I already mentioned that this is a machine with two physical<br>
interfaces with different routes which on the 'external' side handles<br>
SIP customer registrations and has an 'internal' IC Trunk to a<br>
commercial Voice Switch via private IP Range.<br>
<br>
I had the problem, that some of the packets sent out on the 'external'<br>
side contained 'private' IP addresses in either signaling or SDP.<br>
<br>
So I threw all options I could find into the config to bind<br>
transports, endpoints, media and so on to the corresponding interface ip<br>
address. First this looked good. I had the correct IP in every header<br>
and SDP I expected.<br>
<br>
well setting under transport:<br>
<br>
external_signaling_address=[local IP]<br>
<br>
Assuming this is the own interface IP that would be told to external<br>
endpoints was obviously wrong.<br>
<br>
In the end this caused the Proxy-SBC to believe it was not getting an<br>
OK to it's forwarded registration and discard this session.<br>
<br>
Mit freundlichen Grüssen<br>
<br>
-Benoît Panizzon-<br>
-- <br>
I m p r o W a r e   A G    -    Leiter Commerce Kunden<br>
______________________________________________________<br>
<br>
Zurlindenstrasse 29             Tel  +41 61 826 93 00<br>
CH-4133 Pratteln                Fax  +41 61 826 93 01<br>
Schweiz                         Web  <a href="http://www.imp.ch" rel="noreferrer" target="_blank">http://www.imp.ch</a><br>
______________________________________________________<br>
<br>
-- <br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" rel="noreferrer" target="_blank">http://www.api-digital.com</a> --<br>
<br>
Check out the new Asterisk community forum at: <a href="https://community.asterisk.org/" rel="noreferrer" target="_blank">https://community.asterisk.org/</a><br>
<br>
New to Asterisk? Start here:<br>
      <a href="https://wiki.asterisk.org/wiki/display/AST/Getting+Started" rel="noreferrer" target="_blank">https://wiki.asterisk.org/wiki/display/AST/Getting+Started</a><br>
<br>
asterisk-users mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
   <a href="http://lists.digium.com/mailman/listinfo/asterisk-users" rel="noreferrer" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-users</a></blockquote></div>