The CSeq counter should increase for each successive transaction in a
particular direction. In this case the Client sending to the Server. The
CSeq of the BYE should be 4. The PRACK transaction(s) are separate
transactions. they just happen to take place smack in the middle of the
INVITE transaction.
Note that you can still send the final response to the INVITE before the
PRACK receives a final response. If the CSeq of the BYE was 2 instead of 4,
you could potentially have transactions within the same call leg, with the
same CSeq(PRACK and BYE). This would cause a "transaction-clash" according
to the rules of matching requests to transactions in Section 11.5 of the
bis2 draft. More specifically, the BYE would be treated as a retransmission.
-----Original Message-----
From: Venkatesh Venkataramanan
[mailto:[EMAIL PROTECTED]]
Sent: Monday, February 12, 2001 5:00 PM
To: Scott Happell
Cc: [EMAIL PROTECTED]
Subject: RE: [Sip-implementors] RE: [SIP] Question regarding CSEQ
processi ng with PRACK...
I guess I didn't state my question correctly. Following call scenario:
1. UAC sends an INVITE with CSEQ 1.
2. UAS responds with 183 SESSION PROGRESS (CSEQ=1).
3. UAC creates a PRACK with CSEQ=2.
4. UAS responds with a 200 OK (for PRACK, CSEQ 2).
5. UAS sends another provisional response 180 RINGING (CSEQ = 1).
6. UAC creates another PRACK with CSEQ=3.
7. UAS acks the PRACK.
8. UAS sends a 200 OK (for INVITE, CSEQ=1).
9. UAC sends a ACK (for INVITE) completing the 3 way handshake.
At some point one of them decide to hangup. A BYE is issued. What shd the
CSEQ be ? Should be 4 (basically greater than the CSEQ of the last PRACK)?
or can it be 2(basically greater than the CSEQ in the last INVITE)?
The doc says that the CSEQ MUST be greater than the last completed
transaction. In the above call flow, the INVITE is the last completed
transaction and the CSEQ for the same was 1.....
Thanks,
Venkatesh
-----Original Message-----
From: Scott Happell [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 12, 2001 12:52 PM
To: 'Venkatesh Venkataramanan'
Cc: [EMAIL PROTECTED]
Subject: RE: [Sip-implementors] RE: [SIP] Question regarding CSEQ
processi ng with PRACK...
>From draft-ietf-sip-100rel-02.txt
"Assuming the response is to be transmitted reliably, the UAC MUST
create a new request with method PRACK. The Call-ID in this request
MUST match that of the provisional response. The CSeq in this request
MUST be larger than the last request (PRACK or otherwise) sent by
this UAC for this call leg."
I believe the Reliable Provisional Responses extension draft has since been
added to the RFC 2543 bis drafts.
-----Original Message-----
From: Venkatesh Venkataramanan
[mailto:[EMAIL PROTECTED]]
Sent: Monday, February 12, 2001 2:33 PM
To: Arunachalam Venkataman
Cc: [EMAIL PROTECTED]
Subject: [Sip-implementors] RE: [SIP] Question regarding CSEQ processing
with PRACK...
But isn't PRACK a transaction within a transaction? The last transaction
that ended in the example below is the INVITE. So, when a subsequent BYE or
reINVITE/REFER or what ever message is called, shouldn't the rules of CSEQ
mean that all I need to worry about is that CSEQ should be greater than the
one used in the INVITE (no matter how many PRACK's were sent out in
between)?
-----Original Message-----
From: Arunachalam Venkataman [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 12, 2001 11:23 AM
To: 'Venkatesh Venkataramanan'
Cc: [EMAIL PROTECTED]
Subject: RE: [SIP] Question regarding CSEQ processing with PRACK...
I believe the CSEQ should increment for each request sent out. So if the
PRACK in the example cited goes out with a CSEQ of 1, the BYE would be sent
with a CSEQ of 2 (or higher).
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
On Behalf Of Venkatesh Venkataramanan
Sent: Monday, February 12, 2001 12:31 PM
To: Jonathan Rosenberg
Cc: [EMAIL PROTECTED]
Subject: [SIP] Question regarding CSEQ processing with PRACK...
All:
I needed some clarification on the usage of CSEQ with PRACK's. The draft
says that the CSEQ number in PRACK MUST be higher than the last transaction
CSEQ number (INVITE or otherwise). So, for example, say, an UAC sends out an
INVITE with CSEQ 1, it receives a 180 ringing, it issues a PRACK with CSEQ
2.
The question I had is should these CSEQ's be preserved after the INVITE
transaction has ended? Meaning, in the above example, say the PRACK,
generates a 200 OK by the UAS for the same, followed by an ACK for the
INVITE(when the called party answers), the UAC issues an ACK with CSEQ 1
INVITE to complete the 3 way handshake. At a later point of time, say, the
user hungup, which causes the UAC to issue a BYE, should the CSEQ field be
constructed with a sequence number, higher than the last PRACK it sent
out(or received in case of far end disconnects) or the last INVITE it sent
out(or received)? Please elaborate.
Thanks.
Venkatesh
_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to [EMAIL PROTECTED] with
"subscribe sip-implementors" in the body.
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
