[SR-Users] Issue Bug in SEMS (transparent SBC profile)

[Juha Heinanen]

Mojtaba writes:

> Let' me describe the scenario:
> <UE>---------><SEMS>-----------><ASTERISK>
> The UE tries to make calls, The first INVITE message is without an
> Authentication header. The Asterisk server returns 401 Unauthorized.
> The UE sends again INVITE messages to the asterisk server. The second
> INVITE message has an Authentication header. Because both INVITE messages
> have the same CSeq, the asterisk server thinks this is a LOOP message and
> sends 401 Unautirozed messages again.
> In both cases, the Sems set "CSeq: 10 INVITE" header, while the second the
> INVITE message is not re-invite message and the CSeq should be set
> incremental.

As I already quoted, RFC 3261 specifies:

  8.1.1.5 CSeq

  For non-REGISTER requests outside of a dialog, the sequence number
  value is arbitrary.

Section 12.1 tells how dialogs are created:

   Dialogs are created through the generation of non-failure responses
   to requests with specific methods.  Within this specification, only
   2xx and 101-199 responses with a To tag, where the request was
   INVITE, will establish a dialog.

401 is a failure response.  Thus no dialog is created and in the second
INVITE sems is allowed to use whatever CSeq value.

If Asterisk does not allow that, complain Asterisk about it.

-- Juha