IMS/SIP                                                          Home : www.sharetechnote.com

 

 

Followings are the topics to be covered in this page.

 

 

Overview

 

IMS (IP Multimedia Subsystem) is one of the terms that I heard most often since I started studying LTE. But this is one of the terms which is still not clear to me -:).

 

This post is to share my understanding as of now (?) with readers and I will try to put information based on my hands-on experience rather than directly coming from the specification. There may be some part which may not be 100% accurate from the real expert's point of view. I think I keep updating this page very often and very long.

 

 

As usual, the first thing I did to know something about IMS when I first heard of it, I put "IMS" in Google and as you may experienced I got a lot of different kind IMS -:). Then I put "LTE IMS" and got pretty much of the result being more relevent to my interest. But I saw from the searched link a lot of material about SIP. Reading through these links, I start asking myself.. "Hmm... Is IMS same as SIP ?".

And then I started search "SIP" in Google. Of course, a lot of result about SIP popped up but I also got almost same amout of the searched result was about "VoIP". Then I asked myself "Hmm... Is SIP as same as VoIP ?".

With the application of transition rule, I thought "Then... Is IMS same as VoIP ?". It took long time for me to get out of this confusion.

 

The latest version of my understanding about the relationship among IMS, SIP, VoIP is as follows ( I think there should be many other arrows in/out of IMS block). As you see, IMS is sitting on top of everything and it control/use SIP for the various media transfer.

Now let's think about SIP (Session Initiation Protocol). As the name implies, SIP is a kind of signaling protocol which mainly involved in "Initiation" and "Closing" of a media transfer. Once a session is initiated, some other protocols kick in the process to transfer the data part of the media. The specific type of prtocol is determined by the type of media data.

 

 

Now let's think about how these IMS chain get involved in LTE SAE structure and I think just one diagram as shown below is good enough for a big picture. (I will put more details later).

 

 

Now let's get a little bit deeper into some of sub topics which would give you more detailed and practical information. For the start, I would describe some topics about SIP first. One reason is that SIP is one of the biggest applications of IMS framework and another reason is that I haven't yet found any small IMS test system I can try with.

 

 

Some Video Tutorials

 

First, if you are a real beginner for IMS and SIP. I recommend you to see the following video a couple of times and it will give you pretty good big pictures.

 

 

 

Overall Data Path for IMS

 

I was sitting in a couple of IMS training course. I noticed the most common questions from both instructors and audience was "How my IMS voice/data get delivered to the other side in this and that kind of situation ?".

The answer never ends and question never stops.. easily eats up the most of training session.

It may be an important question and answer and necessary to understand the details of IMS mechanism, but not easy to come out with "Short and Clear" answer to this kind of questions because there can be so many variation in each cases.

So my intention is not to give you any single solid answer for "IMS Data Path", but to give you some guide line (or logics of thinking) on IMS data delivery.

 

First, I want you to get yourself familiar with the following diagram.

 

There are several common rules which can help you to get the answer for data path by yourself.

  • i) All LTE data and all LTE signaling message has to go through eNodeB at first step.
  • ii) All LTE data (user data) has to go through S-GW and P-GW. (Note : Both IMS Signaling or IMS Data is regarded as a user data in terms of LTE network. This is an important point that would clear a lot of confusion).
  • iii) ALL IMS Signaling Message has to go through P-CSCF
  • iv) IMS Data (e.g, Voice, Video) may not go through any CSCF.
  • v) For every IMS registration, the IMS message (registration message) go through P-CSCF and S-CSCF talk to HSS to check if the user is IMS service subscriber or not.
  • vi) When you (IMS phone, UA1) want to talk to another IMS phone (UA3), IMS core has to check if the other party (UA2) is IMS subcriber and is now registered to IMS core. It is I-CSCF's job to check all these status.  
  • vii) When you (IMS phone, UA1) want to talk to another phone, first your network should check whether the other party (phone) is IMS capable phone or a home phone or just a conventional IP phone, it is ENUM's job to check about this kind of status.
  • viii) Whenever a service is initiated (requested by a UA), CSCF would talk to PCRF if the requested service is allowed for the user.

 

With these rules in mind (I am pretty sure that I would have missed rules), please print out the diagram above and set a specific scenario (e.g, 'I want to make a call from UA1 to UA2' or from UA1 to UA3 etc) and draw the lines for data path. Don't worry about getting wrong.. you may be wrong in a couple of points but at least more than 70% you would be right if you apply the rule listed above.

 

 

Setting up a SIP test environment - 2 PCs

 

For a long time, I have been looking for a small scale server which is free and can be installed on my PC so that I can have some hands-on experience. As in any learning process, I would never fully understand it without doing it myself, coming across various problems, pulling the hair and asking around every person I know and eventually solving the problems.

After a long waiting and searching, finally I found a handy SIP application server that meets all of my requirements.

The test configuration that I setup is as follows. (For any IP related test, try this kind of two PC test and get familiar with operation/mechanism/troubleshooting first before you try with your mobile device (DUT)).

 

 

The software package that I used "3CX Phone System" and you can get it from following links.

 

3CX Phone System Download : http://www.3cx.com/phone-system/

3CX Phone Download : http://www.softpedia.com/get/Internet/Telephony-SMS-GSM/3CX-VOIP-Phone.shtml

YouTube Introductions :

i) Installing 3CX MyPhone

ii) Installing 3CX MyPhone desktop components

 

To enable 3CX Phone System to support VoIP call functionality, you need to purchase a license. But you can use the demo license which will be emailed to you after you download the software. The demo license allows VoIP call between only two phones, but it is good enough for this kind of testing. (You can use 'chat' services between clients even without the license).

 

Installation is pretty straight forward, but setting all the configuration may be a little tricky. If you email me, I can send you ppt slides showing all the configuration for my test setup.

 

Once you get this working, you can try various things like texting, VoIP and even Video call and capturing the IP traffic with Wireshark and these logs can be your text book.

 

 

Setting up a SIP test environment - LTE Network Simulator and LTE Device

 

