Hi Aman, Juste to mention taht Max Forward header doesn't provide a loop detection mechanism.
A real loop detection mechanism could solve the problem mentioned in the following draft (which is really interesting) http://www.ietf.org/internet-drafts/draft-lawrence-maxforward-problems-00.txt Best regards Marc Bailly On 12/5/05, Aman Arora <[EMAIL PROTECTED]> wrote: > > > > > > Hi Chandan, > > As an alternate to this, RFC 3261 introduced a new header Max-Forwards (as > a MUST in all SIP requests). > Quoting Section 8.1.1.6 and 20.22 from 3261- > The Max-Forwards header field serves to limit the number of hops a > request can transit on the way to its destination. It consists of an > integer that is decremented by one at each hop. If the Max-Forwards > value reaches 0 before the request reaches its destination, it will > be rejected with a 483(Too Many Hops) error response. > > A UAC MUST insert a Max-Forwards header field into each request it > originates with a value that SHOULD be 70. This number was chosen to > be sufficiently large to guarantee that a request would not be > dropped in any SIP network when there were no loops, but not so large > as to consume proxy resources when a loop does occur. Lower values > should be used with caution and only in networks where topologies are > known by the UA. > > 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. > > Thus either Proxy can check on this header to detect a looping message. > Also though this method doens't help distinguish between > a loop and a spiral, yet it is more efficient and faster as compared to > the > method to calculate the branch in the Via. > > rgds > aman > > > > Thangarajan > Inbarajan/BLR/HSS > @HSS To > Sent by: "Chandan Jena - NPD, Chennai" > sip-implementors- <[EMAIL PROTECTED]> > [EMAIL PROTECTED] cc > ia.edu [EMAIL PROTECTED] > a.edu, > [email protected] > 12/05/2005 09:16 Subject > AM Re: [Sip-implementors] Loop detect > problem > > > > > > > > > > > > > > > Hi Chandan, > > Both stateless and stateful proxy can detect loop if they calculate > the > branch parameter using following logic. > > "Proxies choosing to detect loops have an additional constraint > in the value they use for construction of the branch parameter. > A proxy choosing to detect loops SHOULD create a branch > parameter separable into two parts by the implementation. The > first part MUST satisfy the constraints of Section 8.1.1.7 as > described above. The second is used to perform loop detection > and distinguish loops from spirals. The second part is > cryptographic hash of the To tag, From tag, Call-ID header > field, the Request-URI of the request received (before > translation), the topmost Via header, and the sequence number > from the CSeq header field, in addition to any Proxy-Require > and Proxy-Authorization header fields that may be present." > > > "To determine if the request has looped, the proxy element MAY > perform the branch parameter calculation like described above > and compare it to the parameter received in that Via header field. > If the parameters match, the request has looped." > > Regards, > Thangarajan. > > > > > "Chandan Jena - > NPD, Chennai" > <[EMAIL PROTECTED] To > tech.com> <[email protected]> > Sent by: cc > sip-implementors- > [EMAIL PROTECTED] Subject > ia.edu [Sip-implementors] Loop detect > problem > > 12/02/2005 01:14 > PM > > > > > > > > Hi all, > > Does Stateless proxy give loop detect or not? When I tested one > scenario in stateful proxy ,it gives loop detect .but When I tested the > same > scenario in stateless proxy, it doesn't give the loop detect and it added > VIA header again and again. Then after some time the call terminated. What > is the solution for this? How we check loop detect incase of stateless and > stateful ? Plz clarify me on this point. > > > > > > Thanks and Regards > > > > Chandan Kumar Jena > > Member Technical Staff > > HCLTechnologiesLtd > > Chennai-600058 > > Visit: - www.hcltech.com <http://www.hcltechphasis.com> > > > > > Disclaimer: > > This message and any attachment(s) contained here are information that is > confidential, proprietary to HCL Technologies and its customers, > privileged > or otherwise protected by law. The information is solely intended for the > individual or the entity it is addressed to. If you are not the intended > recipient of this message, you are not authorized to read, forward, print, > retain, copy or disseminate this message or any part of it. If you have > received this e-mail in error, please notify the sender immediately by > return e-mail and delete it from your computer. > _______________________________________________ > Sip-implementors mailing list > [email protected] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > *********************** FSS-Private *********************** > "DISCLAIMER: This message is proprietary to Hughes Software Systems > Limited > (HSS) and is intended solely for the use of the individual to whom it is > addressed. It may contain privileged or confidential information and > should not be circulated or used for any purpose other than for what it is > intended. If you have received this message in error, please notify the > originator immediately. If you are not the intended recipient, you are > notified that you are strictly prohibited from using, copying, altering, > or > disclosing the contents of this message. HSS accepts no responsibility for > loss or damage arising from the use of the information transmitted by this > email including damage from virus." > > _______________________________________________ > Sip-implementors mailing list > [email protected] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > > *********************** FSS-Unclassified *********************** > "DISCLAIMER: This message is proprietary to Flextronics Software > Systems Limited (FSS) and is intended solely for the use of the > individual to whom it is addressed. It may contain privileged or > confidential information and should not be circulated or used for > any purpose other than for what it is intended. If you have received > this message in error, please notify the originator immediately. > If you are not the intended recipient, you are notified that you are > strictly prohibited from using, copying, altering, or disclosing > the contents of this message. FSS accepts no responsibility for > loss or damage arising from the use of the information transmitted > by this email including damage from virus." > > _______________________________________________ > Sip-implementors mailing list > [email protected] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > -- ------------------- Marc Bailly _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
