[asterisk-dev] strange spiral handling in chan_sip

[NeoTel Lists]

Hi Klaus, Mark!

I agree with Klaus, that the request should be handled as a new request.
For that I made the attached patch based on 
http://bugs.digium.com/view.php?id=13630

This patch is for the 1.6.0.5, but should work for 1.4.23 as well. 
Any suggestions welcome.  

The idea behind: If the request has no to-tag and we are really
pedantic, let's check the Request URI, too, and, if different put her
into routing again. In my opinion the CallID as a single check for
dialog matching is very poor. See chan_sip.c:6070 ff. in find_call().

br
Walter

> -----Original Message-----
> From: asterisk-dev-bounces at lists.digium.com 
> [mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of 
> Mark Michelson
> Sent: Wednesday, January 14, 2009 4:33 PM
> To: Asterisk Developers Mailing List
> Subject: Re: [asterisk-dev] strange spiral handling in chan_sip
> 
> Klaus Darilion wrote:
> > Hi!
> > 
> > I just found this text in chan_sip which describes how 
> spirals will be 
> > handled:
> > 
> > /* This is a spiral. What we need to do is to just change 
> the outgoing 
> > INVITE
> > * so that it now routes to the new Request URI. Since we 
> created the 
> > INVITE ourselves
> > * that should be all we need to do.
> > */
> > 
> > 
> > IMO this is wrong. If a message spirals back to Asterisk 
> this means that 
> > Asterisk should handle it as it a totally new request - 
> newer it should 
> >   influence the outgoing request.
> > I observed (1.4.22) real bogus behavior that Asterisk sends a new 
> > outgoing INVITE with increased CSeq (looks like a reINVITE) 
> and also it 
> > try to lookup the userpart (instead of the hostpart) of the 
> received 
> > spiraled request.
> > 
> > 
> > Here  is the received spiraled request:
> > 
> > <--- SIP read from 111.11.11.90:5060 --->
> > INVITE sip:8604+4369911161122 at example.at;transport=UDP SIP/2.0
> > Record-Route: <sip:111.11.11.90;lr;ftag=as5764a3a4 
> >        at=yes;x-nt-gw=0>
> > Via: SIP/2.0/UDP 111.11.11.90;branch=z9hG4bKdfe1.f9c82eb2.0
> > Via: SIP/2.0/UDP 
> 111.11.11.65:5084;branch=z9hG4bKdhEr6TTK465LvdH;rport=5084
> > Via: SIP/2.0/UDP 111.11.11.90;branch=z9hG4bKdfe1.e9c82eb2.0
> > Via: SIP/2.0/UDP 
> 22.22.222.183:5060;branch=z9hG4bK52f281cb;rport=5060
> > From:  <sip:072062007301 at example.foobar.at>;tag=as5764a3a4
> > To: <sip:8604+4369911161122 at example.foobar.at>
> > Call-ID: 7ee2bd3a6aea62ff7e40db6e0c385e54 at example.foobar.at
> > CSeq: 103 INVITE
> > Max-Forwards: 67
> > Supported: replaces
> > Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,SUBSCRIBE,NOTIFY
> > Contact: <sip:example.orig at 22.22.222.183>
> > Content-Length: 306
> > Content-Type: application/sdp
> > Record-Route: <sip:111.11.11.65:5084;lr>
> > Record-Route: <sip:111.11.11.90;lr;ftag=as5764a3a4
> > 
> > 
> > from logfile:
> > 
> > [Jan 14 15:08:26] DEBUG[15909] chan_sip.c: Potential spiral 
> detected. 
> > Original RURI was sip:8604+4369911161122 at example.foobar.at, 
> new RURI is 
> > sip:8604+4369911160036 at example.at;transport=UDP
> > [Jan 14 15:08:26] WARNING[15909] chan_sip.c: No such host: 
> > 8604+4369911161122
> > 
> > 
> > regards
> > klaus
> 
> Hi Klaus,
> 
> If you look at issue 13630 on the bugtracker 
> (http://bugs.digium.com/view.php?id=13630), you'll find a 
> patch attached which 
> should cause behavior to be better. The patch treats a 
> suspected spiral the same 
> way we handle a 302 redirect, meaning that Asterisk will 
> start a new call to the 
> new RURI. The patch isn't completely refined yet (e.g. it 
> doesn't handle the 
> promiscredir setting in sip.conf) but it is a step in the 
> right direction.
> 
> The patch that I am referring to is an attachment called 
> 13630_temporary.patch. 
> If you want to skip the step of browsing the issue tracker, 
> you can wget the 
> patch directly with this URL: 
> http://bugs.digium.com/file_download.php?file_id=20433&type=bug
> 
> Mark Michelson
> 
> > 
> > _______________________________________________
> > --Bandwidth and Colocation Provided by http://www.api-digital.com--
> > 
> > asterisk-dev mailing list
> > To UNSUBSCRIBE or update options visit:
> >    http://lists.digium.com/mailman/listinfo/asterisk-dev
> 
> 
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 13630_temporary.1.6.neotel.patch
Type: application/octet-stream
Size: 2793 bytes
Desc: 13630_temporary.1.6.neotel.patch
Url : http://lists.digium.com/pipermail/asterisk-dev/attachments/20090202/15517682/attachment.obj