Following shows the test setup with LTE Network Simulator and LTE Device. (In this case, I used the network interface created by the UE as SIP server port and I configured PDN IP address transmitted by the network simulator to be 192.168.1.231.

 

 

 

SIP Basic Procedures

 

< REGISTRATION with Authentication>

 

 

Following is an example for this process.

 

Step 1 : REGISTER --------------------------------

    REGISTER sip:test.3gpp.com SIP/2.0

    f: <sip:+11234567890@test.3gpp.com>;tag=2722997041

    t: <sip:+11234567890@test.3gpp.com>

    CSeq: 575513373 REGISTER

    i: 2722997021_2363003016@2001::21f:29ff:fe7c:8f51

    v: SIP/2.0/UDP [2001::21f:29ff:fe7c:8f51]:5060;branch=z9hG4bK656994275

    Max-Forwards: 70

    m: <sip:+11234567890@[2001::21f:29ff:fe7c:8f51]:5060>

    P-Access-Network-Info: 3GPP-E-UTRAN-FDD; utran-cell-id-3gpp=3114800102FFFFFFF

    l: 0

    Authorization: Digest uri="sip:test.3gpp.com",

                       username="001010123456789@test.3gpp.com",

                       response="",

                       realm="test.3gpp.com",

                       nonce=""

                       Expires: 7200

     

    Note 1 : Make it sure the 'realm' parameter matches Authentication server domain name. If this does not matches the authentication server, CSCF may send 'Error Code'.

 

Step 2 : 401 UNAUTHORIZED  --------------------------------

    SIP/2.0 401 Unauthorized

    Via: SIP/2.0/UDP [2001::21f:29ff:fe7c:8f51]:5060;branch=z9hG4bK656994275

    From: <sip:+11234567890@test.3gpp.com>;tag=2722997041

    To: <sip:+11234567890@test.3gpp.com>;tag=T3E04A4B5

    Call-ID: 2722997021_2363003016@2001::21f:29ff:fe7c:8f51

    CSeq: 575513373 REGISTER

    Content-Length: 0

    WWW-Authenticate: Digest realm="test.3gpp.com",

                                 nonce="qlWqVapVqlWqVapVqlWqVUUQA5HEt9VVZ3t1TM221cg=",

                                 qop="auth",

                                 opaque="MTcyMjU3ODA2NDo=SU1TLVNJUCBTZXJ2ZXI=",

                                 algorithm=AKAv1-MD5

    P-Associated-URI: <sip:+11234567890@TEST.3GPP.COM>

    P-Associated-URI: <tel:+11234567890>

     

    Note 1 : 'realm' parameter in this message should match the 'realm' parameter in Step 1. Otherwise, UE may not proceed to next step.

    Note 2 : 'algorithm' specified here should be the one supported by UE. Otherwise, UE may not proceed to next step.

 

 

Step 3 : REGISTER -----------------------------------

    REGISTER sip:test.3gpp.com SIP/2.0

    f: <sip:+11234567890@test.3gpp.com>;tag=2722997284

    t: <sip:+11234567890@test.3gpp.com>

    CSeq: 575513374 REGISTER

    i: 2722997021_2363003016@2001::21f:29ff:fe7c:8f51

    v: SIP/2.0/UDP [2001::21f:29ff:fe7c:8f51]:5060;branch=z9hG4bK843051065

    Max-Forwards: 70

    m: <sip:+11234567890@[2001::21f:29ff:fe7c:8f51]:5060>

    P-Access-Network-Info: 3GPP-E-UTRAN-FDD; utran-cell-id-3gpp=3114800102FFFFFFF

    l: 0

    Authorization: Digest username="001010123456789@test.3gpp.com",

                        realm="test.3gpp.com",

                        uri="sip:test.3gpp.com",

                        qop=auth,

                        nonce="qlWqVapVqlWqVapVqlWqVUUQA5HEt9VVZ3t1TM221cg=",

                        nc=00000001,

                        cnonce="11259375",

                        algorithm=AKAv1-MD5,

                        response="a3f549b13f477562f4445b7277cd83c1",

                        opaque="MTcyMjU3ODA2NDo=SU1TLVNJUCBTZXJ2ZXI="

    Expires: 7200

     

    Note 1 : 'realm' parameter in this message should match the 'realm' parameter in Step 2.

    Note 2 : 'algorithm' parameter in this message should match the 'algorithm' parameter in Step 2.

    Note 3 : 'Expires : 7200' means that the registration should be 'renewed' within 7200 seconds.

 

 

Step 4 : 200 OK -----------------------------------

    SIP/2.0 200 OK

    Via: SIP/2.0/UDP [2001::21f:29ff:fe7c:8f51]:5060;branch=z9hG4bK843051065

    From: <sip:+11234567890@test.3gpp.com>;tag=2722997284

    To: <sip:+11234567890@test.3gpp.com>;tag=T44F6AE74

    Call-ID: 2722997021_2363003016@2001::21f:29ff:fe7c:8f51

    CSeq: 575513374 REGISTER

    Contact: <sip:+11234567890@[2001::21f:29ff:fe7c:8f51]:5060>;q=0.500;expires = 7200

    Content-Length: 0

    Date: Mon, 22 Apr 2013 15:43:15 GMT

    Authentication-Info: qop=auth,

                                rspauth="a3f549b13f477562f4445b7277cd83c1",

                                cnonce="11259375",

                                nc=00000001

    P-Associated-URI: <sip:+11234567890@TEST.3GPP.COM>

    P-Associated-URI: <tel:+11234567890>

    P-Associated-URI:  <sip:+11234567890@TEST.3GPP.COM>

    P-Associated-URI: <tel:+11234567890>

 

 

< SUBSCRIBE/NOTIFY >

 

SUSCRIBE message is similar to "Measurement Control" or "Information Request" on Radio Protocol. It request the other party to report on any specific event or specific status.

NOTIFY is similar to "Measurement Report" or "Information Response" on Radio Protocol. Basically it delivers the information that is requested by SUBSCRIBE message.

Overall sequence for SUBSCRIBE and NOTIFY goes as follows.

 

 

 

 

 

Step 1 : SUBSCRIBE -----------------------------------

    SUBSCRIBE sip:+11234567890@test.3gpp.com SIP/2.0

    Via: SIP/2.0/UDP 10.133.202.46:50997;branch=z9hG4bK2968d27245f17c7bcae38c31991bfdaa

    Max-Forwards: 70

    Contact: <sip:+11234567890@10.133.202.46:50997>;+sip.instance="<urn:gsma:imei:00440113-904785-0>"

    To: <sip:+11234567890@test.3gpp.com>

    From: <sip:+11234567890@test.3gpp.com>;tag=210a54

    Call-ID: d57a0b04-785ba328-13a4d876@10.133.202.46

    CSeq: 14534 SUBSCRIBE

    Expires: 600000

    User-Agent: IM-client/OMA1.0 DUT-IMS

    Event: reg

    Accept: application/reginfo+xml

    P-Access-Network-Info: 3GPP-E-UTRAN-FDD;utran-cell-id-3gpp="0010100010000000"

    P-Preferred-Identity: <sip:+11234567890@test.3gpp.com>

    Content-Length: 0

 

Step 2 : 200 OK -----------------------------------

    SIP/2.0 200 OK

    Via: SIP/2.0/UDP 10.133.202.46:50997;branch=z9hG4bK2968d27245f17c7bcae38c31991bfdaa

    From: <sip:+11234567890@test.3gpp.com>;tag=210a54

    To: <sip:+11234567890@test.3gpp.com>;tag=987654321

    Call-ID: d57a0b04-785ba328-13a4d876@10.133.202.46

    CSeq: 14534 SUBSCRIBE

    Expires: 600000

    Contact: <sip:10.133.202.47:5060>

    Record-Route: <sip:10.133.202.47;lr>

    Content-Length: 0

 

Step 3 : NOTIFY -----------------------------------

    NOTIFY sip:+11234567890@test.3gpp.com SIP/2.0

    Via: SIP/2.0/UDP 10.133.202.47:5060;branch=z9hG4bK-d1e4c4961ca9d523ae76b67e088589cd

    Call-ID: d57a0b04-785ba328-13a4d876@10.133.202.46

    From: <sip:+11234567890@test.3gpp.com>;tag=987654321

    To: <sip:+11234567890@test.3gpp.com>;tag=210a54

    Subscription-State: active;expires=600000

    Event: reg

    CSeq: 14534 NOTIFY

    Contact: <sip:10.133.202.47:5060>

    Max-Forwards: 70

    Content-Type: application/reginfo+xml

    Content-Length: 340

     

    <?xml version="1.0" encoding="UTF-8"?>

    <reginfo xmlns="urn:ietf:params:xml:ns:reginfo" version="0" state="full">

    <registration aor="sip:+11234567890@test.3gpp.com" id="12345" state="active">

    <contact id="100" state="active" event="registered" expires="600000">

    <uri>sip:+11234567890@10.133.202.46:50997</uri>

    </contact>

    </registration>

    </reginfo>

 

Step 4 : 200 OK -----------------------------------

    SIP/2.0 200 OK

    Via: SIP/2.0/UDP 10.133.202.47:5060;branch=z9hG4bK-d1e4c4961ca9d523ae76b67e088589cd

    Max-Forwards: 70

    Contact: <sip:+11234567890@10.133.202.46:50997>;+sip.instance="<urn:gsma:imei:00440113-904785-0>"

    To: <sip:+11234567890@test.3gpp.com>;tag=210a54

    From: <sip:+11234567890@test.3gpp.com>;tag=987654321

    Call-ID: d57a0b04-785ba328-13a4d876@10.133.202.46

    CSeq: 14534 NOTIFY

    Allow: NOTIFY,SUBSCRIBE

    Content-Length: 0

 

 

< INVITE >

 

 

 

< VoIP >

 

Most of basic SIP protocol goes as the combination of the procedures explained above. This shows an example showing the interplay of these procedures.

 

If you see the following sample sequence, you will find various example ranging from very simple and pretty much complicated ones.

 

Following Wireshark capture is the one that I captured using the test configuration described in previous section.

 

Following is the filtered log showing only signaling part of VoIP calls that I did.

 

 

Following is the one showing both signaling part and data traffic parts showing various protocols being used in media transfer.

 

 

 

SIP Registration Path

 

 

 

 

 

SIP Message Delivery Path

 

 

 

 

IMS Registration

 

Following illustration is based on the IMS registration sequence posted on EventHelix. I converted the sequence diagram into IMS architecture diagram so that you can get some better idea of interplay of each components.

Try to follow the big picture and understand overall logic. The very detailed sequence and parameters may vary depending on the network organization. So the log you collected from a specific network may be different from what you see here. If you have a log from a test equipment, it may be simpler than what you see here.

 

In Full IMS registration, it can be split into three major process as shown below.

  • Unauthenticated IMS Registration Attempt
  • IPSec Security Association Establishment
  • Authenticated IMS Registration

 

 

< Unauthenticated IMS Registration Attempt >

 

Following is the first main procedure - Unauthenticated IMS Registration Attempt.

 

 

(1) : REGISTER  (Path : UA1 --> eNodeB --> S-GW --> P-GW --> P-CSCF)

 

    REGISTER sip:hims.net SIP/2.0,

    Via: SIP/2.0/UDP UE-IP;branch=0abab,

    Route: sip:[P-CSCF-IP], // Route specifies the IP of next node for this REGISTER to reach. In this case, 'Next Node' is P-CSCF

    Max-Forwards: 20,

    From: <sip:name@hims.net>;tag=abbb,

    To: <sip:name@hims.net>,

    Contact: <sip:[UE-IP]>;expires=90000,

    Call-ID: ababab,

    CSeq: 25 REGISTER,

    Security-Client: port-s, port-c,

    Authorization: Digest username = name.private@hims.net,

    Content-Length: 0

 

Note : Since this step is 'REGISTER' process, 'Authentication' parameter does not carry any specific information for Authentication algorithm. Following is one example that I captured from test equipment.

    Authorization: Digest uri="sip:test.3gpp.com",

          username="001010123456789@test.3gpp.com",

          response="",

          realm="test.3gpp.com",

          nonce=""

 

 

(2): DNS Query (Path : P-CSCF --> DNS Server)

    DNS Query for I-CSCF IP

 

(3): DNS Response (Path : DNS Server --> P-CSCF)

    DNS Response for I-CSCF IP

 

(4) : REGISTER (Path : P-CSCF --> I-CSCF)

 

    REGISTER sip:hims.net SIP/2.0,

    Via: SIP/2.0/UDP pcscf1.vims.net;branch=0aab1,

    Via: SIP/2.0/UDP UE-IP;branch=0abab,

    Max-Forwards: 19,

    From: <sip:name@hims.net>;tag=abbb,

    To: <sip:name@hims.net>,

    Contact: <sip:[UE-IP]>;expires=90000,

    Call-ID: ababab,

    CSeq: 25 REGISTER,

    Content-Length: 0,

    Authorization: Digest username = name.private@hims.net integrity protection:no

 

 

(5) : User Authorization Request (Path : I-CSCF --> HSS)

 

(6) : User Authorization Answer (Path : HSS --> I-CSCF)

 

    S-CSCF Name,

    S-CSCF Capabilities

 

(7) : REGISTER (Path : I-CSCF --> S-CSCF)

 

    REGISTER sip:hims.net SIP/2.0,

    Via: SIP/2.0/UDP icscf1.hims.net;branch=0aab2,

    Via: SIP/2.0/UDP pcscf1.vims.net;branch=0aab1,

    Via: SIP/2.0/UDP UE-IP;branch=0abab,

    Route: sip:scscf1.hims.net,Max-Forwards: 18,

    From: <sip:name@hims.net>;tag=abbb,

    To: <sip:name@hims.net>,

    Contact: <sip:[UE-IP]>;expires=90000,

    Call-ID: ababab,

    CSeq: 25 REGISTER,

    Content-Length: 0,

    Authorization: Digest username =name.private@hims.net integrity protection:no

 

(8) : Multimedia Authentication Request  (Path : S-CSCF --> HSS)

 

(9) : Multimedia Authentication Response  (Path : HSS --> S-CSCF)

    S-CSCF does followings at this point

    • Select Authentication vectors
    • Save the selected authentication vector

 

(10) : 401 UnAuthorized (Path : S-CSCF --> I-CSCF)

 

    WWW-Authenticate: nonce=RAND-AUTN, ck, ik,

    Via: icscf1, pcscf1, ue-ip

 

Note : This message will tell UE to initiate 'REGISTER' with authentication based on the information under 'WWW-Authenticate'. An example is as follows.

    WWW-Authenticate: Digest realm="test.3gpp.com",

        nonce="qlWqVapVqlWqVapVqlWqVUUQA5HEt9VVZ3t1TM221cg=",

        qop="auth",

        opaque="MTcyMjU3ODA2NDo=SU1TLVNJUCBTZXJ2ZXI=",

        algorithm=AKAv1-MD5

 

 

(11) : 401 UnAuthorized (Path : I-CSCF --> P-CSCF)

 

    WWW-Authenticate: nonce=RAND-AUTN, ck, ik,

    Via: pcscf1, ue-ip

     

    P-CSCF does followings at this point

    • Save CK and IK
    • allocate P-CSCF side client and server ports

 

(12) : 401 UnAuthorized (Path : P-CSCF --> P-GW --> S-GW --> eNodeB --> UA1)

 

    WWW-Authenticate: nonce=RAND-AUTN,

    Security-Server: port-s, port-c

 

< IPSec Security Association Establishment >

 

 

 

(1) : IPSec SA for UE Initiated Requests

    UE-Client -> P-CSCF-Server

 

(2) : IPSec SA for Responses to UE

    UE-Server <- P-CSCF-Client

 

(3) : IPSec SA for P-CSCF Initiated Requests

    UE-Server <- P-CSCF-Client

 

(4) : IPSec SA for Responses to P-CSCF

    UE-Client -> P-CSCF-Server

 

 

< Authenticated IMS Registration >

 

 

(1) REGISTER (Path : UA1 --> eNodeB --> S-GW --> P-GW --> P-CSCF)

    Via: UE-IP;UE-Server-Port,

    Route: pcscf1, pcscf-server-port,

    Contact: UE-IP ue-server-port,

    Authorization: Digest username = name.private@hims.net response=RES

Note : Since this step is for Registration with Authentication, 'Authentication' parameter carries detailed information needed for the authentication algorith as shown below. This step is triggered by '401 UnAuthorized' in previous registration step.

    Authorization: Digest username="001010123456789@test.3gpp.com",

          realm="test.3gpp.com",

          uri="sip:test.3gpp.com",

          qop=auth,

          nonce="qlWqVapVqlWqVapVqlWqVUUQA5HEt9VVZ3t1TM221cg=",

          nc=00000001,

          cnonce="11259375",

          algorithm=AKAv1-MD5,

          response="a3f549b13f477562f4445b7277cd83c1",

          opaque="MTcyMjU3ODA2NDo=SU1TLVNJUCBTZXJ2ZXI="

 

 

(2) REGISTER (Path : P-CSCF --> I-CSCF)

    Via: pcscf1 UE-IP;UE-Server-Port,

    Contact: UE-IP ue-server-port,

    Authorization: Digest username = name.private@hims.net response=RES integrity protection: yes,RES

 

(3) User Authorization Request (Path : I-CSCF --> HSS)

    name.private@hims.net

 

(4) User Authorization Response (Path : HSS --> I-CSCF)

    S-CSCF Name,

    S-CSCF Capabilities

 

(5) REGISTER (Path : I-CSCF --> S-CSCF)

    Via: icscf1 pcscf1 UE-IP;UE-Server-Port,

    Contact: UE-IP ue-server-port,

    Authorization: Digest username =name.private@hims.net response=RES integrityprotection: yes,RES

 

(6) Server Assignment Request (Path : S-CSCF --> HSS)

    name.private@hims.net

 

(7) Server Assignment Request (Path : HSS --> S-CSCF)

 

(8) 200 OK (Path : S-CSCF --> I-CSCF)

 

(9) 200 OK (Path : I-CSCF --> P-CSCF)

 

(10) 200 OK (Path : P-CSCF --> P-GW --> S-GW --> eNodeB --> UA1)

 

 

SIP UnRegistration

 

There is no specific message for UnRegistration. SIP uses 'REGISTER' message for Unregistration as well. Just setting 'Expires' field to be 0 perform SIP Unregistration.

 

REGISTER sip:test.3gpp.com SIP/2.0

f: <sip:+11234567890@test.3gpp.com>;tag=589636628

t: <sip:+11234567890@test.3gpp.com>

CSeq: 589636509 REGISTER

i: 589636508_2363003488@10.133.202.46

v: SIP/2.0/UDP 10.133.202.46:5060;branch=z9hG4bK428556305

Max-Forwards: 70

m: <sip:+11234567890@10.133.202.46:5060>

P-Access-Network-Info: 3GPP-E-UTRAN-FDD; utran-cell-id-3gpp=3114800001FFFFFFF

Expires: 0

l: 0

Authorization: Digest uri="sip:test.3gpp.com",username="001010123456789@test.3gpp.com",response="",realm="test.3gpp.com",nonce="",Digest uri="sip:test.3gpp.com",username="001010123456789@test.3gpp.com",response="",realm="test.3gpp.com",nonce=""

 

 

SIP Forking

 

What is "fork" ?

Yes.. it is what you think of now. It is one of the most common tools you use when you eat something. If you look at the shape, a handle (grabbing part) is splitted into multiple thin branches.

If you are familiar with Unix/Linux programming, you will be well aware of 'fork'. Basically it is a method of creating multiple child process from a process.

 

SIP Forking means similar thing. You can think of this as a mechanism to split a SIP call into multiple clones for multiple endpoints.

 

I found a very good high level description of SIP forking from 3CX website (http://www.3cx.com/faqs/copyofauto-attendant/) as below.

 

SIP forking refers to the process of “forking” a single SIP call to multiple SIP endpoints. This is a very powerful feature of SIP.  A single call can ring many endpoints at the same time.

With SIP forking you can have your desk phone ring at the same time as your softphone or a SIP phone on your mobile. For example, you would use SIP forking to ring your deskphone and your Android SIP Phone at the same time, allowing you to take the call from either device easily. No forwarding rules would be necessary as both devices would ring. In the same manner SIP forking can be used in an office and allow the secretary to answer calls to the extension of his/her boss when he is away or unable to take the call.

 

Overall flow goes like this :

i) a UA send INVITE and this message reaches Proxy Server

ii) the Proxy server has information on which multiple endpoints it has to deliver (fork) the messages and fork the INVITE to each of endpoints

 

