IMS  

 

 

 

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.

 

(1) INVITE

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.

 

(2) 183 Session Progress.

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

 

(3) PRACK

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.

 

(4) 200 OK

This is just response for PRACK. This can be very simple 200OK, or it can be more complicated message carrying SDP in it.

 

(5) UPDATE

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

 

(6) 200 OK

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.

 

(7) 180 Ringing

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.

 

(8) PRACK

This is the response (confirmation) for 180 Rining with 100 rel.

 

(9) 200 OK

This is the response (confirmation) for PRACK

 

(10) 200 OK

This is the response (confirmation) for INVITE

 

(11) ACK

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 ?

< Example >

    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

    Supported: 100rel // Indicate "PRACK" is supported

    Supported: precondition // Indicate "Precondition" is supported

    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>

 

< Example >

    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

    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=one.att.net@one.att.net;user=phone>

    v: SIP/2.0/TCP [2001:0:0:2::1]:5060;branch=z9hG4bK932432170smg;transport=TCP

 

< Example >

    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

    Require: precondition // Indicate "precondition" is required

    Require: 100rel // Indicate "PRACK" is Required

    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).

      a=curr:qos local none

      a=curr:qos remote none

      a=des:qos mandatory local sendrecv

      a=des:qos mandatory remote sendrecv

See RFC 3312

  • 5.1 Generating an offer
  • 5.2 Generating an Answer
  • 7 Status Confirmation
  • 8 Refusing an offer

 

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).

      a=curr:qos local sendrecv

      a=curr:qos remote sendrecv

      a=des:qos mandatory local sendrecv

      a=des:qos mandatory remote sendrecv

See RFC 3312

  • 5.1 Generating an offer
  • 5.2 Generating an Answer
  • 7 Status Confirmation
  • 8 Refusing an offer

 

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).

      a=curr:qos local none

      a=curr:qos remote sendrecv

      a=des:qos mandatory local sendrecv

      a=des:qos mandatory remote sendrecv

See RFC 3312

  • 5.1 Generating an offer
  • 5.2 Generating an Answer
  • 7 Status Confirmation
  • 8 Refusing an offer

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.

 

< Case 1 >

: 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 >

: 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 >

: 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

 

(1) INVITE

    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

 

(2) 100 Trying

    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

 

(3) 183 Session Progress

    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=curr:qos local none// Indicate 'local' is not ready for communication since it does not meet 'des' condition

      a=curr:qos remote none// Indicate 'remote' is not ready for communication since it does not meet 'des' condition

      a=des:qos mandatory local sendrecv

      a=des:qos mandatory remote sendrecv

      a=sendrecv

      a=ptime:20

      a=maxptime:240

      a=conf:qos remote sendrecv

      a=rtcp:60001

 

(4) PRACK

    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

 

(5) 200 OK

    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=curr:qos local sendrecv   // Indicate 'local' is ready for communication since it meets 'des' condition

      a=curr:qos remote sendrecv  // Indicate 'remote' is ready for communication since it meets 'des' condition

      a=des:qos mandatory local sendrecv

      a=des:qos mandatory remote sendrecv

      a=sendrecv

      a=ptime:20

      a=maxptime:240

      a=rtcp:60001

 

(6) UPDATE

    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=curr:qos local sendrecv /// Indicate 'local' is ready for communication since it meets 'des' condition

      a=curr:qos remote none ///Indicate 'remote' is not ready for communication since it does not meet 'des' condition

      a=des:qos mandatory local sendrecv

      a=des:qos mandatory remote sendrecv

      a=sendrecv

      a=ptime:20

      a=maxptime:240

 

(7) 200 OK

    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=curr:qos local sendrecv// Indicate 'local' is ready for communication since it meets 'des' condition

      a=curr:qos remote sendrecv//Indicate 'remote' is ready for communication since it meets 'des' condition

      a=des:qos mandatory local sendrecv

      a=des:qos mandatory remote sendrecv

      a=sendrecv

      a=ptime:20

      a=maxptime:240

      a=rtcp:60001

 

(8) 180 Ringing

    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

 

(9) PRACK

    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

 

(10) 200 OK

    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

 

(11) 200 OK

    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

 

(12) ACK

    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