Microsoft Word Master master doc

Figure 3-7 TMMS Client Receives MM (Deferred Retrieval) 
3.2.5.4
 
S04: Deferred MM Retrieval 
To retrieve a message deferred for retrieval the client does almost the same as when 
retrieving immediately. It sends a HTTP GET request with the Request-URI set to the 
URI it learned from the NOTIFY message it got earlier. 
Figure 3-8 Deferred MM Retrieval 
3.2.5.5
 
S05: Streaming Retrieval of MM 
If the Multimedia Message (MM) contains large media parts, like audio or video parts, 
then the TMMS PR may decide that it will stream the content to the client instead of 
letting the client download the contents through HTTP GET, as discussed in the 
sections above. Note that the TMMS PR needs to know if the client supports streaming 
first. Here we will assume that the client supports streaming. 
Each media part is examined and then the TMMS PR decides if that media part shall be 
streamed to the client. If a media part is decided to be streamed then it will be uploaded 
to the streaming media server. The URL to the media part, which originally will follow 
the http URI scheme, will be replaced with a rtsp-uri. Now the altered MM is ready to be 
retrieved by the client. 
The client will be notified about the new
3.2.5.6
 
S06: TMMS Client Unregistration 
When the client wants to disconnect from the service it first must unsubscribe from the 
newmessage-alert event. Next it must unregister with the TMMS PR. Both tasks are 
accomplished by sending the original request, SUBSCRIBE and REGISTER 
respectively, to the TMMS PR with the Expires-header set to 0. 
Figure 3-9 TMMS Client Unregistration 

---

3.2 TMMS Service based on GPRS: : Design 
Page 37 of 93