[asterisk-dev] strange spiral handling in chan_sip

Tue Feb 3 03:26:44 CST 2009

NeoTel Lists schrieb:
> 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

Just consider this scenario:

Asterisk        external     any other
                  device      routing device
   |----INVITE----->|------INVITE-->|
   |                |               |
   |<----INVITE-----|<----INVITE----|

If any of the other devices is a B2BUA, or gateway or just a component 
which changes the callid, Asterisk will accept the incoming call and 
does not have any knowledge that these 2 calls are related.

If all the other components are SIP proxies, then IMO Asterisk should 
behave identically. It is a spiral and Asterisk should accept the call. 
(and if you think this is dangerous as it may cause loops, then restore 
the old behavior and reject with "loop detected" - but do not weird 
things like changing anything in the outgoing INVITE).

regards
klaus

> 
> 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 <http://www.adaanumber.com/>@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
>>