WO2009036605A1

WO2009036605A1 - Method and system for processing sip message with rtsp encapsulation in ims

Info

Publication number: WO2009036605A1
Application number: PCT/CN2007/002783
Authority: WO
Inventors: Aihao Yin
Original assignee: Lucent Technologies Inc
Current assignee: Nokia of America Corp
Priority date: 2007-09-20
Filing date: 2007-09-20
Publication date: 2009-03-26
Anticipated expiration: 2010-03-20
Also published as: CN101803324A

Abstract

The invention proposes a method and system for processing SIP message with RTSP encapsulation in IMS. The method comprises the following steps: defining a new SIP content type; and encapsulating a RTSP message into a SIP message with the new SIP content type. The invention realizes the use of the IMS security features, the reuse of the IMS QoS framework, the use of the existing IMS charging system, and the convergence of the RTSP-based services, such as IPTV and VoD, with the existing SIP-based IMS services.

Description

Method and System for Processing SIP Message with RTSP Encapsulation in IMS

Technical Field of the Invention

The invention generally relates to the field of data communication, and in particular, to a method and system for processing Session Initiation Protocol (SIP) message with Real Time Streaming Protocol (RTSP) encapsulation in IP Multimedia Subsystem (IMS).

Background of the Invention

IMS (IP Multimedia Subsystem) is a new scheme for multimedia transaction, which can meet the novel and diverse requirements proposed by end-users on multimedia transactions. At the moment, IMS is considered to be a core technology in the Next Generation Network (NGN). Both RTSP and SIP are application layer protocols and are transported over the IP network. The IMS UEs (User Equipments), such as 3G handsets, already support the SIP protocol for originating or terminating voice and video sessions. Unlike the traditional ones, these UEs are no longer used for single purpose. They can be enhanced to support other functionalities, such as accessing the IPTV (IP Television) and VoD (Video-On-Demand) services. The RTSP protocol can be easily implemented on the terminal equipments for supporting the IPTV/ VoD services.

The Real Time Streaming Protocol (RTSP), developed by the IETF and published in 1998 as RFC 2326, is a protocol for use in streaming media systems. It provides an extensible frame which allows a client to remotely control a streaming media server, issues VCR-like commands such as "play" and "pause", and allows time -based access to files on a server. The RTSP commands include: DESCRIBE, SETUP, PLAY, PAUSE, RECORD, TEARDOWN, etc. The RTSP messages comprise two types: Request and Response, in which their formats are different from each other, as explained below in detail. • Request message:

Method URIR TSP- Version CR LF

Message Header CR LF

Message Body CR LF

Wherein, the term "Method" refers to any of all available commands; "URI" is the address of the recipient, such as, rtsp://192.168.20.136; "RTSP-Version" is typically RTSP/1.0; and "CR LF" at the end of each line represents the carriage return & line feed. ^• Response message:

R TSP- Version Status-Code Explanation CR LF

Message Header CR LF

Message Body CR LF

Wherein, the term "RTSP-Version" is typically RTSP/ 1.0; "Status-Code" is a numeral value, such as 200, which indicates a status of success; "Explanation" is a text explanation corresponding to the "Status-Code".

RTSP is normally transferred over the TCP protocol. Optionally, it can also be carried over the Hyper Text Transfer Protocol (HTTP).

The Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. SIP is a text-based message protocol. It operates independently of the underlying network transport protocols, establishing sessions between multiple users irrespective if the transferred data is text data, audio data, or video data. The basic SIP methods include: INVITE, CANCEL, BYE, OPTIONS, MESSAGE, SUBSCRIBE, NOTIFY, etc.

The SIP protocol enables end users to communicate with each other via messages. The basic form of a message could either be a request sent from a client to a server or a reply from the server to the client. A message consists of a start-line, one or more header fields, a null line indicating the end of the header fields, and an optional message-body. The generic structure of a SIP message is shown as below: generic-message = start-line message header field 1 message header field 2

CR LF

message-body [optional]

start-line = Request-Line /Status-Line

The SIP messages comprise two types: Request and Response. A SIP Request message may be recognized by the presence of a Request-Line as the start-line. The format of a request-line is shown as below: Request-Line = Method SP Request-URI SP SIP-Version CR LF

