[asterisk-dev] Of loops and spirals

[Enzo Michelangeli]

I have recently encountered a situation where Asterisk, in my opinion,
gets it wrong.

I have my Asterisk registered on two FWD accounts, let's call them 1111
and 2222, defined in two separate sections of sip.conf, [fwd1] and [fwd2].
The registration of 2222 is made with a contact equal to
3333@[myAsterisk'sIPaddress], through the line:

register => 2222:pwd2 at fwd.pulver.com/3333

...so that when someone calls 2222 at fwd.pulver.com this results in a call
to my extension 3333 (handled in extensions.conf).

Now, with a user agent also registered on the same Asterisk, I try to
place a call to 2222 through the first account (the one of 1111):

... Dial(SIP/2222 at fwd1)

Asterisk receives the INVITE from the UA, generates an INVITE to
2222 at fwd.pulver.com with a "From:" header pointing to 1111 at fwd.pulver.com
and a "Contact:" header pointing to 1111@[myAsterisk'sIPaddress] .
Everything's normal so far.

After the authentication challenge etc., FWD accepts the call to 2222; but
due to the fact that 2222 had a registration with "Contact:"
3333@[myAsterisk'sIPaddress] , FWD correctly generates an INVITE for
sip:3333@[myAsterisk'sIPaddress] , with "To:" header pointing to
2222 at fwd.pulver.com and "From:" header pointing to 1111 at fwd.pulver.com :

  INVITE sip:3333@@[myAsterisk'sIPaddress] SIP/2.0
  Max-Forwards: 10
  Record-Route: <sip:2222 at 69.90.155.70;ftag=as4848a450;lr=on>
  Via: SIP/2.0/UDP 69.90.155.70;branch=z9hG4bK2d81.5d452272.0
  Via: SIP/2.0/UDP [myAsterisk'sIPaddress]:5060;branch=z9hG4bK0e33411f
  From: "Enzo Michelangeli" <sip:1111 at fwd.pulver.com>;tag=as4848a450
  To: <sip:2222 at fwd.pulver.com>
  Contact: <sip:1111@[myAsterisk'sIPaddress]>
  [...]

At this point, Asterisk does the first questionable thing: it detects a
loop, and sends a "SIP/2.0 482 Loop Detected" message . I say it's
questionable because the case appears not to be a loop, but what RFC3261
calls a "spiral":

      Spiral: A spiral is a SIP request that is routed to a proxy,
         forwarded onwards, and arrives once again at that proxy, but
         this time differs in a way that will result in a different
         processing decision than the original request.  Typically, this
         means that the request's Request-URI differs from its previous
         arrival.  A spiral is not an error condition, unlike a loop.  A
         typical cause for this is call forwarding.  A user calls
         joe at example.com.  The example.com proxy forwards it to Joe's
         PC, which in turn, forwards it to bob at example.com.  This
         request is proxied back to the example.com proxy.  However,
         this is not a loop.  Since the request is targeted at a
         different user, it is considered a spiral, and is a valid
         condition.

But let's assume that Asterisk has spotted the possibility of
disintermediating FWD away, and passing the call from the UA directly to
the local extension 3333. Unfortunately, what it does is different:

    -- Got SIP response 482 "Loop Detected" back from 69.90.155.70
    -- Now forwarding SIP/spa3kline1-cda8 to 'Local/2222 at from-sip' (thanks
to SIP/fwd0-6b01)

The problem is, there is no local extension 2222: 2222 is a USERNAME, and
with FWD, not even with us. The result is:

  == Everyone is busy/congested at this time
    -- Executing Hangup("SIP/spa3kline1-cda8", "") in new stack

If it really wanted to cut the spiral involving FWD, Asterisk should have
passed the call to the username in the URI that is argument of the INVITE
line, i.e. 3333, dialling 'Local/3333 at from-sip', not the username in the
"To:" header, 2222, as it did. That would require a more active role by
chan_sip (from what I see, the forwarding attempt is made by app_dial).

This happens with Asterisk 1.0.7, but from what I can see in the source
code the handling of this case should not have changed recently (please
correct me if I'm wrong).

Enzo