There are mainly two different types of forking. Parallel and Sequencial Forking.

In Parallel forking, the call gets splitted and conveyed to multiple endpoints simultaneously. In Sequencial forking, the call gets delivered to an end point and gets forked only when there is no response from the first end point.

 

 

IMS/SIP Testing

 

As for any other function, for IMS/SIP testing you can think of two different approaches. One is with Live Network and the other with Lab test equipment. In this section, I would only talk about the test with Lab test equipment, not with Live Air.

 

The most common Lab Test setup would be as shown below. You need an equipment which can emulate Radio Access Network/NAS and then connect the equipment to IMS Server/Test Engine.

As far as I know, most of current (as of Apr 2013) LTE network simulator (UE Test Equipment) have their own embedded IMS Server. But I haven't seen any of those embedded IMS server which is full-fledged to provide enough capability/flexibility to test all the detailed IMS/SIP features.

On the other hand, there is a couple of company who provide IMS Server/Test Engine which provides high flexibility and very side test capability, but these company does not provide their own Access Network/NAS emulator.

So ideally the best solution would be to combine a Access Network emulator from one company with IMS Server from another company, but in reality interfacing the two solution from two different companies would not be easy, even though it is not impossible.

 

< A Tip on Test Equipment Selection >

 

Theoretically, 'LTE Network Simulator' part should not be a critical factor as long as it has basic state machine alowing "UE to camp on and establish EPS bearer", but in practice it is not as simple as it sounds. It is mainly because there can be many different paths to 'EPS bearer establishment for IMS' and Each UE may require different variations of statemachine for the process. For example, some UE require only Default EPS bearer with IPv4, some UE would require the estabilishement of two default EPS bearer and use the second one for IMS and some other UE would require the establishement of one default and one dedicated EPS bearer and use the dedicated bearer for IMS.. there can be many other variations. So the LTE Network Simulator should have very flexible statemache. According to my experience, most of 'LTE Network Simulator' in the market falls into one of the following options.

 

