Closed GoogleCodeExporter closed 8 years ago
- 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
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
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
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
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
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
Original issue reported on code.google.com by
flavioba...@gmail.com
on 17 Jul 2013 at 1:42Attachments: