in-dialog CSeq number MUST be incremented by 1 -- BYE CSeq same as PRACK CSeq
Closed this issue · 1 comments
GoogleCodeExporter commented
What steps will reproduce the problem?
1. Attached is a trace when PRACK is enabled
2. A calls B and A hangs up
3.
What is the expected output? What do you see instead?
BYE should have a CSeq number higher than PRACK's CSeq
But here it is the same, which is in violation of RFC 3261
According to RFC 3261 section 12.2.1.1
Requests within a dialog MUST contain strictly monotonically
increasing and contiguous CSeq sequence numbers (increasing-by-one)
in each direction (excepting ACK and CANCEL of course, whose numbers
equal the requests being acknowledged or cancelled). Therefore, if
the local sequence number is not empty, the value of the local
sequence number MUST be incremented by one, and this value MUST be
placed into the CSeq header field. If the local sequence number is
empty, an initial value MUST be chosen using the guidelines of
Section 8.1.1.5. The method field in the CSeq header field value
MUST match the method of the request.
BYE is re-using the same CSeq number as that used in PRACK as indicated in the
trace below
SENDING from network to pcsf(1)
[PRACK
sip:QbkRBthOEgsTXgkTBA0HHiUrKz1CQEFCQ0NMNgQMGAlsMTcgK2ghOyAnOCs.ITogYX9jZGV4PjUq
dFVXXlsbV1tbWERLQkwOFgcACBNGCgUGVlheWUA_@pcsf-stdn.imsgroup0-000.ims.demo.alcate
l-lucent.com:5060 SIP/2.0
Via: SIP/2.0/UDP 127.0.0.1;branch=z9hG4bK_001_3797762552-3794627768
Via: SIP/2.0/UDP
192.168.10.145:40627;received=10.8.0.62;branch=z9hG4bK1286255543346;rport=40627
From: <sip:+16145829739@ims.demo.alcatel-lucent.com>;tag=1284673043811
To:
<sip:+16145821597@ims.demo.alcatel-lucent.com>;tag=4ca4a2a9-1285859926621769-gm-
po-lucentPCSF-000019
Contact:
<sip:+16145829739@192.168.10.145:40627;transport=udp>;+g.oma.sip-im;language="en
,fr"
Call-ID: 73aa1663-edeb-decc-faba-8dd855649505
CSeq: 1908602408 PRACK
Content-Length: 0
Max-Forwards: 69
Route: <sip:192.11.69.128:5060;lr;transport=udp>
Route: <sip:pcsf-stdn.imsgroup0-000.ims.demo.alcatel-lucent.com:5060;lr;bidx=0>
Route:
<sip:scsf-stdn.imsgroup0-000.ims.demo.alcatel-lucent.com:5070;lr;ottag=ue_orig;b
idx=12>
P-Preferred-Service: urn:urn-7:3gpp-service.ims.icsi.mmtel
Allow: INVITE,ACK,CANCEL,BYE,MESSAGE,OPTIONS,NOTIFY,PRACK,UPDATE,REFER
Privacy: none
P-Access-Network-Info: ADSL;utran-cell-id-3gpp=00000000
User-Agent: IM-client/OMA1.0 IMSDroid/v1.0.292 (doubango r487)
RAck: 1 1908602407 INVITE
]
SENDING from network to pcsf(1)
[BYE
sip:QbkRBthOEgsTXgkTBA0HHiUrKz1CQEFCQ0NMNgQMGAlsMTcgK2ghOyAnOCs.ITogYX9jZGV4PjUq
dFVXXlsbV1tbWERLQkwOFgcACBNGCgUGVlheWUA_@pcsf-stdn.imsgroup0-000.ims.demo.alcate
l-lucent.com:5060 SIP/2.0
Via: SIP/2.0/UDP 127.0.0.1;branch=z9hG4bK_001_3800387512-3797172088
Via: SIP/2.0/UDP
192.168.10.145:40627;received=10.8.0.62;branch=z9hG4bK1284531147919;rport=40627
From: <sip:+16145829739@ims.demo.alcatel-lucent.com>;tag=1284673043811
To:
<sip:+16145821597@ims.demo.alcatel-lucent.com>;tag=4ca4a2a9-1285859926621769-gm-
po-lucentPCSF-000019
Call-ID: 73aa1663-edeb-decc-faba-8dd855649505
CSeq: 1908602408 BYE
Content-Length: 0
Max-Forwards: 69
Accept-Contact: *;+g.oma.sip-im
Accept-Contact: *;language="en,fr"
P-Preferred-Service: urn:urn-7:3gpp-service.ims.icsi.mmtel
Allow: INVITE,ACK,CANCEL,BYE,MESSAGE,OPTIONS,NOTIFY,PRACK,UPDATE,REFER
Privacy: none
P-Access-Network-Info: ADSL;utran-cell-id-3gpp=00000000
User-Agent: IM-client/OMA1.0 IMSDroid/v1.0.292 (doubango r487)
]
What version of the product are you using? On what operating system?
IMSDroid v1.0.292 doubango r487
Please provide any additional information below.
Original issue reported on code.google.com by saket...@gmail.com on 12 Oct 2010 at 10:06
GoogleCodeExporter commented
Fixed in revision 494.
Will be part of the next release of IMSDroid and iDoubs.
Original comment by boss...@yahoo.fr on 13 Oct 2010 at 11:03
- Changed state: Fixed