Option 1 : Script or Statemachine Generation Tool based.

Option 2 : Call Box Based (Ready made statemachine)

 

In theory, it should be possible to implement any statemachine (however complex it is) with Option 1, but "be possible to do something" and "be easy (in practical sense) to do something" is different. Option 1 can be useful for creating test cases for radio stack only (e.g, those like 36.523) but it would be difficult for one or two persons to implement complicated statemachine for application test like IMS.

Usually Option 2 tend to provide more flexible (complicated) statemachine comparing to Option 1, so it can be a better fit for the application test. However, you have to verify the flexibility of the equipment before you decide to pick up since each equipment vendor supports different level of flexibility.

 

 

 

< General Test Methodology >

 

In terms of test methodology, there can be two levels of testing as listed below.

  • Entry level functionality test
  • Detailed protocol stack test
  • Media Quality Test/Analysis (e.g, Voice Quality, Video Quality test)

In Entry Level functionality test, you would try following things (I think most of Access Network Simulator Vendors are TRYING to provide all these functionality, even thought I haven't seen any equipment vendor which support all of these as of now (as of Mar,2013).

  • Turn on IMS functions on UE and see if IMS registration properly go through.
  • Send SMS over IMS and see if the message gets successfully delivered to the other party.
  • Make a Voice Call (VoLTE) from UE or from Test Equipment and see if the call is properly setup.
  • Make an Emergency Call (VoLTE) from UE or from Test Equipment and see if the call is properly setup

In IMS protocol stack test, thre can be an entry level and advanced level testing as well. In entry level testing, you can simply Ignore, Reject or Send Error messages as illustrated below and see how UE act in each of those cases. In advanced level, you would modify the IMS protocol state machine itself and teak each detailed parameters of each message and see how UE respond to each of those variations.

 

 

 

XDM/XCAP

 

As XML gets more widely used, now it gets used as a standard form of storing various configurations in mobile devices and exchanging short informations like supplimentary services.

 

XDM (XML Document Management) and XCAP (XML Configuration Access Protocol) is designed to provide standard way of managing and exchanging information in the form of XML (3GPP 24.623 for the details).

 

XCAP protocol allows a client to read, write, and modify application configuration data stored in XML format on a server. XCAP maps XML document sub-trees and element attributes to HTTP URIs, so that these components can be directly accessed by HTTP. An XCAP server is used by the XCAP clients to store data like Presence policy in combination with a SIP server that supports PUBLISH/SUBSCRIBE/NOTIFY methods to provide a complete SIP SIMPLE server solution.

 

You can find good introductions from followings

 

 

RCS/RCS-e

 

As more and more people gets interested in IMS more than the simple SMS, I am hearing more and more about RCS.

RCS stands for 'Rich Communication Service'. You will find quite a lot of material by googling it, but it would be hard to get a 'short/tangible' understanding of what it really is. Is RCS a kind of specification ? Is it a kind of software package ? Is it a kind of name for a technology ?

 

Confused !!!...

 

Whenevery you get confused by anything when you try to catching up the new technology/words, one of the best way would be to refer to any person/document from which/who the word/technology is orignated.

 

It seems that the origination of RCS/RCS-e comes from GSMA. So I decided to dig things from GSMA.

 

A simple/clear definition of RCS/RCS-e from http://www.gsma.com/rcs-faqs/  

 

  • RCS (Generic Term) = the generic term used to describe “Rich Communication Services”
  • RCS (Special Term) = Project name for the GSMA’s promotion of rich communications among MNOs (Rich Communications Services).
  • RCS-e = Technical spec name for the preferred methods of providing first stage interoperability among MNOs (Rich Communication Services – enhanced). RCS-e is the latest version of Rich Communication Suite (RCS) which will enable mobile phone end users to use instant messaging (IM), live video sharing and file transfer across any device on any network operator

 

Another good definition of RCS can be found at Wikipedia (http://en.wikipedia.org/wiki/Rich_Communication_Suite) as follows.

  • RCS initiative is an industry effort focused on the use of IMS for providing mobile phone communication services. "Rich Communication" in itself is meaningless jargon, which refers to the use of more than just voice for communication, but has long been touted as a benefit of IMS. It is to be noted that much of the capability of RCS is already available from Internet service providers.

 

If you want some intuitive 'feeling' about this, go to http://www.youtube.com/user/RCSChannel

 

As is described above, RCS initiative is a "joint efffort in the industry". It implies that many stakeholders in the industry (both Network Operators and UE manufacturer) should join in the effort and come out with some 'agreed rule (specification)' and implement them according to the specification. I don't know exactly how many Network Operators and UE makers are participating in this joint effort, but seems that there would be over 80 companies (Network Operators + UE Maker).

 

There are very wide spectrum of technicalogies specified in the RCS, but a couple of Core technology that almost everybody talks about RCS are as follows.

 

    i) Enhanced Phonebook : This phone book give you not only simple phone numbers but also presence information and service capability. With these information, you can initiate the communication by selecting one of the available communication types. You can use the Presence information  to communicate any personalized contact features including photo, availability and free text

    ii) Enhanced Messaging : This enables a large variety of messaging options like SMS, MMS, Instant Messaging and buddy related communication history.

    iii) Enriched Call : This enables multimedia contents sharing during the voice call. (e.g, video share, image share and file transfer)

 

