|
|||||||||||||||||||||||||||
Message ExamplesWhat 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)
5.1.4.1 Initial INVITE request (MT Call)
< GSMA IR.92 >2.4.1 SIP Precondition Considerations
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 SupportedRFC 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
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.
Requirement for SDP NegotiationOne 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
|
|||||||||||||||||||||||||||