Sie sind auf Seite 1von 46

SIP Timers

Riku Luostari, Ari Laukkanen


• 04/04/2016

• Strictly for internal use only

1
SIP Timers
Contents

• SIP Protocol Stack


• Transport Layer
• SIP State Machine
• Initial SIP parameters and SIP Timers
• References
• Examples on problem cases related to SIP Timers

2
SIP Timers
Abbreviations
AC Application Characteristics
CN Core Network
CP Client Provisioning
CSCF Call Session Control Function
DDF Device Description Framework
DM Device Management
ICSI IMS Communication Service Identifier
IMS IP Multimedia core network Subsystem
IP Internet Protocol
ISIM IM Services Identity Module
MO Management Object
OMA Open Mobile Alliance
P-CSCF Proxy – CSCF
PDP Packet Data Protocol
SIP Session Initiation Protocol
TU Transaction User
UE User Equipment
USIM Universal Subscriber Identity Module

3
SIP Protocol Stack

4
SIP Protocol Stack Application Layer SIP
Application Layer TU

Transaction
SIP is a layered protocol, comprising the syntax and encoding layer,
Layer
transport layer, transaction layer, and Transaction User (TU) layer.
Transport Layer
The syntax and encoding layer specifies the format and structure of a
SIP message, which can be either a request from a client to a server, or Syntax &
a response from a server to a client. For each request, a method (such Encoding
as INVITE or ACK) is be carried to invoke a particular operation on a
server. For each response, a status code is declared to indicate the
acceptance, rejection or redirection of a SIP request. Transport Layer
TLS
The SIP transport layer defines the behaviour of SIP entities in sending
and receiving messages over the network. All SIP entities must contain TCP/UDP/SCTP
this layer to send/receive messages to/from the underlying transport
medium.
Network Layer
IP
5
SIP Protocol Stack Application Layer SIP
Application Layer TU

Transaction
On top of SIP transport layer is the transaction layer, including the
Layer
INVITE transaction and the non-INVITE transaction. An INVITE
transaction is initiated when an INVITE request is sent; and a Transport Layer
non-INVITE transaction is initiated when a request other than INVITE or
ACK is sent. Each of the transactions consists of a client transaction Syntax &
sending requests and a server transaction responding to requests. Encoding

Residing in the top layer of SIP are the TUs, which can be any SIP
entity. This could be considered as SIP session control. Transport Layer
TLS
Among the four SIP layers, the transaction layer is the most
important layer since it is responsible for request-response TCP/UDP/SCTP
matching, retransmission handling with unreliable transport
medium, and timeout handling when setting up or tearing down a
Network Layer
session.
IP
6
SIP Protocol Stack
Definitions

SIP Transaction Layer adds Cseq and Branch fields:


• CSeq or “Command Sequence” contains an integer and a method name. The CSeq number is
incremented for each new request within a dialog andis a traditional sequence number.
• The branch ID parameter in the Via header field values serves as a transaction identifier, and is
used by proxies to detect loops.

SIP Transport Layer inserts a value of the "sent-by" field into the Via header field:
• This field contains an IP address or host name, and port of the sender. When a response is
received, the client transport examines the top Via header field value. If the value of the "sent-by"
parameter in that header field value does not correspond to a value that the client transport is
configured to insert into requests, the response is silently discarded.

7
SIP Protocol Stack
Definitions

SIP Syntax & Encoding Layer:


• Both Request and Response messages use the basic format of RFC 2822 (even though the syntax
differs in character set and syntax specifics). Both types of messages consist of a start-line, one or
more header fields, an empty line indicating the end of the header fields, and an optional message-
body
• generic-message:
start-line = Request-Line or Status-Line
message-header
CRLF
[ message-body ]

8
SIP Protocol Stack
Request Example – INVITE on TCP
• Network Layer
• IP header – 20B
• TCP header – 32B
• SIP message – here 1873B

• SIP Syntax/Encoding method