A SIP Response message may be recognized by the presence of a Status-Line as the start-line. The format of a status-line is shown as below:

Status-Line = SIP-Version SP Status-code SP Reason-Phrase CR LF

In the actual implementations, RTSP only involves the interactions between the media server and the media client, while SIP involves a lot of network elements for message routing and service control in the IMS network. Although both are related to the establishment and control of real-time media streams, they are used for different services with different network architectures.

For the IMS subscribers to access the IPTV and VoD service, some existing implementations prefer not to use RTSP in the IMS network. SIP is used to establish the sessions with the remote IPTV/VoD servers. Users need to use key pressing mapping to simulate the media control operations such as play, pause, fast forward, etc. This is good for some legacy SIP video endpoints that do not support the RTSP client functionalities, but the control of these services is not natural and it is preferred that these clients need to support RTSP as well.

Some new endpoints support the SIP and RTSP protocols separately. However, since RTSP flows in a different path from SIP, there is little possibility for the IPTV/VoD services to be controlled in the IMS or VoIP (Voice over Internet Protocol) network. Also it is difficult for these services to make use of the existing QoS (Quality of Service), security and charging framework in the IMS or VoIP network. What is more, there is little opportunity for IPTV/VoD services to be blended with the existing IMS or VoIP services.

In the prior art, therefore, how to merge the two separate networks in a more efficient manner so as to reduce the system cost remains a challenge. Thus, there is a need in the art for a method and system for supporting SIP and RTSP simultaneously and efficiently.

Summary of the Invention

The invention is proposed in order to solve the above problems. According to one aspect of the invention, a method for processing SIP message with RTSP encapsulation in IMS is proposed, comprising the following steps: defining a new SIP content type; and encapsulating a RTSP message into a SIP message with the new SIP content type.

According to another aspect of the invention, a system for processing SIP message with RTSP encapsulation in IMS is proposed, comprising: a user equipment, for encapsulating a RTSP message into a SIP message with a newly- defined SIP content type and extracting a RTSP message from a SIP message with the newly- defined SIP content type; and at least one network element in IMS; wherein both the user equipment and the at least one network element in IMS support the newly-defined SIP content type.

The method and system for processing SIP message with RTSP encapsulation in IMS proposed by the present invention encapsulates a RTSP messages into a SIP message, thereby realizing the use of the IMS security features, the reuse of the IMS QoS framework, the use of the existing IMS charging system, and the convergence of the RTSP-based services, such as IPTV and VoD, with the existing SIP-based IMS services.

Description of the Drawings

The novel features believed characters of the invention is set forth in the appended claims. However, the invention itself and its preferred mode, together with further objects and advantages, will be best appreciated from the reading of the following detailed description of the illustrative embodiments taken in conjunction with the drawings, in which:

FIG. 1 illustrates an exemplary IMS architecture with separated SIP and RTSP message flows;

FIG. 2 illustrates an integrated architecture supporting SIP with RTSP encapsulation according to an embodiment of the invention; and

FIG. 3 illustrates an exemplary scenario supporting SIP with RTSP encapsulation according to an embodiment of the invention.

Detailed Description of the Invention

In order to comprehend the present specification precisely and thoroughly, some elements involved in the SIP with RTSP encapsulation processing and configuration according to the invention are to be introduced below with respect to an exemplary IMS architecture. Furthermore, such architecture also presents the original message flows in IMS.

Now referring to figures, and particularly to FIG. 1, there is illustrated an exemplary IMS architecture with separated SIP and RTSP message flows. In FIG. 1, a User Equipment (UE) 110 makes access to service 190, such as IPTV and VoD, through IMS 100. An IMS User Equipment (UE) is a device allowing user access to network services, such as a 3G handset, a SIP phone or a soft-client running on a PC. A UE supports a number of audio/video media codecs and is capable of originating or terminating sessions to the IMS via the SIP interface. IMS 100 comprises P-CSCF 120, S-CSCF 130, I-CSCF 140, AS 150, HSS 160, CRF 170, and Bearer Network 180. Specifically, CSCF (Call Session Control Function) is the core of IMS architecture. All SIP signaling will pass through CSCF, which is treated as the essential node in IMS. CSCF checks every SIP message and makes sure whether the signaling should visit one or more application server (AS) on the path to its final destination.

