I replied to the other email thread but it was blocked because the message was too big. I try to repost it here. I believe it applies to both cases:<div><br></div><div><span style="font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">Hi Duane,</span><div style="font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">
<br></div><div style="font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">I looked at the pcap file you sent me yesterday and I see quite a few problems. I don't have your routing script and am not quite sure what IP address is what device but here are the things I can say you need to look into:</div>
<div style="font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><br></div><div style="font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">1- When the callee sends a 100 Trying, it is routed back to the callee. That doesn't make sense. Seems like a alias problem. </div>
<div style="font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><br></div><div style="font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">2- Then you receive another 100 Trying and 180 Ringing messages from 192.168.88.14 that is sent back to the callee. That is just weired.</div>
<div style="font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><br></div><div style="font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">3- Note that your clients should ONLY talk to their respective servers, if they are sending messages directly to the other server or clients, your request-route headers or aliases/domains in your opensips.cfg script is messed up. First double check your aliases and configured domains. OpenSIPS needs to know what IP addresses and domains are his.</div>
<div style="font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><br></div><div style="font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">4- In scenarios like this, I use <span style="font-family:Helvetica,Arial">record_route_preset() function to force the signalling path. You need to know what you are doing with that though.</span></div>
<div style="font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><font face="Helvetica, Arial"><br></font></div><div style="font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">
<font face="Helvetica, Arial">5- Have the signalling path set on a piece of paper from the original invite and make sure every message is routed the way it should be. By the time you get to Ack and Bye, things will work by itself. </font></div>
<div style="font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><font face="Helvetica, Arial"><br></font></div><div style="font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">
<font face="Helvetica, Arial">6- Never try to patch a fix or cut corners to make it work. Then it will keep breaking with different scenarios and will get harder and harder to fix. Make sure the original invites are properly set and everything should fall in place.</font></div>
<div style="font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><font face="Helvetica, Arial"><br></font></div><div style="font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">
<font face="Helvetica, Arial">7- Use the sip trace module to capture and that gives you better view of what opensips doing. tcpdump can only capture what's on the wire but sometimes messages loop inside that you can only see in the logs or with the sip trace module.</font></div>
<div style="font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><font face="Helvetica, Arial"><br></font></div><div style="font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">
<font face="Helvetica, Arial">Hope these helps. I suspect you have some alias/domain problems. Let us know what you find.</font></div><div style="font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">
<font face="Helvetica, Arial"><br></font></div><div style="font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><font face="Helvetica, Arial">Regards,</font></div><div style="font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">
<font face="Helvetica, Arial">Ali Pey</font></div><div><br></div><div><br><br><div class="gmail_quote">On Mon, Jul 9, 2012 at 2:25 PM, Jeff Pyle <span dir="ltr"><<a href="mailto:jpyle@fidelityvoice.com" target="_blank">jpyle@fidelityvoice.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Duane,<div><br></div><div>I read through your post yesterday twice. It didn't sound like to me it had been resolved...I'll re-re-read it again this afternoon!</div>
<span class="HOEnZb"><font color="#888888"><div><br></div><div><br></div><div>- Jeff</div></font></span><div class="HOEnZb"><div class="h5"><div>
<br></div><div><br><div class="gmail_quote">On Mon, Jul 9, 2012 at 12:11 AM, <span dir="ltr"><<a href="mailto:duane.larson@gmail.com" target="_blank">duane.larson@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Jeff,
<br>
<br>Read my post. I got my calls working but I am not sure if it was a bug or something is just jacked up with my config and I am not following the RFCs the right way. I can go into more detail offline if you need. I hope to get some feedback on my post.
<br><div><br>
<br>On , Jeff Pyle <<a href="mailto:jpyle@fidelityvoice.com" target="_blank">jpyle@fidelityvoice.com</a>> wrote:
<br>> Hi Duane,
<br>>
<br>> I have captures now! I also read through your thread. The situation looks to be the same. I also have a missing username in the self-relayed ACK's RURI.
<br>>
<br>>
<br>> And it's also driving my crazy.
<br>>
<br>>
<br>>
<br>>
<br>> I'm on 1.7 build 9142. You?
<br>>
<br>>
<br>>
<br>>
<br>>
<br>>
<br>> - Jeff
<br>>
<br>>
<br>>
<br>>
<br>> On Sat, Jul 7, 2012 at 7:14 PM, <a href="mailto:duane.larson@gmail.com" target="_blank">duane.larson@gmail.com</a>> wrote:
<br>>
<br>>
<br>> Almost sounds like you and I are having the same issue.
<br>>
<br>>
<br>>
<br>>
<br>>
<br>> Here's my issue
<br>>
<br>>
<br>> <a href="http://opensips-open-sip-server.1449251.n2.nabble.com/Two-OpenSIPS-proxies-issue-td7580685.html" target="_blank">http://opensips-open-sip-server.1449251.n2.nabble.com/Two-OpenSIPS-proxies-issue-td7580685.html</a>
<br>>
<br>>
<br>>
<br>>
<br>>
<br>> Do you have a SIP trace? I'm just wondering if we are having the same problem. Does the ACK that gets relayed to ifself on the other IP have the username missing in the RURI?
<br>>
<br>>
<br>>
<br>>
<br>>
<br>>
<br>>
<br>>
<br>>
<br>>
<br>>
<br>>
<br>>
<br>>
<br>> On , Jeff Pyle <a href="mailto:jpyle@fidelityvoice.com" target="_blank">jpyle@fidelityvoice.com</a>> wrote:
<br>>
<br>>
<br>> > Hello,
<br>>
<br>>
<br>> >
<br>>
<br>>
<br>> >
<br>>
<br>>
<br>> >
<br>>
<br>>
<br>> > I'm attempting to write a config to perform near-end NAT traversal on Opensips 1.7. I'm having a problem with the loose_route of the ACK after the 200 OK, and if I wait long enough, the BYE as well.
<br>>
<br>>
<br>> >
<br>>
<br>>
<br>> >
<br>>
<br>>
<br>> >
<br>>
<br>>
<br>> >
<br>>
<br>>
<br>> > Here's the scenario. An INVITE comes in the WAN side and is t_relay'd to the LAN side. The LAN-side UAS sends a 200 OK, and that is relayed back to the WAN-side UAC. So far, so good. Then the WAN-side UAC sends the ACK to the 200. Opensips relays this from its own WAN IP to its own LAN IP - I found it with ngrep on the lo interface. Eventually Opensips sends a 408 back to the UAC.
<br>>
<br>>
<br>> >
<br>>
<br>>
<br>> >
<br>>
<br>>
<br>> >
<br>>
<br>>
<br>> >
<br>>
<br>>
<br>> > Here's the relevant portion of the config, based largely on the included sample. This works fine with single-interface configurations:
<br>>
<br>>
<br>> >
<br>>
<br>>
<br>> >
<br>>
<br>>
<br>> >
<br>>
<br>>
<br>> >
<br>>
<br>>
<br>> > if (has_totag()) {
<br>>
<br>>
<br>> > if (loose_route()) {
<br>>
<br>>
<br>> > if (method=="INVITE") record_route();
<br>>
<br>>
<br>> >
<br>>
<br>>
<br>> >
<br>>
<br>>
<br>> > if (!t_relay()) sl_reply_error();
<br>>
<br>>
<br>> > exit;
<br>>
<br>>
<br>> > } else {
<br>>
<br>>
<br>> > if (method == "ACK") {
<br>>
<br>>
<br>> > if (t_check_trans()) {
<br>>
<br>>
<br>> >
<br>>
<br>>
<br>> >
<br>>
<br>>
<br>> > if (!t_relay()) sl_reply_error();
<br>>
<br>>
<br>> > exit;
<br>>
<br>>
<br>> > } else {
<br>>
<br>>
<br>> > exit;
<br>>
<br>>
<br>> >
<br>>
<br>>
<br>> >
<br>>
<br>>
<br>> > }
<br>>
<br>>
<br>> > }
<br>>
<br>>
<br>> > sl_send_reply("404", "Not Here");
<br>>
<br>>
<br>> > }
<br>>
<br>>
<br>> > exit;
<br>>
<br>>
<br>> >
<br>>
<br>>
<br>> >
<br>>
<br>>
<br>> > }
<br>>
<br>>
<br>> >
<br>>
<br>>
<br>> >
<br>>
<br>>
<br>> > I've verified with xlogs the ACK hits in the loose_route() portion of the config. It does hit t_relay, but it relays the message to itself on its 'other' IP. I've tried to look the extended debugs but I'm not finding anything telling. Unfortunately I don't have any experience with multiple interface configurations. I suspect it has something to do with the double Via lines added, one from each interface. Perhaps it's not detecting the second Via as its own? (Even if that were the case, I can't explain why it's not responding to itself on the lo interface.)
<br>>
<br>>
<br>> >
<br>>
<br>>
<br>> >
<br>>
<br>>
<br>> >
<br>>
<br>>
<br>> >
<br>>
<br>>
<br>> > I do have mhomed=1 enabled. Without it the initial invite doesn't arrive at the LAN-side UAS.
<br>>
<br>>
<br>> >
<br>>
<br>>
<br>> >
<br>>
<br>>
<br>> > I've experimented with check_via, aliases, etc. No effect. Any suggestions on where to go from here?
<br>>
<br>>
<br>> >
<br>>
<br>>
<br>> >
<br>>
<br>>
<br>> >
<br>>
<br>>
<br>> >
<br>>
<br>>
<br>> >
<br>>
<br>>
<br>> >
<br>>
<br>>
<br>> >
<br>>
<br>>
<br>> >
<br>>
<br>>
<br>> > - Jeff
<br>>
<br>>
<br>> >
<br></div></blockquote></div></div></div></div></blockquote></div></div></div>