[Sip-implementors] CSeq Number implementation

[Manpreet Singh]

Based on the spec, the CSeq numbers should increase monotonically from the
previous requests within the same dialog.

Requests within a dialog MUST contain strictly monotonically
increasing and contiguous CSeq sequence numbers (increasing-by-one)
in each direction.

It is possible for the
CSeq sequence number to be higher than the remote sequence number by
more than one.

So based on what is said above, the CSeq number MUST be higher between
multiple requests. Now does this rule hold on the direction of requests in a
dialog. Example as follows:

A--------------Invite( Cseq = 101 )------------>B
<-------------200OK----------------------------
----------------ACK----------------------------->
At this point, B wants to change the session parameter and sends a new
offer.

<----------------Re-Invite ( CSeq = 101 )--------
--------------------------200OK------------------------->
<-----------------------ACK------------------------------


Now for CSeq numbering schema, does it have to consistent between both
directions in the dialog. So basically B cannot send CSeq of 101 as A
already used it and it needs to send 102 or anything greater than 101? I
know for requests in the same direction, CSeq would have to increase so if A
needs to send a re-Invite or BYE or any mid call requests, it would send 102
and so on. But would the UA on the termination side have to stick to this
rule too or this rule only applies to subsequent requests in the same
direction? Is that what the spec is meaning to say in the line stated above
and based on that, the call flow would be invalid and B will get 500 or
something?

Can someone put more light on the CSeq number implementation when requests
are flowing from both directions.

Thanks
M

[Paul Kyzivat]

CSeq numbering is independent for requests originated by each end.

Note that while the UAC is expected to use consecutive values, the UAS
is expected to allow gaps in the numbering. This is needed in case
messages get lost along the way.

There are some pretty interesting and useful things that can be done by
the UAC violating its rule and jumping the CSeq value by more than one
in some cases. I expect those are present in the wild, so you'd best be
tolerant of that. (E.g. this can help in implementing failover of
dialogs to another server.)

Also remember that the first CSeq value in a dialog must be in range
0:2^31-1 (positive) but that it may increment so as to become >= 2^32,
so you must be prepared for values that appear negative. (Its really an
unsigned value.) There seems to be a limit of 2^31 requests per dialog.
I doubt this will be a problem any time soon.

Paul

Post by Manpreet Singh
Based on the spec, the CSeq numbers should increase monotonically from the
previous requests within the same dialog.
Requests within a dialog MUST contain strictly monotonically
increasing and contiguous CSeq sequence numbers (increasing-by-one)
in each direction.
It is possible for the
CSeq sequence number to be higher than the remote sequence number by
more than one.
So based on what is said above, the CSeq number MUST be higher between
multiple requests. Now does this rule hold on the direction of requests in a
A--------------Invite( Cseq = 101 )------------>B
<-------------200OK----------------------------
----------------ACK----------------------------->
At this point, B wants to change the session parameter and sends a new
offer.
<----------------Re-Invite ( CSeq = 101 )--------
--------------------------200OK------------------------->
<-----------------------ACK------------------------------
Now for CSeq numbering schema, does it have to consistent between both
directions in the dialog. So basically B cannot send CSeq of 101 as A
already used it and it needs to send 102 or anything greater than 101? I
know for requests in the same direction, CSeq would have to increase so if A
needs to send a re-Invite or BYE or any mid call requests, it would send 102
and so on. But would the UA on the termination side have to stick to this
rule too or this rule only applies to subsequent requests in the same
direction? Is that what the spec is meaning to say in the line stated above
and based on that, the call flow would be invalid and B will get 500 or
something?
Can someone put more light on the CSeq number implementation when requests
are flowing from both directions.
Thanks
M
_______________________________________________
Sip-implementors mailing list
Sip-implementors at cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

[Manpreet Singh]

Paul