• SIP Transport/Transaction here


1206B
• Transport
• Sent-by
• Transaction
• Cseq
• Branch

• SIP Message body – 604B

9
SIP Protocol Stack
Request Example – PRACK on UDP

• Network Layer
• IP header – 20B
• UDP header – 8B
• SIP message – here 1149B

• SIP Syntax/Encoding method:


PRACK/Request – here 35B

• SIP transport/transaction
770B
• SIP Transport (Sent-by)
• Transaction Layer
• Branch
• CSeq

• SIP Message body – here 342B

10
SIP Protocol Stack
Response Example – 183 on TCP

• Network Layer
• IP header – 20B
• UDP header – 8B
• SIP message – here 1389B

• SIP Syntax/Encoding method

• SIP transport/transaction
• SIP Transport (Sent-by)
• Transaction Layer
• Branch
• CSeq

• SIP Message body – here 454B

11
Transport Layer

12
Transport Layer Application Layer SIP
Reliable and unreliable protocols TU

Transaction
Both reliable (TCP and SCTP) and unreliable (UDP) transport protocols Layer
can be used for the delivery of the SIP signaling messages. The
operation of these protocols is not discussed here. Transport Layer

However, the choice of protocol is up to the transmitting entity Syntax /


sending/forwarding the message, whether it is UE or core proxy. It Encoding
seems that core proxies change from UDP to TCP and other way
around even during forwarding messages. Also UE’s can use UDP or
TCP and change between messages. Transport Layer
TLS
Impacting factors in the decision process could be e.g. MTU size, or
possibly need for speed in retransmission mechanism for certain TCP/UDP/SCTP
messages.
Network Layer
As per today (3/2016) SCTP is not commonly used, even though it is
also possible. IP
13
Transport Layer
Transactions and protocols

UE - A Outbound Proxy Inbound Proxy UE - B


UAC - A UAC - B

UDP/TCP/SCTP UDP/TCP/SCTP UDP/TCP/SCTP

Transport Layer

Transport Layer
Transport Layer

Transport Layer

Transport Layer

Transport Layer
UDP/TCP/SCTP UDP/TCP/SCTP UDP/TCP/SCTP

The choice for protocol can be different even for the same message forwarded by proxy.
UE can choose the protocol differently for each message.

14
Transport Layer
Example

Red tag
indicates where
UDP protocol
was chosen by
the sending
element during
this (incomplete)
call setup flow.

15
Transport Layer
Choice of Protocol in client end

RFC specification says that the client side of the transport layer is responsible for sending the
request and receiving responses. The user of the transport layer passes the client transport the
request, an IP address, port, transport, and possibly TTL for multicast destinations. If a request is
within 200 bytes of the path MTU, or if it is larger than 1300 bytes and the path MTU is unknown, the
request MUST be sent using an RFC 2914 congestion controlled transport protocol, such as TCP.

In 3GPP networks the SIP signaling is done over tunneled connections and that creates overhead, in
case of UDP this is the size of IP+UDP+GTP headers = 36B. If the actual size of packet is over
1500B (which is the default for most of the hosts), the packet has to be fragmented and split into two
or more packets. GTP tunneling header also explains why UE’s may send using TCP even at lower
tan 1300B packet sizes.

The GTP extras is the reason why many UE’s use lower than specified 1500B MTU by default and
lower than 1300B threshold for switching to TCP instead of UDP.

At the end it is UE vendor choice how MTU size is set and UDP/TCP choice is done.
16
Transport Layer
Choice of Protocol in client end

QXDM shows the following nv item for VoLTE configuration quite probably
setting the threshold in QC devices.

Parameter Name Description


iTCPThresholdValue Value after which to use TCP instead of UDP. (bytes)

17
Transport Layer
Choice of Protocol in client end - example

Size of the message including all headers is 1942B for this INVITE message, UE has
chosen to use TCP.

