Subject: BYE request and CSeq value

From: "Joshua Moloney" <[email-masked]>
Date: Thu, 9 Mar 2000 13:17:50 -0000

Hi all,

I have a question regarding BYE requests and the value of CSeq. It regards
the behaviour of a User Agent that receives a BYE request for an existing
session with a corrupt CSeq value.

draft-ietf-mmusic-sip-new-00 says:
"A BYE request with a CSeq that is not higher should cause a 400 response to
be generated" (section 6.18).

Section 10.1.1. follows this up (generalises the rule):
"When a user agent server recieves a request, it checks the [Call-ID, To
tag, From etc], the CSeq header field value. If less than or equal to the
current sequence number, the request is a retransmission".

Section 10.1.1 implies that an isomorphic request (the retransmission
mentioned above) should be discarded, and an appropriate response sent out.
It also implies that the server state should not be changed.

If the server state should not be changed, then presumably the client's
request to end the session is denied.

Based on the above statements, here's my question:

How is it possible for a user agent to terminate a session when it has
somehow lost track of the sequence (CSeq value)?

Cheers,

Josh Moloney
Nortel Networks -    Public Networks Development

---

From: "Adam B. Roach" <[email-masked]>
Date: Thu, 9 Mar 2000 10:01:47 -0600 (CST)

>be generated" (section 6.18).

Be careful, though: the CSeq values are unique only in each
direction.

>somehow lost track of the sequence (CSeq value)?

Perhaps
CSeq: 4294967295 BYE
?

I can't come up with a beleviable situation where you know
that you're in a call but don't know what your own highest
CSeq value is...

An uncorralatable response (say, 200 response to an
INVITE request that we don't remember making) will contain
what the far end's notion of our last CSeq value is.

An uncorralatable request (as, an INVITE with a To tag
that we don't regocnise) will receive a 481 response.

If you are obtaining the information that you're in a
call from some local source, that same source should
also contain the most recent local CSeq value.

-- 
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
[email-masked]   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA