I think I have multiple issues going on but I might be getting closer to the issue.

<br />

<br />I am wondering if this might be part of the issue.

<br />

<br />If you look at the the following, http://www.tech-invite.com/Ti-sip-dialog.html#inv , for the first INVITE message that the Callee receives the first Proxy that the callee needs to take in its Record-Route is first in the list of Record-Routes on the INVITE message.  As for the Caller the Record-Route set gets flipped (whatever Record-Route is on the top will be its last route hop).  So if this is the case then why is the OpenSIPS/SBC device sending my Callee device an INVITE message with the far end proxy, OpenSIPS/Proxy, on the top of the Record-Route list?  Here is the INVITE that my callee is getting

<br />

<br />INVITE sip:9013XX3XX6@192.168.88.14:3072;line=9zx0whnm SIP/2.0

<br />Record-Route: &lt;sip:50.XX.XX.156;lr;ftag=4aoni525hc;nat=yes;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA;did=598.b8b26331&gt;

<br />Record-Route: &lt;sip:99.XX.XX.161;r2=on;lr&gt;

<br />Record-Route: &lt;sip:192.168.88.1;r2=on;lr&gt;

<br />

<br />

<br />The Record-Route with 50.XX.XX.156 should be at the bottom of the list I think because that is the OpenSIPS/Proxy that is on the Internet.  Am I wrong on this?  On the SIP trace I posted on pastebin this INVITE to the Callee starts on line 299.

<br />

<br />

<br />

<br />

<br />

<br />On , duane.larson@gmail.com wrote:

<br />&gt; I&#39;m really not sure if I am just duck taping the issue but I was able to make most of the call work.  The only problem now is when the Callee hangs up the BYE is sent directly to the OpenSIPS/Proxy IP instead of going to the OpenSIPS/SBC.  This will not work due to firewall issues.

<br />&gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; My ACKs are no longer not showing up as Non-Loose Route messages, but the BYEs are.

<br />&gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; So if the Caller hangs up the Callee sees the BYE message (GOOD!), but if the Callee hangs up the Caller never sees the BYE message (Bad).

<br />&gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; I will send a PCAP trace to Ali directly.

<br />&gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; On , Ali Pey alipey@gmail.com&gt; wrote:

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; Duane,

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; The Ack should not have any request-route headers. Only Route headers. If you see request-route headers, then you need to find how they got there and fix that first.

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; I believe it is ok if the Ack doesn&#39;t go through loose route, in that case it should be sent to the request-uri destination ip and that IP should be your client IP.

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; Let me know if this help. If not, can you attach here a wireshark trace and I will go through your signalling for you. Going thought a text trace can be quit time consuming. In wireshark it&#39;s a lot easier to jump from a message to another through the call flow. You can use tcpdump to capture to .cap file for wireshark.

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; Regards,

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; Ali Pey

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; On Sat, Jul 7, 2012 at 3:35 PM, osiris123d duane.larson@gmail.com&gt; wrote:

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; This is driving me crazy.  I was right the first time when I said that one of

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; the ACKs was not showing up as a loose route.  It is the third ACK that is

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; coming from the OpenSIPS/Proxy.  When it reaches the OpenSIPS/SBC device the

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; ACK fails as a loose route.

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; It would make sense that this would not be a loose route because there are

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; no Route headers so the loose_route() function would return FALSE.

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; The issue still remains that when the ACK reaches the OpenSIPS/SBC it still

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; isn&#39;t routed to the Callee, instead it is looped and routed to the same

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; interface it came from because that is whats in the RURI.

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; --

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; View this message in context: http://opensips-open-sip-server.1449251.n2.nabble.com/Two-OpenSIPS-proxies-issue-tp7580685p7580743.html

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; _______________________________________________

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; Users mailing list

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; Users@lists.opensips.org

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; http://lists.opensips.org/cgi-bin/mailman/listinfo/users

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt; 

<br />&gt; 

<br />&gt; 

<br />&gt; &gt;