[Asterisk-Dev] SIP-to-SIP release problem on B-side when using reinvite

[Markku Korpi]

There seems to be a bug in release behaviour of *, when a SIP-to-SIP call is
released by A (calling party) and canreinvite=yes.
Namely when A hangs up first, then called party B does not get BYE from *
even though * terminates the call. The call continues to exist on the
B-side, while B just hears silence. If the call release is initiate by B,
then the release procedure works properly. In hope to find someone who
is/was fihgting with this problem, too, I am describing the problem in a bit
more detail, below.

The behaviour is the same with this weekends chan_sip and Olle's latest
chan_sip2. I am continuing with debugging, but perhaps someone already has a
diff or a pointer/hint for fixing of this bug?

The problem does not appear when reinvites are not used, of course. However
in my current case the customer wants to keep the payload traffic caused by
the SIP-to-SIP calls from its servers and therefore wants * to make use of
SIP reinvites.

The problem is extremely deterministic, but nobody else seems to have
complained, since I could not find any bug report or other discussions on
this subject.

For completeness and for the records, this is at first how the call with
reinvites is succesfully established (derived from * sip debug output):
(BTW: In this test A was Siemens Pylix and B was X-lite.)

A ---------Invite----> * -------Invite ----> B
                       * <----100 trying---- B
A <----180 Ringing---- * <----180 Ringing--- B
A <------200 OK------- * <------200 OK------ B
                       * -------Ack--------> B
A <------200 OK------- * <------200 OK------ B
A -------Ack---------> *
at this point call is actually already established, but due to
canreinvite=yes * continues with reinvites to A and B:

A <--------Invite----- * -------Invite ----> B
                       * <----100 trying---- B
                       * <----200 OK ------- B
                       * -------Ack--------> B
                       * -------Ack--------> B
A -------200 ok------> *
A <------Ack---------- *
A <================= talking ==============> B

Now the call is established, BUT now it goes wrong when call is released by
A:

A ---------Bye-------> *
A <------200 OK------- * -------Invite ----> B
               Note 1) * <----100 trying---- B
                       * <----200 OK ------- B
                       * <----200 OK ------- B Note 2)
                       * <--------Bye------- B
                       * -----200 OK ------> B
                       * <----200 OK ------- B
                       * <----200 OK ------- B

Note 1: At this point * sends reinvite to B correctly but immediately exits
the hangup. Instead, * should have waited for 200 and sent Ack in the same
way as it does when B hangs up first (see trace of that case below).
Note 2: B is expecting to get SIP Ack from *, but of course it never comes
because * finished the call already. B tries to repeat 200 OK and then
finally tries BYE, etc.

Now, here is how it works when B releases first, and how it should work in
the above case, too:

                       * <--------Bye------- B
A <------Invite ------ * -----200 OK ------> B
A ------(Trying)-----> *
A -------200 OK------> *
A <------Ack---------- *
A <------Bye---------- *
A -------200 OK------> *
As you can see, * retrieves at first the call from  the endpoint by means of
the (re)invite , and then executes call clearing. After this A hears busy
tone (from its its VoIP box) and will hang up.

Before I start making and applying a bug fix for this: Does this sound
familiar to anyone? How did you fix the problem?

Markku Korpi