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