P-CSCF (Proxy CSCF) 120 is the first contact point within the IMS. It behaves like a SIP proxy server, i.e. it accepts requests from the UE 110 and forwards them on. Also P-CSCF 120 can initiate QoS control based on the session description information received in SIP messages.

S-CSCF (Serving CSCF) 130 performs the session control services for the UE. It maintains a session state as needed by the network operator for the support of the services. It processes SIP requests based on the initial Filter Criteria (iFC) downloaded from the Home Subscriber Server (HSS). Wherein, initial Filter Criteria (iFC) contains the rules for processing the subscriber's service requests, for example, routing the requests to specific AS, I-CSCF/RSTP Gateway, etc. It is downloaded by S-CSCF upon the UE's successful registration. It can be expanded to include filtering rules for processing the RTSP body encapsulated in the SIP requests. S-CSCF also relays SIP messages between the SIP network elements, such as P-CSCF, AS and I-CSCF, etc. It also generates Call Detail Records (CDR) for billing purpose.

I-CSCF (Interrogating CSCF) 140 is the contact point for all connections destined to a user of an operator's network or a roaming user currently located within that network operator's service area. I-CSCF hides the network topology information when forwarding SIP messages between different operators' domains. Also I-CSCF can initiate QoS control based on the session description information received in SIP messages.

AS (Application Server) 150 is the IMS application server, which runs the IMS application logic for IMS subscribers. S-CSCF will invoke AS when it checks through the service profile of the subscriber and find that it has IMS application enabled. A valid AS name/address is provisioned for each of IMS service in the service profile.

HSS (Home Subscriber Server) 160 is the IMS subscriber database, which contains all the IMS subscriber service profiles, e.g. iFC, registration data, service filter criteria, service data, and location data.

CRF (Charging Rule Function) 170 is a main entity for flow based charging. CRF can be applied to both offline charging and online charging. Charging rules defined by the system operator are transferred to CRF through a uniform interface so as to make charging for the provided services and contents.

The Bearer Network 180 is a network used for transmitting data between UEs. In the lifecycle of one session, a number of bearer networks can be used.

The Bearer Network 180 and P-CSCF 120 perform the QoS control respectively. The dashed arrows in FIG. 1 indicate the SIP flows. SIP flows pass from the UE 110 through P-CSCF 120, S-CSCF 130, I-CSCF 140, in turn, or on the contrary direction. Also, S-CSCF 130 may exchange SIP messages with AS 150, HSS 160, CPvF 170, respectively. The solid arrows in FIG. 1 indicate the RTSP flows between the UE 110 and the IPTV/VoD services 190 via the bearer network 180. The dashed lines in FIG. 1 indicate the bearer streams between the UE 110 and the IPTV/VoD services 190 via the bearer network 180.

As stated above, since the RTSP flows and the SIP flows follow different paths, it is not possible to control IPTV/VoD services in the IMS or VoIP networks and it is difficult for these services to make use of the existing QoS, security and charging frameworks in the IMS or VoIP networks. Moreover, it is not possible for the IPTV/VoD services to be blended with the existing IMS or VoIP services.

Therefore, in the present invention, a novel method and system is proposed to resolve the addressed problems. It employs SIP messages to carry RTSP messages in the IMS/VoIP network. Instead of contacting with the remote IPTV/VoD servers directly, the IMS UE encapsulates the RTSP message into a SIP message and passes it through the IMS network elements, to facilitate the convergence of RTSP related services into existing IMS framework. In particular, the IMS UE sends the SIP message to P-CSCF. P-CSCF then forwards the SIP message to S-CSCF, which processes and forwards it to I-CSCF. I-CSCF then extracts the RTSP message from the received SIP message and sends to the remote RTSP server, and relays the RTSP response backward to the UE through the original SIP message routing path.