You can find the detailed Technical Specification of RCS-e from

If you are interested specifically on how to test these features, please refer to the test specification at GSMA site.

RCE IOT001 RCS-e Test Cases.

 

 

SIP Message Structure - Examples

 

< Example : REGISTER >

 

Note : This examples is showing one of my log being interpreted according to the example from E-multimedia : http://www.siptutorial.net/SIP/request.html. For the part which is not described in this tutorial, I refered to RFC 3261.

 

[ Line  1 ] REGISTER sip:ims.sharetechnote.com SIP/2.0

[ Line  2 ] Via: SIP/2.0/UDP 192.168.1.15:5060;branch=z9hG4bK3933794001smg;transport=UDP

[ Line  3 ] Expires: 3600

[ Line  4 ] Route: <sip:192.168.1.2:5060;lr>

[ Line  5 ] P-Access-Network-Info: 3GPP-E-UTRAN-FDD;utran-cell-id-3gpp=0000054200000000

[ Line  6 ] User-Agent: SP VOIP IMS 2.0

[ Line  7 ] Privacy: none

[ Line  8 ] Contact: <sip:+11234567890@192.168.1.15:5060>

[ Line  9 ] Authorization: Digest

               username="001010123456789@ims.sharetechnote.com",

               realm="ims.sharetechnote.com",

               uri="sip:ims.sharetechnote.com",

               nonce="",

               response=""

