IMHO,
Going by the reference in Section 16.3 Page -95 as listed below
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.
>> I do not see any "sent-by" value in the via header. Second going by
page 105 RFC-3261 recommendation below for branch parameter
recommendation to be used for loop detection
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 branch parameter in your example are unique ( representing forked
request ), so even if this request would have arrived at the another
proxy ( which has forwarded the first INVITE, it would have forwarded
that INVITE with a unique branch that should be difinitely different
than your second INVITE branch, so it should not be treated as loop.
In general if we think that a request generated by another proxy can be
treated as loop detected at another proxy, there should be something
fundamentally wrong with loop detection mechanism. ( Given that all the
elements are following the base RFC-3261 recommendation ). Right ?
Regards,
Indresh K Singh
>>-----Original Message-----
>>From: sip-implementors-boun...@lists.cs.columbia.edu
>>[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On
>>Behalf Of ext Ashwath Kumar
>>Sent: Sunday, April 19, 2009 4:31 AM
>>To: sip-implementors@lists.cs.columbia.edu
>>Subject: [Sip-implementors] Distinguishing Forked and Looped
>>scenarios atSIP proxy
>>
>>Hi All,
>>
>>I am sending TWO INVITE messages to a proxy .
>>===================== 1st INVITE ==========================
>>INVITE sip:2...@1.20.20.33:5060 SIP/2.0
>>Via: SIP/2.0/UDP 1.1.1.25:7766;branch=z9hG4bK-22034-1-0
>>From: sipp <sip:s...@1.1.1.25:7766>;tag=22034SIPpTag001
>>To: sut <sip:2...@1.20.20.33:5060>
>>Call-ID: 1-22...@1.1.1.25
>>CSeq: 1 INVITE
>>Contact: <sip:s...@1.1.1.25:7766;transport=UDP>
>>Max-Forwards: 70
>>Subject: Performance Test
>>Content-Type: application/sdp
>>Content-Length: 206
>>
>>v=0
>>o=TestSystemsSIP-GW-UserAgent 8345 6736 IN IP4 9.6.3.11
>>s=SIP Call
>>t=0 0
>>m=audio 18570 RTP/AVP 0 19
>>c=IN IP4 145.253.131.140145.253.131.141
>>a=rtpmap:0 PCMU/8000
>>a=rtpmap:19 CN/8000
>>a=ptime:20
>>
>> ================2nd INVITE========================
>>
>> INVITE sip:2...@1.20.20.33:5060 SIP/2.0
>>Via: SIP/2.0/UDP 1.1.1.25:7766;branch=z9hG4bK-22034-1-1
>>From: sipp <sip:s...@1.1.1.25:7766>;tag=22034SIPpTag001
>>To: sut <sip:2...@1.20.20.33:5060>
>>Call-ID: 1-22...@1.1.1.25
>>CSeq: 1 INVITE
>>Contact: <sip:s...@1.1.1.25:7766;transport=UDP>
>>Max-Forwards: 70
>>Subject: Performance Test
>>Content-Type: application/sdp
>>Content-Length: 206
>>
>>v=0
>>o=TestSystemsSIP-GW-UserAgent 8345 6736 IN IP4 9.6.3.11
>>s=SIP Call
>>t=0 0
>>m=audio 18570 RTP/AVP 0 19
>>c=IN IP4 145.253.131.140145.253.131.141
>>a=rtpmap:0 PCMU/8000
>>a=rtpmap:19 CN/8000
>>a=ptime:20
>>
>>===========================
>>
>>These two are distinguised by only one parameter that is
>>branch=z9hG4bK-22034-1-1
>>in via header.
>>
>>Now how the proxy will consider this ?
>>Will Proxy treat it as loop ?
>>or will it treat as an INVITE from some other UA , as in
>>case of forked
>>scenario ?
>>
>>
>>Thanks
>>Ash,
>>_______________________________________________
>>Sip-implementors mailing list
>>Sip-implementors@lists.cs.columbia.edu
>>https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
