[OpenSIPS-Users] loose_route detection of self

[Jeff Pyle]

Ok, debugs:

On the reINVITE that fails:

DBG:core:grep_sock_info: checking if host==us: 11==11 &&  [ww.xx.yy.82] ==
[ww.xx.yy.83] 
DBG:core:grep_sock_info: checking if port 5060 matches port 5060
DBG:rr:after_strict: Next hop:
'sip:8009993355 at ww.xx.yy.83:5060;lr=on;ftag=as3137fec5;did=b92.be47e975' is
loose router 

On the reINVITE that works:

DBG:core:grep_sock_info: checking if host==us: 12==11 &&  [ff.gg.hh.94] ==
[ww.xx.yy.83] 
DBG:core:grep_sock_info: checking if port 5060 matches port 5066
DBG:core:check_self: host != me
DBG:core:grep_sock_info: checking if host==us: 11==11 &&  [ww.xx.yy.83] ==
[ww.xx.yy.83] 
DBG:core:grep_sock_info: checking if port 5060 matches port 5060
DBG:rr:after_loose: Topmost route URI:
'sip:8009993355 at ww.xx.yy.83:5060;lr=on;ftag=as27ab13f7;did=37e.68fb59e7' is
me 

ww.xx.yy.83 is Opensips.
ww.xx.yy.82 is Asterisk 1.2.26 (IP is right next to Opensips)
ff.gg.hh.94 is Asterisk 1.4.23.1 (IP is completely different than Opensips)

I see that the failing reINVITE causes a ³DBG:rr:after_strict² while the one
that succeeds causes a ³DBG:rr:after_loose², but I¹m not sure what that
means here.  I suppose the next stop is the RFC.

If anyone has any thoughts on this one, I¹d much appreciate hearing them.


Thanks,
Jeff


On 3/21/09 11:12 AM, "Jeff Pyle" <jpyle at fidelityvoice.com> wrote:

> Hello,
> 
> I seem to be having a problem with loose_route() not properly detecting when
> a Route set is its own.  Opensips 1.5 build 5491, same PSTN carrier in all
> cases.
> 
> Flow is Asterisk --> Opensips --> PSTN (Sonus NBSe)
> 
> The call sets up properly.  90 or 120 seconds into the call, the PSTN
> carrier sends a reINVITE to refresh the session.  If Asterisk 1.4.23.1 is
> the UAC, all is well.  If Asterisk 1.2.26 is the UAC, Opensips misidentifies
> the Route header in the carrier¹s reINVITE as foreign.  The t_relay then
> routes the packet to itself and bad things happen.
> 
> I¹ve done stare-¹n-compares on the packets in all cases.  The reINVITE from
> the carrier is almost exactly the same.  The differences are as follows:
> 
> - The Asterisk 1.4.23.1 UAC is using port 5066, where Asterisk 1.2.26 uses
> 5060.  This difference is reflected in the RURI of the reINVITE.
> 
> - The To field of the 1.4.23.1 UAC has the :5066 at the end of the URI; the
> 1.2.26 host does not have a port.
> 
> That's it.  The only other difference I can see in the messaging is that the
> 1.2.26 host puts "received=ww.xx.yy.zz" in its Via header of the initial
> transaction, where the 1.4.23.1 host does not.  But the reINVITE is a new
> transaction so I don't know how this could effect affect the reINVITE.
> 
> I am at a loss.  Any thoughts?
> 
> 
> Thanks,
> Jeff

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20090321/6a1e3d93/attachment.htm