Microsoft Word Master master doc

3.2.3.2
 
TMMS Proxy-Relay 
The PR is implemented as a SIP B2BUA. It must be accessible by the clients through 
normal Internet routing procedures. 
3.2.4
 
Security 
As mentioned above, GPRS does provide security for the user. But it does not offer end-
to-end security, which is expected in a service. With SIP there are two possibilities 
offered: SIP and Secure SIP. These are distinguished by the URI used in the addressing, 
which are sip and sips, respectively. 
In the figures below the normal SIP scheme will be used with authentication from HTTP 
Digest. Note that only the first figure includes the authentication part, which is the first 
two messages sent. For the rest of the interactions this part of the scenario is not 
included. 
3.2.5
 
Scenario Implementation 
3.2.5.1
 
S01: TMMS Client Registration 
When a client wants to use the messaging service it needs to register with the TMMS PR 
that it is online. The registration sequence is shown in Figure 3-3 below.

---

3.2 TMMS Service based on GPRS: : Design 
Page 33 of 93 
Figure 3-3 TMMS Client Registration 
The client sends a SIP REGISTER request to its TMMS PR which acts as a registrar for 
its clients. The Request-URI is composed of the client’s username and the TMMS PR’s 
domain name, like 
[e-mail]
. The same is the To and From 
headers set to, but with the sip(s) URI scheme in front, like 
“sips:[e-mail]”. This is the client’s public identity and the 
address for example a friend of this user will use to send her a message. To let the 
TMMS PR know how to contact the user the Contact header is set to an URI which 
contains the user’s current IP-address and the port which can be used. 
When the TMMS PR receives the REGISTER request from the client it first checks if 
the client is authenticated. If not, like in Figure 3-3 above, the TMMS PR returns a 401 
(Unauthorized) response back to the client. This response will include a “WWW-
Authenticate” header which the client will use to authenticate itself. Now the client will 
send a second REGISTER request to the TMMS PR with the authentication details 
included. If the authentication of the client is successful and the username in the 
Request-URI is a TMMS Client then the TMMS PR returns a 200 (OK) response back to 
the client. To check if the client is a TMMS user the TMMS PR does a search in the user 
store for the username. 
To get notifications about new messages the client needs to subscribe to the 
“newmessage-alert” event, which the TMMS PR uses to notify subscribers about new 
messages. Subscription is accomplished by sending a SUBSCRIBE request to the TMMS 
PR, which will respond with 200 (OK). According to [29] the notifier needs to 
immediately send a NOTIFY message to the user with the current state. This message 
will contain a body with URIs to all new messages for the client, if any. How the client 
deals with the NOTIFY message is discussed in sections 3.2.5.3 and 3.2.5.3.1 below. 
Now the client is registered with the TMMS PR and will receive notifications about new 
messages and may send messages to other clients.