Subject: RE: [SIP] SIP proxies and CSeq numbers

From: "Hisham Khartabil" <[email-masked]>
Date: Wed, 1 Nov 2000 11:20:34 +0200

I don't think this is a correct behaviour of the proxy.  The proxy should
wait for the ACK and then the new INVITE.  It forwards the second INVITE
with Cseq=2.  If the proxy was confident that the authentication is ok, why
would it challenge the client in the first place?

Regards,
Hisham
Hotsip Finland

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Jean-Francois Mule
Sent: Tuesday, 31 October 2000 7:39 PM
To: [email-masked]
Cc: [email-masked] '
Subject: RE: [SIP] SIP proxies and CSeq numbers

(A record-route will be added in the call flow to close this discussion on
the sip t.38 side).

But I still believe we have a bug based on what you correctly outlined
Arjun.  CSeq numbers are truly relevant in the context of a sip transaction
and can easily get out of sequence (sick), especially for statefull proxies.
Unless the record-route header is added, we have a recipe for guaranteeing
call failures.

Take this other scenario where the proxy is seating between a public net & a
private trusted net and the proxy requires authentication on one leg only.
        A -> P: authentication is required, A is in the public net.  A
initiates an invite (F1), P challenges A (F2) but P also sends the request
to B (F3) while waiting for the credentials (proxies may act like this: the
proxy knows that A comes from a known but untrusted network and has
confidence the authentication should be ok so it sends the request F3 before
receiving F4).  Another justification for proxies to act this way may be
that to check the credentials on F4, the proxy has check with a remote
authentication server.
        P -> B: no authentication required

If the UA A behaves as you stated in this scenario and sends the ACK
directly to B, the CSeq=2 in the ACK: game over.
Any suggestions on how do we fix this?

Jean-Francois Mule'

SIP UA: A                 Proxy                       SIP UA: B

 |                          |                          |
 |   F1 INVITE (Cseq=1)     |                          |
 |------------------------->|                          |
 |                          |                          |
 |   F2  407 Proxy auth. req|                          |
 |<-------------------------|   F3 INVITE  (Cseq=1)    |
 |                          |------------------------->|
 |   F4 INVITE (Cseq=2)     |                          |
 |------------------------->|                          |
 |                          |   F5  Trying (Cseq=1)    |
 |                          |<-------------------------|
 |   F6  Trying (Cseq=2)    |                          |
 |<-------------------------|                          |
 |                          |   F7  200 OK (Cseq=1)    |
 |                          |<-------------------------|
 |   F8  200 OK (Cseq=2)    |                          |
 |<-------------------------|                          |
 |                                                     |
 |                      F9  ACK (Cseq=2) !             |
 |---------------------------------------------------->|
 |                          |                          |

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, October 30, 2000 10:06 PM
> To: Jean-Francois Mule
> Cc: [email-masked]; [email-masked] '
> Subject: RE: [SIP] SIP proxies and CSeq numbers (was: SIP and T.38 fax
> cal ls - Internet Draft)
>
>
>
>
> Jean,
> Consider this situation:
>
> A sends an INVITE which goes through your Proxy to B. B sends
> a 200 OK with
> Contact as [email-masked].
> This is routed through your proxy and goes to A.
> Now since A has a direct path to B (and the proxy did not do a
> Record-Route),
> A now sends the next request (ACK) directly to B ( protocol behaviour)
>
> The ACK must have the same CSeq as the INVITE although is a
> transaction of
> its own. But in this case,
> the ACK will have the CSeq of A - P which is different from
> the CSeq space
> of P-B. Since ACK went directly
> B would think this ACK is not valid.
> The same problems will arise in any future requests within
> the same call
> which is forwarded directly.
>
> This , as you would notice induces incorrect behaviour.
>
> jean> PS: As for the Record-Route, it was omitted (while it
> is key to proxy
> jean> functions, isn't it optional after all? -- 6.34.1).
> I'll add the
> jean> Record-route to the next I-D revision - thanks.
>
> Yes, its not mandatory. However in your scenario, if you do not do
> Record-Route
> future request can skip your proxy who then cannot change
> CSeq (if thats
> needed in
> the first place)
>
> Regds
> Arjun
>
> --
> Arjun Roychowdhury @ Hughes Software Systems

_______________________________________________
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: Neil Deason <[email-masked]>
Date: Wed, 01 Nov 2000 10:25:04 +0000

> would it challenge the client in the first place?

It certainly isn't correct behaviour. Proxy 1 must not proxy 
on an INVITE (F3) after sending back a final response 407 (F2). 
It also must not change CSeq values in 200 responses (F7 + F8). 

Cheers,
Neil.
-- 
Ubiquity Software Corporation, UK        http://www.ubiquity.net