Ticket #1711 (new defect)

Opened 4 years ago

Reversed order of on_call_tsx_state() notifications on incoming request within call

Reported by: nanang Owned by: bennylp
Priority: normal Milestone: Known-Issues-and-Ideas
Component: pjsip Version: trunk
Keywords: Cc:
Backport to 1.x milestone: Backported: no


Incoming request within call will trigger two transaction state changed notifications: RX_MSG & TX_MSG, both notifications are invoked with tsx state COMPLETED and in reversed order, i.e: TX_MSG (outgoing response) first followed by RX_MSG (incoming request).

This is related to the way incoming request is processed by the invite module, i.e: the incoming request is delivered to invite session state handler first, which may send response (note that sending response will shift the tsx state, for example to COMPLETED if it is a final response, and that tsx state shift will trigger on_call_tsx_state() callback with type==TX_MSG), then after invite session state handler is done, on_call_tsx_state() with type==RX_MSG is called. The corresponding code is mod_inv_on_tsx_state() in sip_inv.c.

A simple modification seems to 'fix' this, e.g: notify app first before calling invite session state handler. However it will change the stack behavior, e.g: on call initialization, when receiving 180 response, on_call_tsx_state() will be called while call state is still in CALLING (instead of EARLY, which is current behavior).


  • Ticket #1627 may need to be reverted by fixes in this ticket.
Note: See TracTickets for help on using tickets.