[ Line 10 ] From: <sip:+11234567890@ims.sharetechnote.com>;tag=2504745718

[ Line 11 ] To: <sip:+11234567890@ims.sharetechnote.com>

[ Line 12 ] Call-ID: 500949143@192.168.1.15

[ Line 13 ] CSeq: 1 REGISTER

[ Line 14 ] Max-Forwards: 70

[ Line 15 ] Content-Length: 0

 

[ Line 1 ] The first line of the text-encoded message is called Request-Line. It identifies that the message is a request. It has format : Method SP Request-URI SP SIP-Version CRLF

    Method : REGISTER

    SP : Single Space

    Request-URI : sip:test.3pgg.com

    SP : Single Space

    SIP-Version : SIP/2.0

 

[ Line  2 ] Via:

This represents the local address of the first node (192.168.1.15:5060 in this case which is same as the caller) where it is expecting the responses to come

 

[ Line  3 ] Expires :

The Expires header field gives the relative time after which the message (or content) expires. The unit is sec. (See "20.19 Expires" of RFC 3261). In case of this example, it means "REGISTER" would expire in 3600 seconds. It means if UE does not renew the registration, the registration status will be cancelled.

 

[ Line  4 ] Route:

This field is used to force routing for a request through the listed set of proxies. This means that the 'REGISTER' message should go through the proxy 192.168.1.2:5060. (See "20.34 Route" of RFC 3261)

 

[ Line  8 ] Contact:

This carries a SIP or SIPS URI that is a direct route to the originator. It contains a username and a fully qualified domain name(FQDN). It may also have an IP address.

     Via field is used to send the response to the request. Contact field is used to send future requests. That is why the 200 OK response from the recipient  goes to the caller through proxies. But when the recipient generates after the 200 OK, it goes directly to the originator bypassing the proxies

 

[ Line  9 ] Authorization:

The Authorization header field contains authentication credentials of a UA. (Refer to "22.2 User-to-User Authentication" of RFC 3261)

 

[ Line 10 ] From:

This carries a display name and a SIP or SIPS URI  "11234567890@ims.sharetechnote.com". It also contains a tag which is a pseudo-random sequence inserted by the SIP application. It works as an identifier of the caller in the dialog.

 

[ Line 12 ] Call-ID:

It is a globally unique identifier of the call generated as the combination of a pseudo-random string and the softphone's IP address.The Call-ID is unique for a call. A call may contain several dialogs. Each dialog is uniquely identified by a combination of From, To and Call-ID.

 

[ Line 13 ] CSeq:

This shows an integer and a method name. When a transaction starts, the first message is given a random CSeq. After that it is incremented by one with each new message. It is used to detect non-delivery of a message or out-of-order delivery of messages

 

[Line 14 ] Max-Forwards :

This is used to limit the number of hops that this request may take before reaching the callee It is decreased by one at each hop. It is necessary to prevent the request from traveling forever in case it is trapped in a loop.

 

 

< Example : 200 OK to REGISTER >

 

: Most of the part is same as the example above. So I would explain things that has not covered above.

 

[ Line 1  ] SIP/2.0 200 OK

[ Line 2  ] Via: SIP/2.0/UDP 192.168.1.15:5060;branch=z9hG4bK3933794001smg;transport=UDP

[ Line 3  ] From: <sip:+11234567890@ims.sharetechnote.com>;tag=2504745718

[ Line 4  ] To: <sip:+11234567890@ims.sharetechnote.com>;tag=987654321

[ Line 5  ] Call-ID: 500949143@192.168.1.15

[ Line 6  ] CSeq: 1 REGISTER

[ Line 7  ] Allow: INVITE, ACK, CANCEL, BYE, PRACK, MESSAGE

[ Line 8  ] Supported: 100rel, timer

[ Line 9  ] Date: Tue, 27 Mar 2012 19:49:16 GMT

[ Line 10 ] Contact: <sip:+11234567890@192.168.1.15:5060>;expires=3600

[ Line 11 ] Content-Length: 0

 

[ Line 7  ] Allow:

This Field lists the set of methods supported by the UA which generate the message. (See "20.5 Allow" of  RFC 3261).

 

[ Line 8  ] Supported:

This field enumerates all the extensions supported by the UAC(User Agent Client) or UAS(User Agent Server). (See "20.37 Supported" of  RFC 3261).

 

 

< Example : SUBSCRIBE >

 

[ Line 1  ] SUBSCRIBE sip:+11234567890@test.3gpp.com SIP/2.0

[ Line 2  ] Via: SIP/2.0/UDP 10.133.202.46:50997;branch=z9hG4bK2968d27245f17c7bcae38c31991bfdaa

[ Line 3  ] Max-Forwards: 70

[ Line 4  ] Contact: <sip:+11234567890@10.133.202.46:50997>;+sip.instance="<urn:gsma:imei:00440113-904785-0>"

[ Line 5  ] To: <sip:+11234567890@test.3gpp.com>

[ Line 6  ] From: <sip:+11234567890@test.3gpp.com>;tag=210a54

[ Line 7  ] Call-ID: d57a0b04-785ba328-13a4d876@10.133.202.46

[ Line 8  ] CSeq: 14534 SUBSCRIBE

[ Line 9  ] Expires: 600000

[ Line 11] User-Agent: IM-client/OMA1.0 DUT-IMS

[ Line 12] Event: reg

[ Line 13] Accept: application/reginfo+xml

[ Line 14] P-Access-Network-Info: 3GPP-E-UTRAN-FDD;utran-cell-id-3gpp="0010100010000000"

[ Line 15] P-Preferred-Identity: <sip:+11234567890@test.3gpp.com>

[ Line 16] Content-Length: 0

 

 

< Example : NOTIFY >

 

: Most of the part is same as the examples above. So I would explain things that has not covered above. (Refer to 7.1.2. NOTIFY of RFC 3265 for the details)

 

[ Line 1  ] NOTIFY sip:+11234567890@ims.sharetechnote.com SIP/2.0

[ Line 2  ] Via: SIP/2.0/UDP 192.168.1.2:5060;branch=z9hG4bK-fa1fec3c8c092d3c03c8555617fa1730;transport=UDP

[ Line 3  ] Call-ID: 2489100824@192.168.1.15

[ Line 4  ] From: <sip:+11234567890@ims.sharetechnote.com>;tag=987654321

