Abstract:
A method and apparatus for managing a HOLD announcement in a communication network. At an Application Server, AS, a message is received from a user terminal, the message comprises of an indicator, specifying whether the AS should provide a HOLD announcement in the event of a change in direction of a media stream between the user terminal and a further node during a session. The AS stores the indicator in a memory. Upon determination that a change in direction of the media stream has occurred, the AS determines, from the indicator, whether or not to provide the HOLD announcement to the further node.

Description:
TECHNICAL FIELD 
       [0001]    The invention relates to providing a HOLD announcement in a communication network. 
       BACKGROUND 
       [0002]    The IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over mobile communication networks. IP Multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within the same session. 
         [0003]      FIG. 1  illustrates schematically how the IMS fits into the mobile network architecture in the case of a GPRS/PS access network (IMS can of course operate over other access networks). As shown in  FIG. 1 , the IMS includes a core network,  101 , and a service network,  102 . Call/Session Control Functions (CSCFs),  103 , operate as Session Initiation Protocol (SIP) proxies within the IMS core network, and interface with other entities such as Breakout Gateway Control Functions (BGCFs),  104 , and Media Resource Function Controllers (MRFCs),  105 , amongst others. A Proxy CSCF (P-CSCF) is the first point of contact within the IMS for an SIP terminal; a Serving CSCF (S-CSCF) provides services to the subscriber; an interrogating CSCF (I-CSCF) identifies the correct S-CSCF and forwards to that S-CSCF a request received from an SIP terminal via a P-CSCF. 
         [0004]    Situations may arise in which a user, participating in a communication session with another user, wishes to place the other user on hold. 3GPP has specified a Communication HOLD supplementary service in TS 24.610, where a user can put another user on HOLD by changing the direction of the media stream in an established communication as defined in chapter “4.5.2.1 Actions at the invoking UE.” In such a case a User Equipment (UE) generates a new session description protocol (SDP) offer, in which the SDP offer contains an attribute specifying the desired change. If the direction of the media stream was initially set to “send and receive,” it may be downgraded to “send only” by specifying a “sendonly” attribute in the SDP offer. If the direction of the media stream was initially set to “receive only,” it may be changed to “inactive” by specifying an “inactive” attribute in the SDP offer. The user can later resume the communication by changing back the media direction. A “recvonly” SDP attribute is used when the stream was previously set to “inactive,” and a “sendrecv” SDP attribute is used when the stream was previously set to “sendonly.” However the latter attribute may be omitted, since “sendrecv” is the default. 
         [0005]    Chapter “4.5.2.4 Actions at the AS of the invoking UE” of TS 24.610 states that it is a network option as to whether to provide an announcement towards the held user. 
         [0006]    There may be circumstances in which it is undesirable to have a HOLD announcement provided by a network when the user changes a direction of the media stream. For example, the user may be participating in a media session, containing both video and audio streams, with another node in a terminating network. Due to bandwidth considerations the user may decide to stop receiving the video stream, but keep the audio stream. In such a case the user may specify that the video stream direction be changed from “send and receive,” to “send only.” In this example, the user would not want an Application Server (AS) to provide a HOLD announcement to the other node in response to this change in direction of the media stream. 
         [0007]    A specification is defined for the use of withholding a HOLD announcement during a conference, and is given in TS 24.610, chapter 4.6.6. If a participant of a conference invokes the HOLD service, it is not desirable to provide an announcement to the conference. The AS configures a HOLD announcement when a request is made to change the direction of the media stream during a conference, and does not provide one to the held users when the request originates from the “focus,” with the “focus” being the central point of control, authentication, and authorization of the conference. 
         [0008]    The withholding of the HOLD announcement specified in TS 24.610 does not solve the problem of allowing a user to configure a HOLD announcement, which is to be implemented when the user makes a change to the direction of the media stream. 
       SUMMARY 
       [0009]    It is an object of the invention to provide greater control to a user on whether or not a HOLD announcement is to be played when the user places a recipient on HOLD. According to a first aspect of the invention, there is provided a method of managing a HOLD announcement in a communication network. At an Application Server, AS, a message is received from a user terminal. The message includes an indicator, specifying whether the AS should provide a HOLD announcement in the event of a change in direction of a media stream between the user terminal and a further node during a session. The AS stores the indicator in a memory. Upon determination that a change in direction of the media stream has occurred, the AS determines, from the indicator, whether or not to provide the HOLD announcement to the further node. A change in the direction of the media stream can occur, for instance, when initially a first user is participating in a media session, containing both video and audio streams, with another user. Due to bandwidth considerations the first user may decide to stop receiving the video stream, but keep the audio stream. In such a case the first user would specify that the video stream direction be changed from “send and receive,” to “send only”. The user in this example would not want an AS to provide a HOLD announcement to the other user in response to this change in direction of the media stream. Therefore the invention solves this problem by providing the user with the option of selecting whether or not they wish that a HOLD announcement is to be provided. 
         [0010]    As an option, the network is an IP Multimedia Subsystem, IMS, network. 
         [0011]    As an option, the indicator is supplied to the AS using a Supplementary Service Code, SSC, at the start of the session. 
         [0012]    As an alternative option, the indicator is supplied to the AS using an a-attribute in a Session Description Protocol, SDP, message. 
         [0013]    As a further alternative option, the indicator is supplied to the AS using supplementary service data, SSD. 
         [0014]    As an option, the change in the direction of the media stream is from a “send and receive” media stream, to a “send only” media stream. 
         [0015]    According to a second aspect, there is provided an AS for managing a HOLD announcement in a communication network. The AS is provided with a receiver for receiving a message from a user terminal. The message comprises an indicator specifying whether the AS should provide a HOLD announcement in the event of a change in direction of a media stream between the user terminal and a further node during a session. The AS is also provided with a memory for storing the indicator and a processor for determining that a change in direction of the media stream has occurred. The processor is arranged to determine, from the indicator, whether or not to provide the HOLD announcement to the further node. 
         [0016]    According to a third aspect, there is provided a method of operating a user terminal. A user utilises the user input, and inputs an indicator specifying whether an AS should provide a HOLD announcement in the event of a change in direction of a media stream during a session involving the user terminal. The user terminal can then transmit a message comprising the indicator to the AS. 
         [0017]    According to a fourth aspect, there is provided a user terminal. The user terminal is provided with a user input device for receiving a user input. The user input includes an indicator specifying whether an AS should provide a HOLD announcement in the event of a change in direction of a media stream during a session involving the user terminal. The user terminal is also provided with a transmitter for transmitting a message including the indicator to the AS. 
         [0018]    According to a fifth aspect, there is provided a computer program, comprising computer readable code which, when run on an AS, causes the AS to perform the method as described above in the first aspect. 
         [0019]    According to a sixth aspect, there is provided a computer program, comprising computer readable code which, when run on a user terminal, causes the user terminal to perform the method as described in the third aspect. 
         [0020]    According to a seventh aspect, there is provided a computer program product comprising a computer readable medium and a computer program as described above in either of the fifth or sixth aspects, wherein the computer program is stored on the computer readable medium. 
     
    
     
       BRIEF DESCRIPTION OF DRAWINGS 
         [0021]      FIG. 1  illustrates schematically in a block diagram an IMS network in association with a mobile network architecture of a General Packet Radio Service (GPRS) access network; 
           [0022]      FIG. 2  is a signalling flow diagram illustrating an exemplary way of configuring a HOLD announcement; 
           [0023]      FIG. 3  is a signalling flow diagram illustrating a further exemplary way of configuring a HOLD announcement; 
           [0024]      FIG. 4  is a flow diagram illustrating an exemplary embodiment of the invention. 
           [0025]      FIG. 5  is a flow diagram illustrating a further exemplary embodiment of the invention. 
           [0026]      FIG. 6  illustrates schematically in a block diagram an exemplary embodiment of an Application Server; 
           [0027]      FIG. 7  illustrates schematically in a block diagram an exemplary embodiment of a User Equipment (UE). 
       
    
    
     DETAILED DESCRIPTION 
       [0028]    The invention provides to a user a way of specifying whether a HOLD announcement in a communication network is to be provided when a change in a direction of a media stream occurs. It can sometimes be undesirable for a HOLD announcement to be played when the direction of the media stream is changed. An example of a change in direction of a media stream may occur when the user is participating in a media session, containing both video and audio streams, with another node in a terminating network. Due to bandwidth considerations the user may decide to stop receiving the video stream, but keep the audio stream. In such a case the user specifies that the video stream direction be changed from “send and receive,” to “send only.” The user in this example would not want an AS to provide a HOLD announcement to the other node in response to this change in direction of the media stream. 
         [0029]    A first exemplary embodiment is illustrated in  FIG. 2 . In this embodiment, a decision on whether or not to provide a HOLD announcement is configured by the user, achievable by utilising an a-attribute in a session description protocol (SDP) message. For example, two new additional a-lines can be defined as, “a=play-announcement” and “a=no-announcement”, specifying that an announcement is to be provided, or not respectively. 
         [0030]    The session&#39;s media stream is initially set to “send and receive.”
   S 201 . A user equipment (UE)  201  makes a request to change the media flow between itself and another node  203  in a terminating network from “send and receive” to “send only.” This is achieved by sending an INVITE towards the other node  203 , wherein the SDP message includes an “a=sendonly” attribute. The SDP also comprises an indicator specifying the user&#39;s settings regarding a HOLD announcement. This is in the form of the additional a-lines, “a=play-announcement” or “a=no-announcement” for example.   S 202 . The AS  202  receives the INVITE associated with the request to change the direction of the media stream, which also includes the indicator relating to whether a HOLD announcement is to be provided at the other node in the event of a change in the direction of the media stream. In this embodiment the indicator is in the form of the additional a-attribute, and is stored by the AS  202 .   S 203 . The INVITE is forwarded on towards the other node  203 . The AS can also provide or withhold a HOLD announcement to the other node, based on the contents of the indicator.   S 204 . Upon receiving the INVITE, the other node  203  sends a 200 OK response towards the UE  201  via the AS  202 , wherein the 200 OK response contains an SDP message requesting that the media stream be set to “receive only.”   
 
         [0035]    This embodiment allows the user to specify whether a HOLD announcement is to be provided during a session in which a change in the direction of the media stream occurs. The embodiment allows the user to configure their desired setting during the session, by including an a-attribute in the SDP. 
         [0036]    In a second embodiment, illustrated in  FIG. 3 , the HOLD announcement is configured by the UE  201  during initialisation of a communication session between the UE  201  and the other node  203 , by utilisation an SIP based user configuration
   S 301 . The UE  201  supplies the AS  202  with a supplementary service code (SSC), also know as a feature access code (FAC). For example, the user can initiate a session with the other node  203  and affix an SSC to the front of the dialled number (B-number), wherein the SSC defines the user&#39;s setting.   S 302 . The AS  202  receives the INVITE sent towards the other node  203 . The AS  202  stores the user&#39;s indicator, based on the SSC and removes the SSC prefix from the B-number.   S 303 . The AS  202  forwards the INVITE towards the other node  203 . Further signalling to set up the session occurs between the other node  203 , the AS  202  and the UE  201 .   S 304 . During an established session the UE  201  makes a request to change the direction of the media stream by sending an INVITE towards the other node  203 . The SDP message includes an “a=sendonly” attribute, corresponding to a request to change from “send and receive” to “send only.”   S 305 . The AS  202  receives the INVITE associated with the request to change the direction of the media stream and looks up the user&#39;s indicator relating to whether a HOLD announcement is to be provided in the event of a change in the direction of the media stream.   S 306 . The AS  202  then forwards the INVITE on towards the other node  203 . The AS can then provide or withhold a HOLD announcement to the other node, based on the contents of the indicator.   S 307 . Upon receiving the INVITE, the other node  203  sends a 200 OK response towards the UE  201  via the AS  202 , the 200 OK response containing an SDP message requesting that the media stream be set to “receive only.”   
 
         [0044]    This embodiment allows the user to specify whether an announcement is to be provided during a session in which a change in the direction of the media stream occurs. The embodiment allows the user to configure their desired setting during the initialisation of the session by supplying the AS  202  with an SSC, where the SSC defines the user&#39;s setting. 
         [0045]    In a third embodiment, supplementary service data is provided for the configuration of HOLD announcements. This allows the user to specify their setting regarding providing or withholding the HOLD announcement, prior to the initialisation of a session. 
         [0046]    This embodiment introduces an XML schema for a HOLD supplementary service, which, in addition to specifying if the service is active or not, specifies if a network provided announcement shall be provided or not. By not providing a HOLD announcement, it is implied that unidirectional data shall be allowed end-to-end. An example of this XML schema is as follows: 
         [0000]    
       
         
               
             
           
               
                   
               
             
             
               
                 &lt;?xml version=“1.0” encoding=“UTF-8”?&gt; 
               
               
                 &lt;xs:schema xmlns:ss=“http://uri.etsi.org/ngn/params/xml/simservs/xcap” 
               
               
                 xmlns:xs=“http://www.w3.org/2001/XMLSchema” 
               
               
                 targetNamespace=“http://uri.etsi.org/ngn/params/xml/simservs/xcap” 
               
               
                 elementFormDefault=“qualified” attributeFormDefault=“unqualified”&gt; 
               
               
                  &lt;xs:element name=“hold” substitutionGroup=“ss:absService”&gt; 
               
               
                   &lt;xs:annotation&gt; 
               
               
                    &lt;xs:documentation&gt;Communication HOLD&lt;/xs:documentation&gt; 
               
               
                   &lt;/xs:annotation&gt; 
               
               
                   &lt;xs:complexType&gt; 
               
               
                    &lt;xs:complexContent&gt; 
               
               
                     &lt;xs:extension base=“ss:simservType”&gt; 
               
               
                      &lt;xs:sequence&gt; 
               
               
                       &lt;xs:element name=“default-behaviour” default=“play- 
               
               
                 announcement” minOccurs=“0”&gt; 
               
               
                        &lt;xs:simpleType&gt; 
               
               
                         &lt;xs:restriction base=“xs:string”&gt; 
               
               
                          &lt;xs:enumeration value=“play-announcement”/&gt; 
               
               
                          &lt;xs:enumeration value=“play-no-announcement”/&gt; 
               
               
                         &lt;/xs:restriction&gt; 
               
               
                        &lt;/xs:simpleType&gt; 
               
               
                       &lt;/xs:element&gt; 
               
               
                      &lt;/xs:sequence&gt; 
               
               
                     &lt;/xs:extension&gt; 
               
               
                    &lt;/xs:complexContent&gt; 
               
               
                   &lt;/xs:complexType&gt; 
               
               
                  &lt;/xs:element&gt; 
               
               
                 &lt;/xs:schema&gt; 
               
               
                   
               
             
          
         
       
     
         [0047]    An example of the UE specifying a desired setting for the HOLD supplementary service in the form of the XML part of a Ut request is as follows: 
         [0000]    
       
         
               
             
           
               
                   
               
             
             
               
                 &lt;?xml version=“1.0” encoding=“UTF-8”?&gt; 
               
               
                 &lt;ss:simservs xmlns=“http://uri.etsi.org/ngn/params/xml/simservs/xcap” &gt; 
               
               
                  &lt;ss:hold active=“true”&gt; 
               
               
                   &lt;ss:default-behaviour&gt;play-no-announcement&lt;/ss:default-behaviour&gt; 
               
               
                  &lt;/ss:hold&gt; 
               
               
                 &lt;/simservs&gt; 
               
               
                   
               
             
          
         
       
     
         [0048]    If a user does not specify whether a HOLD announcement is to be provided or not, then their option may be set by the network operator. 
         [0049]    This embodiment allows the user to specify whether an announcement is to be provided during a session in which a change in the direction of the media stream occurs. The embodiment allows the user to specify their desired setting before initialisation of the session by manipulating the configuration of their HOLD supplementary service at the AS  202 . 
         [0050]      FIG. 4  is a flow diagram illustrating an example of the process of the user configuration and implementation of a HOLD announcement in accordance with the first embodiment of the present invention. The steps are performed as follows:
   S 401  During an established session, a user, wishing to configuring the HOLD announcement, makes use of the user terminal  201  to input a desired setting regarding the condition for providing or withholding a HOLD announcement, in the form of an indicator.   S 402  The user terminal  201  subsequently requests a change in the direction of the media stream, and sends an INVITE towards the other node  202 . The SDP message sent with the INVITE comprises the indicator specifying whether a user associated with the user terminal  201  wishes the AS  202  to provide a HOLD announcement to the other node  203  when a change in the direction of the media stream is detected between the user terminal  201  and the other node  203 .   S 403  The AS  202  receives the INVITE, comprising the indicator from the user terminal.   S 404  The AS  202  stores the indicator and detects a change in direction of the media stream.   S 405  The AS  202  forwards the INVITE on towards the other node  203 .   S 406  The AS  202  looks up the indicator and implements the desired action accordingly.   
 
         [0057]    While step S 401  occurs during a session in this embodiment, it will be appreciated that the user may perform step S 401  before the session has begun, with the user&#39;s setting being stored in a memory  703  in the UE. 
         [0058]      FIG. 5  is a flow diagram illustrating an example of the process of the user configuration and implementation of the HOLD announcement in accordance with the second and third embodiments of the present invention. The steps performed are as follows:
   S 501  A user who wants to configure the HOLD announcement makes use of a user terminal  201  to input a desired setting regarding the condition for providing or withholding a HOLD announcement, in the form of an indicator.   S 502  The user terminal  201  then sends a message to the AS  202 , the message comprising the indicator specifying whether a user associated with the user terminal  201  wishes the AS  202  to provide a HOLD announcement in the event of a change in direction of a media stream between the user terminal  201  and the other node  203  during a session.   S 503  The AS  202  receives the message, comprising the indicator from the user terminal  201 .   S 504  The AS  202  stores the indicator.   S 505  Subsequently during a session, the user requests that the direction of the media stream is to be changed and sends an INVITE request towards the other node  203 . The INVITE request is received at the AS  202 .   S 506  The AS  202  forwards the INVITE on towards the other node.   S 507  The AS  202  looks up the indicator in the memory  503  and implements the desired action accordingly.   
 
         [0066]      FIG. 6  illustrates schematically an example of an AS  202  for implementing an IMS supplementary service in accordance with the methods described above. The AS  202  can be implemented as a combination of computer hardware and software. The AS  202  comprises a processor  601 , a computer readable medium in the form of a memory  602  a receiver  603  and a transmitter  604 . The memory  602  comprises a program  606  and a database  607  used for storing one or more user indicators  605 . When the user terminal  201  requests that a change be made to the direction of the media steam between itself and the other node  203 , an INVITE request is sent towards the other node  203  via the AS  202 . This INVITE request is received by the receiver  603  at the AS  202  and the program  606  is implemented by the processor  601 . The user&#39;s indicator  605 , which is stored within the memory  602 , is accessed and the user&#39;s desired setting is implemented based on the value of the indicator  605 , as to whether the change in direction of the media stream should be accompanied by a HOLD announcement at the other node  203 . The INVITE request is then sent on towards the other node  203  by the transmitter  604  and a HOLD announcement may be withheld or provided depending on the user&#39;s defined setting specified within the indicator. 
         [0067]      FIG. 7  illustrates schematically an example of the UE  201  suitable for implementing the methods described above. The UE  201  can be implemented as a combination of computer hardware and software. The UE  201  comprises a user input device  701  a processor  702  a computer readable medium in the form of a memory  703  a receiver  704  and a transmitter  705 . The memory  703  stores a program  706 . The program  706  is implemented by the processor  702  and is used to process the user input received from the user input device  701 . The processor  702  is used to generate a message, the message comprising an indicator  605  specifying whether a HOLD announcement is to be provided in the event of a change in the direction of the media stream between the UE  201  and the other node  203 . The message is sent to the AS  202  by the transmitter  705 . 
         [0068]    It will be appreciated by the person of skill in the art that various modifications may be made to the above-described embodiments without departing from the scope of the present invention. For example, the above description refers to an IMS network, but it will be appreciated that the methods described may be implemented in other types of networks such as an internet protocol (IP) or Packet Switched (PS) network. 
         [0069]    The following acronyms have been used in the above description: 
         [0070]    3GPP 3rd Generation Partnership Project 
         [0071]    AS Application Server 
         [0072]    BGCFs Breakout Gateway Control Functions 
         [0073]    CSCFs Call/Session Control Functions 
         [0074]    FAC Feature Access Code 
         [0075]    IMS IP Multimedia Subsystem 
         [0076]    IP Internet Protocol 
         [0077]    MRFCs Media Resource Function Controllers 
         [0078]    PS Packet Switched 
         [0079]    SDP Session Description Protocol 
         [0080]    SIP Session Initiation Protocol 
         [0081]    SSC Supplementary Service Code 
         [0082]    SSD supplementary service data 
         [0083]    UE User Equipment 
         [0084]    XML Extensible Markup Language