Subject: Re: [SIP] detection of retransmitted request at stateful proxy

From: William Marshall <[email-masked]>
Date: Tue, 4 Apr 2000 15:21:30 -0400 (EDT)

> 
> Bill, I think you are referring to the problem of request merging in a 
> forking proxy - refer to Jonathan's page - he has a small article and 
> possible solutions.
> 
> -- 
> Best regards,
> Shail

Found that article, but I think the problem I'm describing is a little
different.  Jonathan's diagram is:

                            ----
                       /---| B  |-\
                      /     ----   \
     ----       ---- /              \  ----         ----       ----
    | C1 |-----| A  |                -|  D |-------| E  |-----| C2 |
     ----       ---- \              /  ----         ----       ----
                      \     ----   /
                       \---| C  |-/
                            ----

and the key item is that both forked requests are to go to C2.

I would instead draw the diagram as:

                            ----                  ----
                       /---| B  |-\           /--| C2 |
                      /     ----   \         /    ----
     ----       ---- /              \  ---- / 
    | C1 |-----| A  |                -|  D |
     ----       ---- \              /  ---- \
                      \     ----   /         \    ----
                       \---| C  |-/           \--| C3 |
                            ----                  ----
where the key item is that the two forked requests from A are intended
to get to different endpoints; they just happen to cross at another
proxy on the way.  (Or, perhaps the translation done at A says the next
proxy for both C2 and C3 is D; then we avoid B and C completely.)

Jonathan's mechanisms to toss the secondary requests believing them
to be duplicates isn't right for this case.

I think the problem still is that proxy-D believes the second request it
receives is a duplicate, even if the Request-URI for the first
says C2 and the second says C3.

Bill Marshall
[email-masked]

-----original message-----
Date: Tue, 04 Apr 2000 14:05:01 -0400
From: Shail Bhatnagar <[email-masked]>
Subject: Re: [SIP] detection of retransmitted request at stateful proxy

William Marshall wrote:
> 
> This question is regarding section 12.3.4 of 2543 (and 2543bis).
> If the answer is in the mailing list archives, or the notes file,
> or the faq, I've missed it.
> 
> If a forking proxy receives an INVITE request, and generates two
> INVITES from it, according to 12.4 the only difference between them
> is the branch=x in the via header (and probably the Request-URI too)
> 
> If it happens that both of those forked requests are sent to the same
> stateful proxy as the next hop, how does that proxy know that
> the second isn't a retransmission?  To, From (including tags),
> Call-ID, and CSeq are all identical.
> 
> Adding a tag on the From header at the forking proxy would seem to
> be a bad idea, since then the response wouldn't match at the UAC.
> Also, there may already be a tag on the From header.
> 
> Does this mean the stateful proxy needs to compare Via headers
> also, in determining whether the received request is a retransmission?
> Or, should it compare the Request-URI?
> Is there some other way it can tell that the second is a real request?
> 
> Bill Marshall
> [email-masked]
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip

Bill, I think you are referring to the problem of request merging in a 
forking proxy - refer to Jonathan's page - he has a small article and 
possible solutions.

-- 
Best regards,
Shail

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: "Donovan, Steven R." <[email-masked]>
Date: Wed, 05 Apr 2000 08:08:23 +0000

Bill,

The proxy needs to use the request URI to differentiate between requests
received.  Consider the following scenario discussed earlier on the list:

     C1--->A--->B--->C--->A--->C2

This is a "legal" request loop when the same request (as defined by to,
from, callid and cseq) gets to A the second time with a different request
uri.  As such, it should not be dropped or rejected as a via loop.

Note that in this scenario, proxy A needs to use the branch tag in the first
Via it adds to the request to point to (or contain) the original request
uri.  If the request uri indicated in the branch tag is the same as the
request uri in the request the second time the request is received by A,
then it is a via loop.  If not, then it is a legal loop.

I'm sorry if the wording is a little convoluted, I'm still a little sleep
deprived from flying over the pacific ocean...

Steve

> -----Original Message-----
> From: William Marshall [mailto:[email-masked]]
> Sent: Tuesday, April 04, 2000 2:22 PM
> To: [email-masked]

---

From: William Marshall <[email-masked]>
Date: Wed, 5 Apr 2000 08:16:17 -0400 (EDT)

Steve,

Thanks for the response.

I had thought loop detection was a completely separable issue.  It
obviously isn't.

From your response, I take it the proxy needs to use the Request-URI
as part of the loop detection, and somehow encodes the Request-URI
into the 'x' of branch=x in the via header.

Does that also imply the proxy needs to use the Request-URI for
retransmission detection as well?  So that it compares From, To, Call-ID,
CSeq, and Request-URI to determine whether the received request is
a retransmission of a previous request?

It seems it would have to; otherwise proxy A in your example would
consider the second request it received (the one with the modified
Request-URI) a retransmission of the initial request from C1, 
and ignore it.

Bill Marshall
[email-masked]

----- original message -----
> Date: Wed, 05 Apr 2000 08:08:23 +0000
> From: "Donovan, Steven R." <[email-masked]>
> Subject: RE: [SIP] detection of retransmitted request at stateful proxy
> To: "'William Marshall'" <[email-masked]>, [email-masked]
> 
> Bill,
>

---

From: "Donovan, Steven R." <[email-masked]>
Date: Wed, 05 Apr 2000 14:50:07 +0000

Bill,

Yes, you are correct, the proxy needs to use the request uri to determine
retransmissions as well.  And yes, the proxy needs to be able to determine
the original request uri based on the content of the branch tag.

Steve

> Sent: Wednesday, April 05, 2000 7:16 AM
> To: Donovan, Steven R.; [email-masked]

---

From: [email-masked]
Date: Wed, 5 Apr 2000 20:53:43 +0530

Hi,
The bis draft (latest copy)  does suggest that while generating branch-ids
one should use a crypto hash of to,from,callid,cseq &Request-URI suggesting
MD5 as an algorithm.

Infact section 12.3.1 mentions the use of branch in loop detection

"A request has been looped if the server finds its own address in the Via
header field and the hash computation over
the fields enumerated in Section 6.45.5 yields the same value as the

“branch” parameter in the Via entry
containing the proxy server’s address.
The To, From, Call-ID,andContact tags are copied exactly from the original
request. The proxy
SHOULD change the Request-URI to indicate the server where it intends to
send the request.
A proxy server always inserts a Via header field containing its own address
 into those requests that are
caused by an incoming request. Each proxy MUST insert a “branch” parameter
(Section 6.45). "

However, 12.3,4 does not mention veryfying from the branch id for a
retransmission. Should ths not be added ?

Regds
Arjun

--
Arjun Roychowdhury @ Hughes Software Systems

steve> From your response, I take it the proxy needs to use the Request-URI
steve>  as part of the loop detection, and somehow encodes the Request-URI
steve>  into the 'x' of branch=x in the via header.

William Marshall <[email-masked]> on 04/05/2000 05:46:17 PM

To:   [email-masked], [email-masked]
cc:

Steve,

Thanks for the response.

Bill Marshall
[email-masked]