So if the numbering is independent from each end, then if a UAC sends a Cseq
101 in its initial request then receiving a request from the UAS can be 101
or even less then 101 right? Would it be valid if the UAS sends a request
with Cseq 100 or 99, something lower than 101 in this case?

I actually didn't see Cseq violations from the UAC side, just the issue
where the Cseq from UAC and UAS requests were same and UAC was complaining
about it.

Thanks
M

-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat at cisco.com]
Sent: Thursday, February 01, 2007 8:41 PM
To: Manpreet Singh
Cc: sip-implementors at cs.columbia.edu; discussion at sipforum.org
Subject: Re: [Sip-implementors] CSeq Number implementation

CSeq numbering is independent for requests originated by each end.

Note that while the UAC is expected to use consecutive values, the UAS is
expected to allow gaps in the numbering. This is needed in case messages get
lost along the way.

There are some pretty interesting and useful things that can be done by the
UAC violating its rule and jumping the CSeq value by more than one in some
cases. I expect those are present in the wild, so you'd best be tolerant of
that. (E.g. this can help in implementing failover of dialogs to another
server.)

Also remember that the first CSeq value in a dialog must be in range
0:2^31-1 (positive) but that it may increment so as to become >= 2^32, so
you must be prepared for values that appear negative. (Its really an
unsigned value.) There seems to be a limit of 2^31 requests per dialog.
I doubt this will be a problem any time soon.

Paul

Post by Manpreet Singh
Based on the spec, the CSeq numbers should increase monotonically from
the previous requests within the same dialog.
Requests within a dialog MUST contain strictly monotonically
increasing and contiguous CSeq sequence numbers (increasing-by-one)
in each direction.
It is possible for the
CSeq sequence number to be higher than the remote sequence number by
more than one.
So based on what is said above, the CSeq number MUST be higher between
multiple requests. Now does this rule hold on the direction of
A--------------Invite( Cseq = 101 )------------>B
<-------------200OK----------------------------
----------------ACK----------------------------->
At this point, B wants to change the session parameter and sends a new
offer.
<----------------Re-Invite ( CSeq = 101 )--------
--------------------------200OK------------------------->
<-----------------------ACK------------------------------
Now for CSeq numbering schema, does it have to consistent between both
directions in the dialog. So basically B cannot send CSeq of 101 as A
already used it and it needs to send 102 or anything greater than 101?
I know for requests in the same direction, CSeq would have to increase
so if A needs to send a re-Invite or BYE or any mid call requests, it
would send 102 and so on. But would the UA on the termination side
have to stick to this rule too or this rule only applies to subsequent
requests in the same direction? Is that what the spec is meaning to
say in the line stated above and based on that, the call flow would be
invalid and B will get 500 or something?
Can someone put more light on the CSeq number implementation when
requests are flowing from both directions.
Thanks
M
_______________________________________________
Sip-implementors mailing list
Sip-implementors at cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

[Paul Kyzivat]

Post by Manpreet Singh
Paul
So if the numbering is independent from each end, then if a UAC sends a
Cseq 101 in its initial request then receiving a request from the UAS
can be 101 or even less then 101 right? Would it be valid if the UAS
sends a request with Cseq 100 or 99, something lower than 101 in this case?

If the initial CSeq from A to B is 101, the initial request from B to A
in the same dialog can have any CSeq value between 0 and 2^31-1.

Post by Manpreet Singh
I actually didn't see Cseq violations from the UAC side, just the issue
where the Cseq from UAC and UAS requests were same and UAC was
complaining about it.
Thanks
M
-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat at cisco.com]
Sent: Thursday, February 01, 2007 8:41 PM
To: Manpreet Singh
Cc: sip-implementors at cs.columbia.edu; discussion at sipforum.org
Subject: Re: [Sip-implementors] CSeq Number implementation
CSeq numbering is independent for requests originated by each end.
Note that while the UAC is expected to use consecutive values, the UAS
is expected to allow gaps in the numbering. This is needed in case
messages get lost along the way.
There are some pretty interesting and useful things that can be done by
the UAC violating its rule and jumping the CSeq value by more than one
in some cases. I expect those are present in the wild, so you'd best be
tolerant of that. (E.g. this can help in implementing failover of
dialogs to another server.)
Also remember that the first CSeq value in a dialog must be in range
0:2^31-1 (positive) but that it may increment so as to become >= 2^32,
so you must be prepared for values that appear negative. (Its really an
unsigned value.) There seems to be a limit of 2^31 requests per dialog.
I doubt this will be a problem any time soon.
Paul