[ Line 5  ] To: <sip:+11234567890@ims.sharetechnote.com>;tag=3855569531

[ Line 6  ] Subscription-State: active;expires=3600

[ Line 7  ] Event: reg

[ Line 8  ] CSeq: 1 NOTIFY

[ Line 9  ] Contact: <sip:192.168.1.2:5060>

[ Line 10 ] Max-Forwards: 70

[ Line 11 ] Content-Type: application/reginfo+xml

[ Line 12 ] Content-Length: 336

[ Line 13 ]

<reginfo xmlns="urn:ietf:params:xml:ns:reginfo" version="0" state="full">

<registration aor="sip:+11234567890@ims.sharetechnote.com" id="12345" state="active">

<contact id="100" state="active" event="registered" expires="3600">

<uri>sip:+11234567890@192.168.1.15:5060</uri>

</contact></registration></reginfo>

 

 

< Example : INVITE with SDP >

 

[ Line 1  ] INVITE sip:+10123456789@ims.sharetechnote.com SIP/2.0

[ Line 2  ] Via: SIP/2.0/UDP 192.168.1.15:5060;branch=z9hG4bK3298736468smg;transport=UDP

[ Line 3  ] Supported: 100rel,timer

[ Line 4  ] Allow: INVITE, ACK, CANCEL, UPDATE, BYE

[ Line 5  ] P-Access-Network-Info: 3GPP-E-UTRAN-FDD;utran-cell-id-3gpp=0000054200000000

[ Line 6  ] P-com.HDVVServiceType: MYIMSv1

[ Line 7  ] User-Agent: SP VOIP IMS 2.0

[ Line 8  ] Session-Expires: 1800;refresher=uac

[ Line 9  ] Content-Type: application/sdp

[ Line 10 ] Route: <sip:192.168.1.2:5060;lr>

[ Line 11 ] Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"

[ Line 12 ] From: <sip:+11234567890@ims.sharetechnote.com>;tag=659747293

[ Line 13 ] To: <sip:+10123456789@ims.sharetechnote.com>

[ Line 14 ] Call-ID: 131949458@192.168.1.15

[ Line 15 ] CSeq: 1 INVITE

[ Line 16 ] Max-Forwards: 70

[ Line 17 ] Contact: <sip:+11234567890@192.168.1.15:5060;transport=UDP>;

                                  +g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"

[ Line 18 ] Content-Length: 387

 

[ Line 19 ] v=0

[ Line 20 ] o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4

[ Line 21 ] s=SDP Seminar

[ Line 22 ] i=A Seminar on the session description protocol

[ Line 23 ] u=http://www.cs.ucl.com/Rob/sdp.03.ps

[ Line 24 ] e=mjh@isi.edu (Rob)

[ Line 25 ] c=IN IP4 224.2.17.12/127

[ Line 26 ] t=2873397496 2873404696

[ Line 27 ] a=recvonly

[ Line 28 ] m=audio 49170 RTP/AVP 0

[ Line 29 ] m=video 51372 RTP/AVP 31

[ Line 30 ] m=application 32416 udp wb

[ Line 31 ] a=orient:portrait

 

Note : Line 19-31 is from the example in RFC 2327

 

 

< Example : 100 TRYING >

 

[ Line 1  ] SIP/2.0 100 Trying

[ Line 2  ] Via: SIP/2.0/UDP 192.168.1.15:5060;branch=z9hG4bK3298736468smg;transport=UDP

[ Line 3  ] To: <sip:+10123456789@ims.sharetechnote.com>

[ Line 4  ] From: <sip:+11234567890@ims.sharetechnote.com>;tag=659747293

[ Line 5  ] Call-ID: 131949458@192.168.1.15

[ Line 6  ] CSeq: 1 INVITE

[ Line 7  ] Content-Length: 0

 

 

< Example : 180 Ringing >

 

[ Line 1  ] SIP/2.0 180 Ringing

[ Line 2  ] Via: SIP/2.0/UDP 192.168.1.15:5060;branch=z9hG4bK3298736468smg;transport=UDP

[ Line 3  ] To: <sip:+10123456789@ims.sharetechnote.com>;tag=123456789

[ Line 4  ] From: <sip:+11234567890@ims.sharetechnote.com>;tag=659747293

[ Line 5  ] Max-Forwards: 70

[ Line 6  ] Contact: <sip:+10123456789@192.168.1.2:5060;transport=udp>

[ Line 7  ] Call-ID: 131949458@192.168.1.15

[ Line 8  ] Record-Route: <sip:192.168.1.2:5060;lr>

[ Line 9  ] CSeq: 1 INVITE

[ Line 10 ] Content-Length: 0

 

 

< Example : 200 OK with SDP >

 

[ Line 1  ] SIP/2.0 200 OK

[ Line 2  ] Via: SIP/2.0/UDP 192.168.1.15:5060;branch=z9hG4bK3298736468smg;transport=UDP

[ Line 3  ] To: <sip:+10123456789@ims.sharetechnote.com>;tag=123456789

[ Line 4  ] From: <sip:+11234567890@ims.sharetechnote.com>;tag=659747293

[ Line 5  ] Max-Forwards: 70

[ Line 6  ] Contact: <sip:+10123456789@192.168.1.2:5060;transport=udp>

[ Line 7  ] Call-ID: 131949458@192.168.1.15

[ Line 8  ] Record-Route: <sip:192.168.1.2:5060;lr>

[ Line 9  ] CSeq: 1 INVITE

[ Line 10 ] Content-Type: application/sdp

[ Line 11 ] Supported: timer

[ Line 12 ] Allow: INVITE, ACK, CANCEL, BYE, PRACK, MESSAGE

[ Line 13 ] Content-Length: 379

 

[ Line 14  ] v=0

[ Line 15  ] o=MYIMS 1 1 IN IP4 192.168.1.2

[ Line 16  ] s=-

[ Line 17  ] i=A VOIP Session

[ Line 18  ] c=IN IP4 192.168.1.2

[ Line 19  ] t=0 0

[ Line 20  ] m=audio 53746 RTP/AVP 107 97 110

[ Line 21  ] b=AS:49

[ Line 22  ] b=RS:800

[ Line 23  ] b=RR:2400

[ Line 24  ] a=ptime:20

[ Line 25  ] a=maxptime:20

[ Line 26  ] a=rtpmap:107 AMR-WB/16000

[ Line 27  ] a=fmtp:107 octet-align=1; mode-set=2

[ Line 28  ] a=rtpmap:97 AMR/8000

[ Line 29  ] a=fmtp:97 octet-align=1; mode-set=7

[ Line 30  ] a=rtpmap:110 telephone-event/8000

[ Line 31  ] a=fmtp:110 0-15

[ Line 32  ] a=mid:0

[ Line 33  ] a=sendrecv

 

 

< Example : ACK >

 

[ Line 1  ] ACK sip:+10123456789@192.168.1.2:5060;transport=udp SIP/2.0

[ Line 2  ] Via: SIP/2.0/UDP 192.168.1.15:5060;branch=z9hG4bK3608780455smg;transport=UDP

