SIP precondition is a session setup mechanism that keeps alerting and final call establishment from progressing until required resources are ready. In IMS and VoLTE, the most common precondition type is QoS precondition, where SDP attributes describe whether local and remote media resources have reached the desired state.
The mechanism is mainly visible in INVITE, 183 Session Progress, PRACK, UPDATE, and 200 OK messages. The signaling exchange uses SIP option tags such as
This page explains why precondition is used, how RFC 3312 and IMS specifications apply it, how to read the SDP parameters, and how a full MO VoLTE sequence reaches the state where ringing and final answer can continue.
Contents
- Why Precondition?
- How It Is Implemented
- How Precondition Is Indicated in a Message
- Require vs Supported
- Precondition Type
- How to Evaluate the Condition
- Requirement for SDP Negotiation
- Full Sequence Example 1: MO VoLTE with Precondition
Why Precondition?
Precondition is used to prevent the call from alerting the far end before the media path is likely to work. This is important for IMS voice because the SIP dialog, radio bearer setup, IP bearer policy, and media resource reservation are not always completed at the same time.
The motivation for Precondition is also well described in RFC 3312.
Some architectures require that at session establishment time, once the callee has been alerted, the chances of a session establishment failure are minimum. One source of failure is the inability to reserve network resources for a session. In order to minimize "ghost rings", it is necessary to reserve network resources for the session before the callee is alerted.
In practical IMS troubleshooting, this means that INVITE processing should wait until the required QoS state is reached. If the precondition state is not satisfied, ringing or final answer can be delayed until the SIP/SDP exchange and bearer setup make the media session usable.
How It Is Implemented
Precondition behavior is defined by RFC 3312 and then constrained by IMS profiles such as 3GPP TS 24.229 and GSMA IR.92. The common idea is the same: SIP option tags announce whether preconditions and reliable provisional responses are supported or required, while SDP attributes carry the current, desired, and confirmation state for media resources.
RFC 3312
For the implementation, we have to think about two things. "How do we define the precondition ?" and "How we convey the message (the information on precondition)".
The 'definition (information)' is specified in several properties in SDP as follows in RFC 3312.
current-status = "a=curr:" precondition-type
SP status-type SP direction-tag
desired-status = "a=des:" precondition-type
SP strength-tag SP status-type
SP direction-tag
confirm-status = "a=conf:" precondition-type
SP status-type SP direction-tag
precondition-type = "qos" | token
strength-tag = ("mandatory" | "optional" | "none"
= | "failure" | "unknown")
status-type = ("e2e" | "local" | "remote")
direction-tag = ("none" | "send" | "recv" | "sendrecv")
Then how these information are exchanged between the sender and the receiver. RFC 3312 also shows an example as shown below. (The best way to understand how it is implemented would be to go through a real protocol log. I will post a real log as soon as I get it).
Overall description of this flow can be as follows and the detail may vary a little depending on specific situations.
A UE (UA) send INVITE to initiate a session for a specific services. At this step, UE send SDP offer and usually this SDP carries information about media
Note : In some application, especially in LTE, the other party (called party) send 100 Trying after the INVITE. But it doesn't seem to be mandatory according to RFC.
The other party (Called Party) is sending 183 Session Progress. It basically saying "I received your INVITE message and am doing something to make this work". In theory, this is just a simple provisioning message for information purpose, but depending on the parameters carried by this message this can be a very crucial message.
One example is when this message carries following header. This means 'this session requires Precondition.' and 'this message requires 100 rel'. What is 100 rel required ? It means 'Since this message would carry very important contents, I want to get conformation (PRACK) from the other party'. Usually Provisoning message like 183 does not require any response from the other party, but if it carries header 'Require: 100rel', the other party should send specific confirmation message called PRACK.
Usually when a provisioning message carries very important contents like SDP, it adds 'Require: 100rel' to make it sure that the other party successfully received the message.
Require: precondition
Require: 100rel
This SIP message clip highlights the following parameters: Require. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.
Since this message set 'Precondition = Required', it start exchanging the required qos parameters as shown below. 'des (desired):qos' defines the final qos condition for this session, 'curr(current):qos' means the qos condition that we currently achieved. In this setting, both 'curr:qos local' and 'curr:qos remote' is set to be 'none' since we are at the stage where no resource is allocated in either local nor remote side.
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
This is a kind of confirmation message for 183 Session Progress. This means "I received 183 Session Progress message that you sent". In some cases, PRACK can carry SDP in it. Depending on whether PRACK carries SDP or not, or Depending on the detailed qos setting in the SDP, there can be some variations on UPDATE process. Refer to Requirement for SDP Negotiation section for details.
This is just response for PRACK. This can be very simple 200OK, or it can be more complicated message carrying SDP in it.
UPDATE message is sent from the Calling party to the called party. Main purpose of this message is "OK, now I am ready to establish the session at least on my side. This and this kind of media can be setup. This and this kind of qos (resource allocation) is confirmed". I means the calling party send out this message only when the required resource/condition is guaranteed.
One example of the required condition in LTE case would be the completion of Dedicated EPS Bearer Setup. It implies 'UPDATE would be sent out after Dedicated EPS Bearer Setup'. (At the early stage of IMS implementation, I saw most of UE does not care about this condition, but in more recent UEs (as of late 2014) I saw most of UE mandate 'Dedicated EPS Bearer' as a precondition for UPDATE. If you have problem with missing 'UPDATE' message when you were expecting it, first check if 'Dedicated EPS Bearer' is established and then check as described in Requirement for SDP Negotiation
One example of qos setting in the SDP in UPDATE message is as follows. In this example, you would see 'qos for local satisfies the requirement' now because "curr:qos local sendrecv >= des:qos mandatory local sendrecv" (see How to evaluate the condition ? for the details)
a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
This is response(confirmation) to UPDATE. Also, another important functionality of this message is to carry the SDP with qos parameter. One example of qos parameter in this SDP is as follows. you would see 'qos for both local and remote satisfies the requirement and ' now because "curr:qos local sendrecv >= des:qos mandatory local sendrecv and curr:qos remote sendrecv >= des:qos mandatory remote sendrecv" (see How to evaluate the condition ? for the details)
a=curr:qos local sendrecv
a=curr:qos remote sendrecv
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
Once you see this state of qos setting, it means both local and remote side are all ready to establish a communication.
At this step, both called party and calling party would hear ringing sound. Since this is an important step, it would carry the following header.
Require: 100rel
This SIP message clip highlights the following parameters: Require. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.
This means PRACK is required at next step.
This is the response (confirmation) for 180 Ringing with 100 rel.
This is the response (confirmation) for PRACK
This is the response (confirmation) for INVITE
This is the response (confirmation) for 200 OK (INVITE)
3GPP TS 24.229
5.1.3.1 Initial INVITE request (MO Call)
- The preconditions mechanism should be supported by the terminating UE
- The "integration of resource management and SIP" extension is hereafter in this subclause referred to as "the precondition mechanism" and is defined in RFC 3312 as updated by RFC 4032
- In case of the precondition mechanism being used on both sides, this confirmation will be sent in either a PRACK request or an UPDATE request.
- In case of the precondition mechanism not being supported on one or both sides, alternatively a reINVITE request can be used for this confirmation after a 200 (OK) response has been received for the initial INVITE request.
- In case the terminating UE does not support the PRACK request (as described in RFC 3262) and does not support the UPDATE request (as described in RFC 3311).
5.1.4.1 Initial INVITE request (MT Call)
- The preconditions mechanism should be supported by the terminating UE
- The "integration of resource management and SIP" extension is hereafter in this subclause referred to as "the precondition mechanism" and is defined in RFC 3312 as updated by RFC 4032
GSMA IR.92
2.4.1 SIP Precondition Considerations
- The UE must support the SIP preconditions framework, as specified in 3GPP TS 24.229. Operators can disable the use of preconditions in the network; the means by which this takes place is outside the scope of this document.
- The terminating UE implementation must not rely on the use of preconditions by the originating UE
How Precondition Is Indicated in a Message
Precondition support is visible in both SIP headers and SDP body lines. SIP headers such as
INVITE sip:user1@192.168.1.11:37607 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.12:64700;branch=z9hG4bK635101086023655710;rport;transport=UDP
Max-Forwards: 69
Call-ID: 635101086023565705@192.168.1.2
CSeq: 6 INVITE
Via: SIP/2.0/UDP 192.168.1.2:64627;branch=z9hG4bK635101086023565705;transport=UDP
To: <sip:user1@anritsu-cscf.com>
From: <sip:0123456789@anritsu-cscf.com>;tag=1111111111
Contact: <sip:0123456789@anritsu-cscf.com:64627;transport=udp>
Allow: INVITE, UPDATE, ACK, CANCEL, BYE, PRACK, MESSAGE
Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-application.ims.iari.gsma-vs";require;explicit
Privacy: id
Content-Type: application/sdp
Content-Length: 565
This SIP message clip highlights the following parameters: Via, Contact, CSeq, Call-ID, From, To, Content-Type, Content-Length, Accept-Contact, Max-Forwards, Supported, Allow, Privacy. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.
Record-Route: <sip:192.168.1.2;lr>
INVITE sip:0123456789;phone-context=one.att.net@one.att.net;user=phone SIP/2.0
Allow: INVITE,ACK,OPTIONS,CANCEL,BYE,UPDATE,INFO,REFER,NOTIFY,MESSAGE,PRACK
This SIP message clip highlights the following parameters: Allow. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.
P-Preferred-Identity: <sip:310410123456789@one.att.net>
User-Agent: SAMSUNG IMS CLIENT 4.0
This SIP message clip highlights the following parameters: User-Agent. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.
P-Preferred-Service: urn:urn-7:3gpp-service.ims.icsi.mmtel
CSeq: 1 INVITE
Max-Forwards: 70
P-Access-Network-Info: 3GPP-E-UTRAN-FDD;utran-cell-id-3gpp=31041000010000000
Route: <sip:[2001:0:0:2::2]:5060;lr>
a: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
c: application/sdp
f: <sip:310410123456789@one.att.net>;tag=2763466811
i: 2270680280
l: 733
m: <sip:310410123456789@[2001:0:0:2::1]:5060;transport=UDP>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
t: <sip:0123456789;phone-context=one.att.net@one.att.net;user=phone>
v: SIP/2.0/TCP [2001:0:0:2::1]:5060;branch=z9hG4bK932432170smg;transport=TCP
This SIP message clip highlights the following parameters: Route, CSeq, P-Access-Network-Info, Max-Forwards. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.
SIP/2.0 183 Session Progress
Max-Forwards: 70
Via: SIP/2.0/TCP [2001:0:0:2::1]:5060;branch=z9hG4bK932432170smg;transport=TCP
From: <sip:310410123456789@one.att.net>;tag=2763466811
To: <sip:0123456789;phone-context=one.att.net@one.att.net;user=phone>;tag=1111111111
Call-ID: 2270680280
CSeq: 1 INVITE
Contact: <sip:0123456789@[2001:0:0:2::2]:65094;transport=tcp>
This SIP message clip highlights the following parameters: Via, Contact, CSeq, Call-ID, From, To, Max-Forwards. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.
Record-Route: <sip:[2001:0:0:2::2];lr>
Content-Type: application/sdp
This SIP message clip highlights the following parameters: Content-Type, Require. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.
RSeq: 1
Content-Length: 763
Privacy: none
This SIP message clip highlights the following parameters: Content-Length, Privacy. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.
P-Asserted-Identity: <sip:0123456789>;phone-context=one.att.net@one.att.net;user=phone
Require vs Supported
The difference between
RFC 3262 4.UAC Behavior says :
When the UAC creates a new request, it can insist on reliable delivery of provisional responses for that request. To do that, it inserts a Require header field with the option tag 100rel into the request. A Require header with the value 100rel MUST NOT be present in any requests excepting INVITE, although extensions to SIP may allow its usage with other request methods
If the UAC does not wish to insist on usage of reliable provisional responses, but merely indicate that it supports them if the UAS needs to send one, a Supported header MUST be included in the request with the option tag 100rel. The UAC SHOULD include this in all INVITE requests.
If a provisional response is received for an initial request, and that response contains a Require header field containing the option tag 100rel, the response is to be sent reliably. If the response is a 100 (Trying) (as opposed to 101 to 199), this option tag MUST be ignored, and the procedures below MUST NOT be used.
Precondition Type
The precondition type identifies what kind of readiness must be satisfied before the session can continue. IMS voice traces usually use
|
Precondition-Type |
Description |
Specification |
|
conn |
Connectivity precondition |
RFC5898 |
|
qos |
Quality of Service preconditions |
RFC3312 |
|
seq |
Security precondition |
RFC5027 |
How to Evaluate the Condition
How to know whether the precondition is met and allowed to go forward or not ?
The answer to this question is simple. It is as follows :
Current condition (Resource Readiness) >= Desired Condition (Resource Requirement)
I think an example from RFC 3312 can be the best explanation for this. The example in the specification says as follows :
The following values for current and desired status would not allow session establishment to resume:
current status = resources reserved in the send direction
desired status = resources reserved in both (sendrecv) directions
On the other hand, the values of the example below would make session establishment resume:
current status = resources reserved in both (sendrecv) directions
desired status = resources reserved in the send direction
Now let me give you some example from real SIP transaction.
|
Message |
Comments |
|
This shows an example showing 'Neither remote nor local is ready for communication' because i) desired qos for local says 'sendrecv' is required, but current qos for local says 'none' (no resource ready). ii) desired qos for remote says 'sendrecv' is required, but current qos for remote says 'none' (no resource ready). |
See RFC 3312
|
|
Message |
Comments |
|
This shows an example showing 'both local and remote is ready for communication' because i) desired qos for local says 'sendrecv' is required, and current qos for local says 'sendrecv' (sendrecv is ready). ii) desired qos for remote says 'sendrecv' is required, and current qos for remote says 'sendrecv' (sendrecv ready). |
See RFC 3312
|
|
Message |
Comments |
|
This shows an example showing 'remote is ready but local is not ready for communication' because i) desired qos for local says 'sendrecv' is required, and current qos for local says 'none' (resource is ready). ii) desired qos for remote says 'sendrecv' is required, and current qos for remote says 'sendrecv' (sendrecv ready). |
See RFC 3312
|
Requirement for SDP Negotiation
The UPDATE requirement depends on what information has already been exchanged in the INVITE, 183 Session Progress, and PRACK sequence. If PRACK confirms the required SDP state, UPDATE may not be needed. If PRACK lacks SDP or lacks the required QoS attributes, UPDATE is normally needed to report the updated precondition state.
One of the key requirement for the implementation of Precondition is how to perform SDP negotiation. There are several different cases to perform the SDP negotiation and I experienced a lot of case of testing problem related to this negotiation process and I am still (as of end of 2013) see these problems for some devices.
Case 1: PRACK carries SDP and QoS attributes
: In this case, SDP go through with PRACK process and SDP in PRACH carries the required QoS parameter as shown below, and following UPDATE process is not mandatory (But in most devices, I saw most UE UE performs both PRACK and UPDATE process.
Case 2: PRACK carries SDP without QoS attributes
: In this case, UE send SDP piggybacked in PRACK but it does not carry the required QoS parameter in it. In this case, UPDATE process is required after it. One of the common problem happens when UE send SDP without the required QoS parameter in it but does not initiate UPDATE procedure. In this case, Network keep waiting UPDATE message without going through next step and UE also keep waiting for Network to go through next step creating some kind of deadlock situation. Finally call setup timer expires and UE or NW would initiate CANCEL procedure.
Case 3: PRACK carries no SDP
: In this case, PRACK from UE does not carry SDP at all. In this case, UPDATE process is required after it. One of the common problem happens when UE complete PRACK without SDP but does not initiate UPDATE procedure. In this case, Network keep waiting UPDATE message without going through next step and UE also keep waiting for Network to go through next step creating some kind of deadlock situation. Finally call setup timer expires and UE or NW would initiate CANCEL procedure.
Full Sequence Example 1: MO VoLTE with Precondition
This example shows a mobile-originated VoLTE call where precondition and reliable provisional response handling are used together. The key state transition is that the initial 183 response advertises required QoS, the UE confirms or updates its local readiness, and the network proceeds toward ringing and final answer after the required media conditions are satisfied.
INVITE sip:0123456789;phone-context=test.net@test.net;user=phone SIP/2.0
Allow: INVITE,ACK,OPTIONS,CANCEL,BYE,UPDATE,INFO,REFER,NOTIFY,MESSAGE,PRACK
This SIP message clip highlights the following parameters: Allow. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.
P-Preferred-Identity: <sip:310410123456789@test.net>
User-Agent: TEST IMS CLIENT 4.0
This SIP message clip highlights the following parameters: User-Agent. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.
P-Preferred-Service: urn:urn-7:3gpp-service.ims.icsi.mmtel
CSeq: 1 INVITE
Max-Forwards: 70
P-Access-Network-Info: 3GPP-E-UTRAN-FDD;utran-cell-id-3gpp=31041000010000000
Route: <sip:[2001:0:0:2::2]:5060;lr>
a: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
c: application/sdp
f: <sip:310410123456789@test.net>;tag=2763466811
i: 2270680280
k: 100rel,timer,precondition
l: 733
m: <sip:310410123456789@[2001:0:0:2::1]:5060;transport=UDP>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
t: <sip:0123456789;phone-context=test.net@test.net;user=phone>
v: SIP/2.0/TCP [2001:0:0:2::1]:5060;branch=z9hG4bK932432170smg;transport=TCP
v=0
o=TEST-IMS-UE 1234562 0 IN IP6 2001:0:0:2::1
s=SS VOIP
c=IN IP6 2001:0:0:2::1
t=0 0
m=audio 50000 RTP/AVP 116 107 97 115 111 110
This SIP message clip highlights the following parameters: Route, CSeq, P-Access-Network-Info, Max-Forwards. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.
b=AS:49
a=rtpmap:116 AMR-WB/16000
a=fmtp:116 mode-change-capability=2; max-red=0
a=rtpmap:107 AMR-WB/16000
a=fmtp:107 octet-align=1;mode-change-capability=2; max-red=0
a=rtpmap:97 AMR/8000
a=fmtp:97 mode-change-capability=2; max-red=0
a=rtpmap:115 AMR/8000
a=fmtp
SIP/2.0 100 Trying
Via: SIP/2.0/TCP [2001:0:0:2::1]:5060;branch=z9hG4bK932432170smg;transport=TCP
Max-Forwards: 70
From: <sip:310410123456789@test.net>;tag=2763466811
To: <sip:0123456789;phone-context=test.net@test.net;user=phone>
Call-ID: 2270680280
CSeq: 1 INVITE
Content-Length: 0
This SIP message clip highlights the following parameters: Via, CSeq, Call-ID, From, To, Content-Length, Max-Forwards. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.
SIP/2.0 183 Session Progress
Max-Forwards: 70
Via: SIP/2.0/TCP [2001:0:0:2::1]:5060;branch=z9hG4bK932432170smg;transport=TCP
From: <sip:310410123456789@test.net>;tag=2763466811
To: <sip:0123456789;phone-context=test.net@test.net;user=phone>;tag=1111111111
Call-ID: 2270680280
CSeq: 1 INVITE
Contact: <sip:0123456789@[2001:0:0:2::2]:65094;transport=tcp>
This SIP message clip highlights the following parameters: Via, Contact, CSeq, Call-ID, From, To, Max-Forwards. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.
Record-Route: <sip:[2001:0:0:2::2];lr>
Content-Type: application/sdp
Require: precondition
Require: 100rel
This SIP message clip highlights the following parameters: Content-Type, Require. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.
RSeq: 1
Content-Length: 763
Privacy: none
This SIP message clip highlights the following parameters: Content-Length, Privacy. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.
P-Asserted-Identity: <sip:0123456789>;phone-context=test.net@test.net;user=phone
v=0
o=anritsu 1 1 IN IP6 2001:0:0:2::2
s=SS VOIP
c=IN IP6 2001:0:0:2::2
t=0 0
m=audio 60000 RTP/AVP 116 107 97 115 111 110
b=AS:49
a=rtpmap:116 AMR-WB/16000
a=fmtp:116 mode-change-capability=2; max-red=0
a=rtpmap:107 AMR-WB/16000
a=fmtp:107 octet-align=1;mode-change-capability=2; max-red=0
a=rtpmap:97 AMR/8000
a=fmtp:97 mode-change-capability=2; max-red=0
a=rtpmap:115 AMR/8000
a=fmtp:115 octet-align=1;mode-change-capability=2; max-red=0
a=rtpmap:111 telephone-event/16000
a=fmtp:111 0-15
a=rtpmap:110 telephone-event/8000
a=fmtp:110 0-15
a=sendrecv
a=ptime:20
a=maxptime:240
a=conf:qos remote sendrecv
a=rtcp:60001
PRACK sip:0123456789@[2001:0:0:2::2]:65094;transport=UDP SIP/2.0
RAck: 1 1 INVITE
CSeq: 2 PRACK
Max-Forwards: 70
P-Access-Network-Info: 3GPP-E-UTRAN-FDD;utran-cell-id-3gpp=31041000010000000
Route: <sip:[2001:0:0:2::2];lr>
f: <sip:310410123456789@test.net>;tag=2763466811
i: 2270680280
k: precondition
l: 0
t: <sip:0123456789;phone-context=test.net@test.net;user=phone>;tag=1111111111
v: SIP/2.0/UDP [2001:0:0:2::1]:5060;branch=z9hG4bK367193557smg;transport=UDP
This SIP message clip highlights the following parameters: Route, CSeq, P-Access-Network-Info, Max-Forwards. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.
SIP/2.0 200 OK
Max-Forwards: 70
Via: SIP/2.0/TCP [2001:0:0:2::1]:5060;branch=z9hG4bK1835967788smg;transport=TCP
From: <sip:310410123456789@test.net>;tag=2763466811
To: <sip:0123456789;phone-context=test.net@test.net;user=phone>;tag=1111111111
Call-ID: 2270680280
CSeq: 3 UPDATE
Allow: INVITE, ACK, CANCEL, BYE, PRACK, MESSAGE
Contact: <sip:0123456789@[2001:0:0:2::2]:65094;transport=tcp>
This SIP message clip highlights the following parameters: Via, Contact, CSeq, Call-ID, From, To, Max-Forwards, Allow. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.
Record-Route: <sip:[2001:0:0:2::2];lr>
Content-Type: application/sdp
Content-Length: 743
Privacy: none
v=0
o=anritsu 1 2 IN IP6 2001:0:0:2::2
s=SS VOIP
c=IN IP6 2001:0:0:2::2
t=0 0
m=audio 60000 RTP/AVP 116 107 97 115 111 110
This SIP message clip highlights the following parameters: Content-Type, Content-Length, Privacy. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.
b=AS:49
a=rtpmap:116 AMR-WB/16000
a=fmtp:116 mode-change-capability=2; max-red=0
a=rtpmap:107 AMR-WB/16000
a=fmtp:107 octet-align=1;mode-change-capability=2; max-red=0
a=rtpmap:97 AMR/8000
a=fmtp:97 mode-change-capability=2; max-red=0
a=rtpmap:115 AMR/8000
a=fmtp:115 octet-align=1;mode-change-capability=2; max-red=0
a=rtpmap:111 telephone-event/16000
a=fmtp:111 0-15
a=rtpmap:110 telephone-event/8000
a=fmtp:110 0-15
a=sendrecv
a=ptime:20
a=maxptime:240
a=rtcp:60001
UPDATE sip:0123456789@[2001:0:0:2::2]:65094;transport=TCP SIP/2.0
Proxy-Require: sec-agree
This SIP message clip highlights the following parameters: Proxy-Require. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.
Security-Verify:
CSeq: 3 UPDATE
Max-Forwards: 70
P-Access-Network-Info: 3GPP-E-UTRAN-FDD;utran-cell-id-3gpp=31041000010000000
Route: <sip:[2001:0:0:2::2];lr>
c: application/sdp
f: <sip:310410123456789@test.net>;tag=2763466811
i: 2270680280
l: 738
m: <sip:310410123456789@[2001:0:0:2::1]:5060;transport=UDP>
t: <sip:0123456789;phone-context=test.net@test.net;user=phone>;tag=1111111111
v: SIP/2.0/TCP [2001:0:0:2::1]:5060;branch=z9hG4bK1835967788smg;transport=TCP
v=0
o=TEST-IMS-UE 1234562 1 IN IP6 2001:0:0:2::1
s=SS VOIP
c=IN IP6 2001:0:0:2::1
t=0 0
m=audio 50000 RTP/AVP 116 107 97 115 111 110
This SIP message clip highlights the following parameters: Route, CSeq, P-Access-Network-Info, Max-Forwards. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.
b=AS:49
a=rtpmap:116 AMR-WB/16000
a=fmtp:116 mode-change-capability=2; max-red=0
a=rtpmap:107 AMR-WB/16000
a=fmtp:107 octet-align=1;mode-change-capability=2; max-red=0
a=rtpmap:97 AMR/8000
a=fmtp:97 mode-change-capability=2; max-red=0
a=rtpmap:115 AMR/8000
a=fmtp:115 octet-align=1;mode-change-capability=2; max-red=0
a=rtpmap:111 telephone-event/16000
a=fmtp:111 0-15
a=rtpmap:110 telephone-event/8000
a=fmtp:110 0-15
a=sendrecv
a=ptime:20
a=maxptime:240
SIP/2.0 200 OK
Max-Forwards: 70
Via: SIP/2.0/TCP [2001:0:0:2::1]:5060;branch=z9hG4bK1835967788smg;transport=TCP
From: <sip:310410123456789@test.net>;tag=2763466811
To: <sip:0123456789;phone-context=test.net@test.net;user=phone>;tag=1111111111
Call-ID: 2270680280
CSeq: 3 UPDATE
Allow: INVITE, ACK, CANCEL, BYE, PRACK, MESSAGE
Contact: <sip:0123456789@[2001:0:0:2::2]:65094;transport=tcp>
This SIP message clip highlights the following parameters: Via, Contact, CSeq, Call-ID, From, To, Max-Forwards, Allow. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.
Record-Route: <sip:[2001:0:0:2::2];lr>
Content-Type: application/sdp
Content-Length: 743
Privacy: none
v=0
o=anritsu 1 2 IN IP6 2001:0:0:2::2
s=SS VOIP
c=IN IP6 2001:0:0:2::2
t=0 0
m=audio 60000 RTP/AVP 116 107 97 115 111 110
This SIP message clip highlights the following parameters: Content-Type, Content-Length, Privacy. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.
b=AS:49
a=rtpmap:116 AMR-WB/16000
a=fmtp:116 mode-change-capability=2; max-red=0
a=rtpmap:107 AMR-WB/16000
a=fmtp:107 octet-align=1;mode-change-capability=2; max-red=0
a=rtpmap:97 AMR/8000
a=fmtp:97 mode-change-capability=2; max-red=0
a=rtpmap:115 AMR/8000
a=fmtp:115 octet-align=1;mode-change-capability=2; max-red=0
a=rtpmap:111 telephone-event/16000
a=fmtp:111 0-15
a=rtpmap:110 telephone-event/8000
a=fmtp:110 0-15
a=sendrecv
a=ptime:20
a=maxptime:240
a=rtcp:60001
SIP/2.0 180 Ringing
Max-Forwards: 70
Via: SIP/2.0/TCP [2001:0:0:2::1]:5060;branch=z9hG4bK932432170smg;transport=TCP
From: <sip:310410123456789@test.net>;tag=2763466811
To: <sip:0123456789;phone-context=test.net@test.net;user=phone>;tag=1111111111
Call-ID: 2270680280
CSeq: 1 INVITE
Contact: <sip:0123456789@[2001:0:0:2::2]:65094;transport=tcp>
This SIP message clip highlights the following parameters: Via, Contact, CSeq, Call-ID, From, To, Max-Forwards. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.
Record-Route: <sip:[2001:0:0:2::2];lr>
Require: 100rel
This SIP message clip highlights the following parameters: Require. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.
RSeq: 2
Content-Length: 0
Privacy: none
This SIP message clip highlights the following parameters: Content-Length, Privacy. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.
P-Asserted-Identity: <sip:0123456789>;phone-context=test.net@test.net;user=phone
PRACK sip:0123456789@[2001:0:0:2::2]:65094;transport=UDP SIP/2.0
RAck: 2 1 INVITE
CSeq: 4 PRACK
Max-Forwards: 70
P-Access-Network-Info: 3GPP-E-UTRAN-FDD;utran-cell-id-3gpp=31041000010000000
Route: <sip:[2001:0:0:2::2];lr>
f: <sip:310410123456789@test.net>;tag=2763466811
i: 2270680280
l: 0
t: <sip:0123456789;phone-context=test.net@test.net;user=phone>;tag=1111111111
v: SIP/2.0/UDP [2001:0:0:2::1]:5060;branch=z9hG4bK589904351smg;transport=UDP
This SIP message clip highlights the following parameters: Route, CSeq, P-Access-Network-Info, Max-Forwards. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.
SIP/2.0 200 OK
Max-Forwards: 70
Via: SIP/2.0/UDP [2001:0:0:2::1]:5060;branch=z9hG4bK589904351smg;transport=UDP
From: <sip:310410123456789@test.net>;tag=2763466811
To: <sip:0123456789;phone-context=test.net@test.net;user=phone>;tag=1111111111
Call-ID: 2270680280
CSeq: 4 PRACK
Allow: INVITE, ACK, CANCEL, BYE, PRACK, MESSAGE
Contact: <sip:0123456789@[2001:0:0:2::2]:65487;transport=udp>
This SIP message clip highlights the following parameters: Via, Contact, CSeq, Call-ID, From, To, Max-Forwards, Allow. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.
Record-Route: <sip:[2001:0:0:2::2];lr>
Supported: 100rel
Content-Length: 0
Privacy: none
This SIP message clip highlights the following parameters: Content-Length, Supported, Privacy. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.
SIP/2.0 200 OK
Max-Forwards: 70
Via: SIP/2.0/TCP [2001:0:0:2::1]:5060;branch=z9hG4bK932432170smg;transport=TCP
From: <sip:310410123456789@test.net>;tag=2763466811
To: <sip:0123456789;phone-context=test.net@test.net;user=phone>;tag=1111111111
Call-ID: 2270680280
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, BYE, PRACK, MESSAGE
Contact: <sip:0123456789@[2001:0:0:2::2]:65487;transport=udp>
This SIP message clip highlights the following parameters: Via, Contact, CSeq, Call-ID, From, To, Max-Forwards, Allow. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.
Record-Route: <sip:[2001:0:0:2::2];lr>
Content-Length: 0
Privacy: none
This SIP message clip highlights the following parameters: Content-Length, Privacy. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.
P-Asserted-Identity: <sip:0123456789>;phone-context=test.net@test.net;user=phone
ACK sip:0123456789@[2001:0:0:2::2]:65487;transport=UDP SIP/2.0
CSeq: 1 ACK
Max-Forwards: 70
Route: <sip:[2001:0:0:2::2];lr>
f: <sip:310410123456789@test.net>;tag=2763466811
i: 2270680280
l: 0
m: <sip:310410123456789@[2001:0:0:2::1]:5060;transport=UDP>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
t: <sip:0123456789;phone-context=test.net@test.net;user=phone>;tag=1111111111
v: SIP/2.0/UDP [2001:0:0:2::1]:5060;branch=z9hG4bK2949521758smg;transport=UDP
This SIP message clip highlights the following parameters: Route, CSeq, Max-Forwards. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.