I think I have multiple issues going on but I might be getting closer to
the issue.
I am wondering if this might be part of the issue.
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
INVITE sip:[email protected]:3072;line=9zx0whnm SIP/2.0
Record-Route:
<sip:50.XX.XX.156;lr;ftag=4aoni525hc;nat=yes;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA;did=598.b8b26331>
Record-Route: <sip:99.XX.XX.161;r2=on;lr>
Record-Route: <sip:192.168.88.1;r2=on;lr>
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.
On , [email protected] wrote:
I'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.
My ACKs are no longer not showing up as Non-Loose Route messages, but the
BYEs are.
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).
I will send a PCAP trace to Ali directly.
On , Ali Pey [email protected]> wrote:
> Duane,
>
> 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.
>
>
> I believe it is ok if the Ack doesn'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.
>
>
>
>
> 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'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.
>
>
>
>
> Regards,
> Ali Pey
>
> On Sat, Jul 7, 2012 at 3:35 PM, osiris123d [email protected]>
wrote:
>
>
> This is driving me crazy. I was right the first time when I said that
one of
>
>
> the ACKs was not showing up as a loose route. It is the third ACK that
is
>
>
> coming from the OpenSIPS/Proxy. When it reaches the OpenSIPS/SBC device
the
>
>
> ACK fails as a loose route.
>
>
>
>
>
> It would make sense that this would not be a loose route because there
are
>
>
> no Route headers so the loose_route() function would return FALSE.
>
>
>
>
>
> The issue still remains that when the ACK reaches the OpenSIPS/SBC it
still
>
>
> isn't routed to the Callee, instead it is looped and routed to the same
>
>
> interface it came from because that is whats in the RURI.
>
>
>
>
>
> --
>
>
> View this message in context:
http://opensips-open-sip-server.1449251.n2.nabble.com/Two-OpenSIPS-proxies-issue-tp7580685p7580743.html
>
>
>
>
> Sent from the OpenSIPS - Users mailing list archive at Nabble.com.
>
>
>
>
>
> _______________________________________________
>
>
> Users mailing list
>
>
> [email protected]
>
>
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
>
>
>
>
>
>
>
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