Size of this PRACK message including all headers is 733B, UE has chosen to use UDP.

18
Transaction State Machine

19
Transaction State Machine
State Machines - RFC3261

SIP defines the following 4 state machines,

Invite Client Transaction (Section 17.1.1)


Non Invite Client Transaction (Section 17.1.2)
Invite Server Transaction (Section 17.2.1)
Non Invite Server Transaction (Section 17.2.2)

Note that RFC6026 made some modifications to the State Machines, applying
only to the handling of INVITE message 2xx responses. RFC6026 is taken into
account in the following pages.

20
Transaction State Machine
SIP Transaction Relationships on Transaction Layer

UE - A Outbound Proxy Inbound Proxy UE - B


UAC - A UAC - B

Request Request Request

transaction

transaction
transaction

transaction

transaction

transaction
Server

Server

Server
Client
Client

Client
Response Response Response

The transaction layer is responsible for request-response matching, retransmission handling in case of
UDP, and timeout handling.

21
Request from
Client State Timer E send TU, send
Timer F Expiry
request request
Machine for or Transport
Error. Inform TU

NON-INVITE
Trying
Timer F expires
200-699 or transport
response to TU 1xx error, inform TU
1xx to TU

Timer E expiry, Proceeding


1xx
send request
Response
to TU
200-699
response to TU

Completed

Timer K

Terminated
22
Timer A Expiry:
Timer B Expiry
Reset A, resend
Client State INVITE Send INVITE
or Transport
Error. Inform TU
Machine for
INVITE 300-699, ACK
Calling
2xx
sent response 2xx to TU
to TU
1xx
1xx to TU

1xx Proceeding 2xx


1xx to TU 2xx to TU

300-699, ACK
sent resp. to TU 2xx
2xx to TU
300-699, ACK
sent
Completed Accepted
(RFC6026)
Transport
Timer D expiry Timer M
Error, inform
expires
TU
Terminated
Includes RFC6026

23
Request received
Server State pass to TU

Machine for
NON-INVITE
Trying
transport error,
200-699 from inform TU
TU send 1xx
response from TU send
Response

1xx from TU Proceeding


Request
send response
send
response
200-699 from
TU send
response

Completed Request
send
response

Timer J expiry

Transport Error.
Terminated Inform TU
24
INVITE, Pass INVITE
Server State to TU, send 100 if TU
won’t in 200ms
Machine for INVITE Send Transport error
inform TU
INVITE Response

101-199 from
TU send Proceeding
response
300-699 from Transport error
TU send 2xx from TU inform TU
response send response
Timer G expires
send response
INVITE Send 2xx from TU
response send response
Completed INVITE

Transport Error
inform TU ACK
Accepted

Confirmed

Timer H expires Timer L ACK to TU


Timer I
expires
expires

Terminated
25
Includes RFC6026
Transaction State Machine
SIP Responses

1xx: Provisional -- request received, continuing to process the


request;

2xx: Success -- the action was successfully received, understood,


and accepted;

3xx: Redirection -- further action needs to be taken in order to


complete the request;

4xx: Client Error -- the request contains bad syntax or cannot be


fulfilled at this server;

5xx: Server Error -- the server failed to fulfill an apparently


valid request;

6xx: Global Failure -- the request cannot be fulfilled at any


server.

26
Initial Parameters and Timers

27
Initial Parameters and Timers
Initial Parameters

Before UE can construct the first SIP message (i.e. REGISTER) the UE needs the following
information which can be stored in various location in UE (e.g. ISIM, USIM, modem settings, PDP
Context)

• GPRS Access Point configuration ConRefs


• Preference of PDP context for IMS signalling PDPContextOperPref
• IP address for P-CSCF P_CSCF_Address

• SIP Timers T1, T2 and T4 (Timer_T1, Timer_T2, Timer_T4)

• IMS Communication Service IDentifications list ICSI_list.

Contents of above can be changed using IMS Management Object (IMS MO)