Now referring to FIG. 2, there is illustrated an integrated architecture supporting SIP with RTSP encapsulation according to an embodiment of the invention. In FIG. 2, a User Equipment (UE) 210 makes access to service 290, such as IPTV and VoD, through IMS 200. IMS 200 comprises P-CSCF 220, S-CSCF 230, I-CSCF 240, AS 250, HSS 260, CRF 270, Bearer Gateway 285, and Bearer Network 280. Except the Bearer Gateway 285, all of the other elements in FIG.2 are similar to those as shown in FIG. 1, but with some enhancements according to the invention.

First of all, an IMS SIP interface with new content type is defined, i.e. a new SIP content type is defined, so that the RTSP message can be encapsulated into the SIP message. For example:

Content-type: application /RTSP

It indicates that a SIP message with such content type encapsulates a RTSP message therein. The new content type needs to be supported by various IMS network elements that are involved, as mentioned below. The IMS UE 210 has the following enhancements:

^• Add a configuration option of encapsulating a RTSP message as the SIP message body.

^■ With this option enabled, upon initiating a RTSP -based service request (IPTV/VoD, etc), the UE encapsulates the RTSP message into a SIP MESSAGE method and sends it to P-CSCF, instead of sending the RTSP message directly.

P-CSCF 220, in which QoS Application Function (QoS AF) 225 is comprised, is the first contact point of the IMS network for UEs, in which the enhancements include:

^• Recognize the new SIP content type, i.e. realize that there is a RTSP message encapsulated in the SIP message, and forward the SIP message with the encapsulated RTSP message to S-CSCF.

^• Parse the encapsulated RTSP message for media description information, so as to request QoS resource for the RTSP session. This is an optional functionality enabled by this invention.

^• Relay the SIP message with the encapsulated RTSP messages between the UE and S- CSCF.

^• Additionally, it is now possible for P-CSCF to parse the requirements, such as bandwidth, rate, from the RTSP message and initiate QoS control using the existing QoS functionality. The QoS AF 225 is able to communicate with the Bearer Gateway 285 for QoS control.

S-CSCF 230 is a network element that serves the UE's service request, in which the enhancements include:

^• Recognize the new SIP body type and parse the encapsulated RTSP message.

^• Determine which RTSP gateway to forward the message to.

^• Optionally forward the encapsulated RTSP message to SIP application server (AS). This allows the opportunities of service blending and the possibilities of some more complex services.

^• Collect and report the RTSP related charging information to an IMS charging function, such as CRF 260.

^• Requesting IMS subscriber service profiles from an IMS database, such as HSS 260. The IMS subscriber service profiles comprise but not limit to initial filter criteria (iFC), registration data, service filter data, service data, and location data. In particular, iFC is used for processing SIP message with encapsulated RTSP message, for example, routing the message to specific AS, I-CSCF/RSTP Gateway, etc.

^• Relay the SIP message with the encapsulated RTSP message between two network elements in IMS, for example, between P-CSCF and the RTSP gateway, or between the SIP AS and the RTSP gateway.

I-CSCF 240 comprises a new RTSP gateway 245. The new RTSP gateway 245 is to be deployed at the edge of the IMS network, preferably as part of the I-CSCF, but not essential. I- CSCF 240 performs the following functionalities:

^• Extract the encapsulated RTSP message from the received SIP message.

^• Perform DNS (Domain Name Service) query of the RTSP indicated in the RTSP URL, and send the RTSP request to an external RTSP server.

^• Receive the RTSP response from the RTSP server and encapsulate it into the SIP message.

^• Relay the SIP message with the encapsulated RTSP messages to S-CSCF.

The dashed arrows in FIG. 2 indicate the SIP flows. SIP flows pass from the UE 210 through P-CSCF 220, S-CSCF 230, I-CSCF 240, in turn, or on the contrary direction. Also, S- CSCF 230 may exchange SIP messages with AS 250, HSS 260, CRF 270, respectively. The solid arrows in FIG. 2 indicate the RTSP flows between I-CSCF 240 and the IPTV/VoD services 290. The dashed lines in FIG. 2 indicate the bearer streams between the UE 210 and the IPTV/ VoD services 290 via the bearer network 280. The solid line in FIG.2 indicates the QoS control.

