CSeq sequence apparently out of standard

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Any call from two sipml5 clients connected to WebRTC2SIP with SIP SBC proxy

What is the expected output? What do you see instead?

The call is made correctly even if sometimes the SBC replies to a BYE message 
with a 500 Internal Server Error

What version of the product are you using? On what operating system?

Chrome 27 on windows
WebRTC2SIP Gateway 2.5.1

Please provide any additional information below.

I think cseq number are randomly generated without following unitary increments 
as described in sip rfc3261

On Windows platform generated cseq are small numbers, while on Linux are larger.

Could this be the reason that generates random 500 Internal Server Error?

Are CSeq numbers generated differently on Linux and Windows?

Where can I change, in the code, this behavior? 

Thanks in advance.

Original issue reported on code.google.com by flavioba...@gmail.com on 17 Jul 2013 at 1:42

Attachments:

• SBC2WebRTC_issue.txt
• WebRTC2SBC_issue.txt

[GoogleCodeExporter]

- First CSeq is random then incremented by 1. Standard doesn't require starting 
at 1.
- BYE CSeq is not the same as INVITE CSeq. Check RFC 3261.

Original comment by boss...@yahoo.fr on 17 Jul 2013 at 2:46

• Changed state: Invalid

[GoogleCodeExporter]

Hi Mamadou, happy to work with you again.
I try to understand better as it seems, because of some misinterpretation in 
RFC, something is going wrong between WebRTC and IMS core network.

What we see is that during an established session (confirmed dialog)webRTCGw is 
sending a BYE with a Cseq that has no relation with the CSeq used at the 
beginning of the dialog in the INVITE sent by the caller. This behaviour is 
creating some problems on core side.
Looking at the RFC3261 we've tried to understand what's wrong with it and we've 
found:

12.3 Termination of a Dialog

   Independent of the method, if a request outside of a dialog generates
   a non-2xx final response, any early dialogs created through
   provisional responses to that request are terminated.  The mechanism
   for terminating confirmed dialogs is method specific.  In this
   specification, the BYE method terminates a session and the dialog
   associated with it.  See Section 15 for details.

There we can find:

15.1 Terminating a Session with a BYE Request

15.1.1 UAC Behavior

   A BYE request is constructed as would any other request within a
   dialog, as described in Section 12.

In section 12 we can find:

12.2.1.1 Generating the Request

   A request within a dialog is constructed by using many of the
   components of the state stored as part of the dialog..... (cut)
.....
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.

The only clarification that I ask to you is, does any UA involved in the dialog 
have its own CSeq local sequence ?, or do they have the same CSeq as first 
setted up from the UAC that started the INVITE dialog (caller)?

Because in my opinion this can be the reason of the misinterpretation we are 
having in the core, where the dialog starting UAC (caller) setted up its own 
local sequence number used in INVITE and expect to have it used as local cseq 
also on calee side when new requests inside the dialog are coming from this 
side.

Can you confirm this?

Thanks in advance
BR
Marfi

Original comment by marf...@gmail.com on 17 Jul 2013 at 3:29

[GoogleCodeExporter]

reopening to check later
code to increment cseq: 
https://code.google.com/p/doubango/source/browse/branches/2.0/doubango/tinySIP/s
rc/dialogs/tsip_dialog.c?r=938#325

Original comment by boss...@yahoo.fr on 17 Jul 2013 at 3:48

• Changed state: Accepted

[GoogleCodeExporter]

Hi Marco,
Didn't know "marfing" is your account (thanks to g+)

Original comment by boss...@yahoo.fr on 17 Jul 2013 at 3:55

[GoogleCodeExporter]

I've checked RFC3261 again and tested many other clients/servers. All seems 
correct. What you're missing here is "in each direction". 
- If you send an INVITE then your BYE would have a CSeq++.
- If you received an INVITE then your BYE would have any CSeq.

For example, when I use Linphone to call Xlite:
INVITE (Linphone -> Xlite): CSeq = 18
BYE (Xlite -> Linphone): CSeq = 2

Original comment by boss...@yahoo.fr on 24 Jul 2013 at 9:29

• Changed state: Invalid

[GoogleCodeExporter]

additional info:
http://sipforum.org/pipermail/discussion/2010-August/007722.html
https://lists.cs.columbia.edu/pipermail/sip-implementors/2001-February/000440.ht
ml

Original comment by boss...@yahoo.fr on 24 Jul 2013 at 9:48