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

From: "Paul D.Smith" <[email-masked]>
Date: Fri, 9 Jan 2004 12:55:56 -0000

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.

Could people please take a look at this, see if they have already
encountered
it and it so, let me know if they have suggestions for a solution?

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.

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.

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
- 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.

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.

Thanks,
Paul DS.

Paul D.Smith
Network Protocols Group
Data Connection Ltd (DCL)
Tel: +44 20 8366 1177  Email: [email-masked]
Fax: +44 20 8363 1039  Web:   http://www.dataconnection.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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 11 Jan 2004 09:59:02 -0500

inline.

> 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.

>   appear to increment the CSeq.

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

> have been incremented by the client when sending the new transaction over

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

> - Proxy times out UDP transaction and now tries TCP, changing the branch and

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

> 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.

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.

-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