Message Examples
What is 'Precondition' in SIP/IMS ?
It has the same meaning that you may find from any dictionary. It is a 'condition' to be met before 'something' begins.
You only have to understand what is the 'condition' and what is the 'something' in this statement. In short, the condition is 'you must have reserved enough resource' and 'something' is 'any SIP session'.
Precondition is defined in RFC 3312. The RFC describes 'Precondition' as follows.
preconditions require that the participant reserve network resources before continuing with the session. We do not define new quality of service reservation mechanisms; these preconditions simply require a participant to use existing resource reservation mechanisms before beginning the session. ...... A precondition is a set of constraints about the session which are introduced in the offer.
|
|
Why Precondition ?
The motivation for Precondition is also well described in RFC 3312 in very plain language. Thank god, this RFC is not like 3GPP -:)
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.
I think the description in RFC 3312 is described in a way that everybody can understand.. but if I put my own version on motivation for Precondition is as follows. Simply put, 'Don't accept my request when you are not ready." and "Don't request anything when you are not ready." It is waste of time.
How it is implemented ?
There are multiple specification that specifies about Precodition. Even though most of those specification is originated from RFC 3312, there be minor variations (additional requirement) in each specification.
< 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 reciever. 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
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 PRACH carry 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 rining sound. Since this is an important step, it would carry the following header.
Require: 100rel
This means PRACK is required at next step.
This is the response (confirmation) for 180 Rining 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 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 ?
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
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
P-Preferred-Identity: <sip:310410123456789@one.att.net>
User-Agent: SAMSUNG IMS CLIENT 4.0
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
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>
Record-Route: <sip:[2001:0:0:2::2];lr>
Content-Type: application/sdp
RSeq: 1
Content-Length: 763
Privacy: none
P-Asserted-Identity: <sip:0123456789>;phone-context=one.att.net@one.att.net;user=phone
Require vs Supported
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
|
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
One of the key requirement for the implementation of Precodintion 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.
: 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.
: 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.
: 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
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
P-Preferred-Identity: <sip:310410123456789@test.net>
User-Agent: TEST IMS CLIENT 4.0
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
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
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>
Record-Route: <sip:[2001:0:0:2::2];lr>
Content-Type: application/sdp
Require: precondition
Require: 100rel
RSeq: 1
Content-Length: 763
Privacy: none
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
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>
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
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
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
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>
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
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>
Record-Route: <sip:[2001:0:0:2::2];lr>
Require: 100rel
RSeq: 2
Content-Length: 0
Privacy: none
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
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>
Record-Route: <sip:[2001:0:0:2::2];lr>
Supported: 100rel
Content-Length: 0
Privacy: none
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>
Record-Route: <sip:[2001:0:0:2::2];lr>
Content-Length: 0
Privacy: none
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