ChallyCai / doubango

Automatically exported from code.google.com/p/doubango
0 stars 1 forks source link

in-dialog CSeq number MUST be incremented by 1 -- BYE CSeq same as PRACK CSeq #22

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
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 9 years ago
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