A SIP transaction is a request and one or several responses. The INVITE transaction is special, it's a three-way handshake request - response - ack

Responses are divided into temporary responses and final responses. A final response closes the transaction, temporary responses just updates the transaction.

Some transactions will open a new SIP dialog, some will not. Some transactions are allowed within an active dialog, some are not.

Transactions and chan_sip The current version of chan_sip.c does not have much notion of a SIP transaction or a dialog. Each transaction will update the dialog, so only the last request is remembered and the direction of the last request.

While this can be seen as effective, it does not allow for situations with multiple concurrent transactions. Most importantly, the INVITE transaction can be open for a long time (Ringing) and other things may happen at the same time.

We do need to change chan_sip3 so that the transaction state engine works properly.

Random thoughts

Integrate sip_pkt and sip_request - done
Mark the UNACKed packets in dialog->packets with a flag Maybe two lists of packets, to keep it simple for do_monitor? Or a flag when we have no open transactions?
Use sip-request as "transaction holders" within sip_dialog
Keep them in Cseq order
Add transaction state
When do you delete them - 32 secs after first transmit
Then we finally can fix the "ignore" ignorant stuff and resend last response
The first transaction that opened in a dialog needs to be saved for the CANCEL/BYE (in an INVITE transaction)
For SUBSCRIBE dialogs, we need to keep the initial SUBSCRIBE Then unacknowledged NOTIFY transactions. Keep the transaction until timer expires
Queue system for incoming packets?

SIP_dialog

sip_trans Request (our or remote) response (our or remote)
sip_trans

Asterisk is a trademark for Digium, inc.. | Edvina.net | Asterisk.org | This documentation was generated with Doxygen

Asterisk developer's documentation :: Codename Pineapple

Chan_sip3: Implementing transactions