Opened 8 years ago

Last modified 7 years ago

#1992 new defect

Set INVITE transaction state to Terminated after sending OK

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

Description (last modified by ming)

According to the RFC 3261:

If, while in the "Proceeding" state, the TU passes a 2xx response to
   the server transaction, the server transaction MUST pass this
   response to the transport layer for transmission.  It is not
   retransmitted by the server transaction; retransmissions of 2xx
   responses are handled by the TU.  The server transaction MUST then
   transition to the "Terminated" state.

Currently, sip_transaction will switch to Completed state upon doing this, and the behavior has been observed from nearly the beginning of PJSIP. There's a flag handle_200resp, which, if set to false, will immediately set the state to Terminated, but it seems that the 200 retransmission is not done anywhere.

Test scenario (sipp xml attached):

  1. PJSIP receives re-INVITE
  2. PJSIP answers 200
  3. Before remote sends ACK another re-INVITE arrives
  4. PJSIP return "500 Another INVITE transaction in progress"

It is desirable that PJSIP can accept the second re-invite (read also ticket #1455). However, it's still unclear who should do the 200 retransmission and handle the ACK (should it be sip_dialog?) and how many it should keep track (what if there are 3 re-invites and the previous two hasn't sent ACK?).

Thanks to Sagi Iltus and Itay Bianco for the report.

Attachments (1)

uas-reinv2.xml (4.1 KB) - added by ming 8 years ago.

Download all attachments as: .zip

Change History (3)

Changed 8 years ago by ming

comment:1 Changed 8 years ago by ming

  • Description modified (diff)

comment:2 Changed 7 years ago by ming

  • Milestone changed from release-2.7 to Known-Issues-and-Ideas
Note: See TracTickets for help on using tickets.