[asterisk-dev] strange spiral handling in chan_sip

Mark Michelson mmichelson at digium.com
Wed Jan 14 09:33:15 CST 2009

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 
> * 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 --->
> INVITE sip:8604+4369911161122 at example.at;transport=UDP SIP/2.0
> Record-Route: <sip:;lr;ftag=as5764a3a4 
>        at=yes;x-nt-gw=0>
> Via: SIP/2.0/UDP;branch=z9hG4bKdfe1.f9c82eb2.0
> Via: SIP/2.0/UDP;branch=z9hG4bKdhEr6TTK465LvdH;rport=5084
> Via: SIP/2.0/UDP;branch=z9hG4bKdfe1.e9c82eb2.0
> Via: SIP/2.0/UDP;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
> Contact: <sip:example.orig at>
> Content-Length: 306
> Content-Type: application/sdp
> Record-Route: <sip:;lr>
> Record-Route: <sip:;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: 

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

More information about the asterisk-dev mailing list