[ Line 3  ] From: <sip:+11234567890@ims.sharetechnote.com>;tag=659747293

[ Line 4  ] To: <sip:+10123456789@ims.sharetechnote.com>;tag=123456789

[ Line 5  ] CSeq: 1 ACK

[ Line 6  ] Call-ID: 131949458@192.168.1.15

[ Line 7  ] Max-Forwards: 70

[ Line 8  ] Route: <sip:192.168.1.2:5060;lr>

[ Line 9  ] Contact: <sip:+11234567890@192.168.1.15:5060;transport=UDP>;

              +g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"

[ Line 10 ] Content-Length: 0

 

 

< Example : BYE >

 

[ Line 1  ] BYE sip:+10123456789@192.168.1.2:5060;transport=udp SIP/2.0

[ Line 2  ] Via: SIP/2.0/UDP 192.168.1.15:5060;branch=z9hG4bK864033094smg;transport=UDP

[ Line 3  ] From: <sip:+11234567890@ims.sharetechnote.com>;tag=659747293

[ Line 4  ] To: <sip:+10123456789@ims.sharetechnote.com>;tag=123456789

[ Line 5  ] CSeq: 2 BYE

[ Line 6  ] Call-ID: 131949458@192.168.1.15

[ Line 7  ] Max-Forwards: 70

[ Line 8  ] Route: <sip:192.168.1.2:5060;lr>

[ Line 9  ] Contact: <sip:+11234567890@192.168.1.15:5060;transport=UDP>;

                           +g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"

[ Line 10 ] Content-Length: 0

 

 

 

Appendix : SIP Message Format

 

This is based on RFC 3261

 

1. Request Message

 

Request Message

Description

REGISTER

A Client use this message to register an address with a SIP server

INVITE

A User or Service use this message to let another user/service participate in a session. The body of this message would include a description of the session to which the callee is being invited.

ACK

This is used only for INVITE indicating that the client has received a final response to an INVITE request

CANCEL This is used to cancel a pending request
BYE A User Agent Client use this message to terminate the call
OPTIONS

This is used to query a server about its capabilities

 

 

2. Response Message

 

Code

Category

Description

1xx Provisional

The request has been received and processing is continuing

2xx Success

An ACK, to indicate that the action was successfully received, understood, and accepted.

3xx Redirection

Further action is required to process this request

4xx Client Error

The request contains bad syntax and cannot be fulfilled at this server

5xx Server Error

The server failed to fulfill an apparently valid request

6xx Global Failure

The request cannot be fulfilled at any server

 

 

Code

Message

Description

1xx

100

Trying

This response indicates that the request has been received by the next-hop server and that some unspecified action is being taken on behalf of this call (for example, a database is being consulted).

This response, like all other provisional responses, stops retransmissions of an INVITE by a UAC.  The 100 (Trying) response is different from other provisional responses, in that it is never forwarded upstream by a stateful proxy.

Ref : RFC3261 21.1.1 100 Trying

 

180

Ringing

The UA receiving the INVITE is trying to alert the user.  This response MAY be used to initiate local ringback

Ref : RFC3261 21.1.2 180 Ringing

 

181

Call Is Being Forwarded

A server MAY use this status code to indicate that the call is being forwarded to a different set of destinations

Ref : RFC3261 21.1.3 181 Call Is Being Forwarded

 

182

Queued

The called party is temporarily unavailable, but the server has decided to queue the call rather than reject it.  When the callee becomes available, it will return the appropriate final status response. The reason phrase MAY give further details about the status of the call, for example, "5 calls queued; expected waiting time is 15 minutes".  The server MAY issue several 182 (Queued) responses to update the caller about the status of the queued call.

Ref : RFC3261 1.1.4 182 Queued

 

183

Session Progress

This response is used to convey information about the progress of the call that is not otherwise classified.  The Reason-Phrase, header fields, or message body MAY be used to convey more details about the call progress.

Ref : RFC3261 21.1.5 183 Session Progress

2xx

200

OK

The request has succeeded.  The information returned with the response depends on the method used in the request

Ref : RFC3261 21.2.1 200 OK

3xx

300

Multiple Choices

The address in the request resolved to several choices, each with its own specific location, and the user (or UA) can select a preferred communication end point and redirect its request to that location.

 

The response MAY include a message body containing a list of resource characteristics and location(s) from which the user or UA can choose the one most appropriate, if allowed by the Accept request header field.  However, no MIME types have been defined for this message body.

Ref : RFC3261 21.3.1 300 Multiple Choices

 

301

Moved Permanently

The user can no longer be found at the address in the Request-URI, and the requesting client SHOULD retry at the new address given by the Contact header field.  The requestor SHOULD update any local directories, address books, and user location caches with this new value and redirect future requests to the address(es) listed.

Ref : RFC3261 21.3.2 301 Moved Permanently

 

302

Moved Temporarily

The requesting client SHOULD retry the request at the new address(es) given by the Contact header field (Section 20.10).  The Request-URI of the new request uses the value of the Contact header field in the response

Ref : RFC3261 21.3.3 302 Moved Temporarily

 

305

Use Proxy

The requested resource MUST be accessed through the proxy given by the Contact field.  The Contact field gives the URI of the proxy.The recipient is expected to repeat this single request via the proxy.  305 (Use Proxy) responses MUST only be generate by UASs

Ref : RFC3261 21.3.4 305 Use Proxy

 

380

Alternative Service

The call was not successful, but alternative services are possible. The alternative services are described in the message body of the response.  Formats for such bodies are not defined here, and may be the subject of future standardization

Ref : RFC3261 21.3.5 380 Alternative Service

4xx

400

Bad Request

 

 

401

Unauthorized

 

 

402

Payment Required

 

 

403

Forbidden

 

 

404

Not Found

 

 

405

Method Not Allowed

 

 

406

Not Acceptable

 

 

407

Proxy Authentication Required

 

 

408

Request Timeout

 

 

410

Gone

 

 

413

Request Entity Too Large

 

 

414

Request-URI Too Long

 

 

415

Unsupported Media Type

 

 

416

Unsupported URI Scheme

 

 

420

Bad Extension

 

 

421

Extension Required

 

 

423

Interval Too Brief

 

 

480

Temporarily Unavailable

 

 

481

Call/Transaction Does Not Exist

 

 

482

Loop Detected

 

 

483

Too Many Hops

 

 

484

Address Incomplete

 

 

485

Ambiguous

 

 

486

Busy Here

 

 

487

Request Terminated

 

 

488

Not Acceptable Here

 

 

491

Request Pending

 

 

493

Undecipherable

 

5xx

500

Server Internal Error

 

 

501

Not Implemented

 

 

502

Bad Gateway

 

 

503

Service Unavailable

 

 

504

Server Time-out

 

 

505

Version Not Supported

 

 

513

Message Too Large

 

6xx

600

Busy Everywhere

 

 

603

Decline

 

 

604

Does Not Exist Anywhere

 

 

606

Not Acceptable