Hi,
actually the scenario does not imply any actual looping or spiralling.
Maybe the following chart will be more explicit:
X Proxy DSLM (A and B)
-----------> -----INVITE A------>
<-----486-----------
serial fork
-----INVITE B------>
<-----482-----------
So the DSLM identifies as a loop the second branch of a call for which
it already declined the first branch.
Regards,
Bogdan
Pandurangan R S wrote:
> Hi,
>
>
>> There're bugs in loop detection of rfc3261,
>>
>> Check draft-ietf-sip-fork-loop-fix-08, which will fix it eventually.
>>
>
> The loop detection logic described in rfc3261 never detects a request
> as looped when it is actually NOT. There is a potential scenario which
> can occur during forking in which the loop detection logic described
> in rfc3261 does NOT detect an exponential amplification. This issue is
> addressed by draft-ietf-sip-fork-loop-fix-08 (rfc 5393 now).
>
> The scenario described by Bogdan, seems to be a valid spiral as
> described in rfc3261.
>
> The following is an extract from rfc3261
>
> The loop detection procedure in RFC 2543
> had a serious bug which would report "spirals" as an error
> condition when it was not. The optional loop detection procedure
> is more fully and correctly specified here.
>
> So may be DSLM card is following rfc 2543 loop detection logic.
>
> Thanks
> Pandu
>
> On Fri, Jan 23, 2009 at 3:44 PM, Rockson Li (zhengyli)
> <[email protected]> wrote:
>
>> There're bugs in loop detection of rfc3261,
>>
>> Check draft-ietf-sip-fork-loop-fix-08, which will fix it eventually.
>>
>> Regards,
>> -Rockson
>> -----Original Message-----
>> From: [email protected]
>> [mailto:[email protected]] On Behalf Of
>> Bogdan-Andrei Iancu
>> Sent: Friday, January 23, 2009 5:07 PM
>> To: [email protected]
>> Subject: [Sip-implementors] Loop detection
>>
>> Hi,
>>
>> I'm trying to figure out what is the correct behaviour (in regards to
>> Loop Detection) in the following scenario:
>>
>> We use DSLAM with VoIP capabilities which can manage 60 VoIP accounts
>> per card.
>> Let's assume the following configuration:
>> - two accounts A and B configured on the same card
>> - A account has an "on-busy" redirect to B (the redirect is done by
>> the server where A and B are registered)
>> - a third X external account (not local to the card).
>>
>> Now, when X calls A, the calls go to A (to the card) and "482 Busy" is
>> replied (this is the tested scenario). Then, the server will serial fork
>> the call to B account (do redirect) and a new branch of the call is sent
>> for user B (so, with a different RURI and VIA). This second branch hits
>> the same card again (as first branch of A) -> the SIP stack of the card
>> returns 482 Loop Detection (following the RFC 3261, section 8.2.2.2 -
>> Call-Id, From Tag and CSeq are the same as we have 2 branches of the
>> same call).
>>
>> Going through the section 16.3 point 4 (Loop Detection), it mentions
>> checking the VIA branch param for loop detection (if I got it right).
>>
>> So, the question is:
>> is the DSLM card behaving correctly (the loop detection check) ? Is
>> this that is missing from how this should be performed ?
>>
>>
>> Thanks and Regards,
>> Bogdan
>> _______________________________________________
>> Sip-implementors mailing list
>> [email protected]
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>
>> _______________________________________________
>> Sip-implementors mailing list
>> [email protected]
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>
>>
>
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
