<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">You can not possibly confirm that from the data provided. What you stated is worth a try, but there was not enough information to even indicate that is the issue.<div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On May 1, 2017, at 9:19 PM, Sergey Safarov <<a href="mailto:s.safarov@gmail.com" class="">s.safarov@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><p dir="ltr" class="">I can confirm that issue related to fragmented UDP packets from carrier equipment. <br class="">
Try swith to TCP transport. </p>
<br class=""><div class="gmail_quote"><div dir="ltr" class="">пн, 1 мая 2017, 23:12 Michael Jerris <<a href="mailto:mike@jerris.com" class="">mike@jerris.com</a>>:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">you can’t tell just from the data provided, but these issues are usually nat related. Inspect the IP addrs and ports in the sip packet and on the wire and see if all looks right.</div><div style="word-wrap:break-word" class=""><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On May 1, 2017, at 3:13 PM, Charles Bujold <<a href="mailto:cjbujold@accra.ca" target="_blank" class="">cjbujold@accra.ca</a>> wrote:</div><br class="m_5602447765643316875Apple-interchange-newline"><div class=""><div class="m_5602447765643316875WordSection1" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">Hi,<span class="m_5602447765643316875Apple-converted-space"> </span><u class=""></u><u class=""></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">Getting a strange issue, all incoming calls work great, but outgoing calls are getting dropped. <span class="m_5602447765643316875Apple-converted-space"> </span><u class=""></u><u class=""></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">Initially though that it was a NAT issue but verified the NAT and it is working properly. The proper external IP is being used and the gateway is registering with the service provider without issue.<u class=""></u><u class=""></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">Checked the call flow with sngrep and wireshark and found some strange issues.<u class=""></u><u class=""></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div><ol start="1" type="1" style="margin-bottom:0cm;margin-top:0cm" class=""><li class="MsoNormal" style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">From my end, making the outbound call I see the call being connected and I receive a 200 OK that the call is connected and I have a connection. It will last about 1.5 minutes while at the same time I see 5-6 INVITE being sent from my Freeswitch to my service provider and then a BYE that it is hanging up.<u class=""></u><u class=""></u></li></ol><div style="margin:0cm 0cm 0.0001pt 36pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div><ol start="2" type="1" style="margin-bottom:0cm;margin-top:0cm" class=""><li class="MsoNormal" style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">From my service provider, they see the call established and then: SIP/SDP 82 Request: INVITE sip: telephonnumber@IPxxxxxx:5060; transport=udp, in-dialog<u class=""></u><u class=""></u></li></ol><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">The question is what is the “in-dialog” it seems to be causing the call to not be recognize that it is active and INVITE being generated and not being answered which causes the Bye Command to occur.<u class=""></u><u class=""></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class=""><u class=""></u> <u class=""></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif" class="">Not certain how to fix. Any suggestions would be appreciated.<u class=""></u><u class=""></u></div></div></div></blockquote></div></div></div></blockquote></div></div></blockquote></div><br class=""></div></body></html>