<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hello,<br>
<br>
Ok, thanks for the notification.<br>
Seems I didn't look close enough at the config :D Anyway, glad that
you got it fixed.<br>
<br>
Regards,<br>
<pre class="moz-signature" cols="72">Vlad Paiu
OpenSIPS Developer
<a class="moz-txt-link-freetext" href="http://www.opensips-solutions.com">http://www.opensips-solutions.com</a> </pre>
<br>
On 07/11/2012 05:50 AM, Duane Larson wrote:
<blockquote
cite="mid:CAFcM1Eo2vyaiQ+XPEnO-ryfYza6j5EFYTfASiu9izNNihQTCMg@mail.gmail.com"
type="cite">
<p>Just to update...</p>
<p> </p>
<p>My config on the OpenSIPS/SBC was all jacked up. I basically
have two routes in my config, one for SIP messages coming from
the LAN and one for SIP messages coming from the WAN. On the
LAN side before I was doing my "if has_totag" and "if
loose_route" I had unintentionally put my "if method is not
REGISTER|MESSAGE then record_route()" before it. Then on my WAN
side I didn't even have the "if method is not REGISTER|MESSAGE
then record_route()". So that was really jacking up my
routing. Not having the "if method is not REGISTER|MESSAGE then
record_route()" in my WAN side route was the reason why I saw
the INVITE coming from the OpenSIPS/Proxy and the Record_route
headers not being in the correct order when my Callee received
the INVITE relayed by the OpenSIPS/SBC.</p>
<p> </p>
<p>Also like Ali said my contacts were also an issue. I saw
Jeff's post about fix_contact() so I got rid of that on my
OpenSIPs/Proxy device.</p>
<p> </p>
<p>Things look a lot better now. I thought all that duct taping
was hidding something and it got out of control.</p>
<p> </p>
<p>Thanks for working with me. This really gave me a good
refreshers course in SIP routing.<br>
<br>
</p>
<div class="gmail_quote">On Mon, Jul 9, 2012 at 3:45 AM, Vlad Paiu
<span dir="ltr"><<a moz-do-not-send="true"
href="mailto:vladpaiu@opensips.org" target="_blank">vladpaiu@opensips.org</a>></span>
wrote:<br>
<blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex;
border-left: 1px solid rgb(204, 204, 204);"
class="gmail_quote">
<div text="#000000" bgcolor="#ffffff"> Hello,<br>
<br>
This is quite strange, can you please also post a full
OpenSIPS debug for the call where that ACK got relayed out
like<br>
<br>
<div> ACK
sip:50.xx.xx.156;lr;ftag=d4xut7i3jx;nat=yes;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA;did=0f9.1ddb82a6
SIP/2.0.</div>
<div> Record-Route:
<sip:99.xx.xx.161;r2=on;lr>.</div>
<div> Record-Route:
<sip:192.168.88.1;r2=on;lr>.</div>
<br>
<br>
Regards,<br>
<pre cols="72">Vlad Paiu
OpenSIPS Developer
<a moz-do-not-send="true" href="http://www.opensips-solutions.com" target="_blank">http://www.opensips-solutions.com</a> </pre>
<div>
<div class="h5"> <br>
On 07/09/2012 07:09 AM, <a moz-do-not-send="true"
href="mailto:duane.larson@gmail.com" target="_blank">duane.larson@gmail.com</a>
wrote:
<blockquote type="cite">I just got my calls working by
removing the Record-Route's and then reinserting then
in an order that would according to my topology. <br>
<br>
I will need to go back and start from scratch to see
if a lot of the other stuff I did was really needed or
not and then update but here is were I edited the
Record-Routes <br>
<br>
When the INVITE is coming from my OpenSIPS/Proxy to
the Callee I did <br>
<br>
if ( is_method("INVITE") ) { <br>
remove_hf("Record-Route"); <br>
insert_hf("Record-Route: $(hdr(Record-Route)[2])\r\n",
"Via"); <br>
insert_hf("Record-Route: $(hdr(Record-Route)[1])\r\n",
"Via"); <br>
insert_hf("Record-Route: $(hdr(Record-Route)[0])\r\n",
"Via"); <br>
} <br>
<br>
Then when the 180 and 200 are coming from the Callee
to the Caller before the 180 and 200 go to the Caller
I did the following <br>
<br>
<br>
if (t_check_status("180")){ <br>
remove_hf("Record-Route"); <br>
insert_hf("Record-Route: $(hdr(Record-Route)[2])\r\n",
"Via"); <br>
insert_hf("Record-Route: $(hdr(Record-Route)[1])\r\n",
"Via"); <br>
insert_hf("Record-Route: $(hdr(Record-Route)[0])\r\n",
"Via"); <br>
<br>
} <br>
<br>
<br>
if (t_check_status("200")){ <br>
remove_hf("Record-Route"); <br>
insert_hf("Record-Route: $(hdr(Record-Route)[2])\r\n",
"Via"); <br>
insert_hf("Record-Route: $(hdr(Record-Route)[1])\r\n",
"Via"); <br>
insert_hf("Record-Route: $(hdr(Record-Route)[0])\r\n",
"Via"); <br>
<br>
} <br>
<br>
<br>
So not sure if there is something wrong with the way
OpenSIPS places the Record-Route ordering when
OpenSIPS has multiple interfaces. I am not 100% sure
if what I have done here is right or not but calls are
working now. <br>
<br>
Any feedback? <br>
<br>
<br>
On , <a moz-do-not-send="true"
href="mailto:duane.larson@gmail.com" target="_blank">duane.larson@gmail.com</a>
wrote: <br>
> I think I have multiple issues going on but I
might be getting closer to the issue. <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> I am wondering if this might be part of the
issue. <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> If you look at the the following, <a
moz-do-not-send="true"
href="http://www.tech-invite.com/Ti-sip-dialog.html#inv"
target="_blank">http://www.tech-invite.com/Ti-sip-dialog.html#inv</a>
, 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>
> <br>
> <br>
> <br>
> <br>
> INVITE <a moz-do-not-send="true"
href="mailto:sip:9013XX3XX6@192.168.88.14:3072;line=9zx0whnm"
target="_blank">sip:9013XX3XX6@192.168.88.14:3072;line=9zx0whnm</a>
SIP/2.0 <br>
> <br>
> <br>
> Record-Route:
4aoni525hc;nat=yes;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA;did=598.b8b26331><br>
> <br>
> <br>
> Record-Route: <br>
> <br>
> <br>
> Record-Route: <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <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>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> On , <a moz-do-not-send="true"
href="mailto:duane.larson@gmail.com" target="_blank">duane.larson@gmail.com</a>
wrote: <br>
> <br>
> <br>
> > 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. <br>
> <br>
> <br>
> > <br>
> <br>
> <br>
> > <br>
> <br>
> <br>
> > <br>
> <br>
> <br>
> > <br>
> <br>
> <br>
> > <br>
> <br>
> <br>
> > My ACKs are no longer not showing up as
Non-Loose Route messages, but the BYEs are. <br>
> <br>
> <br>
> > <br>
> <br>
> <br>
> > <br>
> <br>
> <br>
> > <br>
> <br>
> <br>
> > <br>
> <br>
> <br>
> > <br>
> <br>
> <br>
> > 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>
> <br>
> <br>
> > <br>
> <br>
> <br>
> > <br>
> <br>
> <br>
> > <br>
> <br>
> <br>
> > <br>
> <br>
> <br>
> > <br>
> <br>
> <br>
> > I will send a PCAP trace to Ali directly. <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>
> > On , Ali Pey <a moz-do-not-send="true"
href="mailto:alipey@gmail.com" target="_blank">alipey@gmail.com</a>>
wrote: <br>
> <br>
> <br>
> > <br>
> <br>
> <br>
> > <br>
> <br>
> <br>
> > > Duane, <br>
> <br>
> <br>
> > <br>
> <br>
> <br>
> > <br>
> <br>
> <br>
> > > <br>
> <br>
> <br>
> > <br>
> <br>
> <br>
> > <br>
> <br>
> <br>
> > > 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>
> <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>
> > > 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. <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>
> > > <br>
> <br>
> <br>
> > <br>
> <br>
> <br>
> > <br>
> <br>
> <br>
> > > <br>
> <br>
> <br>
> > <br>
> <br>
> <br>
> > <br>
> <br>
> <br>
> > > 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. <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>
> > > <br>
> <br>
> <br>
> > <br>
> <br>
> <br>
> > <br>
> <br>
> <br>
> > > <br>
> <br>
> <br>
> > <br>
> <br>
> <br>
> > <br>
> <br>
> <br>
> > > Regards, <br>
> <br>
> <br>
> > <br>
> <br>
> <br>
> > <br>
> <br>
> <br>
> > > Ali Pey <br>
> <br>
> <br>
> > <br>
> <br>
> <br>
> > <br>
> <br>
> <br>
> > > <br>
> <br>
> <br>
> > <br>
> <br>
> <br>
> > <br>
> <br>
> <br>
> > > On Sat, Jul 7, 2012 at 3:35 PM,
osiris123d <a moz-do-not-send="true"
href="mailto:duane.larson@gmail.com" target="_blank">duane.larson@gmail.com</a>>
wrote: <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>
> > > This is driving me crazy. I was right
the first time when I said that one of <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>
> > > the ACKs was not showing up as a loose
route. It is the third ACK that is <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>
> > > coming from the OpenSIPS/Proxy. When
it reaches the OpenSIPS/SBC device the <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>
> > > ACK fails as a loose route. <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>
> > > <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>
> > > It would make sense that this would not
be a loose route because there are <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>
> > > no Route headers so the loose_route()
function would return FALSE. <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>
> > > <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>
> > > The issue still remains that when the
ACK reaches the OpenSIPS/SBC it still <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>
> > > isn't routed to the Callee, instead it
is looped and routed to the same <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>
> > > interface it came from because that is
whats in the RURI. <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>
> > > <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>
> > > -- <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>
> > > View this message in context:
<a moz-do-not-send="true"
href="http://opensips-open-sip-server.1449251.n2.nabble.com/Two-OpenSIPS-proxies-issue-tp7580685p7580743.html"
target="_blank">http://opensips-open-sip-server.1449251.n2.nabble.com/Two-OpenSIPS-proxies-issue-tp7580685p7580743.html</a><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>
> > > <br>
> <br>
> <br>
> > <br>
> <br>
> <br>
> > <br>
> <br>
> <br>
> > > <br>
> <br>
> <br>
> > <br>
> <br>
> <br>
> > <br>
> <br>
> <br>
> > > Sent from the OpenSIPS - Users mailing
list archive at Nabble.com. <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>
> > > <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>
> > >
_______________________________________________ <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>
> > > Users mailing list <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>
> > > <a moz-do-not-send="true"
href="mailto:Users@lists.opensips.org"
target="_blank">Users@lists.opensips.org</a> <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>
> > > <a moz-do-not-send="true"
href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users"
target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a>
<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>
> > > <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>
> > > <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>
> > > <br>
> <br>
> <br>
> > <br>
> <br>
> <br>
> > <br>
> <br>
> <br>
> > >
<pre><fieldset></fieldset>
_______________________________________________
Users mailing list
<a moz-do-not-send="true" href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a>
<a moz-do-not-send="true" href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a>
</pre>
</blockquote>
</div>
</div>
</div>
<br>
_______________________________________________<br>
Users mailing list<br>
<a moz-do-not-send="true"
href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>
<a moz-do-not-send="true"
href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users"
target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
--<br>
*--*--*--*--*--*<br>
Duane<br>
*--*--*--*--*--*<br>
--<br>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
Users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a>
<a class="moz-txt-link-freetext" href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a>
</pre>
</blockquote>
</body>
</html>