From the above detailed descriptions of the integrated IMS architecture supporting SIP with RTSP encapsulation, the advantages compared to the prior art will be readily appreciated by the person with skills in the art, which are listed as below:

^• Use of the IMS security features: The RTSP messages can be securely protected via secure SIP transport, such as SIP over IPSec (IP Security) or TLS (Transport Layer Protocol).

^• Reuse of the IMS QoS framework: The QoS resource request in the RTSP message can be parsed by the SIP servers, so as to perform QoS control via the existing network interfaces between the SIP server and the policy decision function.

^• The RTSP services can now make use of the existing charging system of the IMS services.

^• The RTSP-based services, such as IPTV and VoD, can be converged with the existing SIP-based IMS services.

It is noted that the idea and implementation of SIP with RTSP encapsulation as cited above can be applied to other SIP-based networks, such as IMS, pre-IMS VoIP networks, etc. Such implementation also falls into the spirit and the scope of the present invention. Now referring to FIG.3, there is illustrated an exemplary scenario supporting SIP with RTSP encapsulation according to an embodiment of the invention. For the purpose of consistency, clarity, and understandability, the exemplary scenario is illustrated in conjunction with the IMS architecture supporting SIP with RTSP encapsulation, as shown in FIG. 2.

Initially, at Step 1, a subscriber (user) browses the IPTV and VoD program list on his/her IMS UE. The selection of a program is made by clicking or selecting an RTSP link, such as, rtsp://vod.example.com/musicl l23.en.

At Step 2, the IMS UE is configured to enable the RTSP encapsulation by using a SIP protocol configuration option. Instead of sending the RTSP server the RTSP link, rtsp://vod.example.com, directly, the UE encapsulates the initial RTSP DESCRIBE request in the SIP MESSAGE method and sends it to P-CSCF. As an example, there is a SIP message with the encapsulated RTSP message shown below.

MESSAGE siρ:p-cscf@ims-domain.com:5060 SIP/ 2.0

Via: SIP/2.0/UDP 10.86.9.26:5060;branch=z9hG4bK421eb

From: "Joe Smith" <sip:imsuel@ims-domain.com:5060>;tag=15c31

To: sip:p-cscf@ims-domain. com: 5060

Call-ID: UNSET000.20050224.073704. l@10.86.9.26

CSeq: 1234 MESSAGE

Contact: <sip:imsuel@10.86.9.26:5060;user=phone>

Content-Type: application/ RTSP

Content-Length: 121

DESCRIBE rtsp:// vod.example.com/musicl 123. en RTSP /1.0

CSeq: 312

Accept: application /sdp, application /rtsl, application /mheg

Then at Step 3, P-CSCF recognizes the new SIP content type: "application/RTSP", and forwards the message to S-CSCF that serves this UE.

At Step 4, upon receiving the SIP message with RTSP encapsulation, S-CSCF determines whether or not to apply the application scenario based on the content type "application/RTSP" and the content. If yes, the process proceeds to Step 4a, in which S-CSCF forwards the message to AS to trigger the application logic. This allows the opportunities of service blending and the possibilities of some more complex services. Optionally, at Step 4b, S- CSCF collects and reports the RTSP related charging information to an IMS charging function, such as CRF 270. Optionally, at Step 4c, S-CSCF requests IMS subscriber service profiles from an IMS database, such as HSS 260. Regardless of the performance of Step 4a, 4b, or 4c, S- CSCF chooses I-CSCF based on the RTSP destination received in the encapsulated RTSP message (either from P-CSCF or from AS) and sends the SIP message to I-CSCF.

Then at Step 5, I-CSCF acknowledges the SIP message with the SIP "200 OK" response, extracts the RSTP message from the SIP message, and sends it to a remote RTSP server based on the information in the RTSP message.

As an example, the SIP response sent backward to UE through S-CSCF, AS (optional), and P-CSCF is shown as below:

SIP /2.0200 OK

Via: ...

From: "Joe Smith" <sip:imsuel@ims-domain.com:5060>;tag=15c31

To: sip:p-cscf@ims-domain. com: 5060

Call-ID: UNSET000.20050224.073704. l@10.86.9.26

CSeq: 1234 MESSAGE

Content-Length: 0

