Using Mobile Terminal Initiated QoS

When using mobile terminal initiated QoS, it is mandatory for the Multimedia Telephony client to be able to get knowledge about the status of the resource reservation. The basic idea is that when the Multimedia Telephony client knows that it does not have resources reserved for the media stream it indicates using the SDP attribute 'inactive' (see RFC 3108 [131]) and using the SIP precondition method (see RFC 3312 [57] and RFC 4032 [56]) that it has no resources available. The SIP precondition method makes it possible for a Multimedia Telephony client to suspend the establishment of the Multimedia Telephony session until the resource reservation is finalized. Basically, the SIP precondition method triggers additional exchange of SIP messages within the Multimedia Telephony session establishment procedure. This gives the possibility to include a second SDP exchange in order to signal when the Multimedia Telephony client gets information that the resources are reserved and it is ready to send and receive media. The signaling flow in Figure 4.9 shows the case when both Multimedia Telephony clients need to perform resource reservation and establish RABs for the media. The signaling flow in Figure 4.2 also uses SIP preconditioning. It can be noted that the Multimedia Telephony session setup flow uses fewer SIP messages than the general IMS session establishment in Figure 4.2. This is a result of a number of optimizations, such as the use of SIP PRACK only for provisional responses that carry SDP and the start of resource reservation on the originating side before the reception of the SIP response. To describe the different events in more detail a numbered list is added below. The numbers correspond to specific messages and events marked in the figure. The following text explains the specific message or event in more detail.

1. The Multimedia Telephony client A has received a request to establish a Multimedia Telephony session to Multimedia Telephony user B that is using Multimedia Telephony client B. A SIP INVITE request is created. The request-URI of that SIP INVITE is either a SIPURI (e.g. sip:[email protected]) or a tel URI (e.g. tel:+1-212-555-2222, see RFC 2806 [182]) that addresses Multimedia Telephony user B. The SIP INVITE request should also contain the public user identity of the calling Multimedia Telephony user A to allow Originating Identification Presentation (see Section 4.7.4). Further, the SIP INVITE request also provides the IP address of the

MM Telephony Client A home network

MM Telephony Client B home network

MM Telephony Client A MM Telephony user

IMS Core A

TAS A

TAS B

IMS Core B

MM Telephony Client B

A initiate the call

A initiate the call

(2b) Policy control of SDP and authorization of resources

The PDP context establishment and RAB setup progresses and are finalized

(2b) Policy control of SDP and authorization of resources

(*) PDP context establishment may start here

Ringing indication ■4-

Connection indication

(7) SIP INVITE

Progress

-(14) SIP 183 Session Progress

Progress

(36) SIP 180 Ringing

(37) SIP 180_ Ringing

(35) SIP 180 Ringing

1(22) SIP PRACK-(23) SIP PRACKi i(26) SIP 200 OK--(27) SIP 200 OKI

(8) Policy control

(10) PDP

of SDP and

context

authorization of

establishment

resources

starts

(11) SIP 183 I- Session -Progress

The PDP context establishment and RAB setup progresses and are finalized

Indication of incoming call

MM Telephony user

Figure 4.9: Establishment of a two-party Multimedia Telephony session using mobile initiated quality of service.

originating Multimedia Telephony client, information if the Multimedia Telephony client supports SigComp and if privacy is requested (Originating Identification Restriction). The SIP INVITE request must also indicate the level of support for reliable provisional responses and the precondition mechanism.

The SIP INVITE request must contain a description of the user plane session. In Multimedia Telephony sessions, SDP is used to describe the user plane part of the session. For more information about the SDP offer and the media capability of the Multimedia Telephony client, see Sections 5.1 and 5.2. Important attributes in the SDP are the 'inactive' attribute and the precondition attributes. When sending the SIP INVITE request it is assumed that the Multimedia Telephony client knows that the PDP context and radio bearer for media are not set up. Therefore it indicates in the SDP that the session is 'inactive' and that the preconditions to start the session are not met and hence local resource reservation must occur.

The SIP INVITE request is sent to IMS core A, which acknowledges the request with a SIP 100 Trying response. The SIP 100 Trying response is an informal response that informs the sending entity that the receiving entity has received the SIP INVITE request. When the originating Multimedia Telephony client gets information that the SIP INVITE request was successfully delivered it turns off the SIP retransmission timer (for the SIP INVITE request) to prevent multiple transmissions of the SIP INVITE, as it may take a while for the terminating side to respond to the invitation request.

2. (a) In 3GPP release 6 it is allowed to start resource reservation directly after having sent the SIP INVITE. This is the case shown here. The other possibility, which may be more often used, is to start resource reservation after the reception of the first SDP answer. This happens at step 17 and is marked in the figure with a (*). Based on the session description in the SIP INVITE sent in step 1, the Multimedia Telephony client starts to establish a PDP context with suitable QoS. The PDP context activation results in the establishment of a radio bearer with suitable radio bearer parameters for the service (for a description of radio bearers for media, see Section 5.6).

(b) When the IMS core A receives the SIP INVITE request it sends the session information to the PCRF to verify that the session description does not violate any operator controlled rules for the Multimedia Telephony session and to authorize resources for the Multimedia Telephony session being initiated. The PCRF also gets information from GGSN that a PDP context is being established for the Multimedia Telephony session. Given that resources are authorized by the PCRF for the Multimedia Telephony session, the PDP context activation and the Multimedia Telephony session establishment can progress, otherwise both processes are terminated by the network.

3. The SIP INVITE request is routed to the Telephony Application Server (TAS A). The TAS acknowledges the reception of the SIP INVITE request with a SIP 100 Trying response. It is proposed in 3GPP, but not decided at the time of writing this book, that a feature tag (for more information on feature tag see RFC 3840 [173]) is included in the SIP INVITE request to identify that the request is a Multimedia Telephony session invitation that should be routed to a TAS. This methodology is already used for 3GPP CSICS (for more information about 3GPP CSICS, see Section 8.1) and OMA PoC

