Chapter 3 The applications of W-CSCF
3.2 Subscribe/Notify Applications
3.2.1 The functions of each component
The functions of the W-CSCF:
1. When receiving the SIP REGISTER message, the W-CSCF must check the SIP Contact header whether the request is PTT message or not. If the Contact header consists of one PTT media flag, the SIP REGISTER is a PTT message. Then, the W-CSCF will send 200 OK including the GLMS location of this domain to the UE.
Moreover, the W-CSCF will pass this SIP REGISTER to the PoC/USV server to register the service and set the new user status of online.
2. When receiving the SIP INVITE message, the W-CSCF must check the SIP Accept-Contact header whether the request is PTT message or not. If the Accept-Contact header consists of one PTT media flag, the SIP INVITE is a PTT message. Then, the W-CSCF will pass this SIP INVITE to the PoC/USV server of this domain to trigger the Push-to-talk service.
3. When receiving the SIP MESSAGE, the W-CSCF must check the SIP Accept-Contact header whether the intention of this request is to set status or not. If it is for setting status, the W-CSCF will pass this SIP MESSAGE to the PoC/USV.
4. When receiving the SIP SUBSCRIBE message, the W-CSCF must check the callee is in this domain or not. If the callee is registered in this domain, the W-CSCF will pass the SIP SUBSCRIBE to the PoC/USV. If the callee is not registered in this domain, the W-CSCF will send LIR to the HSS to query where is the CSCF location of the callee. After getting the CSCF location of the callee, the W-CSCF will pass this SIP SUBSCRIBE to the CSCF.
5. When receiving the SIP NOTIFY message, the W-CSCF will check whether the man who subscribes the status is in this domain or not. If the man is registered in
other domain, the W-CSCF will query HSS to get the CSCF location of the man.
Then, the W-CSCF will pass the SIP NOTIFY to the CSCF of this man.
The functions of the PoC/USV:
1. When receiving the SIR REGISTER message, the PoC/USV server sets online status for the UE to the GLMS and gets the friend list and status of the UE. Then, the PoC/USV server will send the SIP NOTIFY including the online status of the UE to the friends of the UE and send the SIP NOTIFY including the friend’s status of the UE to the UE.
2. When receiving the SIP INVITE message, the PoC/USV server will pass this SIP INVITE to the W-CSCF of this domain.
3. When receiving the SIP MESSAGE, the PoC/USV server sets the status of the UE to the GLMS and gets the friend list of the UE. Then, the PoC/USV server will send the SIP NOTIFY including the status of the UE to the friends of the UE.
4. When receiving the SIP SUBSCRIBE message, the PoC/USV server will query the GLMS for the status of the user and set the subscriber to be a temporary friend of the user. Then, the PoC/USV server will send the SIP NOTIFY including the status of the user to the subscriber. There will be one timeout for the temporary case.
The functions of the GLMS:
1. When receiving the HTTP PUT message from the PoC/USV server, the GLMS will change the status of the UE.
2. When receiving the HTTP GET message from the UE, the GLMS will return the address list and friend list to the UE.
3. When receiving the HTTP GET message from the PoC/USV server, the GLMS will query the local database for the UE and return the status and friend’s list of the UE to the PoC/USV server.
The functions of the UE:
1. The UE could send the SIP REGISTER to get GLMS location.
2. The UE could connect to the GLMS to get the address list and friend list.
3. The UE could send the SIP INVITE to initiate a PTT session.
4. The UE could send the SIP MESSAGE to change his current status.
5. The UE could send the SIP SUBSCRIBE to query other user status.
6. The UE could receive the SIP NOTIFY to update the status of his friend.
3.2.2 The scenarios of the status monitoring
There are several scenarios for the status monitoring at this distributed system. The first scenario is registration. The second scenario is change user status. The third scenario is subscription. We will describe these scenarios below.
Registration: This scenario is to say that the UE2 is roaming from the W-CSCF#1 domain to the W-CSCF#2 domain and executes the registration to the W-CSCF#2 domain. Then, the friends including the UE1 and the UE3 of the UE2 will be notified that the UE2 is online. Here the UE1 and the UE3 is in the W-CSCF#1 domain. Figure 3-5 shows the message flow of the scenario of the registration.
1. The UE2 roams to the W-CSCF#2 domain. Then, The UE2 sends the SIP REGISTER message to the W-CSCF#2 to execute the registration.
2. When the W-CSCF#2 receives the SIP REGISTER, it sends the Cx-Put/Pull (SAR) message to the HSS to register the UE2. The HSS returns the Cx-Put/Pull-Resp (SAA) including the user profile of the UE2 to the W-CSCF#2.
3. The W-CSCF#2 returns the SIP 200 OK including the GLMS2 location to the UE2.
4. The UE2 gets the address list and friend list from the GLMS2 using the HTTP GET.
UE2 WCSCF2 PoC GLMS HSS WCSCF1 UE1 UE3
8. send friends list and status 9. NOTIFYFigure 3-4: the scenario of the registration
5. The W-CSCF#2 checks the SIP REGISTER and discovers that the REGISTER is a PTT message. Then, the W-CSCF#2 sends the REGISTER to the PoC/USV2 server.
6. The PoC/USV2 server returns the SIP 200 OK to the W-CSCF#2.
7. The PoC/USV2 server sets the online status for the UE2 to the GLMS2.
8. The PoC/USV2 server gets the friends list and status from the GLMS2.
9. The PoC/USV2 will send three SIP NOTIFY message to the W-CSCF#2. One NOTIFY message including the statuses of the UE2’s friends is sent to the UE1.
The other Notify messages including the current status of the UE2 are sent to the UE1 and UE3.
10. The W-CSCF#2 passes the SIP NOTIFY to the UE2.
11. The W-CSCF#2 sends the Cx-Location-Query (LIR) to the HSS to query the CSCF location of the UE1 and the UE3.The HSS returns the Cx-Location-Query-Resp (LIA) containing the CSCF location of the UE1 and the UE3 to the W-CSCF#2.
12. The W-CSCF#2 sends two SIP NOTIFY messages to the W-CSCF#1.
13. The W-CSCF#1 sends the LIR to the HSS to query the serving CSCF of the UE1 and the UE3.The HSS returns the LIA to the W-CSCF#1 containing the serving CSCF location of the UE1 and the UE3.
14. The W-CSCF#1 discovers that it is the serving CSCF of the UE1 and passes the SIP NOTIFY to the UE1.
15. The W-CSCF#1 passes the SIP NOTIFY to the UE3.
Change user status: This scenario is to say that the UE2 makes call with the UE4 using Push-to-talk and the UE2 sends the SIP MESSAGE to change his current status. Then, the friends of the UE2 will be notified that the UE2 is busy now. Figure 3-6 shows the message flow of this scenario.
1. The UE2 sends the SIP INVITE to initiate a Push-to-talk session with the UE4.
2. The W-CSCF#2 receives the SIP INVITE and it discovers that the message is a PTT message. Then, it passes the SIP INVITE to the PoC/USV2 in this domain.
3. The PoC/USV2 receives the SIP INVITE and passes the message back to the W-CSCF#2.
4. The W-CSCF#2 sends the LIR to the HSS to query the CSCF location of the UE4.
5. The HSS returns the LIA containing the CSCF location of the UE4.
6. The W-CSCF#2 sends the SIP INVITE to the W-CSCF#1 which is contained in the LIA.
7. The W-CSCF#1 sends the LIR to the HSS to query the serving CSCF of the UE4.
8. The HSS returns the LIA containing the serving CSCF location of the UE4.
9. The W-CSCF#1 discovers that it is the serving CSCF of the UE4 and it passes the SIP INVITE to the UE4.
10-12. The UE4 returns the SIP 200 OK to the PoC/USV2 server and the PoC/USV2 server modifies the information in the 200 OK for RTP/RTCP connection.
13-14. The PoC/USV2 server passes the SIP 200 OK to the UE1.
15. The UE1 connects direct to the PoC/USV2 server using RTP/RTCP and the PoC/USV2 server connects direct to the UE4 using RTP/RTCP. Then, the Push-to-talk session is established and the PoC/USV2 server can through the W-CSCF domain by using RTP/RTCP protocol.
UE2 WCSCF2 PoC/USV GLMS HSS WCSCF1 UE4 UE1 UE3
1. INVITE
Figure 3-5: the scenario of the change user status
16. After the session is established, the UE2 sends the SIP MESSAGE to change his status and to notify his friends.
17. The W-CSCF#2 receives the SIP MESSAGE and passes the message to the PoC/USV2 server.
18. The PoC/USV2 server sets the busy status for the UE2 by using the HTTP PUT to the GLMS2.
19. The PoC/USV2 server gets the friend list of the UE2 from the GLMS2 by using the HTTP GET.
20. The PoC/USV2 server sends the SIP NOTIFY to the W-CSCF#2 according to the friend list.
21-28. The SIP NOTIFY message will be sent to the UE1 and the UE3 and the UE1 and the UE3 will know that the UE2 is at busy status now.
Subscription: This scenario is to say that the UE5 wants to subscribe the status of the UE2, but the UE5 is not in the friend list of the UE2. When the UE5 sends the SIP SUBSCRIBE to ask the status of the UE2, the PoC/USV server will return the current status of the UE2 to the UE5 and initiate a subscription timeout for the UE5. The PoC/USV server will notify the UE5 of the UE2’s new status every time until the subscription timeout terminates.
1-4. The UE2 sends the SIP MESSAGE to set his current status and the PoC/USV2 server gets the friend list of the UE2.
5-7. According to the friend list, the PoC/USV2 server sends the SIP NOTIFY containing the status of the UE2 to the UE6.
8. The UE5 sends the SIP SUBSCRIBE to the W-CSCF#1 to ask the current status of the UE2.
9. The W-CSCF#1 sends the LIR to the HSS to get CSCF location of the UE2 and the HSS returns the LIA to the W-CSCF#1.
UE5 WCSCF1 HSS WCSCF2 PoC GLMS UE2 UE6
Figure 3-6: the scenario of the subscription
10. The W-CSCF#1 sends the SIP SUBSCRIBE to the W-CSCF#2.
11. The W-CSCF#2 uses the LIR/LIA to get the serving CSCF of the UE2.
12. The W-CSCF#2 passes the SIP SUBSCRIBE to the PoC/USV2 server and the PoC/USV2 server initiates a subscription timeout for the UE5.
13. The PoC/USV2 server gets current status of the UE2 from the GLMS2.
14-18. The PoC/USV2 server sends the SIP NOTIFY containing the UE’2 status to the
UE5.
19-22. The UE2 sends the SIP MESSAGE to set his current status and the PoC/USV2 server gets the friend list of the UE2.
23-28. The PoC/USV2 server sends the SIP NOTIFY to the UE6 according to the friend list of the UE2 and sends the SIP NOTIFY to the UE5 according to the subscription timeout.
Chapter 4 System Implementation
This chapter describes out system implementation. At first, we brief the developing platform and programming tools. Then, we describe the implementation of each network entity containing the W-CSCF, the PoC/USV server and the SIP UA.
4.1 Platforms and Tools
We have implemented the W-CSCF on the Linux Platform and the PoC/USV server, SIP UA and GLMS on the Microsoft Windows Platform. We use the Microsoft Visual C++ 6.0 as our developing tool on the Microsoft Windows Platform and we also use the MySQL and MySQL++ for database management. In our implementation, we extend the SIP proxy to turn into the W-CSCF and modify the SIP UA to fit in with our demands. The following sections describe how each network entity is implemented.
4.2 W-CSCF
As the description of the Chapter 2, we can realize that the architecture of the W-CSCF consists of two blocks containing the Non-INVITE Server and INVITE Server. Here we will describe the two blocks by flow chart and we will also describe the CxEventHandler function.
4.2.1 The Non-INVITE Server
W-CSCF waits
Figure 4-1: The flow chart of the Non-INVITE Server
The figure 4-1 shows the flow chart of the Non-INVITE Server that we have implemented in the W-CSCF. When the W-CSCF is ready to listen for incoming requests, the W-CSCF can accept a Non-INVITE request by the Non-INVITE Server. In our system, we will only deal with the SIP REGISTER, OPTIONS, SUBSCRIBE and NOTIFY messages and the other Non-INVITE messages will be direct passed to the next node. When receiving the REGISTER, we use SAR/SAA to register the UE and return SIP 200 OK to the UE. Moreover, we check the SPTs that we will send the REGISTER to the next node if the return value of the function is existence. By the way, we will do nothing if the return value is NULL. When receiving the OPTIONS, we check the SPTs to get one Application Server since we know that the message is used to set status for the UE. When receiving the SUBSCRIBE and NOTIFY, we use the LIR/LAA to get the CSCF location of the target and pass the message to next node.
4.2.2 The INVITE Server
( AS: Originating UA )
Check whether the
Figure 4-2: The flow chart of the INVITE Server
The figure 4-2 shows the flow chart of the INVITE Server that we have implemented in the W-CSCF. When the W-CSCF is ready to listen for incoming requests, the W-CSCF can accept an INVITE request by the INVITE Server. In our system, we will check where the INVITE message comes from by using the information which is included in the SIP headers.
In order to achieve the goal, we create two table files containing the AS file and the CSCF file.
We add all locations of the AS and the CSCF which are close to the W-CSCF in the files and the two files are used with the XML format. At first, we check that is the SIP From header including the AS location. If this INVITE is from the AS, the AS must act as originating UA
and the W-CSCF will use the LIR/LIA to find the serving CSCF of the target and pass the message out. If the SIP From header is not including the AS location, we will check that is the SIP Via header including the AS location. If the INVITE is via the AS, we will check that does the SIP Call-ID exist. If the Call-ID is not existence, the AS must act as B2B UA and the W-CSCF will use the LIR/LIA to find the serving CSCF of the target. But if the Call-ID is existence, the AS must act as proxy and the W-CSCF will check SPTs. If the return value is NULL, the W-CSCF will pass the message to next SIP node. If the SIP Via header is not including the AS location, we will check that is the SIP Via header including the CSCF location. If the INVITE is via the CSCF, we will check the SPTs as the same before and take down the Call-ID of this message. If the SIP Via header is not including the CSCF location, the originator of the INVITE must be the UE and the W-CSCF must act as a mobile originating (MO) CSCF. In this case, the W-CSCF will check the SPTs to find that does the UE mark any service in the user profile. If the UE marked the service, the W-CSCF will pass the INVITE to the AS to trigger some application for the UE.
4.2.3 The CxEventHandler function
The figure 4-3 shows the flow chart of the CxEventHandler function that we have implemented in the W-CSCF. When the Cx library triggers the CxEventHandler function, the function will check that the Cx Response is the Cx-Location-Query-Resp (LIA) or the Cx-Put/Pull-Resp (SAA). If the response is LIA, we will check that is the original SIP request INVITE message. If the original message is INVITE, we will check that does the W-CSCF act as a mobile terminating (MT) CSCF. If the W-CSCF acts as the MT CSCF, the W-CSCF will check the SPTs to match Filter Criteria. If one AS is matched, the W-CSCF will pass the INVITE to the AS. If no AS is matched, the W-CSCF will pass the INVITE to the WGSN
which the UE is located. If the W-CSCF does not act as the MT CSCF, the W-CSCF will pass the INVITE to the other CSCF. If the original request is not INVITE, the request will be SUBSCRIBE or NOTIFY message. Then, we will check that does the W-CSCF act as a MT CSCF and do the same as before. On the other hand, if the Cx response is SAA, it must do for registration. The W-CSCF will store the user profile into the local database and return the SIP 200 OK to the UE. Moreover, we will check the SPTs to match the Filter Criteria. If SPTs match, the W-CSCF will pass the REGISTER to the AS. If SPTs do not match, we will do nothing at all.
Figure 4-3: The flow chart of the CxEventHandler function
4.3 PoC/USV server
The PoC Server has implemented according to the PoC Specification by the member of our laboratory and we enhance the PoC Server to become the PoC/USV server. In each W-CSCF domain, there is only one PoC/USV server and it is close to the W-CSCF. On the other hand, the SIP UA cannot connect direct to the PoC/USV server. The figure 4-4 shows
the flow chart of the PoC/USV server. There are seven functions to support status monitoring containing the set online function, the set offline function, the set busy function, the get friend list function, the get friend status function, the set timer function and the check timer function.
The USV server will check the incoming requests to trigger the registration function, the un-registration function, the change function and the subscription function. The termination of
The USV server will check the incoming requests to trigger the registration function, the un-registration function, the change function and the subscription function. The termination of