Post by Manpreet Singh
Based on the spec, the CSeq numbers should increase monotonically from
the previous requests within the same dialog.
Requests within a dialog MUST contain strictly monotonically
increasing and contiguous CSeq sequence numbers (increasing-by-one)
in each direction.
It is possible for the
CSeq sequence number to be higher than the remote sequence number by
more than one.
So based on what is said above, the CSeq number MUST be higher between
multiple requests. Now does this rule hold on the direction of
A--------------Invite( Cseq = 101 )------------>B
<-------------200OK----------------------------
----------------ACK----------------------------->
At this point, B wants to change the session parameter and sends a new
offer.
<----------------Re-Invite ( CSeq = 101 )--------
--------------------------200OK------------------------->
<-----------------------ACK------------------------------
Now for CSeq numbering schema, does it have to consistent between both
directions in the dialog. So basically B cannot send CSeq of 101 as A
already used it and it needs to send 102 or anything greater than 101?
I know for requests in the same direction, CSeq would have to increase
so if A needs to send a re-Invite or BYE or any mid call requests, it
would send 102 and so on. But would the UA on the termination side
have to stick to this rule too or this rule only applies to subsequent
requests in the same direction? Is that what the spec is meaning to
say in the line stated above and based on that, the call flow would be
invalid and B will get 500 or something?
Can someone put more light on the CSeq number implementation when
requests are flowing from both directions.
Thanks
M
_______________________________________________
Sip-implementors mailing list
Sip-implementors at cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

[Sarkar, Uttam]

Manpreet,
See my answer inline.

-----Original Message-----
From: sip-implementors-bounces at cs.columbia.edu
[mailto:sip-implementors-bounces at cs.columbia.edu] On Behalf Of Manpreet
Singh
Sent: Thursday, February 01, 2007 8:45 PM
To: Paul Kyzivat
Cc: discussion at sipforum.org; sip-implementors at cs.columbia.edu
Subject: Re: [Sip-implementors] CSeq Number implementation

Paul

So if the numbering is independent from each end, then if a UAC sends a
Cseq
101 in its initial request then receiving a request from the UAS can be
101 or even less then 101 right?
Would it be valid if the UAS sends a request with Cseq 100 or 99,
something lower than 101 in this case?

[US} Yes. UAS can send new request on that dialog with Cseq with 1 too.

I actually didn't see Cseq violations from the UAC side, just the issue
where the Cseq from UAC and UAS requests were same and UAC was
complaining about it.

Thanks
M

-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat at cisco.com]
Sent: Thursday, February 01, 2007 8:41 PM
To: Manpreet Singh
Cc: sip-implementors at cs.columbia.edu; discussion at sipforum.org
Subject: Re: [Sip-implementors] CSeq Number implementation

CSeq numbering is independent for requests originated by each end.

Note that while the UAC is expected to use consecutive values, the UAS
is expected to allow gaps in the numbering. This is needed in case
messages get lost along the way.

There are some pretty interesting and useful things that can be done by
the UAC violating its rule and jumping the CSeq value by more than one
in some cases. I expect those are present in the wild, so you'd best be
tolerant of that. (E.g. this can help in implementing failover of
dialogs to another
server.)

