Abstract:
Method and Apparatus for making more efficient use of air link resources and network capacity in a mobile telecommunications system in which unauthorized and/or unsupported media types transmitted in a session initialization protocol (SIP) message sent from one equipment user (UE) to another are deleted by the network(s) as the SIP message is routed through the system.

Description:
CROSS REFERENCE TO RELATED APPLICATIONS  
       [0001]     This application is a continuation of U.S. patent application Ser. No. 10/022,998 filed Dec. 18, 2001, which claims the benefit of U.S. Provisional Patent Application No. 60/294,192, filed on May 29, 2001, which are incorporated by reference as if fully set forth. 
     
    
     BACKGROUND  
       [0002]     The present invention relates to wireless telecommunications. More specifically, the present invention relates to a technique for reducing unnecessary consumption of the air link resources and network capacity by reducing the size of transmitted messages.  
         [0003]     The current third generation partnership project (3GPP) and internet engineering task force (IETF) session description protocol (SDP) protocol (RFC 2327) mandate that the proxy call state control functions (P-CSCF), the serving call state control functions (S-CSCFs) and the terminating end user (User Equipment UE) to examine the media contents of the session description protocol (SDP) text in the session initialization protocol (SIP) message.  
         [0004]      FIG. 1  shows a simplified session initiation system. A user, UE-A  20 , desires to initiate a media session with another user UE-B  40 . In  FIG. 1 , UE-A  20  is shown as “roaming” in network A  22 , not its home network. UE-A  20  sends a SIP invite message  44   1  to UE-B  40  via network A  22 . The UE-A SIP invite  44   1  indicates all the media types that it can support. As shown in  FIG. 1 , the SIP invite  44   1  has a header, global information, and a list of the supported media types (media  1  to media  6 ). The supported media types include information for each media, such as the CODEC type, stream format, stream bit rate, and communication port number. Under the proposed system, there are no limits on the number of media types that a UE can include in the SIP invite message.  
         [0005]      FIG. 2  is an example of a SIP invite message. The SIP invite message has a header, global information and supported media types for UE-A  20  for potential use in the proposed media session. The header includes various overhead information, such as the origin and destination of the SIP invite. The global information includes information common to all the proposed media types, such as the destination address and the proposed session identification (ID) number. The supported media types are listed. In this example, four media types are listed, two video (video media  1  and video media  2 ) and two audio (audio media  3  and audio media  4 ). Each proposed media session includes information regarding the media session, such as the port number, real time protocol (RTP) payload type and RTP format and clock rate port.  
         [0006]     UE-A  20  sends the SIP invite to its current network, such as network A  22 , in which it is currently located. UE-A may be “roaming,” as shown in  FIG. 1  and communicating with a network, network A  22 , or it may be in its home network, network B  30 . The SIP invite  44   1  is examined by a P-CSCF  24  of its current network, such as network A  22 , for routing to its destination, UE-B  40  via UE-A&#39;s home network, network B  30 . The P-CSCF  24  examines the session description protocol (SDP) multimedia contents of the SIP invite  44   1  for validation and authorization. If the P-CSCF&#39;s network, network A  24 , does not support any part of the media information, (such as the CODESs, bit rate or the type), it flags that portion of the media information by setting the port number to “0” and leaving the other contents of the media information untouched, as shown for media  5  and  6  for SIP invite  44   2 .  
         [0007]      FIG. 3  is an example of such a flagged SIP invite  44 . To illustrate, the P-CSCF cannot support video media  1 . As shown in  FIG. 3 , the port number is set to “0” so that UE-B  40  realized that video media  1  cannot be selected for the media session.  
         [0008]     The network A P-CSCF  24  forwards the modified SIP invite  44   2  to the network B S-CSCF  26  for further handling, routing and validation. If UE-A  20  is in the home network, both the P-CSCF and S-CSCF function are performed by the home network  30 . The network B S-CSCF  26  examines the SIP invite  44   2  including the media information. Media types not supported by UE-A&#39;s service license agreement (SLA) are flagged. If UE-A  20  is in its home network, the flagging process is only performed by the S-CSCF  26 , not by the P-CSCF  24 . The S-CSCF  26  forwards the SIP invite  44   3  to UE-B&#39;s home network, network C 36 , using intorgating-CSCFS (I-CSCF)  28 ,  32 .  
         [0009]     The network C S-CSCF  34  similarly examines the SIP invite  44   3  for media types not available under UE-B&#39;s SLA. The not available media types are flagged, as illustrated for media  1  and of SIP  44   4 . If UE-B  40  is not in its home network, as shown, the SIP invite  44   4  is forwarded to the P-CSCF  38  of the network, network D  42 , where UE-B  40  is currently located, or “roaming.” If UE-B  40  is in its home network, the SIP invite  44   4  is forwarded to the P-CSCF  38  of the home network.  
         [0010]     The P-CSCF  38  flags the media types not supported by the network, network D. No additional flagged media types are shown in SIP invite  44   5 . If the UE-B is in its home network, the flagging is only performed by the S-CSCF  34 . The P-CSCF  38  sends the SIP invite  44   5  to UE-B  40 . UE-B  40  examines the media information of the SIP invite  44   5  and determines whether it is capable of using any of the unflagged media types. If it can not use any of the unflagged media types or there are not any remaining unflagged media types, UE-B  40  sends UE-A  20  a session description protocol message (SPM)  46  with all media types flagged. If it can use the unflagged media types, UE-B  40  selects one or more of the available media types for the session. The selected media types unflagged and the flagged media types are returned to UE-A  20  in the SPM  44 .  
         [0011]     As shown in  FIGS. 2 and 3 , the SIP invite message  44  is large and, accordingly, consumes valuable air interface and wireless network resources. This resource consumption either degrades the network performance or reduces the maximum number of users serviced by the networks.  
         [0012]     Accordingly, it is desirable to have alternate approaches for media session initiation.  
       SUMMARY  
       [0013]     The present invention reduces the size of the SIP message by eliminating or deleting unsupported and/or unauthorized media types in the SIP along the signaling route from the originating end user to the terminating one and back. The present invention restricts the media information carried within the SIP message to information that is allowed by the network and authorized for the users at both ends. 
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0014]      FIG. 1  is an example of an overall system diagram for media session initiation.  
         [0015]      FIG. 2  is an example of a Session Initialization Protocol (SIP) message.  
         [0016]      FIG. 3  is an example of a SIP message with a flagged media type.  
         [0017]      FIGS. 4   a  and  4   b  are signaling diagrams.  
         [0018]      FIG. 5  is an example of an overall system diagram.  
         [0019]      FIG. 6  is an example of a SIP message.  
         [0020]      FIG. 7  is an example of a SIP message with removed media information. 
     
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS  
       [0021]      FIGS. 4   a  and  4   b  is a signaling diagram of the present invention.  FIG. 5  illustrates an example of the components of the media session initiation. UE-A  46  desires to initiate a media session with UE-B  68 . UE-A  46  and UE-B  48  may be any wireless communication device, such as a mobile phone, personal computer (PC) or personal digital assistant (PDA). UE-A  46  in the system of FIG.  5  is shown as “roaming” in network A  50 . For  FIG. 1 , network B  58  is the “home” network for UE-A  46 . Alternately, UE-A  46  may be in its home network.  
         [0022]     UE-A  46  determines the CODECS available for the media types for the proposed session, ( 74 ). A SIP invite  52   1 , such as shown in  FIG. 2 , is composed using this information. UE-A  46  sends the SIP invite message  52   1  intended for UE-B  58  via network A is P-CSCF  48 . UE-B  68  is shown as “roaming” in network D  70 . Alternately, UE-B  68  may be in its home network, network C  64 . The SIP invite  52   1  includes all the media types that UE-A  46  can support and invites UE-B  68  to choose the type(s) that it can support. The media information includes the CODEC types, stream format, stream bit rate, and communication port number, among other media attributes. Under the current proposed system, there are no limits on the number of media types that a UE can include in the SIP invite message  52   1 . Furthermore, there are no restrictions on the end user, such as UE-B  68  to include unauthorized unsupported media types.  
         [0023]     The P-CSCF  48 , incorporated in network A, routes the SIP invite  52   1  to the end user (UE-B  68 ). The P-CSCF function  48  initiates examination of the SIP invite message  52   1  for routing and for validation and authorization of the SDP multimedia contents. If network A  50  does not support any part of the media information (such as the CODECS, the bit rate or the media type), P-CSCF  48  deletes the media entry from the SDP message leaving only the supported media entries, ( 76 ), as shown as SIP invite  52   2 . In the example SIP invite  52   2 , media types  5  and  6  have been deleted, since it is not supported by network A  50 . Deleting the media type is performed by removing all of the information of the unsupported media type.  
         [0024]      FIG. 6  is an example of the SIP invite message  44  of  FIG. 2  with the media types deleted, as shown as SIP invite  52 . To illustrate, network A  50  does not support video media types, (video media  1  and  2 ). As shown in  FIG. 6 , the information concerning video media  1  and  2  is deleted, leaving only audio media  3  and  4 . The P-CSCF  48  then forwards the modified SIP invite  52   2  to the S-CSCF  54  of network B  58  for further handling (routing and validation). The S-CSCF  54  of network B  58  examines the SIP invite  52   2  including the modified SDP message. The S-CSCF  54  will remove unauthorized media types that UE-A  46  is not permitted to use under its SLA, ( 78 ). The S-CSCF  54  (which usually exists in the UE home network) also removes any not permitted media contents. In the  FIG. 5  example, media type  1  is deleted, as shown for SIP invite  52   3 . If UE-A  46  is in its home network, typically both the P-CSCF and S-CSCF function  46 ,  54  are performed by the home network, with only the S-CSCF  54  deleting media types.  
         [0025]     The S-CSCF  54  forwards the further modified SIP invite  52   3  to UE-B&#39;s home network, network C  64 , through its I-CSCF  56  (Intorgating-CSCF). After receiving the SIP invite  52   3  via its I-CSCF  60 , the S-CSCF  62  of network C  64  removes media types not permitted under UE-B&#39;s SLA, ( 80 ). After forwarding the SIP invite  52   4  to UE-B&#39;s current network D  70 , P-CSCF  66  removes unsupported media types of the current network, where UE-B is roaming, ( 82 ). As shown in  FIG. 5 , no additional media types are deleted in SIP invite  52   5 . If UE-B  68  is in its home network, typically the S-CSCF and P-CSCF functions  62 ,  66  are performed by the home network, with the S-CSCF  62  deleting the media types.  
         [0026]     UE-B  68  examines the remaining SDP media types of the SIP invite  52   5  and determines if it can support them. If it can, it selects one or more of the remaining media types and sends UE-A  48 , a session progress message  72 , ( 84 ), through the network D P-CSCF  66 . If it can not support any of the media types or none remain in the SDP information, UE-B  68  also sends a session progress message with all the media types deleted.  
         [0027]      FIG. 7  is an example of a SPM  72 . To illustrate a possible derivation for SPM  72 , UE-B  68  receives the SIP invite  52  of  FIG. 6 . UE-B  68  is capable of supporting audio media  3 . A SPM  72  is generated at UE-B  68  only containing the selected media type, audio media  3 , and a header and global information. Audio media type  4  is not included.  
         [0028]     Upon reception of the SPM  72 , the P-CSCF  66  authorizes network D  70  to allocated the resources for the sessions indicated by the media type information, ( 86 ). The SPM progresses to UE-A  46  through the network C S-CSCF  62 , the network B S-CSCF  54  and the network A P-CSCF  48 . The network A P-CSCF  48  authorizes network A  50  to allocate the resources for the indicated session(s), ( 88 ). After the P-CSCF  48  sends the SPM  72  to UE-A  46 , UE-A  46  determines the initial CODEC(S) to use for the media session(s) of the SPM  72 , ( 90 ).  
         [0029]     UE-A  46  sends a final SPM to UE-B  68 , through the same path, indicating the selected CODEC(S). At the same time as sending the final message, UE-A reserves the resources for the selected CODEC, ( 92 ), and, if successful, sends a success message to UE-B  68 . After UE-B receives the final SPM, it reserves resources for the selected CODEC, ( 94 ).  
         [0030]     When UE-B  68  receives the success message, it stops sending messages with its old CODEC, sets up the receiver for the new CODEC and sends an O.K. message to UE-A, ( 98 ). After UE-A  98  receives the O.K. message, it sends a success message with the new CODEC and sets up the receiver for the new CODEC, ( 98 ). After UE-B  68  receives the success message, it starts sending data with the new CODEC, ( 100 ).