<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Don't know if this will help you, but we ran into a similar problem with one of our PSTN providers. In essence, their GW (incorrectly) updated the contact info of an established dialog when it got an ACK. In our case, the ACK sometimes contained a contact with an RFC 1918 IP address, and subsequent in-dialog requests from the remote GW would be lost. This code snippet addressed the issue:<div><br></div><div><div><span class="Apple-tab-span" style="white-space:pre"><font class="Apple-style-span" face="'Courier New'"> </font></span><font class="Apple-style-span" face="'Courier New'">if (loose_route()) {</font></div><div><span class="Apple-tab-span" style="white-space:pre"><font class="Apple-style-span" face="'Courier New'"> </font></span><font class="Apple-style-span" face="'Courier New'">xlog ("L_DBG", "loose_route;$rm\n");</font></div><div><span class="Apple-tab-span" style="white-space:pre"><font class="Apple-style-span" face="'Courier New'"> </font></span><font class="Apple-style-span" face="'Courier New'">if(is_method("ACK")) {</font></div><div><span class="Apple-tab-span" style="white-space:pre"><font class="Apple-style-span" face="'Courier New'"> </font></span><font class="Apple-style-span" face="'Courier New'">if(is_present_hf("Contact")) remove_hf("Contact");</font></div><div><span class="Apple-style-span" style="font-family: 'Courier New'; white-space: pre; "> };</span></div><div><font class="Apple-style-span" face="'Courier New'"><span class="Apple-style-span" style="white-space: pre;"> };</span></font></div><div><font class="Apple-style-span" face="'Courier New'"><span class="Apple-style-span" style="white-space: pre;"><br></span></font></div></div><div><br></div><div>Be interested to hear how you resolve this. Cheers,<br><div apple-content-edited="true"> <div style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><div>--</div><div>kobi</div></div><br class="Apple-interchange-newline"> </div><br><div><div>On Mar 3, 2009, at 4:41 PM, Brett Nemeroff wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Question...<div><br class="webkit-block-placeholder"></div><div>In general the receipient of an INVITE should respond to that invite to the address in the contact header, right?</div><div><br class="webkit-block-placeholder"> </div><div>What if there is a record-route header? That should prevail, right?</div><div><br class="webkit-block-placeholder"></div><div>I'm having a problem that with a single provider, some (not all) calls they don't send the BYE from the FAR side of the call back via me, instead it goes direct to the originator.</div> <div><br class="webkit-block-placeholder"></div><div>Example:</div><div><br class="webkit-block-placeholder"></div><div>My customer places a call to me. I send to my provider. Provider sends it to destination.</div><div><br class="webkit-block-placeholder"> </div><div>Destination hangs up, BYE goes to my customer instead of me.. My INVITE to my provider DOES have a record-route header init.</div><div><br class="webkit-block-placeholder"></div><div>Originally, this problem began because my customer would reinvite the call right after the call was established and the re-invite, because it was in-dialog wouldn't get record routed.</div> <div><br class="webkit-block-placeholder"></div><div>So I moved my record-route block to before my loose route block. Now, sometimes I get byes.. I'm not sure what I'm doing wrong.. any ideas?</div><div>-Brett</div> <div><br class="webkit-block-placeholder"></div> _______________________________________________<br>Users mailing list<br><a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>http://lists.opensips.org/cgi-bin/mailman/listinfo/users<br></blockquote></div><br></div></body></html>