And the RTSP message sent to the remote RTSP server vod.example.com is shown as below:

DESCRIBE rtsp:// ^f vod.example.com /music 1123. en RTSP/ 1.0

CSeq: 312

Accept: application/ sdp, application /rtsl, application /mheg

To this end, it is noted that: 1) according to the SIP protocol, the SIP method shall be acknowledged with a SIP response. In the next few steps, it is default that the SIP MESSAGE method is always acknowledged immediately by the remote SIP end (UE or I-CSCF) using the SIP "200 OK" response, which shall traverse through the IMS core network (S-CSCF/AS/P- CSCF) as normal; 2) I-CSCF may contact a Domain Name Service (DNS) server to get the resolved IP address of the RTSP server.

At Step 6, the remote RTSP server acknowledges the RTSP DESCRIBE command with the RTSP "200 OK" response and sends to I-CSCF. The exemplary RTSP response sent to I- CSCF is shown as below:

RTSP/ 1.0200 OK

CSeq: 312

Content-Type: application /sdp

Content-Length: 182

v=0 o=mhandley 28908445262890842807 IN IP4126.16.64.4

S=SDP Seminar c=IN IP4224.2.17.12 t=28733974962873404696 a=recvonly m =audio 3456 R TP /A VP 0 m=video 2232 R TP/ A VP 31 a=orient:portrait

Then at Step 7, I-CSCF encapsulates the RTSP "200 OK" response using SIP MESSAGE method and sends to S-CSCF. The exemplary SIP message with the encapsulated RTSP response sent to S-CSCF is shown as below:

MESSAGE sip:imsuel@ims-domain.com SIP /2.0

Via: SIP/2.0/UDP 10.86.5.35:5060;branch=z9hG4bK43567

From: <sip:i-cscf@ims-domain. com:5060>;tag=4564

To: "Joe Smith" <sip:imsuel@ims-domain.com:5060>;

Call-ID: 1232343453534@10.86.5.35

CSeq: 5589 MESSAGE

Contact: <sip:i-cscj@10.86.5.35:5060>

Content-Type: application /RTSP

Content-Length: 254

RTSP/ 1.0200 OK

CSeq: 312

Content-Type: application /sdp

Content-Length: 182

v=0 o=mhandley 28908445262890842807 IN IP4126.16.64.4

S=SDP Seminar c=IN IP4224.217.12 t=28733974962873404696 a=recvonly m=audio 3456 R TP /A VP 0 m =video 2232 R TP /A VP 31 a —orientiportrait

Then at Step 8, S-CSCF forwards the SIP message back to P-CSCF. Optionally, if at Step 4 S-CSCF determines to apply the application scenario, i.e. there is any application triggered as described in step 4a, then at Step 8a, S-CSCF forwards the SIP message to the AS prior to forwarding it to P-CSCF.

At Step 9, P-CSCF forwards the SIP message with the encapsulated RTSP response back to the IMS UE.

At Step 10, the UE extracts the RTSP response from the received SIP message and continues with the next command, such as initiating the media stream by sending the RTSP PLAY command, down the same message flow.

The dashed arrows, the solid arrows, the dashed lines, and the solid line shown in FIG.3 refer to the same denotations as FIG. 2, and the detailed descriptions are skipped.

Hereinabove, the detailed descriptions of the exemplary scenario supporting SIP with RTSP encapsulation according to the embodiment of the invention are provided. It will be apparent to the person with skills in the art that the steps are taken as examples only, not intended to be any limitation or exhaustion.

The detailed descriptions of a method and system for processing SIP message with RTSP encapsulation in IMS according to the invention are provided hereinabove with reference to the embodiments. As appreciated by the person with ordinary skills in the art, the present invention may be embodied as a method, a system, and/or a computer program product. Therefore, the present invention can be embodied in the form of hardware, software, or the combination thereof. Additionally, the present invention may be embodied as a computer program product contained on machine-readable media where the computer executable program instructions for programming a computer system to execute the process according to the invention are stored. The term "machine-readable media" used herein includes any media that provide the computer system with instructions for execution. Such media may take various forms, including but not limited to: non-volatile media, volatile media, and transmission media. Non-volatile media commonly comprises, for example, floppy disk, floppy magnetic disk, hard disk, magnetic tape, or any other magnetic media, CD-ROM or any other optical media, slotting card or any other physical media with hole pattern, PROM, EPROM, EEPROM, flash memory, any other memory chip or cartridge, or any other media that can be read by the computer system and are appropriate for storing instructions.

