[OpenSIPS-Users] Two OpenSIPS proxies issue

Mon Jul 9 15:40:29 CEST 2012

Hi Duane,

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:

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.

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.

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.

4- In scenarios like this, I use record_route_preset() function to force
the signalling path. You need to know what you are doing with that though.

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.

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.

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.

Hope these helps. I suspect you have some alias/domain problems. Let us
know what you find.

Regards,
Ali Pey

On Mon, Jul 9, 2012 at 4:45 AM, Vlad Paiu <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 Developerhttp://www.opensips-solutions.com
>
>
> On 07/09/2012 07:09 AM, 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 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 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 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> 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>
> 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
> >
> >
> > >
> >
> >
> > >
> >
> >
> > > >
> >
> >
> > >
> >
> >
> > >
> >
> >
> > > >
> >
> >
> > >
> >
> >
> > >
> >
> >
> > > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >
> >
> > >
> >
> >
> > >
> >
> >
> > > >
> >
> >
> > >
> >
> >
> > >
> >
> >
> > > >
> >
> >
> > >
> >
> >
> > >
> >
> >
> > > >
> >
> >
> > >
> >
> >
> > >
> >
> >
> > > >
> >
> >
> > >
> >
> >
> > >
> >
> >
> > > >
> >
> >
> > >
> >
> >
> > >
> >
> >
> > > >
> >
> >
> > >
> >
> >
> > >
> >
> >
> > > >
> >
> >
> > >
> >
> >
> > >
> >
> >
> > > >
> >
> >
> > >
> >
> >
> > >
> >
> >
> > > >
> >
> >
> > >
> >
> >
> > >
> >
> >
> > > >
>
>
> _______________________________________________
> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
> _______________________________________________
> 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/20120709/daa9c310/attachment-0001.htm>