I dont think the SBC will detect a loop. As per the RFC text above, a loop situation will occur, only when the request does not match an ongoing transaction at the UAS(as per the rules mentioned above), but the call id, from tag and cseq match that of an ''ongoing'' transaction.. This situation will not arise in a parallel forking case, as each forked branch creates a unique transaction of its own (and hence a unique from tag).
i have a doubt on why a SBC should behave as a B2BUA? Should it not behave as a proxy server between 2 sip domains? aayush. On 2/4/09, Robert Sparks <[email protected]> wrote: > You are describing a merge, not a loop, and as Dale pointed out, if > the B2BUA is > playing the role of a proxy, it shouldn't merge detect. If it's being > more than a proxy, > then it needs to choose one and reject the other with the same kind of > local-policy > logic an actual endpoint would use. > > RjS > > > On Feb 4, 2009, at 10:31 AM, Elwell, John wrote: > >> Apologies if this has been discussed in the past. >> >> Consider a domain proxy that is configured to parallel fork an INVITE >> request to two targets. As a result it would forward the INVITE >> request >> twice, and as far as I can see the two forwarded requests would in >> general differ only in the following respects: >> - different Request-URIs (the respective contact URIs); >> - different top Via header field entries (different branch >> parameters); >> - if applicable, different History-Info header field values. >> >> Supposing the two new targets are both reachable via the same edge >> "proxy", which is actually implemented as a B2BUA (e.g., an SBC). The >> edge B2BUA would receive one request and shortly afterwards would >> receive the other request. The similarity and differences between the >> two requests are such that, in accordance with RFC 3261, the second >> request would be treated by the B2BUA (acting as a UAS) as a loop >> and be >> rejected with 482, assuming it arrives within a given time period. For >> TCP transport the second INVITE request would need to arrive before >> the >> ACK relating to the first INVITE request, but for UDP transport the >> window is extended by T4 seconds. >> >> The text concerned in RFC 3261 is in 8.2.2.2: >> "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." >> in 17.2.3: >> "The INVITE request matches a transaction if the Request-URI, To tag, >> From tag, Call-ID, CSeq, and top Via header field match those of the >> INVITE request which created the transaction. In this case, the >> INVITE is a retransmission of the original one that created the >> transaction." >> and in 17.1.2.2: >> "Once the client transaction enters the "Completed" state, it MUST set >> Timer K to fire in T4 seconds for unreliable transports, and zero >> seconds for reliable transports. The "Completed" state exists to >> buffer any additional response retransmissions that may be received >> (which is why the client transaction remains there only for >> unreliable transports). T4 represents the amount of time the >> network >> will take to clear messages between client and server transactions. >> The default value of T4 is 5s." >> >> Questions: Has this problem has been seen in practice? If so, what >> steps >> have been taken to overcome it? If not, have I misinterpreted RFC >> 3261? >> >> John >> _______________________________________________ >> Sip mailing list https://www.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use [email protected] for questions on current sip >> Use [email protected] for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use [email protected] for questions on current sip > Use [email protected] for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [email protected] for questions on current sip Use [email protected] for new developments on the application of sip