Although the present invention has been presented and described specifically by reference to the preferable embodiments, it is not intended to be exhaustive or limited the invention in the form disclosed. Many modifications on forms and details will be apparent to those ordinary skills in the art without deviating from the spirit and scope of the invention. The embodiments were chosen and described in order to best explain the principles of the invention, the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.

Claims

1. A method for processing SIP message with RTSP encapsulation in IMS, comprising the following steps: defining a new SIP content type; and encapsulating a RTSP message into a SIP message with the new SIP content type.

2. The method of claim 1, further comprising the step of relaying the SIP message with the encapsulated RTSP message between any two network elements in IMS or between a user equipment and one network element in IMS.

3. The method of claim 1, wherein the step of encapsulating a RTSP message into a SIP message with the new SIP content type comprises: initiating said encapsulation upon a configuration option is enabled.

4. The method of claims 1, further comprising the step of parsing the encapsulated RTSP message for QoS requirements to request QoS resource for the RTSP session and initiate QoS control with a bearer gateway.

5. The method of claims 1, further comprising the step of determining which RTSP gateway to forward the SIP message to.

6. The method of claims 1, further comprising the step of forwarding the SIP message to an application server for service blending based on the content type and the content of the SIP message.

7. The method of claims 1, further comprising the step of collecting and reporting the RTSP related charging information to an IMS charging function.

8. The method of claims 1, further comprising the step of requesting IMS subscriber service profiles from an IMS database, wherein the IMS subscriber service profiles comprise initial filter criteria for processing the SIP message with the encapsulated RTSP message.

9. The method of claim 1, further comprising the step of extracting the RTSP message from the SIP message with the encapsulated RTSP message.

10. The method of claim 9, further comprising the step of performing a DNS query of the RTSP for the resolved IP address of an external RTSP server;

11. The method of claims 9, further comprising the step of sending the extracted RTSP message to the external RTSP server and receiving a RTSP response from the RTSP server.

12. A system for processing SIP message with RTSP encapsulation in IMS, comprising: a user equipment, for encapsulating a RTSP message into a SIP message with a newly- defined SIP content type and extracting a RTSP message from a SIP message with the newly- defined SIP content type; and at least one network element in IMS in communication with the user equipment; wherein both the user equipment and the at least one network element in IMS support the newly-defined SIP content type.

13. The system of claim 12, wherein the at least one network element relays the SIP message with the encapsulated RTSP message between any two network elements or between the user equipment and one network element.

14. The system of claim 12, wherein the user equipment initiates said encapsulation upon a configuration option is enabled.

15. The system of claim 12, wherein the at least one network element parses the encapsulated RTSP message for QoS requirements to request QoS resource for the RTSP session and initiate QoS control with a bearer gateway.

16. The system of claim 12, wherein the at least one network element determines which RTSP gateway to forward the SIP message to.

17. The system of claim 12, wherein the at least one network element forwards the SIP message to an application server for service blending based on the content type and the content of the SIP message.

18. The system of claim 12, wherein the at least one network element collects and reports the RTSP related charging information to an IMS charging function.

19. The system of claim 12, wherein the at least one network element requests IMS subscriber service profiles from an IMS database, the IMS subscriber service profiles comprise initial filter criteria for processing the SIP message with the encapsulated RTSP message.

20. The system of claim 12, wherein the at least one network element extracts the RTSP message from the SIP message with the encapsulated RTSP message.

21. The system of claim 20, wherein the at least one network element performs a DNS query of the RTSP for the resolved IP address of an external RTSP server;

22. The system of claim 20, wherein the at least one network element sends the extracted RTSP message to the external RTSP server and receives a RTSP response from the RTSP server.

23. The system of claim 20, wherein the at least one network element encapsulates the RTSP response into a SIP message with the new SIP content type.