Subject: RE: [Sip] Server Location and trying requests bug?

From: "Paul D.Smith" <[email-masked]>
Date: Mon, 12 Jan 2004 16:08:05 -0000

Jonathan,

I have commented on your responses below, but it seems that I have
failed to get across the problems that we encountered.  I will
therefore attempt to recouch the problem using some ASCII-art flows.
My comments on your response are couched in terms of my new examples
so please read this section before looking at my in-line comments.

There are two scenarios which I am considering.

1. UAC/UAS "direct" (i.e. not intervening SIP proxy)
2. UAC/proxy/UAS

Note that in both cases there is a NAT (or similar) between the UAS and the
SIP entity (UAC or proxy) to which it is attached.  I've shown this as a
NAT below.  This entity is not SIP aware but can cause problems with
responses
failing to traverse back towards the UAC.

I have shown requests as RQ[c,b] where c and b represent CSeq and
branches respectively:

- RQ[1,1] and RQ[1,2] have the same CSeq but different branches
- RQ[1,1] and RQ[2,2] have different CSeq and different branches.

Scenario 1.a (we hit this at SIPit13)

UAC                 NAT                 UAS

RQ[1,1] ----------->   RQ[1,1]---------->
                       <---------2XX[1,1]
RQ[1,2] ----------->   RQ[1,2]---------->
<------------5XX[1,2]  <---------5XX[1,2]

What has happened here is that the UAS has received the request, processed
it successfully but the response could not reach the UAC.  Server
(re)Location
then kicked in on the UAC and found a different route (say TCP instead of
UDP)
and the request again reached the UAS.  But the CSeq has not been increased
so the UAS correctly rejects the request.

After discussions with various people at SIPit13, it seemed a reasonable fix
to have the UAC increment the CSeq during Server (re)Location which results
in the following...

Scenario 1.b - Allow Server (re)Location to increment Cseq

UAC                 NAT                 UAS

RQ[1,1] ----------->   RQ[1,1]--------->
                       <--------2XX[1,1]
RQ[2,2] ----------->   RQ[2,2]--------->
<------------2XX[2,2]  <--------2XX[2,2]

This seemed to solve the problem until we considered proxies.  If we
assume that incrementing Cseq is correct we end up with the following.

Scenario 1.2

UAC                 Proxy               NAT                 UAS

RQ[1,1] ----------->     RQ[1,1]------->   RQ[1,1]--------->
                                           <---------2XX[1,1]
                         RQ[2,2]------->   RQ[2,2]---------->
<---------------????     <------2XX[2,2]   <---------2XX[2,2]

But now what happens to the response?  We cannot mangle the CSeq
before the proxy returns it otherwise the next Cseq the UAC would
expect to send would be 2 whilst the UAS would expect a Cseq of 3.

So, as you correctly say, I have to conclude that it must be wrong
for Server (re)Location to increment the Cseq.  But how, therefore,
do we solve the problem of scenario 1.a?

I've commented on your specific feedback in line below, referencing
the scenarios given above.

I look forward to reading your comments,
Paul DS.

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: 11 January 2004 14:59
To: SIP (E-mail)
Subject: Re: [Sip] Server Location and trying requests bug?

inline.

Paul D.Smith wrote:

> All,
> 
> I believe there is an issue with Server Location that makes it impossible
to
> reroute requests successfully in the following scenario.
> 
> If the request reaches the server, but the resulting response does not
reach
> the client (perhaps a NAT blocked its path) then Server Location
processing
> cannot be used to find a different route via which the request can be
> completed and result in a successful response to the client.

I dont see why. The client (UAC or proxy) cannot differentiate the 
case where a request fails to reach the server, and the response fails 
to reach the client. Both manifest themselves as failure to receive a 
response.

[PDS] Hopefully scenario 1.a has explained this.  The issue is that the
      UAC and UAS now have different ideas of the state of the dialog or
      call i.e. the next Cseq that the UAC should send on a request.

