SIP transaction flags

SIP transaction flags

(Emin Gabrielyan)

Consider the following example of a cancelled call setup request:

In the above example:

192.168.1.10 is a SIP phone with a phone number 308 (Budge Tone 100)

192.168.1.11 is a SIP phone with a phone number 309 (Budge Tone 100)

192.168.1.15 is an OpenSER v.1.2.0 proxy server [configuration file]

All 7 messages shown in the diagram are transmitted in scope of one SIP transaction.

It is confirmed by the OpenSER function t_check_trans(), which returns “true” if the current request is associated to an on-going transaction. For this example, the function t_check_trans() returns “false” only for the INVITE request (meaning that INVITE starts a new transaction) and it t_check_trans() returns “true” when processing CANCEL and ACK requests.

The message flags (called also transaction flags) are transaction persistent. It means that if we set some flags while processing the INVITE request, these flags must be visible also when we process all other requests and replies in scope of the same transaction.

This is not the case: The flags which are set for INVITE are visible only when processing 100 (Trying), 180 (Ringing), and 487 (Request Cancelled). However, the flags are not visible when processing CANCEL, 200 (OK), and ACK.

Below is the printout of the proxy server [cfg]. You can see that the flags set in the INVITE are seen only when processing 100, 180, and 487 replies:

0(18096) [ Method INVITE from 192.168.1.10:5060 ]

INVITE sip:309@192.168.1.15 SIP/2.0

Via: SIP/2.0/UDP 192.168.1.10;branch=z9hG4bK94bea4ca587ee4aa

From: <sip:308@192.168.1.15>;tag=98d29722f6c1e57a

To: <sip:309@192.168.1.15>

...

0(18096) [ End of Request (new transaction flags 3) ]

[ Reply 100 (Trying) from 192.168.1.11:5060 concerning INVITE ]

SIP/2.0 100 Trying

Via: SIP/2.0/UDP 192.168.1.15;branch=z9hG4bK2601.4ab8f3e4.0

Via: SIP/2.0/UDP 192.168.1.10;branch=z9hG4bK94bea4ca587ee4aa

From: <sip:308@192.168.1.15>;tag=98d29722f6c1e57a

To: <sip:309@192.168.1.15>

...

[ End of Reply (transaction flags 3) ]

[ Reply 180 (Ringing) from 192.168.1.11:5060 concerning INVITE ]

SIP/2.0 180 Ringing

Via: SIP/2.0/UDP 192.168.1.15;branch=z9hG4bK2601.4ab8f3e4.0

Via: SIP/2.0/UDP 192.168.1.10;branch=z9hG4bK94bea4ca587ee4aa

Record-Route: <sip:192.168.1.15;lr=on;ftag=98d29722f6c1e57a>

From: <sip:308@192.168.1.15>;tag=98d29722f6c1e57a

To: <sip:309@192.168.1.15>;tag=8345c68ebf2e5dc3

...

[ End of Reply (transaction flags 3) ]

0(18096) [ Method CANCEL from 192.168.1.10:5060 ]

CANCEL sip:309@192.168.1.15 SIP/2.0

Via: SIP/2.0/UDP 192.168.1.10;branch=z9hG4bK94bea4ca587ee4aa

From: <sip:308@192.168.1.15>;tag=98d29722f6c1e57a

To: <sip:309@192.168.1.15>

...

0(18096) [ End of Request (transaction flags 0) ]

[ Reply 200 (OK) from 192.168.1.11:5060 concerning CANCEL ]

SIP/2.0 200 OK

Via: SIP/2.0/UDP 192.168.1.15;branch=z9hG4bK2601.4ab8f3e4.0

Via: SIP/2.0/UDP 192.168.1.10;branch=z9hG4bK94bea4ca587ee4aa

From: <sip:308@192.168.1.15>;tag=98d29722f6c1e57a

To: <sip:309@192.168.1.15>;tag=8345c68ebf2e5dc3

...

[ End of Reply (transaction flags 0) ]

[ Reply 487 (Request Cancelled) from 192.168.1.11:5060 concerning INVITE ]

SIP/2.0 487 Request Cancelled

Via: SIP/2.0/UDP 192.168.1.15;branch=z9hG4bK2601.4ab8f3e4.0

Via: SIP/2.0/UDP 192.168.1.10;branch=z9hG4bK94bea4ca587ee4aa

Record-Route: <sip:192.168.1.15;lr=on;ftag=98d29722f6c1e57a>

From: <sip:308@192.168.1.15>;tag=98d29722f6c1e57a

To: <sip:309@192.168.1.15>;tag=8345c68ebf2e5dc3

...

[ End of Reply (transaction flags 3) ]

0(18096) [ Method ACK from 192.168.1.10:5060 ]

ACK sip:309@192.168.1.15 SIP/2.0

Via: SIP/2.0/UDP 192.168.1.10;branch=z9hG4bK94bea4ca587ee4aa

From: <sip:308@192.168.1.15>;tag=98d29722f6c1e57a

To: <sip:309@192.168.1.15>;tag=8345c68ebf2e5dc3

...

0(18096) [ End of Request (transaction flags 0) ]

Full printout of the proxy server is available [htm], [txt], [doc].

A bug in t_check_trans() function?

Another issue is related to the t_check_trans() function when processing ACK requests.

In a simple scenario with an answered call [rfc3261, p.10-11] the ACK message should be considered out of scope of the call setup transaction INVITE / 100 (Trying) / 180 (Ringing) / 200 (OK).

However, when in such scenario processing the ACK message, the t_check_trans() function returns “true” as if the ACK message belongs to an on-going transaction. When invoking t_check_trans() function the second time (while still processing the ACK message), the function returns “false” (which is the correct answer). The answer stays “false” for all further calls of the function (while processing the ACK).

See the OpenSER configuration file [cfg] and the debug printouts of the proxy server for this scenario [htm], [txt], [doc].