28
Initial Parameters and Timers
IMS Management Object (IMS MO)

IMS Management Object (IMS MO) information is stored in various locations in UE and contains the following:

• GPRS Access Point configuration – ConRefs - commonly stored in modem configuration, nv item QC
• Preference of PDP context for IMS signalling – PDPContextOperPref
• IP address for P-CSCF P-CSCF_Address – it may be configured during initial provisioning or via a 3GPP IMS
MO or stored in the ISIM or assigned in the PDP Context

• Timer settings used to initiate SIP timers, variables T1, T2 and T4 - Timer_T1, Timer_T2,
Timer_T4 - commonly stored in modem configuration, nv item QC

• IMS Communication Service IDentifications list - ICSI_list which indicates which ICSI values are supported by
the network, commonly stored in modem configuration, nv item QC
• the private user identity - Private_User_Identity USIM – generated automatically based on IMSI
• all public user identities - Public_user_identity_list USIM – generated automatically based on IMSI
• home network domain name - Home_network_domain_name REALM USIM – generated automatically based
on IMSI,

Contents of above can be changed once connection between UE and IMS is created (QCI5 ) through OMA DM
protocol that can carry new IMS OM contents from IMS to USIM. IMS can also read the contents through the same
29
mechanism.
Initial Parameters and Timers
IMS Parameter Source

In practice the source location of the IMS Parameters can be defined by the operator
and/or UE vendor.

The UE could be set for example to use:


• Only hardcoded values from UE (mostly for UE/network testing purposes)
• ISIM values (US operators)
• Fall-back to USIM if ISIM is empty (some European operators)
• Forced USIM (some European operators, because of known issues with values
stored in ISIM)

30
Initial Parameters and Timers
T1, T2, T4

• T1 - value is an estimate of the Round Trip Time (RTT) of transactions between UE SIP a client
and IMS and defines the initial retransmit time. By default 500ms in RFC, but 2 seconds is adopted
as default value in VoLTE (24.449). T1 is the most important setting and many of the actual timers
are initiated/calculated using it.

• T2 - value identifies the maximum retransmit time to all non-INVITE messages. By default in RFC
this is 4000ms, but 16sec is adopted as default value in VoLTE (24.449).

• T4 - denotes the time the network will take to clear messages between the SIP Client and SIP
Server. By default 5000ms, but 17sec is adopted as default value in VoLTE (24.449).

T1, T2, T4 are mostly not directly used, instead they are used to initiate or to calculate the values for
actual timers Timer A, Timer B, Timer C, … , Timer K

31
Initial Parameters and Timers
Timer A, B, …, K

Timers A, B,…,K are constructed using T1, T2 and T4 settings:


• Timer A is initially set to T1 and defines initial INVITE request retransmission interval for UDP.
Each time INVITE is retransmitted, Timer A is multiplied by A until Timer B expires,
• Timer B is set to 64*T1. It is INVITE transaction timeout timer, which defines the maximum time
the client waits for SIP response from server. Retries are sent until Timer B expires.
• Timer C > 3 min. Proxy INVITE transaction timeout
• Timer D > 128sec for UDP Wait time for response retransmissions. 0 sec. for TCP and SCTP
• Timer E initially T1 Non-INVITE request retransmission interval, UDP only. At each retransmission
Timer A is doubled, up until T2 is met.
• Timer F 64*T1 Non-INVITE transaction timeout timer

32
Initial Parameters and Timers
Timer A, B, …, K

• Timer G initially T1, INVITE response retransmission interval


• Timer H max(64*T1, 32 sec) Wait time for ACK receipt
• Timer I T4 for UDP Wait time for ACK retransmissions 0 sec. for TCP and SCTP
• Timer J 64*T1 for UDP, Wait time for retransmissions of non-INVITE requests 0 sec. for TCP and
SCTP
• Timer K T4 for UDP, Wait time for response retransmissions 0 sec. for TCP and SCTP