(for more information about OMA PoC, see Section 8.2). As an example of the format of feature tags, 3GPP CSICS service enabler uses the feature tags +g.3gpp-cs-voice and +g.3gpp-cs-video.

4-7. The SIP INVITE request is routed from TAS A to IMS core B via IMS core A and TAS B. If the original SIP INVITE request contained a request-URI that was a tel-URI, it was translated to a globally routable SIP URI before the SIP INVITE request leaves IMS core A and is sent to IMS core B. Usually the ENUM-DNS protocol (see RFC 2916 [76]) is used for this process.

8. Before the SIP INVITE request is sent to Multimedia Telephony client B, a policy control of the SDP offer is done to verify that the session description does not violate any operator controlled rules for the Multimedia Telephony session. If the Multimedia Telephony client B is allowed to reserve resources for a Multimedia Telephony session, the GGSN is notified about the positive policy decision.

9. The SIP INVITE request is sent from IMS core B to Multimedia Telephony client B.

10. When the Multimedia Telephony client has received the SDP offer in the SIP INVITE request it determines the set of codecs it is capable of supporting for this Multimedia Telephony session and calculates the probable session bandwidth. Based on this information the PDP context activation procedure is started. Given that resources are authorized by the PCRF in step 8 for the Multimedia Telephony session, the PDP context activation progresses, otherwise it is terminated by the network. In the successful case, the PDP context activation results in a resource reservation, i.e. the establishment of a radio bearer with suitable radio bearer parameters for the service (for a description of radio bearers for media, see Section 5.6).

11. Since Multimedia Telephony client A marked that the preconditions of the session are not met and it thus needs to do a local resource reservation, Multimedia Telephony client B needs to answer the SIP INVITE request with a SIP 183 Session Progress response. Multimedia Telephony client B is QoS aware and indicates this using the precondition attribute. It indicates that it has no resources available and that the SDP and thus the media are still inactive. The SDP answer will also contain possible codec alternatives for the Multimedia Telephony session. The SDP answer will mark the intersection of the codecs that Multimedia Telephony client A indicated in the SDP offer and the set of codecs Multimedia Telephony client B is capable of supporting as possible codec alternatives. It will also contain the IP address and port numbers to be used for the media stream(s).

12-17. The SIP 183 Session Progress is sent back to Multimedia Telephony client A following the same path as the SIP INVITE request. When Multimedia Telephony client A receives the SIP 183 Session Progress response it also gets the SDP answer indicating which codec(s) can be used in the Multimedia Telephony session. In the earlier 3GPP releases it was mandatory for Multimedia Telephony client A to start resource reservation here; however, most implementations of Multimedia Telephony clients following the 3GPP release 6 and 7 specifications for IMS will start the resource reservation after step 17, though it is possible to do otherwise. However, if the PDP context activation was started in step 2a there is a quite high possibility that it has finalized at this point in time. Thus, if there is a need to modify the

PDP context because the initially requested QoS has a mismatch against the possible media codecs in the SDP answer, it could be done after step 17 without interfering with the activation procedure started at step 2a.

18. In most cases the initial SIP INVITE will trigger paging and procedures to set up the radio connection on the terminating side before the SIP INVITE request can be sent to Multimedia Telephony client B. Therefore, in most cases the PDP context activation and radio bearer setup initiated in step 2a will be finalized before step 18. In the initial SIP INVITE request, Multimedia Telephony client A indicated support for reliable provisional responses. Therefore, Multimedia Telephony client A can use a provisional response to SIP 183 Session Progress to indicate that the resource reservation is done and its SDP is now active (using the 'sendrecv' attribute) and that the preconditions for the Multimedia Telephony session are met by including a second SDP offer. This provisional response is a SIP PRACK response (see RFC 3262 [171]). It could be noted that even if the resource reservation was not finalized because it may have been started after step 17, the SIP 183 Session Progress should be acknowledged by a provisional response since it carried vital SDP information.

19-24. The SIP PRACK is sent to Multimedia Telephony client B.

25-31. The SIP PRACK is acknowledged by a SIP 200 OK response sent from Multimedia Telephony client A to Multimedia Telephony client B. In this case it is most probable that the resource reservation that started at step 10 is finalized. Therefore, the terminating Multimedia Telephony client B can answer back with a final SDP answer indicating that it is ready with the resource reservation.

32-38. When the following two conditions are fulfilled the terminating Multimedia Telephony client B starts to ring: (1) PDP context activation and radio bearer setup started at step 10 must be finalized in order to have a radio bearer ready for media and (2) the SIP PRACK request must have been received and the final SDP answer must have been sent back to Multimedia Telephony client A. When the Multimedia Telephony client B starts to ring it sends a SIP 180 Ringing response back to Multimedia Telephony client A, which can then give its user an indication that is has started to ring on the terminating side. Given that the SIP 200 OK response sent in step 25 included the final SDP answer, the SIP 180 Ringing does not have to carry any SDP.

39-45. At some point in time Multimedia Telephony user B answers the call. A final SIP 200 OK response is sent back to Multimedia Telephony client B. When the SIP 200 OK response is received, the Multimedia Telephony user A gets a connection indication.

46-52. The SIP 200 OK response is acknowledged by a SIP ACK message that is sent from Multimedia Telephony client A to Multimedia Telephony client B.

53. Media starts to flow between the two Multimedia Telephony clients.

More information about basic communication procedures in IMS can be found in 3GPP

TS24.229 [25] and the basic Multimedia Telephony session procedures are to be written in

0 0

Post a comment