Also remember that the first CSeq value in a dialog must be in range
0:2^31-1 (positive) but that it may increment so as to become >= 2^32,
so you must be prepared for values that appear negative. (Its really an
unsigned value.) There seems to be a limit of 2^31 requests per dialog.
I doubt this will be a problem any time soon.

Paul

Post by Manpreet Singh
Based on the spec, the CSeq numbers should increase monotonically from
the previous requests within the same dialog.
Requests within a dialog MUST contain strictly monotonically
increasing and contiguous CSeq sequence numbers (increasing-by-one)
in each direction.
It is possible for the
CSeq sequence number to be higher than the remote sequence number

by

Post by Manpreet Singh
more than one.
So based on what is said above, the CSeq number MUST be higher between
multiple requests. Now does this rule hold on the direction of
A--------------Invite( Cseq = 101 )------------>B
<-------------200OK----------------------------
----------------ACK----------------------------->
At this point, B wants to change the session parameter and sends a new
offer.
<----------------Re-Invite ( CSeq = 101 )--------
--------------------------200OK------------------------->
<-----------------------ACK------------------------------
Now for CSeq numbering schema, does it have to consistent between both
directions in the dialog. So basically B cannot send CSeq of 101 as A
already used it and it needs to send 102 or anything greater than 101?
I know for requests in the same direction, CSeq would have to increase
so if A needs to send a re-Invite or BYE or any mid call requests, it
would send 102 and so on. But would the UA on the termination side
have to stick to this rule too or this rule only applies to subsequent
requests in the same direction? Is that what the spec is meaning to
say in the line stated above and based on that, the call flow would be
invalid and B will get 500 or something?
Can someone put more light on the CSeq number implementation when
requests are flowing from both directions.
Thanks
M
_______________________________________________
Sip-implementors mailing list
Sip-implementors at cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

[Sanjay Sinha (sanjsinh)]

Post by Manpreet Singh
-----Original Message-----
From: sip-implementors-bounces at cs.columbia.edu
[mailto:sip-implementors-bounces at cs.columbia.edu] On Behalf Of
Manpreet Singh
Sent: Thursday, February 01, 2007 8:45 PM
To: Paul Kyzivat (pkyzivat)
Cc: discussion at sipforum.org; sip-implementors at cs.columbia.edu
Subject: Re: [Sip-implementors] CSeq Number implementation
Paul
So if the numbering is independent from each end, then if a
UAC sends a Cseq
101 in its initial request then receiving a request from the
UAS can be 101 or even less then 101 right? Would it be valid
if the UAS sends a request with Cseq 100 or 99, something
lower than 101 in this case?

Yes it is valid. UAC & UAS have their own CSEQ number space and each
side is free to start with a number it wants.

Sanjay

Post by Manpreet Singh
I actually didn't see Cseq violations from the UAC side, just
the issue where the Cseq from UAC and UAS requests were same
and UAC was complaining about it.
Thanks
M
-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat at cisco.com]
Sent: Thursday, February 01, 2007 8:41 PM
To: Manpreet Singh
Cc: sip-implementors at cs.columbia.edu; discussion at sipforum.org
Subject: Re: [Sip-implementors] CSeq Number implementation
CSeq numbering is independent for requests originated by each end.
Note that while the UAC is expected to use consecutive values,
the UAS is expected to allow gaps in the numbering. This is
needed in case messages get lost along the way.
There are some pretty interesting and useful things that can
be done by the UAC violating its rule and jumping the CSeq
value by more than one in some cases. I expect those are
present in the wild, so you'd best be tolerant of that. (E.g.
this can help in implementing failover of dialogs to another
server.)
Also remember that the first CSeq value in a dialog must be in range
0:2^31-1 (positive) but that it may increment so as to become

= 2^32, so you must be prepared for values that appear

negative. (Its really an unsigned value.) There seems to be a
limit of 2^31 requests per dialog.
I doubt this will be a problem any time soon.
Paul

Based on the spec, the CSeq numbers should increase

