Patent Publication Number: US-2018041549-A1

Title: In-Session Communication

Description:
TECHNICAL FIELD 
     The present application relates to a method, a system, devices and a computer program for setting-up a communication channel between two entities in a telecommunication network. 
     BACKGROUND 
     “In-call application” is a technique whereby a voice call is enhanced with an additional service or services such as:
         Voice recording, including providing a link in the call log to the voice recording   Speech recognition and speech transcription   Record my geographic location   “reminder whispering”   (for classified users only) Obtaining information related to the remote party, such as
           Current geographic location   Mobile phone IMEI, model   Subscription information   Speech-enabled user authentication   “silently” link in an additional “listen-only” party in the call   
               

       FIG. 1  shows an architectural view of a system in which in-call applications can be applied. The execution of these in-call services may take place under control of an entity in the control plane, e.g. a session initiation protocol application server (SIP-AS)  40  shown in  FIG. 1  or by an entity in the user plane, by way of example a media resource function  20  (MRF). When the SIP-AS  40  is in control of the execution of the in-call service, the SIP-AS  40  may, in its turn, apply instructions to the MRF  20 , e.g. for voice recording. In that case the SIP-AS  40  is in control, whereas the MRF  20  does the execution of the service such as the voice recording. As can be deduced from  FIG. 1 , a mobile entity or UE  100  may have a control plane connection by a CSCF  10  to the other, remote other remote party, wherein the user plane passes through MRF  20 . The SIP-AS  40  can comprise the in-call application  50  which may be then in communication with MRF  20  for the application of the service. Furthermore, an entity  60  providing the value added services is provided which represents an application server that is functionally connected to MMTel-AS  30  (Multimedia Telephony Application Server) which is a session state model instance for augmenting the MMTel (multimedia telephony) communication session. The SIP-AS  40  may be a SIP-AS that is linked into the SIP chain specifically for providing the capability to invoke in-call applications. It comprises a functional connection towards an external application server where the actual in-call application server is being executed. 
     Different possibilities exist how to initiate the execution of an in-call service. Manners to initiate the execution of an in-call service comprise (non-exhaustive):
         Voice command: the user can pronounce a particular word that triggers the execution of the service.   DTMF tone;   HTTP; a separate data channel needs to be established (mobile data connection) towards the in-call application server.       

     The use of voice commands is inherently problematic. A first problem with voice commands is that the remote (destination) party hears the command. Another problem with voice commands is that it may not always be captured correctly. A further problem with voice commands is that it requires the user plane to be always routed through the Media resource function, to capture a possible voice command. Summarizing:
         Voice command: the user can pronounce a particular word that triggers the execution of the service. Hereto, the user plane of the call shall be unconditionally anchored in an MRF. Additional disadvantages comprise:
           Voice command can be heard by remote party;   The system (specifically: the MRF) needs to “learn” the voice command;   Limited number of commands can be used at any one time;   Cannot be used when the call is on hold, since there is then no user plane data transmission;   
           DTMF tone; disadvantages comprise:
           Tone can be heard by remote party;   Limited number of commands possible (16 DTMF tones standardized of which 12 are available through the keypad);   
           HTTP; a separate data channel needs to be established (mobile data connection) towards the in-call application server; the http session must then be correlated by the in-call application server with the service logic processing instance for this subscriber&#39;s voice call.       

     SUMMARY 
     Accordingly, a need exists to overcome the above-mentioned problems and to improve the control of an application of a service to a data flow such as a voice call. 
     This need is met by the features of the independent claim. Further aspects are described in the dependent claims. 
     According to a first aspect a method is provided by an initiating entity to initiate the set up of one or more communication channels for exchange of information between the initiating entity and one or more responding entities. According to one step, a first message is transmitted on an end-to-end control channel between a first entity and a second entity. The first message comprises as a destination address a second entity address, wherein offer data is added to the transmitted first message and the offer data indicate that the initiating entity is configured to support one or more communication channels and the offer data comprising an address at which the initiating entity is configured to receive the information. A second message is received on the end-to-end control channel wherein the message comprises as destination address a first entity address. The second message furthermore comprises acceptance data in response to the offer data, wherein the acceptance data indicate that a responding entity has accepted the set up of a communication channel and the acceptance data comprising an address at which the responding entity is configured to receive the information. The address at which the service control responding entity is configured to receive service control messages is stored. 
     According to a further aspect the invention furthermore relates to the corresponding initiating entity operating as mentioned above. The initiating entity comprises a message managing unit configured to transmit the first message on an end-to-end control channel between a first entity and a second entity, wherein the first message comprises as a destination address a second entity address. The message managing unit is configured to add offer data to a transmitted first message, the offer data indicating that the initiating entity is configured to support one or more communication channels and the offer data comprising an address at which the initiating entity is configured to receive the information. Furthermore, the message managing unit is configured to receive a second message on the end-to-end control channel, wherein the second message comprises as the destination address an address of the first entity. The second message furthermore comprises acceptance data in response to the offer data and the acceptance data indicate that a responding entity has accepted the set-up of a communication channel and the acceptance data comprise an address at which the responding entity is configured to receive the information. Furthermore, a storage unit is provided configured to store the address at which the responding entity is configured to receive the information. 
     The above described method/entity under the first/second aspect helps to set up a communication channel that may be used for controlling application and/or services such as the in-call services discussed in the introductory part of the specification. Both the initiating entity and the responding entity can use the end-to-end control channel where information on control messages are exchanged which have as a destination address either the first entity or the second entity. The information may furthermore contain the offer that the initiating entity is ready to set up a control channel in the end-to-end control channel with any of the entities located in the end-to-end control channel. When the initiating entity receives the acceptance data comprising the address from the responding entity, the initiating entity knows how to address the responding entity in order to direct a control command to the responding entity using the end-to-end control channel. The initiating entity may store the address of the responding entity in order to set up the service control channel between the service control initiating entity and the service control responding entity. 
     According to another aspect, a method by the responding entity is provided to set up the one or more communication channels for the exchange of information between one or more initiating entities and the responding entity. The responding entity receives a first message on end-to-end control channel between the first entity and the second entity, wherein the first message comprises as a destination address the second entity address. The first message furthermore comprises offer data indicating that an initiating entity is configured to support a communication channel and the offer data comprising an address at which the initiating entity is configured to receive the information. The responding entity may store the address at which the initiating entity is configured to receive the information if the responding entity accepts to set up a communication channel between the initiating entity and the responding entity. The responding entity may then transmit a second message to the first entity, wherein the second message comprises a acceptance data in response to the offer data, wherein the acceptance data indicate that the responding entity accepts to set up the communication channel, wherein the acceptance data furthermore comprise an address at which the responding entity is configured to receive the information. 
     According to an additional aspect a responding entity in the invention furthermore relates to the corresponding responding entity. When the responding entity is interested in setting up a communication channel using the end-to-end control channel, it can indicate this to the initiating entity with the above-described method. 
     The responding entity comprises a message managing unit configured to receive a first message on the end-to-end control channel between a first entity and a second entity, wherein the first message comprises as a destination address the second entity address. The first message furthermore comprises offer data indicating that an initiating entity is configured to support a communication channel and the offer data comprising an address at which the initiating entity is configured to receive the information. Furthermore, a storage unit is provided configured to store the addresses at which the initiating entity is configured to receive the information if the responding entity accepts to set up the communication channel between the initiating entity and the responding entity. The message managing unit is configured to transmit a second message to the first entity, wherein the second message comprises acceptance data in response to the offer data. The acceptance data indicate that the responding entity accepts the set up of the communication channel and the acceptance data comprise an address at which the responding entity is configured to receive the information. 
     The invention also relates to a system comprising the initiating entity and the responding entity. 
     Furthermore, a method for communicating with one or more second entities is provided by a first entity, wherein an end-to-end control channel is configured between a third and a fourth entity and wherein the first entity and the one or more second entities are part of the end-to-end control channel. The first entity adds an address of the second entity to communicate with the first entity to a control message to be transmitted on the end-to-end control channel. Additionally, information for communication with the second entity is added to the control message and the control message is transmitted towards the second entity via the end-to-end control channel, wherein the destination address of the control message comprises an address of the fourth entity. 
     Furthermore, a first entity is provided configured to communicate with one or more second entities, wherein an end-to-end control channel is configured between a third and a fourth entity, wherein the first entity and the one or more second entities are part of the end-to-end control channel. The first entity comprises a message managing unit configured to add an address of the second entity to communicate with the first entity to a message to be transmitted on the end-to-end control channel. Furthermore, the message managing unit is configured to add information for communicating with the second entity to the message and is configured to transmit the message towards a second entity via the end-to-end control channel, wherein the destination address of the message comprises an address of the fourth entity. 
     When a communication channel between the first entity and the second entity has been established, the first entity may use the end-to-end control channel to send one or more messages to the second entity. A message has as a destination address the address of the fourth entity, but additionally contains the address of the second entity so that the latter recognizes that the message contains added information for the second entity. Using the added information, the second entity may then apply the message, e.g. a service, in accordance with the information contained in this control message. 
     Additionally, a method for communicating with one or more first entities by the second entity is provided, wherein an end-to-end control channel is configured between a third and a fourth entity. The one or more first entities and the second entity are part of the end-to-end control channel. The second entity receives a control messages having as destination address the address of the fourth entity and determines whether an extracted address from the received control message corresponds to an address at which the second entity is configured to receive messages. In the affirmative case, information is extracted from the received control message for communicating with the one or more first entities. 
     Furthermore, a second entity is provided configured to communicate with one or more first entities, wherein the end-to-end control channel is configured between a third and a fourth entity and wherein the one or more first entities and the second entity are part of the end-to-end control channel. The second entity comprises a receiver configured to receive a message having as destination address an address of the fourth entity. The second entity furthermore comprises a processing unit configured to determine whether an extracted address from the received message corresponds to an address at which the second entity is configured to receive information, wherein in the affirmative the processing unit is configured to extract information for communicating with the one or more first entities from the message. 
     The invention also relates to a system comprising the first entity and the second entity. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  schematically shows an architectural view of an environment in which a service may be applied to the user plane. 
         FIG. 2  is a schematic architectural view of a system in which, according to aspects of the invention, an end-to-end control channel is used for controlling an application of a service to a user plane. 
         FIG. 3  is an example schematic representation of internal architecture of a mobile entity for signaling between the mobile entity and the application server. 
         FIG. 4  is an example schematic representational view of in-session signaling between the mobile entity and the application server. 
         FIG. 5  is an example schematic representation of a functional decomposition of a serving call session control function involved in the end-to-end control channel. 
         FIG. 6  shows an example schematic representation of the different session parts in the end-to-end control channel. 
         FIG. 7  is an example schematic representational view of a communication between the mobile entity and the application server. 
         FIG. 8  is an example schematic view of a message exchange for establishing the control channel between the mobile user entity and the application server. 
         FIG. 9  is an example schematic representation of a message flow for controlling an in-call application. 
         FIG. 10  is an example schematic message exchange for establishing a signaling relationship between a first mobile entity and a first application server and a second mobile entity and a second application server. 
         FIG. 11  is an example schematic architectural view, wherein a mobile entity has different relationships to different application servers. 
         FIG. 12  is an example schematic view of a message exchange for establishing multiple controls with different application servers. 
         FIG. 13  shows an example of the possible control channels between the different pairs of entities in the end-to-end control channel. 
         FIG. 14  shows an example of an in-session signaling relationship between an arbitrary pair of the entities contained in the end-to-end control channel. 
         FIG. 15  shows an example message flow for establishing a signaling relationship or control channel between two of the entities in the end-to-end control channel. 
         FIG. 16  shows an example schematic view of multiple in-session application signaling relationships. 
         FIG. 17  shows an example schematic architectural view of how an entity can play the role of the service control initiating entity, a service control responding entity or a service control entity. 
         FIG. 18  is an example schematic representation of how service control channels can be built between different entities in the end-to-end control channel. 
         FIG. 19  is an example schematic architectural view of a service application entity. 
     
    
    
     DETAILED DESCRIPTION 
     In the following, embodiments will be described in detail with reference to the accompanying drawings. It is to be understood that the following description of the embodiments is not to be taken in a limiting sense. The scope of the invention is not intended to be limited by the embodiments described hereinafter or by the drawings, which are taken to be illustrative only. Furthermore, it is to be understood that the features mentioned above and further below can be used not only in the respective combinations indicated, but also in other combinations or in isolation. Features of the above or below mentioned aspects and embodiments may be combined with each other in other embodiments. 
     The drawings are to be regarded as being schematic representations, and elements illustrated in the drawings are not necessarily shown to scale. Rather, the various elements are represented such that their function and general purpose becomes apparent to a person skilled in the art. Any connection or coupling between functional bocks, devices, components or other physical or functional units shown in the drawings or described herein may be implemented by a direct or by an indirect connection or coupling. A coupling between components may be established over a wired or wireless connection. Furthermore, functional blocks may be implemented in hardware, firmware, software or a combination thereof. 
     According to one aspect, a transparent communication channel may be established on top of another communication channel or within a session, for example within a SIP (Session Initiation Protocol) session. As an alternative to an SIP session a communication channel or end-to-end channel according to ITU H.323 may be used. The communication channel may be established between a mobile entity (UE) and a server or between 2 servers in the network. The servers may be application servers (for example SIP application servers). This enables for example the UE to provide instructions to a SIP-AS, related to the execution of an in-call application. Vice versa, the SIP-AS may send instructions to the UE during the call. 
     The transfer of the instructions or response messages between the UE and the SIP-AS may occur fully in line with SIP signaling. Normally, when a call is established between two entities such as UE-A and UE-B, then when UE-A sends a SIP request towards UE-B, the SIP request is destined for the end point of the SIP session, i.e., the SIP request is destined for UE-B. In other cases, the SIP request (for example REFER) is destined for the MMTel-AS, for initiating Explicit Communication Transfer (ECT). 
     The method below describes as an example a communication channel between a UE-A and a SIP-AS. The method entails that the UE-A and SIP-AS exchange during call establishment, or on top of an already established call, an in-call application process identifier or offer data. The offer data indicate that the sending entity (UE-A) is ready to establish a relationship (for example a control relationship) with any of the entities located in the end-to-end control channel in the direction of the second entity which builds the endpoint of the end-to-end control channel. This identifier can be used by the UE or the SIP-AS to send an in-call message (for example in-call) application instruction to the SIP-AS or UE respectively. 
     The below in detail describes methods, devices, system and computer program products can be used for any (communication) channel to be established between two network entities within an end-to-end control channel for communicating and/or exchanging messages (e.g. control messages) between those two network entities. The two network elements may be the end points of the end-to-end control channel, they may be entities located between the end points of the end-to-end control channel, or a mixture of both. The (communication) channel may be a service communication channel for controlling a service located in one of the two network entities, or the (communication) channel may be used to exchange any kind of information between the two network entities (for example status messages, control messages, service control messages, UE specific information, call specific information, ...). An example of the latter comprises the transfer of HTML update information, from an application server to an application client, said application client being contained in a mobile terminal and said transfer being for the purpose of providing the application client with call progress information. 
       FIG. 2  shows as an example embodiment an architectural view of an IMS terminal or UE  100  connected to and registered in an IMS (IP Multimedia Subsystem) core network. The UE  100  may establish communication sessions through the IMS network. The communication sessions are handled by SCC-AS (Service Centralization and Continuity Application Server)  220 , an Enterprise Application Server  200  and Multimedia Telephony Application Server  210 . 
     The sequence of the invocation of an application server depends on the call case. Application Server  200  is the application server on which residential or enterprise advanced services are deployed. The UE  100  can furthermore generate a relation to the in-call application  50  via which the application of the service to the user plane in MRF  20  is controlled. 
     At call establishment SIP signaling traverses the CSCF  10  and the SIP-AS  200 - 220 . The SIP session is established end-to-end between the calling party and the called party. It is desirable, however, that the UE  100  can exchange signaling with the application servers. 
     As indicated in  FIG. 3 , the signaling exchange between the UE  100  and the SIP-AS  200  is taking place within the end-to-end SIP session. The UE  100  comprises an in-call application client  120  and a telephony application  130 . At the side of the UE  100 , the signaling exchange related to the in-call application control is tapped into or from the SIP user agent  110 . An RTP termination  140  is provided for the user plane data exchange with the other end. At the side of the application server  200 , the signaling exchange related to the in-call application control is tapped into or from the B2BUA (Back-to-Back User Agent) and from there to the in-call application server  50 . The SIP signaling related to in-call application control may be not related to the actual SIP session. This means that it is not used for establishing, maintaining or releasing the SIP session. 
     This is further shown in  FIG. 4 , in which a two-tier signaling structure within a SIP session is shown. The Tier 1 signaling shown by reference numeral  81  is formed by the regular SIP signaling used for establishing, maintaining and terminating the SIP session. The SIP session may span several SIP signaling entities between UE-A and UE-B, such as for example P-CSCF, S-CSCF, SCC-AS, MMTel-AS etc. In the embodiment shown, the SIP session passes two SIP proxies  70 ,  75 . Furthermore, the in-session application signaling shown by reference numeral  82  is indicated. This is formed by the SIP message exchange between two SIP signaling endpoints. Here, UE-A  100  and SIP-AS  200 . These SIP signaling endpoints are located in two designated positions within the SIP session. In UE  100 , the in-session signaling is directed to the in-call application client as indicated above in  FIG. 3 , and in the SIP-AS  200  the signaling is directed to the in-call application server. 
     In the example of  FIG. 4 , the SIP session is established between UE-A and UE-B, whereby the SIP session traverses the SIP-AS serving UE-A. In-between UE-A  100  and the SIP-AS  200 , there are server SIP signaling entities. Typically, there may be the P-CSCF, the S-CSCF (i), the SCC-AS, the S-CSCF (ii), the MMTel-AS and the S-CSCF (iii). The following distinction between S-CSCF (i), S-CSCF (ii) and S-CSCF (iii) is made: S-CSCF (i) represents the process that sends the Invite to the SCC-AS; S-CSCF (ii) represents the process that receives the Invite back from the SCC-AS and that sends the Invite to the MMTel-AS. S-CSCF (iii) represents the process that receives the Invite back from the MMTel-AS  210  and that sends the Invite to the SIP-AS  200 . Thus,  FIG. 5  shows as an example the functional decomposition of the S-CSCF  10   a,  wherein the SIP entities depicted in the upper part represent B2BUA, wherein the SIP entities depicted in the lower part of  FIG. 5  represent a SIP proxy, whereas the SIP session is established between UE-A and UE-B. The in-session application signaling runs between the two signaling endpoints on the SIP path. Signaling endpoints may be a user agent, e.g. a SIP terminal or a B 2 BUA. 
     The explanation shown in  FIG. 5  may be simplified as shown in  FIG. 6  for explanatory purposes. The first SIP session is established between UE-A  100  and the SBG/P-CSCF  10   b.  The second SIP session is established between the SGB/P-CSCF  10   b  and the SCC-AS  220 . The third SIP session is established between SCC-AS  220  and the MMTel-AS  210 . The fourth SIP session is established between MMTel-AS  210  and the SIP-AS  200 . The fifth SIP session is established between the SIP-AS  200  and the remote party. The application signaling relationship that is required for the UE  100  to control in-call applications is shown for example in  FIG. 7 . Between UE-A  100  and SIP-AS  200  a signaling relationship is established so that the UE-A  100  may control the in-call applications of the SIP-AS  200 . 
       FIG. 8  shows an example sequence diagram for establishing the application signaling relationship between the UE-A  100  and the SIP-AS  200 . The SIP entities in-between the UE-A  100  and the UE-B  300  and the SIP-AS serving the respective party, such as the P-CSCF, S-CSCF, SCC-AS and MMTel-AS, are not shown. Provisional responses and the acknowledgement transactions are not shown either. The SIP-AS  200   a  shown in the diagram may be the application server  200  shown in  FIG. 2 . The sequence diagram conveys how the UE-A  100  and SIP-AS  200   a  establish a signaling relationship. In step S 1  the UE-A  100  sends an Invite request comprising the content: Invite sip: B-party-number@B-party-domain SIP/2.0. Furthermore, it comprises a session application header such as: Session-application: &lt;sip:in-call-application@A-party-IP-address&gt;. 
     The UE  100  indicates with the SIP header that it can receive SIP messages, especially SIP Info that are addressed to sip: in-call-application@A-party-IP-address. In step S 2 , this Invite request is further transmitted to SIP-AS  200   b  comprising the content: Invite sip:B-party-number@B-party-domain SIP/2.0. As can be deduced from the comparison of the content contained in steps S 1  and S 2 , the session application content was removed by SIP-AS  200   a.  In step S 3 , the content is forwarded to the UE-B  300  comprising the same content as present in step S 2 . 
     In steps S 4  and S 5 , the SIP 200 Ok message sent back to the SIP-AS  200   b  and SIP-AS  200   a  respectively. Now, in step S 6  the SIP-AS  200   a  serving the UE-A  100  adds the session application header to the 200 Ok message, such as Session-application:&lt;sip:in-call-application@sipas.ims.mnc702.mcc320.3gppnetwork.org&gt;. With this added session application content, the SIP-AS  200   a  indicates with this header that it can receive SIP messages, especially SIP Info messages that are addressed to &lt;sip:in-call-application@sipas.ims.mnc702.mcc320.3gppnetwork.org&gt;. 
     By virtue of (i) UE-A comprising sip:in-call-application@A-party-IP-address in the session establishment request and (ii) SIP-AS including sip:in-call-application@sipas.ims.mnc702.mcc320.3gppnetwork.org in the session establishment answer, UE-A and SIP-AS have established an application signaling relationship in step S 8 . The establishment of this relationship does not affect the end-to-end SIP session establishment or the establishment of the user plane in S 7 . 
     UE-A  100  and SIP-AS  200   a  can utilize this Application signaling relationship to exchange SIP Info messages for the control of in-call applications. These messages are routed in accordance with regular SIP signaling. That means, among others, that these messages will be sent towards the contact address of the UE (SIP-AS→UE) or towards the Contact address of the SIP-AS (UE→SIP-AS). (since the SIP-AS is acting as B2BUA, the SIP signaling is addressed towards the SIP-AS′ Contact address). When the UE  100  receives a SIP Info message containing the header Session-application: &lt;sip:in-call-application@A-party-IP-address&gt;, the UE knows that this SIP message is meant for the UE-resident application “in-call-application”. The SIP message as such will be handled as per the regular SIP transaction rules, comprising the sending of a 200 Ok. The message will, however, not be forwarded to the phone application. Instead, it will be forwarded to the in-call application client  120  of  FIG. 3 . 
     Likewise, when the SIP-AS  200   a  receives a SIP Info message containing the header &lt;sip:in-call-application@sipas.ims.mnc702.mcc320.3gppnetwork.org&gt;, the SIP-AS  200   a  knows that this SIP message is meant for SIP-AS resident application “in-call-application”  50 . The SIP message as such may be handled as per the regular SIP transaction rules, comprising the sending of a 200 Ok. The message may, however, not be forwarded to the call handling application in the SIP-AS. Instead, it will be forwarded to the in-call application server. Depending on the use case the SIP Info message may be terminated at the SIP-AS  200   a  (and so not forwarded to UE-B  300 ) or it may be forwarded to UE-B  300  (with or without the header sip:in-call-application@sipas.ims.mnc702.mcc320.3gppnetwork.org). 
       FIG. 9  shows an example for an in-session signaling between UE-A  100  and SIP-AS  200   a  for in-call application control. As a preamble, it is assumed that during the establishment of SIP session from UE  100  to UE  300 , UE  100  and SIP-AS A  200   a  have exchanged their respective in-call application address. As a result, UE  100  and SIP-AS  200   a  have established an in-call application signaling relationship. Both UE-A and SIP-AS A are ready to receive an in-call application data message. Thus, the different SIP session sections in step S 1  are established and the user plane is established as indicated by step S 2 . 
     At time A, the user intends to trigger the execution of an in-call application (step S 3 ). Hereto, the UE-A sends a SIP Info “towards” the B-party: INFO &lt;B-party contact address&gt;SIP/2.0 Session-application: &lt;sip:in-call-application@sipas.ims.mnc702.mcc320.3gppnetwork.org&gt;&lt;message body&gt; (step S 3 ). More specifically, it sends the SIP Info using the contact address and Route set as applicable for the SIP session that is established towards the B-party. UE-A comprises the header Session-application: &lt;sip:in-call-application@sipas.ims.mnc702.mcc320.3gppnetwork.org&gt;. The body of the Info message may contain the in-call application instruction, such as “Record call”, or “Connect confidential third party”. 
     When the Info message arrives at the SIP-AS  200   a,  the message is forwarded to the in-call application server; this forwarding is the result of the presence of the SIP header Session-application: &lt;sip:in-call-application@sipas.ims.mnc702.mcc320.3gppnetwork.org&gt;. The SIP-AS is acting as B2BUA. The SIP-AS may respond with 200 Ok (step S 4 ); i.e. it may not pass the Info message on. At B, the in-call application server starts the execution of the requested service. 
     For the actual in-call application control, syntax may be defined. The body of the Info message of step S 5 : INFO &lt;A-party contact address&gt;SIP/2.0 Session-application: &lt;sip:in-call-application@A-party-IP-address&gt;&lt;message body&gt; may contain the command for executing the required in-call application. The 200 Ok of the Info message may carry the result of the execution (step S 6 ).  FIG. 9  additionally shows the example case that the in-call application server  200   a  sends an in-call instruction to UE-A  100 . The principle is identical to the case, whereby UE  100  sends the in-call application instruction. 
       FIG. 10  shows a signaling sequence diagram for another embodiment in which both UE-A  100  and UE-B  300  establish an in-call application signaling relationship with their respective SIP-AS  200   a,    200   b.  The establishment of the application signaling relationship between UE-A and SIP-AS A  200   a  and the establishment of the application signaling relationship between UE-B  300  and SIP-AS B  200   b  occur independently of one another. In step  51  of  FIG. 10 , a SIP Invite is sent to SIP-AS  200   a  as follows: Invite sip: B-party-number@B-party-domain SIP/2.0 Session-application: &lt;sip:in-call-application@A-party-IP-address&gt;, wherein the Invite message is forwarded to SIP-AS B in step S 2  with the following content: Invite sip:B-party-number@B-party-domain SIP/2.0. The session application header may be not passed between S-CSCF serving the A-party and the S-CSCF serving the B-party. In step S 3 , the Invite message is forwarded to UE-B  300  with the session application being added: Invite sip:B-party-number@B-party-IP-address SIP/2.0 Session-application: &lt;sip:in-call-application@sipas-b.ims.mnc702.mcc320.3gppnetwork.org&gt;. In step S 4 , the SIP 200 Ok message comprises the content that the UE-B  300  accepts to set up a control channel and adds the content SIP/2.0 200 Ok Session-application: &lt;sip:in-call-application@B-party-IP-address&gt;. The session application content may be removed by SIP-AS B  200   b  before the SIP 200 Ok message is transmitted in step S 5  to SIP-AS A  200   a,  where in step S 6  the offer from UE-A to SIP-AS A is accepted by adding the following content: SIP/2.0 200 Ok Session-application: &lt;sip:in-call-application@sipas-a.ims.mnc702.mcc320.3gppnetwork.org&gt;. The user plane is established in step S 7 . The application signaling relationship is generated in step S 8  between UE-A  100  and SIP-AS A  200   a.  The application signaling relationship is established in step S 9  between UE-B  300  and SIP-AS B  200   b.  At the times indicated by the arrows S 8  or S 9 , the application signaling relationship may be used. The application signaling relationship between UE-A and SIP-AS A may be established after step S 6  is received at UE-A, and the application signaling relationship between UE-B  300  and SIP-AS B  200   b  may be established when SIP-AS B has received step S 4 . 
     Furthermore, it is possible that the mobile entity establishes an application signaling relationship with more than one service application entities, e.g. two application servers. This is shown in example  FIG. 11 . The SIP signaling for the deployment case shown in  FIG. 11  runs between UE  100  and MMTel-AS  210  and between UE- 100  and SIP-AS  200 . MMTel-AS  210  and SIP-AS  200  may extend the application signaling relationship towards an external application server. This extending may be done through HTTP-Rest. HTTP-Rest is a designated protocol for extending the SIP application service logic towards a higher layer service platform. So, the signaling for the in-call application runs between UE  100  and MMTel-AS  210  and between UE  100  and SIP-AS  200 , but MMTel-AS  210  and SIP-AS  200  extend the actual in-call command towards the application server  51 ,  50  that is functionally connected to the MMTel-AS  210  and SIP-AS  200  respectively through a northbound interface. 
       FIG. 12  shows the corresponding example signal sequence diagram for establishment of the multiple in-call application signaling relationships. In steps S 1  and S 2 , an Invite request is transmitted from UE-A  100  via SIP-AS A 1   200   a  and SIP-AS A 2   200   b,  both messages comprising the following content: Invite sip:B-party-number@B-party-domain SIP/2.0 Session-application: &lt;sip:in-call-application@A-party-IP-address&gt;. In step S 3 , the Invite messages forwarded to the remote party with the session application header may be removed by the application server  200   b.  The SIP 200 Ok message is received in step S 4 , and in step S 5  the SIP-AS A 2   200   b  adds the acceptance data to set up the in-call signaling relationship as follows: SIP/2.0 200 Ok Session-application: &lt;sip:in-call-application@sipas-a2.ims.mnc702.mcc320.3gppnetwork.org&gt;. In step S 6 , SIP-AS A 1   200   a  adds its acceptance data so that in step S 6  the UE  100  receives the following message: 
     SIP/2.0 200 Ok 
     Session-application: &lt;sip:in-call-application@sipas-a1.ims.mnc702.mcc320.3gppnetwork.org&gt;Session-application: &lt;sip:in-call-application@sipas-a2.ims.mnc702.mcc320.3gppnetwork.org&gt;. The user plane is established in step S 7 , the first relationship being established in step S 8 , the second application signaling relationship being established in step S 9 . It should be understood that steps S 7 , S 8  and and S 9  need not be carried out in the order indicated. For example step S 8  may occur earlier than step S 9  or both steps may occur simultaneously. 
     The two SIP-AS&#39;s both return their in-call application signaling addresses towards UE-A so that UE-A  100  establishes two independent relationships. The UE  100  can subscribe to two sets of in-call application services, one set facilitated by SIP-AS  200   a,  the other set being offered by in-call apps of SIP-AS  200   b.    
     Generally, the UE  100  may be preconfigured with the address of the in-call application servers with which it can establish an in-call application signaling relationship. When the UE has received in the 200 Ok message comprising the session application header from the different application servers, the UE  100  knows that the relationship(s) is/are established and that it can exchange in-call application signaling with each of the application servers  200   a,    200   b.    
     In practice, the address of the application server with which the UE can establish an in-call application signaling relationship may be configured in the UE as a wild card address. For a particular call, the SIP-AS that is linked into the SIP session may be one of a group of load sharing/redundant SIP-AS&#39;s. The name of each such SIP-AS would match with the wild card address configured in the UE  100 . 
     The above described principles can be further enhanced to facilitate in-session communication between an arbitrary pair of SIP entities in the SIP chain between UE-A  100  and UE-B  300 . This is shown in  FIG. 13 , wherein  FIG. 13  depicts an example session case whereby three SIP entities  70 ,  75 ,  76  are provided between UE  100  and UE  300 . In-session signaling relationships may be established between any pair of entities in the SIP chain. In the example shown in  FIG. 13 , there are five SIP session endpoints in the chain. This leads to 10 potential relationships 
     
       
         
           
             
               ( 
               
                 
                   
                     5 
                   
                 
                 
                   
                     2 
                   
                 
               
               ) 
             
             = 
             10. 
           
         
       
     
     By way of example, SIP entity  70  B2BUA # 1  of  FIGS. 14  and B2BUA # 2   75  can establish an in-session signaling relationship enabling them to transparently exchange messages (for example application messages) as shown in  FIG. 14 . 
       FIG. 15  shows an example message sequence diagram for establishing in-session application signaling relationships between SIP-AS1  200   a  and SIP-AS2  200   b.  The different steps carried out in this figure comprise the following content, wherein S-A means session application and the strike-through parts mean that the SIP header is removed: 
     S 1 : Invite sip:B-party SIP/2.0
         S-A: &lt;sip:in-call-app@A-party-address&gt;       

     S 2 : Invite sip:B-party SIP/2.0
         S-A: &lt;sip:in-call-app@A-party-address&gt;   S-A: &lt;sip:in-call-app@B2BUA1-address&gt;       

     S 3 : Invite sip:B-party SIP/2.0
         S-A:&lt;sip:in-call-app@A-party-address&gt;   S-A:&lt;sip:in-call-app@B2BUA1-address&gt;   S-A:&lt;sip:in-call-app@SIPAS1-address&gt;       

     S 4 : Invite sip:B-party SIP/2.0
         S-A:&lt;sip:in-call-app@A-party-address&gt;   S-A:&lt;sip:in-call-app@B2BUA1-address&gt;   S-A:&lt;sip:in-call-app@SIPAS1-address&gt;   S-A:&lt;sip:in-call-app@SIPAS2-address&gt;       

     S 5 : Invite sip:B-party SIP/2.0
         S-A:&lt;sip:in-call-app@A-party-address&gt;   S-A:&lt;sip:in-call-app@B2BUA1-address&gt;   S-A:&lt;sip:in-call-app@SIPAS1-address&gt;   S-A:&lt;sip:in-call-app@SIPAS2-address&gt;   S-A:&lt;sip:in-call-app@B2BUA2-address&gt;       

     S 6 : SIP/2.0 200 Ok S-A:&lt;sip:in-call-app@A-party-address&gt;
         S-A:&lt;sip:in-call-app@B2BUA1-address&gt;   S-A:&lt;sip:in-call-app@SIPAS1-address&gt;   S-A:&lt;sip:in-call-app@SIPAS2-address&gt;       

     S 7 : SIP/2.0 200 Ok S-A:&lt;sip:in-call-app@A-party-address&gt;
         S-A:&lt;sip:in-call-app@B2BUA1-address&gt;   S-A:&lt;sip:in-call-app@SIPAS1-address&gt;       

     S 8 : SIP/2.0 200 Ok
         S-A:&lt;sip:in-call-app@A-party-address&gt;   S-A:&lt;sip:in-call-app@B2BUA1-address&gt;   S-A:&lt;sip:in-call-app@SIPAS1-address&gt;; &lt;sip:in-call-application@SIPAS2-address&gt;       

     S 9 : SIP/2.0 200 Ok
         S-A:&lt;sip:in-call-app@A-party-address&gt;       

     S 10 : SIP/2.0 200 Ok 
     The principles disclosed in  FIG. 15  can be summarized as follows: 
     An in-session application signaling relationship may be established between any pair of SIP signaling entities from UE-A  100  to UE-B  300 , including these two entities. 
     Any permutation of in-session application signaling relationships may be established. In the example of  FIG. 15 , a maximum of 
     
       
         
           
             
               ( 
               
                 
                   
                     6 
                   
                 
                 
                   
                     2 
                   
                 
               
               ) 
             
             = 
             15 
           
         
       
     
     relationships can be established:
         UE-A—B2BUA1; UE-A—SIP-AS1; UE-A—SIP-AS2; UE-A—B2BUA2; UE-A—UE-B   B2BUA1—SIP-AS1; B2BUA1—SIP-AS2; B2BUA1—B2BUA2; B2BUA1—UE-B   SIP-AS1—SIP-AS2; SIP-AS1—B2BUA2; SIP-AS1—UE-B   SIP-AS2—B2BUA2; SIP-AS2—UE-B   B2BUA2—UE-B       

     For the signaling the following conclusions can be drawn: 
     As the Invite request message is conveyed from UE-A  100  to UE-B  300 , each entity may add itself to a stack of session application headers; an entity will do this only when it intends to establish an in-session signaling relationship with one or more designated other SIP entities, typically an application server. In the example of  FIG. 15 , each of the entities UE-A up to and including B2BUA2 adds a session application header in the Invite request. 
     When an entity sends 200 Ok, it may add its own address to the session application header for each upstream SIP entity with which it wishes to establish an in-session application signaling relationship. In the example of  FIG. 15 , only SIP-AS2  200   b  wishes to establish an in-session application signaling relationship. More specifically, SIP-AS1  200   a  is the only SIP entity with which SIP-AS2  200   b  wishes to establish an in-session application signaling relationship. 
     A session application header in the 200 Ok may hence contain a multitude of responding addresses. 
     When a SIP entity receives a 200 Ok, then before passing on the 200 Ok, it may remove its own session application header from the 200 Ok. Rationale is that the presence of this header in the 200 Ok may be only for the purpose of this SIP entity. In the example of  FIG. 15 , SIP-AS1 removes its session application header from the 200 Ok, since that header has served its purpose, namely to inform SIP-AS1 that an in-session application signaling relationship has been established with SIP-AS2. 
       FIG. 16  shows an example use case where the following in-session application relationships are established: A first in-session application signaling relationship is established between UE-A  200  and MMTel-AS  210 , and a second in-session application signaling relationship is established between MMTel-AS  210  and SIP-AS  200 . The top part of  FIG. 16  reflects the network architecture, whereas the bottom part represents the logical sequence of the SIP entities. The two relationships may be established in the method described above in connection with  FIG. 15 . The first relationship between UE-A  100  and MMTel-AS  210  may be used by UE-A  100  for interacting with service logic that is coupled to MMTel or with a service logic that is coupled through HTTP-Rest with MMTel. The second relationship between MMTel-AS  210  and SIP-AS  200  may be used for the purpose of service interworking between MMTel-AS  210  or the service logic that is coupled through HTTP-Rest with MMTel and SIP-AS  200  or the service logic that is coupled through HTTP-Rest with SIP-AS  200 . 
       FIG. 18  summarizes different options: In the first line, an end-to-end control channel as known is established between UE-A  100  and UE-B  300 . In the second line of  FIG. 18 , a service control channel is established between UE-A  100  and SIP-AS # 1   200 , whereas in the third line a service control channel is established between two application servers such as application server  200  and  220 . In the fourth line, a service control channel is established between the two UEs  100 ,  300  whereas in the last but one line a multi-service control channel embodiment is shown with a first service control channel between UE-A  100  and 
     SIP-AS # 1   200  and a second service control channel being formed between UE-A  100  and SIP-AS # 2   210 . UE-A is the service control entity and the service application entity for service control channel  1  and for service control channel  2 . SIP-AS  200  is the service application entity and the service control entity for service control channel  1 , wherein SIP-AS  210  is the service application entity and the service control entity for service control channel  2 . In the last line of  FIG. 18 , a service control channel is set up between UE-A  100  and SIP-AS # 2   210 , wherein UE-A adds offer data in the SIP message, SIP-AS # 2   210  adds acceptance data. 
     From the discussion of the above figures some general conclusions can be drawn. When a communication channel (for example a service control channel) should be set up, an initiating entity (for example a service control initiating entity such as UE-A  100 ) can transmit a first message in the (SIP) communication channel, this message comprising offer data indicating that the initiating entity supports one or more communication channels. Furthermore, as could be deduced from the examples given above, the offer data contain the address at which the initiating entity is able to receive the messages. A responding entity (for example a service control responding entity) can then send an answer message on the end-to-end control channel, this answer message comprising acceptance data in response to the offer data. The acceptance data indicate that the responding entity has accepted to a set up of the communication channel (for example the service control channel) and the acceptance data comprise the address at which the responding entity is configured to receive the messages (for example the service control messages). Thus, the initiating entity can then use this address in order to send messages to the responding entity. 
     As could be inter alia deduced from  FIG. 12 , the received message, i.e. the second message can comprise acceptance data originating from more than one responding entities which are located in the end-to-end control channel towards the second entity. The end-to-end control channel is set up (or already established) between the first entity and the second entity, and the first message is transmitted in direction of the second entity, the response message being received from the second entity. The acceptance data originating from the more than one responding entities may indicate that each of the one more than one responding entities have accepted to set up dedicated communication channels (for example service control channels) between the initiating entity and each of the more than one responding entities, and the acceptance data comprise an address at which each of the responding entities is configured to receive messages (for example service control messages). The initiating entity can then store the addresses in order to set up the dedicated communication channels between the initiating entity and each of the responding entities. In the embodiment of  FIG. 12 , UE-A, a service control initiating entity, received acceptance data from SIP-AS  200   a  and SIP-AS  200   b  so that it was able to build the two different signaling relationships. The first entity may be the control initiating entity and may be a user equipment. Furthermore, the initiating entity can contain the application server. 
     Furthermore, as could be seen from the examples above, the acceptance data may be removed from the second message before the second message is transmitted to the first entity. The first entity may comprise a user equipment or the initiating entity. Furthermore, an application server may comprise the initiating entity. 
     In the same way for the responding entity (for example a service control responding entity) receiving the message with the offer data, this received message may furthermore comprise offer data originating from more than one initiating entities (for example service control initiating entities) located in the end-to-end control channel towards the first entity. The offer data originating from more than one initiating entities comprise the address at which each of the more than one initiating entities is configured to receive the information (for example service control messages). This could be inter alia deduced from  FIG. 15 , where the message is received in steps S 1  to S 5  comprising offer data originating from more than one service control initiating entities. The responding entity may then store the received addresses of the initiating entities where the responding entity accepts the set up of dedicated communication channel (for example dedicated service control channels). A second message is then transmitted to the first entity which comprises the acceptance data in response to the offer data. The acceptance may indicate that the responding entity accepts the set up of the dedicated communication channels, the acceptance data comprising an address at which the responding entity is configured to receive the information from the more than one initiating entities. This can be also deduced from  FIG. 12 , where the message received at UE  100  comprises the acceptance data from SIP-AS  200   a  and from SIP-AS  200   b.    
     The second entity may comprise or can be part of the responding entity (for example the service control responding entity), wherein the second entity may comprise a user equipment. 
     The offer data may also be added to the second message transmitted back to the first entity. Furthermore, the second message from the second entity can be received and the acceptance data can be added before the received second message is transmitted further to the first entity. An application server may furthermore comprise the service control responding entity. 
     Furthermore, it may be deduced from the different embodiments that the first message is a request message and the second message is a response message. More precisely, the request message may be a SIP Invite message and the response message may be a SIP 200 Ok message. 
     The offer data and/or the acceptance data may be added as a header of the first and/or the second message. 
     When the end-to-end control channel is established and the signaling relationship between the initiating entity and the responding entity is established, the initiating entity can play the role of the a control entity (for example a service control entity), and the responding entity can play the role of an application entity (for example a service application entity) which applies the service to for example a data flow. The information (for example the control message) itself including the instruction how to apply the service to the data flow may be added as information to the control message. The control message received on the end-to-end control channel may be received from the first entity and the address is added to the control message and transmitted further to the second entity. In this embodiment, the control entity may be located between the first and the second entity, and the application entity may be further located in direction of the second entity. Furthermore, the control entity may comprise an application server. In another embodiment, the control message may be generated by the control entity on the end-to-end control channel with the address of the first entity as destination address before the information is added and the control message is transmitted to the second entity. The first entity may comprise the service control entity. 
     As far as the application entity itself is concerned, which applies the service in accordance with the information contained in the control message, the received control message may not be forwarded to the second entity. 
     The second entity may comprise the application entity or the mobile entity. In another embodiment the received control message may be forwarded to the second entity without the extracted address and without the extracted information. The application entity may comprise the application server and the application entity can transmit an acknowledgement message in response to the received control message using a source address contained in the received control message as destination address. The control message may be a service control message and the generated control message may be configured such that it cannot establish, maintain or release the end-to-end control channel. 
     The control message can be generated in accordance with a session initiation protocol. Furthermore, the address and the information may be extracted from the request line and from a header, respectively, of the control message. 
     Furthermore, a first entity may communicate with one or more of the second entities and an end-to-end control channel is configured between a third and a fourth entity, the first and the one or more second entities being part of the end-to-end control channel. For communicating, the first entity may add an address of a second entity to communicate with the first entity to a control message to be transmitted on the end-to-end control channel. Furthermore, information for communicating with the second entity is added to the control message and the control message is transmitted towards the second entity via the end-to-end control channel, wherein the destination address of the control message comprises an address of the fourth entity. 
     The control message may be received on the end-to-end control channel from the third entity, wherein the address and the information for communicating with the second entity is added to the control message and the control message is transmitted further to the fourth entity. 
     The first entity can comprise an application server and the third entity may comprise the first entity and/or a mobile entity. Additionally, the address and the information may be added to the header of the control message. The first entity can be a service control entity and the one or more second entities can be service application entities wherein the third and the fourth entity are the endpoints of the end-to-end control channel. 
     When the second entity is communicating with one or more of the first entities, the control message is received by the second entity, the control message having as destination address an address of the fourth entity. The second entity further determines whether an extracted address from the received control message corresponds to an address at which the second entity is configured to receive messages. If this is the case, the information for communication with one or more of the first entities is extracted from the control message. 
     The received control message may not be forwarded to the fourth entity. As an alternative, it is possible that the received control message is forwarded to the fourth entity without the extracted address and without the extracted information. Furthermore, the fourth entity can comprise the second entity or a mobile entity. 
     The second entity can comprise an application server. Furthermore, an acknowledgement message may be transmitted in response to the received control message using a source address contained in the received control message as destination address. 
     The address and the information may be extracted from a header of the control message. 
     Furthermore, the generated control message may be designed such that it cannot establish, maintain or release the end-to-end control channel. Furthermore, it is possible that the one or more first entities are service control entities and that the second entity is a service application entity. 
     As far as the initiating entity, by way of example the service control initiating entity, is concerned, the message managing unit may be configured to remove acceptance data from the second message before transmitting the second message to the first entity. 
     Furthermore, an initiating entity may be provided to initiate the set up of one or more communication channels, the initiating entity comprising a processor and a memory. The memory can contain instructions executable by said processor whereby the initiating entity is operative to transmit a first message on an end-to-end control channel between a first entity and a second entity, wherein the first message comprises as a destination address a second entity address and wherein offer data is added to the transmitted first message. The offer data can indicate that the initiating entity is configured to support one or more communication channels and the offer data can comprise an address at which the initiating entity is configured to receive the messages. Furthermore, the initiating entity is operative to receive a second message on the end-to-end control channel, wherein the second message comprises as destination address an address of the first entity. The second message furthermore comprises acceptance data in response to the offer data and the acceptance data indicate that a responding entity has accepted the set up of a communication channel and the acceptance data comprise an address at which the responding entity is configured to receive the messages. Furthermore, the initiating entity is operative to store the address at which the responding entity is configured to receive the message. 
     Furthermore, the responding entity configured to set up one or more communication channels can comprise a processor and a memory, wherein the memory contains instructions executable by said processor. The responding entity is operative to receive a first message on the end-to-end control channel between the first entity and the second entity, wherein the first message comprises as a destination address the second entity address. The first message furthermore comprises offer data indicating that an initiating entity is configured to support a communication channel and the offer data comprise an address at which the initiating entity is configured to receive the messages. The responding entity is furthermore operative to store the addresses at which the one or more initiating entities are configured to receive the messages if the responding entity accepts to set up a communication channel between the one or more initiating entities and the responding entity. Furthermore, it is operative to transmit a second message to the first entity, wherein the second message comprises acceptance data in response to the offer data. The acceptance data indicate that the responding entity accepts the set up of the communication channel and the acceptance data comprise an address at which the responding entity is configured to receive the messages. 
     Furthermore, a first entity configured to communicate with one or more second entities is provided comprising a processor and a memory, said memory containing instructions executable by the processor, wherein an end-to-end control channel is configured between a third and a fourth entity and wherein the first entity and the one or more second entities are part of the end-to-end control channel. The first entity is operative to add an address of a second entity to communicate with the first entity to a control message to be transmitted on the end-to-end control channel. Furthermore, information for communicating with the second entity is added to the control message and the control message is transmitted towards the second entity via the end-to-end control channel, wherein the destination address of the control message comprises an address of the fourth entity. 
     Additionally, a second entity configured to communicate with one or more of the first entities is provided with the end-to-end control channel being configured between the third and the fourth entity and wherein the one or more first entities and the second entity are part of the end-to-end control channel. The second entity is operative to receive a control message having as destination address an address of the fourth entity. Furthermore, it is operative to determine whether an expected address from the received control message corresponds to an address at which the second entity is configured to receive messages. If this is the case, it is operative to extract information for communicating with the one or more first entities from the control message. 
       FIG. 17  shows an example schematic view of a mobile entity  100  which may play the role of a initiating entity (for example a service control initiating entity), a responding entity (for example a service control responding entity) or a control entity (for example a service control entity) as discussed above. A message managing unit  110  is provided which is configured to transmit the different messages discussed above when the UE is acting as initiating or responding entity or as a control entity. The message managing unit  110  may furthermore operate as input/output unit providing the capability of transmitting and receiving control messages or user data to other entities. The UE  100  can furthermore comprise an in-call application client  120  to which the in-session messages for in-call application (control) is forwarded as discussed inter alia in connection with  FIG. 3 . When the UE receives an in-call application command, it may, by way of example, display information contained in the application command, on the UE&#39;s display. Alternatively, the application command may comprise a request for the user to provide input needed for application control by an application server. The telephony application  130  is provided to control the normal phone-related operation of the mobile entity. RTP termination  140  is provided to receive and transmit the media data or user plane data. A storage unit  150  is provided which can store a suitable program code to be carried out by the different functional entities or by a processing entity  160 , which can be provided to coordinate the operation of the whole user entity. 
       FIG. 19  shows an example of an application entity  500  (which may correspond to the service application entity  50  shown in  FIG. 2  or  FIG. 3 ) which may apply a service to the data flow. The application entity comprises an input/output unit  510  with a transmitter  511  and a receiver  512 , the transmitter  511  representing the possibility to transmit user data or control messages to other entities, the receiver  512  representing the possibility to receive user data or (control) messages from other entities. A processing unit  520  is provided which is responsible for the operation of the application entity, a memory  530  storing the suitable program code to be carried out by the processing unit  520  in order to operate the application entity as discussed above. 
     The above described embodiments enable a mobile entity or any other entity in a end-to-end control channel to communicate with any other entity in the end-to-end control channel for example to establish, utilize and control network-based in-call applications in a transparent manner without the remote party to notice it as it would be the case with an audible indication. The method is also transparent in the sense that it does not rely on any other data communication channel than the already established end-to-end control channel. 
     An additional advantage can be seen that it provides means for transparent data, in-session communication between two entities (for example application servers) that are connected in the chain of the call. This capability may become relevant for advanced enterprise or residential use cases where for example multiple application servers may jointly control a call. By way of example, MMTel-AS and SIP-AS chained in a call, the SIP-AS may provide enterprise services for the served subscriber. 
     An in-call signaling relationship (for example application signaling relationship) may be established between two entities (for example a UE and a SIP-AS). This in-call signaling relationship allows for transparent exchange of signaling messages between the entities, for example for the control of in-call applications. The transfer of the messages (for example SIP messages, specifically the Info transaction), may occur in accordance with standard signaling rules (for example SIP signaling rules). One aspect is that the in-call application signaling is explicitly addressed towards the remote end (for example by virtue of the fact that the UE applies the regular SIP routing, as applicable for this SIP session), but is implicitly addressed towards another entity (for example SIP-AS serving the subscriber, by virtue of the fact that it contains the session application header). The result is that there is an in-session signaling relationship established between two entities (for example on the end-to-end SIP chain). The signaling protocol (for example SIP) is carrying the messages for the in-session signaling relationship, but there is no impact on the end-to-end signaling session (for example SIP session). 
     The in-session relationship may also be established between two entities in the chain (for example SIP-AS&#39;s in the SIP chain), as described in one of the examples. This method will be important with proliferation of for example SIP-AS&#39;s within a single SIP session, e.g. the chaining of a SIP-AS for advanced enterprise/residential services and MMTel-AS. 
     The capability may be formed by a session header (for example the session application SIP header). This header may be used to let two entities located in an end-to-end (SIP) session path between two (SIP) session endpoints establish a transparent communication channel with one another. The end-to-end (SIP) session acts as conveyer for the transparent communication channel between the two entities located on this (SIP) session path. But yet, the (SIP) communication between these two entities located on this (SIP) session path does not form part of end-to-end (SIP) session signaling.