[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Question on loop detection
Aayush,
> -----Original Message-----
> From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On
> Behalf Of aayush bhatnagar
> Sent: 05 February 2009 15:45
> To: Elwell, John
> Cc: sip at ietf.org; Armenio, Joao
> Subject: Re: [Sip] Question on loop detection
>
> >>[JRE] If an upstream proxy has forked, each branch will
> have the same
> >>From tag.
>
> True..agreed.
>
> Another thing regarding section 17.2.3. The branch parameter will be
> different for each forked branch, as specified by you inline. However,
> the transaction matching rules of 17.2.3 you quote inline are
> applicable only if the branch parameter is absent, or does not have a
> magic cookie. If you have a magic cookie present, the matching wont
> fail as per 17.2.3..and subsequently as per 8.2.2.2, there will be no
> loop detection.
[JRE] Whether or not the branch parameter matches, the Request-URI will
not match. So therefore the transactions do not match and the rules for
182 come into play.
>
> I suppose your implementation is not following the magic
> cookie paradigm?
>
> >>[JRE] I believe in practice SBCs do behave as B2BUAs, but
> perhaps not in
> >>this respect. Behaving as proxies in this respect would indeed solve
> >>this problem.
>
> Whether the SBC acts as a B2BUA or a proxy also depends on the
> services that it is offering. If your SBC is handling media, QoS,
> admission control,call screening and regulatory services such as
> Lawful Intercept, then it will need to act as a B2BUA. It has no
> choice.
[JRE] I agree, but it might behave as a proxy with respect to this
particular issue.
John
>
> However, if the SBC only needs to provide a point of interconnect
> between trusted/non-trusted domains, then proxy behavior might be
> sufficient.
>
> On 2/5/09, Elwell, John <john.elwell at siemens.com> wrote:
> > Robert,
> >
> > It is true this is a merge rather than a loop situation, but the
> > conditions I describe are conditions for sending a 482
> "loop detected".
> >
> > John
> >
> >> -----Original Message-----
> >> From: Robert Sparks [mailto:rjsparks at nostrum.com]
> >> Sent: 04 February 2009 22:08
> >> To: Elwell, John
> >> Cc: sip at ietf.org; Armenio, Joao
> >> Subject: Re: [Sip] Question on loop detection
> >>
> >> 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 sip-implementors at cs.columbia.edu for questions on current sip
> >> > Use sipping at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
> > Use sipping at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
> Use sipping at ietf.org for new developments on the application of sip
>