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