monotonically from

the previous requests within the same dialog.
Requests within a dialog MUST contain strictly monotonically
increasing and contiguous CSeq sequence numbers

(increasing-by-one)

in each direction.
It is possible for the
CSeq sequence number to be higher than the remote

sequence number by

more than one.
So based on what is said above, the CSeq number MUST be

higher between

multiple requests. Now does this rule hold on the direction of
A--------------Invite( Cseq = 101 )------------>B
<-------------200OK----------------------------
----------------ACK----------------------------->
At this point, B wants to change the session parameter and

sends a new

offer.
<----------------Re-Invite ( CSeq = 101 )--------
--------------------------200OK------------------------->
<-----------------------ACK------------------------------
Now for CSeq numbering schema, does it have to consistent

between both

directions in the dialog. So basically B cannot send CSeq of

101 as A

already used it and it needs to send 102 or anything greater

than 101?

I know for requests in the same direction, CSeq would have

to increase

so if A needs to send a re-Invite or BYE or any mid call

requests, it

would send 102 and so on. But would the UA on the termination side
have to stick to this rule too or this rule only applies to

subsequent

requests in the same direction? Is that what the spec is meaning to
say in the line stated above and based on that, the call

flow would be

invalid and B will get 500 or something?
Can someone put more light on the CSeq number implementation when
requests are flowing from both directions.
Thanks
M
_______________________________________________
Sip-implementors mailing list
Sip-implementors at cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

_______________________________________________
Sip-implementors mailing list
Sip-implementors at cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

[Robert Sparks]

Each end of the dialog has its own CSeq sequence. They are independent.
The first time B (in your example) sends an in-dialog request, it
makes a new CSeq up that has nothing to do with the CSeq that A chose.
After that it increments its CSeqs as it goes and makes sure the ones
from A keep going up as well.

Search for the phrases "remote sequence" and "local sequence" in
RFC3261 sections 12.1 and 12.2 for more detail.

RjS

Post by Manpreet Singh
Based on the spec, the CSeq numbers should increase monotonically
from the previous requests within the same dialog.
Requests within a dialog MUST contain strictly monotonically
increasing and contiguous CSeq sequence numbers (increasing-by-one)
in each direction.
It is possible for the
CSeq sequence number to be higher than the remote sequence
number by
more than one.
So based on what is said above, the CSeq number MUST be higher
between multiple requests. Now does this rule hold on the direction
A--------------Invite( Cseq = 101 )------------>B
<-------------200OK----------------------------
----------------ACK----------------------------->
At this point, B wants to change the session parameter and sends a
new offer.
<----------------Re-Invite ( CSeq = 101 )--------
--------------------------200OK------------------------->
<-----------------------ACK------------------------------
Now for CSeq numbering schema, does it have to consistent between
both directions in the dialog. So basically B cannot send CSeq of
101 as A already used it and it needs to send 102 or anything
greater than 101? I know for requests in the same direction, CSeq
would have to increase so if A needs to send a re-Invite or BYE or
any mid call requests, it would send 102 and so on. But would the
UA on the termination side have to stick to this rule too or this
rule only applies to subsequent requests in the same direction? Is
that what the spec is meaning to say in the line stated above and
based on that, the call flow would be invalid and B will get 500 or
something?
Can someone put more light on the CSeq number implementation when
requests are flowing from both directions.
Thanks
M
_______________________________________________
This is the SIP Forum discussion mailing list
TO UNSUBSCRIBE, or edit your delivery options, please visit http://
sipforum.org/mailman/listinfo/discussion
Post to the list at discussion at sipforum.org

[Jerry Yin]

Hi,

I have a question regarding to the rport RFC. It only addressed the Server
Behavior for responses. How about Requests from Server (or callee) to the
UAC, such as re-Invite from callee to caller. If these requests are still
sent to the "contact" address, would it be blocked by the NAT firewall?

Regards,
Jerry