33
Initial Parameters and Timers
Timers Summary for VoLTE (TS24.449)
SIP Timer Value to be applied at Value to be applied at the P- Meaning
T1, T2 the UE CSCF toward a UE
T1 2s default 2s default RTT estimate
T2 16s 16s The maximum retransmit interval for non-INVITE requests and INVITE
responses
T4 17s 17s Maximum duration a message will remain in the network

Timer A initially T1 initially T1 INVITE request retransmit interval, for UDP only
Timer B 64*T1 64*T1 INVITE transaction timeout timer
Timer C > 3 min > 3 min proxy INVITE transaction timeout
Timer D >128s >128s Wait time for response retransmits
0s for TCP/SCTP 0s for TCP/SCTP
Timer E initially T1 initially T1 non-INVITE request retransmit interval, UDP only
Timer F 64*T1 64*T1 non-INVITE transaction timeout timer
Timer G initially T1 initially T1 INVITE response retransmit interval
Timer H 64*T1 64*T1 Wait time for ACK receipt.
Timer I T4 for UDP T4 for UDP Wait time for ACK retransmits
0s for TCP/SCTP 0s for TCP/SCTP
Timer J 64*T1 for UDP 64*T1 for UDP Wait time for non-INVITE request retransmits
0s for TCP/SCTP 0s for TCP/SCTP
Timer K T4 for UDP T4 for UDP Wait time for response retransmits
0s for TCP/SCTP 0s for TCP/SCTP

34
Initial Parameters and Timers
Example – non-INVITE on UDP
Timer E and Timer F for non-INVITE messages work almost as Timer A and Timer B for INVITE
messages. E works the same as A, but T2 is used for setting the maximum repetition period for
retransmissions. For example let’s assume T1 is 2sec and T2 =16sec
• first non-INVITE message is sent at time zero.
• First re-transmitted non-INVITE is sent T1 = 2sec later.
• The 2nd retransmission is sent min(2 x 2sec, T2) after the second, 4sec later and so on until…
• Sixth is sent min(2 x 8sec, T2) = 16sec later, and this retransmission period is kept until Timer F =
64xT1 = 128sec expires. Max 8 transmissions are made.

• For 1xx response, Timer E is applied directly for next retransmission and retransmissions continue
until 2xx-6xx is received
• For 2xx-6xx retransmissions are stopped and dialogue goes to ‘Completed’ state and client applies timer K to
buffer any additional response retransmissions after which dialogue is terminated

Timer F = 64 x T1
T1 T1x2 T1x4 T1x8 T1x16 T1x16 T1x16 E
ini 2 3 4 5 6 7 8

35
Initial Parameters and Timers
Example – INVITE on UDP
Timer A and Timer B are the most important ones from INVITE message point of view. For example let’s
assume T1 is 2000ms and that the first INVITE message is sent at time zero.
• First re-transmitted INVITE is sent T1 = 2sec later.
• The 2nd retransmission is sent 2 times 2sec after the second = 4sec later.
• The fourth is sent 2 times 4sec = 8sec sec after the third.
• The time doubles every time until the final INVITE retransmission is sent before Timer B expires
which is set to 64 x T1 = 128sec. This means that INVITE is sent maximum of 7 times.

• Reception of 1xx stops any retransmissions and UE waits for further instructions and dialog is proceeding
• Reception of 2xx stops any retransmissions and UE and dialog is directly terminated.
• Reception of 3xx-6xx stops any retransmissions and UE must generate ACK response, client proceeds to
completed state and UE waits until Timer D expires and after which the dialogue terminates

Timer B = 64 x T1
T1 T1x2 T1x4 T1x8 T1x16 T1x32 E
ini 2 3 4 5 6 7

