Dear Rajeev,
Soft-switches play the role of B2BUA ( comply with UAC/UAS requirement
)when they are on the edge of the network and some times they also play
the role of proxy where they are just letting calls pass through them (
not directly connected to the end users )
1) User A ------- softswitch A ( B2BUA ) ------ softswitchB ( proxy )
------- softswitch C ( B2BUA ) ------------ user C
2) UserA------softswitch A ( B2BUA )-------- softswitch B ( B2BUA )
---------- User B
Below recommendations compliance should help avoid getting into the loop
8.2.2.2 Merged Requests
If the request has no tag in the To header field, the UAS core MUST
check the request against ongoing transactions. If the From tag,
Call-ID, and CSeq exactly match those associated with an ongoing
transaction, but the request does not match that transaction (based
on the matching rules in Section 17.2.3), the UAS core SHOULD
generate a 482 (Loop Detected) response and pass it to the server
transaction.
The same request has arrived at the UAS more than once, following
different paths, most likely due to forking. The UAS processes
the first such request received and responds with a 482 (Loop
Detected) to the rest of them.
Recommendations in section 16.3 ( Max-Forwards Check and Optional Loop
Detection Check )
3. Max-Forwards check
The Max-Forwards header field (Section 20.22) is used to limit the
number of elements a SIP request can traverse.
If the request does not contain a Max-Forwards header field, this
check is passed.
If the request contains a Max-Forwards header field with a field
value greater than zero, the check is passed.
If the request contains a Max-Forwards header field with a field
value of zero (0), the element MUST NOT forward the request. If
the request was for OPTIONS, the element MAY act as the final
recipient and respond per Section 11. Otherwise, the element MUST
return a 483 (Too many hops) response.
4. Optional Loop Detection check
An element MAY check for forwarding loops before forwarding a
request. If the request contains a Via header field with a sent-
by value that equals a value placed into previous requests by the
proxy, the request has been forwarded by this element before. The
request has either looped or is legitimately spiraling through the
element. To determine if the request has looped, the element MAY
perform the branch parameter calculation described in Step 8 of
Section 16.6 on this message and compare it to the parameter
received in that Via header field. If the parameters match, the
request has looped. If they differ, the request is spiraling, and
processing continues. If a loop is detected, the element MAY
return a 482 (Loop Detected) response.
20.22 Max-Forwards
The Max-Forwards header field must be used with any SIP method to
limit the number of proxies or gateways that can forward the request
to the next downstream server. This can also be useful when the
client is attempting to trace a request chain that appears to be
failing or looping in mid-chain.
The Max-Forwards value is an integer in the range 0-255 indicating
the remaining number of times this request message is allowed to be
forwarded. This count is decremented by each server that forwards
the request. The recommended initial value is 70.
This header field should be inserted by elements that can not
otherwise guarantee loop detection. For example, a B2BUA should
insert a Max-Forwards header field.
Now to answer your question what can be done on the Soft-Switches will
depend upon what is configurable on soft-switches. Is the loop detection
something which can be activate/de-activated or you can choose to
include lower values of max-forwards ( so that looping breaks much
earlier than when it will with default value of 70 ). I am not sure. I
think the focus should be not doing a manual intervention when the loop
is detected, but rather to prevent the loop in the first place and there
are recommendations specified to do that.
Regards,
Indresh K Singh
>>-----Original Message-----
>>From: [email protected]
>>[mailto:[email protected]] On
>>Behalf Of ext Rajeev Verghese
>>Sent: Wednesday, February 24, 2010 12:24 AM
>>To: [email protected]
>>Subject: [Sip-implementors] Loop Avoidance between SIP trunks
>>
>>
>>Hi,
>>
>> I have a scenario where I have 4 Softswitches ( 1, 2, 3, 4)
>>which are interconnected via SIP-T, each of these switches
>>has routes to various external destinations.
>>The calls between switches 1, 2, 3, 4 could overflow between
>>each other via the SIP Trunks, my issue is that i have no
>>control over the calls if they keep looping between the switches.
>>
>>Is there a parameter in the SIP trunk configuration where i
>>can define a MAX forward or something to avoid this call
>>looping state, hope the query is clear. Looking forward to
>>any suggestions.
>>
>>Thank you,
>>Rajeev
>>
>>_________________________________________________________________
>>Hotmail: Trusted email with Microsoft's powerful SPAM protection.
>>https://signup.live.com/signup.aspx?id=60969
>>_______________________________________________
>>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
