[OpenSIPS-Users] Two OpenSIPS proxies issue
Vlad Paiu
vladpaiu at opensips.org
Wed Jul 11 10:40:31 CEST 2012
Hello,
Ok, thanks for the notification.
Seems I didn't look close enough at the config :D Anyway, glad that you
got it fixed.
Regards,
Vlad Paiu
OpenSIPS Developer
http://www.opensips-solutions.com
On 07/11/2012 05:50 AM, Duane Larson wrote:
>
> Just to update...
>
> 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.
>
> 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.
>
> Things look a lot better now. I thought all that duct taping was
> hidding something and it got out of control.
>
> Thanks for working with me. This really gave me a good refreshers
> course in SIP routing.
>
> On Mon, Jul 9, 2012 at 3:45 AM, Vlad Paiu <vladpaiu at opensips.org
> <mailto:vladpaiu at opensips.org>> wrote:
>
> Hello,
>
> This is quite strange, can you please also post a full OpenSIPS
> debug for the call where that ACK got relayed out like
>
> ACK
> sip:50.xx.xx.156;lr;ftag=d4xut7i3jx;nat=yes;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA;did=0f9.1ddb82a6
> SIP/2.0.
> Record-Route: <sip:99.xx.xx.161;r2=on;lr>.
> Record-Route: <sip:192.168.88.1;r2=on;lr>.
>
>
> Regards,
>
> Vlad Paiu
> OpenSIPS Developer
> http://www.opensips-solutions.com
>
>
> On 07/09/2012 07:09 AM, duane.larson at gmail.com
> <mailto:duane.larson at gmail.com> wrote:
>> 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.
>>
>> 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
>>
>> When the INVITE is coming from my OpenSIPS/Proxy to the Callee I did
>>
>> if ( is_method("INVITE") ) {
>> remove_hf("Record-Route");
>> insert_hf("Record-Route: $(hdr(Record-Route)[2])\r\n", "Via");
>> insert_hf("Record-Route: $(hdr(Record-Route)[1])\r\n", "Via");
>> insert_hf("Record-Route: $(hdr(Record-Route)[0])\r\n", "Via");
>> }
>>
>> 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
>>
>>
>> if (t_check_status("180")){
>> remove_hf("Record-Route");
>> insert_hf("Record-Route: $(hdr(Record-Route)[2])\r\n", "Via");
>> insert_hf("Record-Route: $(hdr(Record-Route)[1])\r\n", "Via");
>> insert_hf("Record-Route: $(hdr(Record-Route)[0])\r\n", "Via");
>>
>> }
>>
>>
>> if (t_check_status("200")){
>> remove_hf("Record-Route");
>> insert_hf("Record-Route: $(hdr(Record-Route)[2])\r\n", "Via");
>> insert_hf("Record-Route: $(hdr(Record-Route)[1])\r\n", "Via");
>> insert_hf("Record-Route: $(hdr(Record-Route)[0])\r\n", "Via");
>>
>> }
>>
>>
>> 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.
>>
>> Any feedback?
>>
>>
>> On , duane.larson at gmail.com <mailto:duane.larson at gmail.com> wrote:
>> > 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:9013XX3XX6 at 192.168.88.14:3072;line=9zx0whnm
>> <mailto:sip:9013XX3XX6 at 192.168.88.14:3072;line=9zx0whnm> SIP/2.0
>> >
>> >
>> > Record-Route:
>> 4aoni525hc;nat=yes;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA;did=598.b8b26331>
>> >
>> >
>> > Record-Route:
>> >
>> >
>> > Record-Route:
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > 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 , duane.larson at gmail.com <mailto:duane.larson at gmail.com> 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 alipey at gmail.com <mailto:alipey at gmail.com>> 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
>> duane.larson at gmail.com <mailto:duane.larson at gmail.com>> 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
>> >
>> >
>> > >
>> >
>> >
>> > >
>> >
>> >
>> > > >
>> >
>> >
>> > >
>> >
>> >
>> > >
>> >
>> >
>> > > >
>> >
>> >
>> > >
>> >
>> >
>> > >
>> >
>> >
>> > > > Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>> >
>> >
>> > >
>> >
>> >
>> > >
>> >
>> >
>> > > >
>> >
>> >
>> > >
>> >
>> >
>> > >
>> >
>> >
>> > > >
>> >
>> >
>> > >
>> >
>> >
>> > >
>> >
>> >
>> > > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>> >
>> >
>> > >
>> >
>> >
>> > >
>> >
>> >
>> > > >
>> >
>> >
>> > >
>> >
>> >
>> > >
>> >
>> >
>> > > >
>> >
>> >
>> > >
>> >
>> >
>> > >
>> >
>> >
>> > > >
>> >
>> >
>> > >
>> >
>> >
>> > >
>> >
>> >
>> > > >
>> >
>> >
>> > >
>> >
>> >
>> > >
>> >
>> >
>> > > >
>> >
>> >
>> > >
>> >
>> >
>> > >
>> >
>> >
>> > > >
>> >
>> >
>> > >
>> >
>> >
>> > >
>> >
>> >
>> > > >
>> >
>> >
>> > >
>> >
>> >
>> > >
>> >
>> >
>> > > >
>> >
>> >
>> > >
>> >
>> >
>> > >
>> >
>> >
>> > > >
>> >
>> >
>> > >
>> >
>> >
>> > >
>> >
>> >
>> > > >
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
>
> --
> --
> *--*--*--*--*--*
> Duane
> *--*--*--*--*--*
> --
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20120711/f7f1e87e/attachment-0001.htm>
More information about the Users
mailing list