36
Initial Parameters and Timers
Example from QC UE nv items, extracted with QXDM
Name Description Operator MO ID
TimerSipRegValue SIP registration expiry timer (In Seconds) 600000
TimerSipSubscribeValue SIP subscribe expirey timer (In Seconds) 0
Timer_T1Value SIP T1 timer (In ms) 2000
Timer_T2Value
SIP T2 timer (In ms) 16000
Timer_T4Value SIP T4 timer (In ms) 17000
Timer_TfValue SIP TF timer (In ms) 128000
Timer_TJValue SIP TJ timer (In ms) 128000
Timer_Vzw (Starts from version 3) Timer_VZW for SIP INVITE requests. Value is between 0-30
0
seconds.
TimerEmergencySipRegValue
600000
TimerEmergency_T1Value 2000
TimerEmergency_T2Value 16000
TimerEmergency_T4Value 17000
TimerEmergency_TfValue 128000
TimerEmergency_TJValue 128000
Timer_TBValue NV parameters for TimerB requirement. INVITE transaction timeout timer. Value is between
0
0 to 64*T1. If set to 0, takes default value of 64*T1.
iTCPMaxBackOffTimer TCP Max back off timer 0

37
Timer Optimisation
Considerations

38
Timer Optimisation Considerations
CSFB

If there is no response to INVITE until TimerB/F expires,


• In case of MO call, some of the UE’s may attempt CSFB.
• Several QC devices have been tested positively,
• QC nv item name voipSilentRedialEnabled)
• In case of MT call, TAS may attempt CSFB
• at least Mavenir 03/2016
• Example:

12:43:20.99 SIP INVITE to MS-B from P-CSCF (MS-B)


12:43:30.91 SIP CANCEL by MTAS at (~10 seconds after SIP INVITE)
12:43:31.24 SGsAP-PAGING-REQUEST

Above suggests that TAS applies 10sec TimerB – or uses some other mechanism to
trigger the CANCEL and continues by Paging for CS.
39
Timer Optimisation Considerations
CSFB

If there is no response to INVITE, once TimerB/F expires, some of the UE’s and/or some
TAS are known to attempt to make CSFB after Timer B or F expiry.

This is good, however, with default timer settings Timer B/F expires after 128sec and
hence is not going to provide any improvement from end user perspective, this puts
pressure to reducing T1 value. But to get any sensible Timer B/F values (e.g. <15sec), T1
would need to be 234ms which would result in large number of retransmissions from UE
and hence this should not be applied to UE.

If TAS is able to initiate CSFB, perhaps smaller timer T1 settings could be applied only
there? Or it may have other mechanism/parameters to control the cancellation of INVITE
and moving to CS attempt.

40
References

41
References

IETF RFC3261
IETF RFC6026
3GPP TS 24.449
GSMA – IR92IETF RFC 4028

42
Example problem cases

43
Example Problem Cases
Case 1 - Double Registration, Timer E

UDP, Non-Invite -> Timer E, which is initially set to T1 = 2000ms.

SIP:REGISTER sent twice at 2000ms difference in timestamp, as no response


before Timer E (=T2 = 2sec) expiry.

44
Example Problem Cases
Case 2 – 200-699 response to non-INVITE message

UE receives 504 as response to non-INVITE message -> The process in


Transaction Layer goes to COMPLETED stage and will go to TERMINATED
stage once timer K (=T4 = 16sec) expires.

45
Example Problem Cases
Case 3 – REGISTER Failure, Timer E
This example shows unsuccessful registration. All messages are on UDP and so follow the
UDP/non-INVITE timers.
• first REGISTER message of the failure case is sent at timestamp 0sec
• First re-transmitted REGISTER is sent Timer E = T1 = 2sec later at 2sec.
• The 2nd retransmission is sent min(2 x 2sec, T2) after the second, 4sec later at 6sec.
• The 3rd retransmission is sent min(2 x 4sec, T2) after the second, 8sec later at 14sec.
• T2 here would have limited the following retransmission intervals and process would have ended at
Timer F

46
<Change information classification in footer>