> At SIPit13 we encountered the following problem.
> 
> - Send a request using UDP
> - Request reached the server but the response could not get back for some
>   reason
> - Client timed out and then tried TCP, changing the branch
> - New request reached the server which complained because the request did 
>   appear to increment the CSeq.

The server should be prepared to receive requests with CSeq more than 
one higher. RFC3261 explicitly discusses this.

[PDS] That is not the problem.  In scenario 1.a, the UAS believes that the
      UAC sent a new request that _didn't_ increment the Cseq.

> 
> These were specifically REGISTER requests but I believe this affects other
> requests, especially those in-dialog and INVITEs.
> 
> Clearly the server was operating correctly and so there was some
discussion
> as
> to whether the client was at fault. RFC3261 only states the following
> (RFC3261, 8.1.2, p42).
> 
>    The UAC SHOULD follow the procedures defined in [4] for stateful
>    elements, trying each address until a server is contacted.  Each try
>    constitutes a new transaction, and therefore each carries a different
>    topmost Via header field value with a new branch parameter.
>    Furthermore, the transport value in the Via header field is set to
>    whatever transport was determined for the target server.
> 
> However it was decided that in fact the CSeq of the transaction should
also
> have been incremented by the client when sending the new transaction over
> TCP.

It should, though in rfc3261 (as opposed to 2543), it should actually 
work in either case.

[PDS] I disagree.  As per scenario 1.a, the UAS is quite correct to reject
      what it believes is a new request that has not incremented the CSeq.

> 
> But now consider what would happen if the CSeq were updated in this manner
> but there was an intervening proxy.
> 
> - Client sends request which reaches proxy
> - Proxy forwards on using UDP
> - Request reaches server but response cannot get back
> - Proxy times out UDP transaction and now tries TCP, changing the branch
and
>   the CSeq

It should NOT have done that. The proxy should not touch the CSeq. 
Only the branch ID parameter.

[PDS] Agreed.  But this means that scenario 2 fails.  Also, if you are
implying
      that the "real" UAC can increment the Cseq but the "proxy" UAC cannot,
then
      the UAC side of proxy and the "real" UAC are now inconsistent.

> - New request reaches the server, which is happy and responds
> - Response now reaches proxy but the original request had Cseq X and the
>   response has CSeq (X+1)
> 
> Now the proxy might be able to massage the response Cseq back to X but
then
> we
> have the strange situation that the client believes the next CSeq should
be
> (X+1) whilst the server believes it should be (X+2).  Clearly, a
subsequent
> in-dialog reINVITE from the client will fail because the server does not
> believe the Cseq has been incremented.

As I mentioned above, the server should be prepared to receive 
requests with CSeq one or more greater than the last received.

[PDS] As above, this is not the problem that we hit.

> 
> Clearly, without incrementing Cseq, we will hit the "response not
returned,
> subsequent request fails" problem in both the UAC/UAS and UAC/proxy/UAS
> cases.
> But incrementing the CSeq only fixes the UAC/UAS case and introduces more
> problems in the UAC/proxy/UAS case.  For this reason we believe the
> discussed
> solution is wrong.
> 
> At the moment, this seems to be a problem that RFC3261 fails to address
and
> we
> have yet to determine a simple fix.

The problem is in the server. From 12.2.2:

> If the remote sequence number is empty, it MUST be set to the value
>    of the sequence number in the CSeq header field value in the request.
>    If the remote sequence number was not empty, but the sequence number
>    of the request is lower than the remote sequence number, the request
>    is out of order and MUST be rejected with a 500 (Server Internal
>    Error) response.  If the remote sequence number was not empty, and
>    the sequence number of the request is greater than the remote
>    sequence number, the request is in order.  It is possible for the
>    CSeq sequence number to be higher than the remote sequence number by
>    more than one.  This is not an error condition, and a UAS SHOULD be
>    prepared to receive and process requests with CSeq values more than
>    one higher than the previous received request.  The UAS MUST then set
>    the remote sequence number to the value of the sequence number in the
>    CSeq header field value in the request.

[PDS] As above, this is not the problem we are hitting.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip