But as on an average the number of loops happening is very less, the
cost of the Max-Forwards solution is tolerable, however the cost of the
old solution is high even for a normal "non-looped" call, so only 3261
has made the loop detection optional.
Cheers,
Prasanna
Nataraju A B wrote:
AFAIK, we should not reply on Max-Forwards to detect the Loops.
This lead to totally in-efficient usage of memory and resources in case
of loops....
Thanks & Regards,
Nataraju A.B.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Aman
Arora
Sent: Monday, December 05, 2005 2:40 PM
To: Chandan Jena - NPD, Chennai; Thangarajan Inbarajan
Cc: [EMAIL PROTECTED];
[email protected]
Subject: Re: [Sip-implementors] Loop detect problem
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
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
