WO2009010632A1 - Procédés d'échange d'informations - Google Patents

Procédés d'échange d'informations Download PDF

Info

Publication number
WO2009010632A1
WO2009010632A1 PCT/FI2008/050427 FI2008050427W WO2009010632A1 WO 2009010632 A1 WO2009010632 A1 WO 2009010632A1 FI 2008050427 W FI2008050427 W FI 2008050427W WO 2009010632 A1 WO2009010632 A1 WO 2009010632A1
Authority
WO
WIPO (PCT)
Prior art keywords
wireless communication
communication terminal
capability information
application
application capability
Prior art date
Application number
PCT/FI2008/050427
Other languages
English (en)
Inventor
Frans Tuomela
Original Assignee
Teliasonera Ab
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Teliasonera Ab filed Critical Teliasonera Ab
Priority to EP08787704.9A priority Critical patent/EP2168350B1/fr
Priority to NO08787704A priority patent/NO2168350T3/no
Priority to DK08787704.9T priority patent/DK2168350T3/en
Publication of WO2009010632A1 publication Critical patent/WO2009010632A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1083—In-session procedures
    • H04L65/1094—Inter-user-equipment sessions transfer or sharing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/04—Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/53—Network services using third party service providers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/24—Negotiation of communication capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/75—Indicating network or usage conditions on the user display
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/22—Processing or transfer of terminal data, e.g. status or physical capabilities
    • H04W8/24—Transfer of terminal data

Definitions

  • the present invention relates to wireless communications systems.
  • IP Multimedia Subsystem is a 3rd Generation Partnership
  • the circuit switched CS call e.g.
  • CSICS Circuit Switched IMS Combinational Services
  • the exchanged information may contain information about IMS media types sup- ported, MSISDN and preferred SIP URI 1 ME Identifier, CS video and voice telephony capability, MMS version supported and other supported IMS based services or non-IMS based services. If the terminals support the necessary functionality, the terminals offer to the subscribers the possibility to add the IMS session to the existing CS call. If the IMS session is initiated, it is done as any other IMS session. Alternatively, a CS call is added to an existing IMS session.
  • An object of the present invention is to provide an enhanced mechanism for providing capability information of a remote party in a commu- nication system.
  • the object of the invention is achieved by means of methods, communication terminals, a network unit, a communication system and a program as claimed in the independent claims.
  • the preferred embodiments of the invention are disclosed in the dependent claims.
  • an exchange of common capability information of wireless communication terminals is improved by taking in account also capabilities of any adjacent external device(s) (e.g. PC and/or laptop) of an end-user.
  • the invention allows communication parties to see and use applications capabilities of their wireless communication terminals and adjacent external devices, e.g. during circuit- switched or packet-switched one-to-one call.
  • an aspect of the invention enables to transfer capability information of wireless terminals and a remote external device related capability information to an adjacent external device (e.g. PC or laptop) of end-user, and use this information in the adjacent external device to initiate other application sessions or transactions.
  • an adjacent external device e.g. PC or laptop
  • visibility of the application capability related information to other communication parties is controlled in an intermediate network.
  • Figure 1 a diagram illustrating an example of a capability exchange according to an embodiment of the invention
  • Figure 2 illustrates an example view displayed to the end-user
  • Figure 3 a diagram illustrating another example of a capability exchange according to an embodiment of the invention.
  • Figure 4 is a diagram illustrating still another example of a capability exchange according to an embodiment of the invention
  • Figure 5 is a diagram illustrating a still further example of a capability exchange according to an embodiment of the invention
  • Figure 6 illustrates an example of a signalling scheme for implementing the application capability exchange according to an embodiment of the invention
  • Figure 7 illustrates an example of a signalling scheme for imple- meriting the connection establishment request for a specific application.
  • Example embodiment of the present invention will be described using simultaneous circuit switched (CS) call and IP Multimedia Subsystem (IMS) session as an example of the communications system architecture.
  • This concept is also referred to as the Circuit Switched IMS Combinational Services (CSICS).
  • the circuit switched CS call may be established for example in UMTS Terrestrial Radio Access Network (UTRAN) or in GSM/EDGE Radio Access Network (GERAN), or in any other suitable public land mobile network (PLMN).
  • UTRAN UMTS Terrestrial Radio Access Network
  • GERAN GSM/EDGE Radio Access Network
  • PLMN public land mobile network
  • the invention is, however, intended to be restricted to any examples described herein.
  • a wireless communication terminal may refer to any wireless device.
  • the terminal is a wireless mobile terminal supporting IMS functionality via a PLMN.
  • the wireless communica- tion terminal may be an UMTS or GSM/EDGE smart mobile terminal having S60 operating system from Nokia Inc.
  • the application capabilities of the terminal could include native S60 applications available in the terminal.
  • An external data device may refer to any data running applications and communicating with an adjacent wireless communication terminal and fur- ther with a remote party, i.e. with a remote wireless terminal and/or remote external device.
  • the external data device may be, for example, a personal computer (PC), a laptop computer, or any similar computing device.
  • the application capabilities of the external device may be any application available in the device, such as a calendar, Windows NetMeeting, Windows Remote Desktop, and Windows Meeting Space.
  • the communication link between a wireless terminal and an external data device may preferably be a short-range wireless link, such a Bluetooth link, a WiFi link, an infrared link, etc.
  • the intermediate CS entities may be any PLMN entities involving with the CS call establishment between the communication terminals.
  • the logical functions/units responsible for the call control in the intermediate network are called Call Session Control Functions (CSCF).
  • CSCF Call Session Control Functions
  • P-CSCF Proxy- CSCF
  • the P-CSCF is the only contact point for the subscriber to the IMS. This means that all the signalling traffic to or from the subscriber is routed via the P-CSCF.
  • the P-CSCF determines the Interrogating CSCF (I-CSCF) located at the home domain of the subscriber.
  • I-CSCF Interrogating CSCF
  • the P-CSCF also performs signalling compression/decompression and authorises bearer resources for the subscriber.
  • the P-CSCF may be located either in the subscriber's home net- work or in the visiting network.
  • the I-CSCF has three major tasks to perform. First it hides the topology of the subscriber's home network and second it allocates the Serving CSCF (S-CSCF) for the subscriber during the IMS registration procedure. The third task of the I-CSCF is to lookup the S-SCSF of the called subscriber in case of incoming session initiation request. In practice the I-CSCF is located in the subscriber's home network.
  • the S-CSCF is the centre node of the IMS.
  • the S-CSCF authenticates the subscriber by using authentication data retrieved from the HSS. After authentication of the subscriber the S-CSCF binds the user's current IP address and the subscriber identity until the subscriber is deregistered from the (MS. The S-CSCF also informs the HSS about the changes of the registration state of the subscriber. Other task of the S-CSCF is to trigger the services when required. For this purpose the S- CSCF retrieves the subscriber related filter criteria information from the HSS, which it then uses to detect if certain application is to be evoked during the IMS procedures. The S-CSCF also prevents the subscriber for performing unau- thorized operations. The S-CSCF is typically located in the subscriber's home network. In the examples herein, all Call Session Control Functions (CSCFs) are referred to as one entity, P/I/S-CSCF, for simplicity.
  • CSCFs Call Session Control Functions
  • the Session Initiation Protocol performs the session control in the IMS.
  • SIP is a control protocol that may be used for establishing, modifying, and terminating multimedia sessions. With SIP it is possible to invite new participants to the existing sessions and modify the media of the existing session.
  • SIP defines the following entities: User Agent Client (UAC), User Agent Server (UAS), registrar, redirect server and proxy server.
  • UAC and the UAS are the endpoints of SIP signalling.
  • the registrar stores the location information of the user.
  • the proxy servers route the message toward the destination and the redirect server informs the sending party about the destination the message should have been sent to.
  • SIP works with SIP dialogs between UAC and UAS.
  • One SIP dialog may contain several transactions, which in turn contain one SIP request and usually one or more SIP responses.
  • An example of a capability exchange according to an embodiment of the invention is now described with reference to Figure 1. Let us first assume that users have already registered to the IMS. Let us further assume that a CSI user agent CUA#2 run in the mobile terminal MT2 starts the circuit switched (CS) call towards a CSI user agent CUA#1 run in the mobile terminal MT1 by sending out a CS SETUP message, step 1 in Figure 1. CUA#1 receives the SETUP message and sends an ALERTING message towards CUA#2 to inform that the call is being processed, step 2.
  • CS circuit switched
  • CUA#1 then notifies the end-user about the incoming mobile terminating (MT) call through a user interface (Ul) of the mobile terminal MTl
  • CUA#1 notifies an adjacent external device (e.g. a laptop) DEVICE#1 about the incoming call via a short-range wireless link 20 (e.g. Bluetooth), step 3.
  • a short-range wireless link 20 e.g. Bluetooth
  • DEVICE#1 When DEVICE#1 receives the incoming call notification from CUA#1 , DEVICE#1 informs the end-user about the incoming call. After that the end-user accepts or rejects the incoming call from DEVICE#1. It has to be noted that the end-user may accept or reject the incoming call in DEVICE#1 or CUA#1. After the end-user has accepted the call (step 4), the CS call is connected between CUA#1 and CUA#2, step 5.
  • CUA#1 requests remote party application capabilities over an intermediate IM core network (CN) 23, e.g. by sending SIP OPTIONS request to CUA#2, step 6.
  • CUA#2 has received the application capabilities request from CUA#1, CUA#2 requests application capabilities from an adjacent external device DEVICE#2 (e.g. a laptop) that is in range and al- ready connected via a short-range wireless link 21 , step 7.
  • DEVICE#2 application logic detects and returns application capabilities information of DE- VICE#2 (e.g. p2p applications, Windows NetMeeting, Windows Remote Desktop, and Windows Meeting Space) to CUA#2, step 8.
  • the description of application capabilities may include also information if a specific application capabil- ity is already active (i.e. a running application) or inactive in DEVICE#2.
  • CUA#2 a specific application logic detects the own application capabilities of CUA#2/mobile terminal MT2, step 9.
  • CUA#2 sends a response (e.g. a SIP 200 OK response with SDP (Session Description Protocol)) carrying the application capabilities information of CUA#2/mobile terminal MT2 and the external device DEVICE#2 to CUA#1, step 10.
  • the description of applica- tion capabilities may include information if a specific application capability is already active (i.e. running) or inactive in DEVICE#2 and/or CUA#2.
  • a network entity in the intermediate IMS CN network which is generally referred to as a visibility con- trol (VC) herein, may filter the application capabilities information of CUA#2/mobile terminal MT2 and the external device DEVICE#2 based on predetermined visibility rules of the remote end-user of DEVICE#2 (the calling remote party), step 11 .
  • the visibility control VC may prevent some of the capabilities information from being forwarded to CUA#1.
  • VC or some other network element may add further services, such as permanent service(s) of the remote end-user into the capability list (e.g. a flick service or a web blog) in step 11.
  • CUA#1 receives the application capabilities information of the remote party from CUA#2 via the visibility control VC, step 12, and detects the own application capabilities of CUA#1/mobile terminal MT1 , step 13.
  • CUA#1 sends the application capabilities information (e.g. a list) of CUA#1 , CUA#2 and DEVICE#2) to DEVICE#1 over the short-range wireless link 20, step 14.
  • DEVICE#1 special application logic tries to find matching/identical application capabilities with the remote party (CUA#2, DEVICE#2), and application capa- bilities (e.g. a web blog) that can be used from DEVICE#1 , step 15.
  • the special application login presents matching (shared) application capabilities to the end-user of DEVICE#1 (the called party), step 16.
  • An example view displayed to the end-user is illustrated in Figure 2.
  • the end-user may now start to use one or more of the matching applications in the session with the remote party.
  • the calling party i.e. CUA#2
  • the calling party may also execute application capability exchange by sending specific a request to the called party (e.g. SIP OPTIONS request).
  • the steps 6 to 16 described above may further be performed in the reverse rejection, i.e. the calling party CUA#2/DEVICE#2 may executes further steps corresponding to steps 6 and 12 - 16, and the called party CUA#1/DEVICE#1 may perform further steps corresponding to step 7-10.
  • the visibility control VC may again perform the filtering/adding to the application capabilities of the called end-user based on predetermined filtering rules.
  • the description (or list) of application ca- pabilities may include information about status of a specific application capability (e.g. whether the application is active or inactive).
  • the installed application has to be started up before its usage is possible.
  • Windows NetMeeting application may be installed to DEV1CE#2, but it is not up and running, and therefore connection establishment from the other party (e.g. DEVICE#1) is not possible. Therefore, the end-user of DEVICE#1 may request to start up the specific application in DEVICE#2 (e.g. by sending SIP REFER request from DEVICE#1 to DEVICE#2 via CUA#1 and CUA#2).
  • this request may also include option to initiate connection establishment (e.g. Windows Net- Meeting session) from DEVICE#2 to DEVICE#1 (also known as a callback).
  • connection establishment e.g. Windows Net- Meeting session
  • DEVICE#2 also known as a callback
  • the application capability exchange can be done even if the called party rejects the incoming call. Further, the application capability exchange can be re-executed at any time during a call (e.g. when terminal capabilities have been changed in CUA#2/DEVICE#2).
  • the exchange of application capabilities may be done outside of a circuit- switched or packet-switched call. For example, the application capability exchange may be initiated from the end-user's call log/history.
  • CUA#1 may include its own application capabilities and the applications capabilities of DEVICE#2 to the capability request (e.g. by sending SlP OPTIONS method with SDP to CUA#2) in step 6.
  • CUA#2 does not have to separately request the application capabilities from CUA#1.
  • the visibility control VC may reuse the end-user's presence rules (that are based on OMA (Open Mobile Alliance) definitions) as visibility rules.
  • OMA Open Mobile Alliance
  • FIG. 4 Still another example of a capability exchange according to an em- bodiment of the invention is now described with reference to Figure 4.
  • a CS call is established between CUA#1 and CUA#2 through an intermediate CS network 22, steps 1-5, in a similar manner as described regarding steps 1-5 in Figure 1.
  • CUA#1 requests re- mote party application capabilities over an intermediate IM core network (CN) 23, e.g. by sending SIP OPTIONS request to CUA#2, step 6.
  • CN intermediate IM core network
  • CUA#2 receives the application capabilities request from CUA#1 , there is no adjacent external device (e.g. a laptop) connected via a short-range wireless link.
  • CUA#2 is not able to request application capabilities from any external device but a specific application logic detects the own application capabilities of CUA#2/mobile terminal MT2, step 7.
  • CUA#2 sends a response (e.g. a SIP 200 OK response with SDP (Session Description Protocol)) carrying the application capabilities information of CUA#2/mobile terminal MT2 to CUA#1 , step 10.
  • the description of application capabilities may include infor- mation if a specific application capability is already active (i.e. running) or inactive in CUA#2.
  • a network entity in the intermediate IMS CN network 23, which is generally referred to as a visibility control (VC) herein, may filter and/or the application capabilities information of CUA#2/mobile terminal MT2 based on predetermined visibility rules of the remote end-user of CUA#2 (the calling remote party), step 9, in a similar manner as described regarding step 11 in Figure 1.
  • VC visibility control
  • CUA#1 receives the application capabilities information of the remote party from CUA#2 via the visibility control VC, step 10, detects the own application capabilities of CUA#1/mobile terminal MT1 , step 11.
  • CUA#1 sends the application capabilities information (e.g. a list) of CUA#1 and CUA#2 to DEVICE#1 over the short-range wireless link 20, step 12.
  • DEVICE#1 special application logic tries to find matching/identical application capabilities with the remote party (CUA#2), and application capabilities (e.g. a web blog) that can be used from DEVICE#1 , step 13.
  • the special application login presents matching (shared) application capabilities to the end-user of DEVICE#1 (the called party), step 15.
  • the end-user may now start to use one or more of the matching applications in the session with the remote party.
  • the calling party i.e. CUA#2
  • the calling party may also execute application capability exchange in a reverse direction by sending specific a request to the called party (e.g. SIP OPTIONS request).
  • SIP OPTIONS request e.g. SIP OPTIONS request.
  • DEVICE#1/CUA#1 may remotely start the matching but currently inactive application(s) in DEVICE#2/CUA#2.
  • a CS call is established between CUA#1 and CUA#2 through an intermediate CS network 22, steps 1-5, in a similar manner as described regarding steps 1-5 in Figure 1.
  • CUA#1 requests remote party application capabilities over an intermediate IM core network (CN) 23, e.g. by sending SIP OPTIONS request to CUA#2, step 6.
  • CN intermediate IM core network
  • step 7 the IM core network 23 cannot find the end-user of the CUA#2, for example because the end- user of the CUA#2 does not have IMS subscription, and therefore do not have a SIP URI which is used for routing in the IMS. It is also possible that the IM core network 23 cannot find the end-user of the CUA#2, in step 7, because the end-user of the CUA#2 is not currently registered to IMS.
  • a network entity in the intermediate IMS CN network 23 which is generally referred to as a visibility control (VC) herein, may attempt to retrieve application capability information for the end-user of MT2 from at least one network server based on a user's identity, network address, telephone number, or like.
  • suitable network servers include a domain name service (DNS) server, an electronic numbering (ENUM) service server, or an XML document data management server (XDMS).
  • DNS domain name service
  • ENUM electronic numbering
  • XDMS XML document data management server
  • Electronic Numbering (ENUM) is a protocol developed by the Internet Engineering Task Force (IETF) to allow the Public Switched Telephone Network (PSTN) and the Internet to interoperate.
  • ENUM allows telephone numbers (such as E.164 numbers) to be mapped to Uniform Resource Identifiers (URIs) using a Domain Name System (DNS)-based architecture.
  • ENUM transforms the telephone number — the most basic and commonly used communications address — into a universal identifier that can be used across many different devices and applications (voice, fax, mobile, email, text messaging, location-based services and the Internet). More specifically, so-called URIs are resolved from the telephone number of MT2 by reversing the telephone number and placing dots after each digit. Then as a domain name, the "e164.arpa" is placed at the end of the string.
  • the VC translates the number +358405116002 (in accordance with the rule described in IETF RFC 3761) into the ENUM domain 2.0.0.6.11.5.8.5.3.e164.arpa, and then the VC sends, step 8, a query to the DNS, the query containing the ENUM domain thereby requesting the DNS to fook up the ENUM domain.
  • the DNS returns Naming Authority Pointer Resource (NAPTR) records which describe mapping from E.164 number to URIs.
  • NPTR Naming Authority Pointer Resource
  • the reply from the DNS will contain information on the application capabilities of the user of MT2, such as the email and instant message.
  • the query result may also contain an URI that refers to a specific XDM application.
  • the VC may use the URI of the specific XDM application to retrieve XML document/list which presents application capabilitiesi- ties of the user of the MT2, step 9.
  • the VC sends the retrieved application capabilities information to CUA#1( e.g. by sending SIP 200 response with SDP), step 10.
  • CUA#1 receives the application capabilities information of the remote party from CUA#2 via the visibility control VC, and detects the own appli- cation capabilities of CUA#1/mobile terminal MT1 , step 11.
  • CUA#1 sends the application capabilities information (e.g. a list) of CUA#1 and the end-user of MT2 to DEVICE#1 over the short-range wireless link 20, step 12.
  • DE- VICE#1 special application logic tries to find matching/identical application capabilities with the remote party (MT2), and application capabilities (e.g. a web blog) that can be used from DEVICE#1 , step 13.
  • the special application login presents matching (shared) application capabilities to the end-user of DEVICE#1 (the called party), step 15.
  • the end-user may now start to use one or more of the matching applications in the session with the remote party.
  • FIG. 6 illustrates an example of a more detailed signalling scheme for implementing the application capability exchange according to an embodiment of the invention.
  • the visibility control entity VC is situated at an application server (AS).
  • AS application server
  • CSCFs Call Session Control Functions
  • P/I/S-CSCF Call Session Control Functions
  • MT1 initiates a CS call by sending a Setup message to intermediate CS entities that acknowledge the receipt by sending a Call Proceeding message.
  • the CS entities send a Setup message further to MT2 that acknowledges by sending Call Confirm and Alerting messages to the CS entities.
  • An alerting message is sent further to MT1.
  • MT2 notifies the incoming call to an adjacent external device (e.g. PC or laptop) that accepts the incoming call.
  • Connect and Connect Acknowledge messages are exchanged first between MT2 and the CS entities, and then between the CS entities and MT1. As a result a CS call has been setup.
  • MT1 requests application capabilities by sending an OPTIONS tel:+3585116002 SIP/2.0 message to P/I/S-CSCF that forwards an OPTIONS sip:frans.tuomela@teliasonera.com,gprs SIP/2.0 message to the Application server AS.
  • AS initiates (in SIP Back-to-Back User Agent mode) a new OPTIONS sip:frans.tuomela@teiiasonera.com.gprs SIP/2.0 message back to S-CSCF.
  • P/I/S-CSCF forwards an OPTIONS sip:frans.tuomela@194.142.21.55 SIP/2.0 message to MT2 (194.142.21.55 being the SIP URI of the end-user) that gets application capabilities from the adjacent PC/laptop and gets its own mobile applications capabilities.
  • the obtained application capabilities of MT2 and the remote PC/laptop are sent in a SIP/2.0 200 OK message to P/I/S-CSCF and further with a SIP/2.0 200 OK message to AS.
  • AS retrieves visibility rules for shared applications of the re- mote-end user from an XDMS server, and modifies capabilities in the SIP response using these rules.
  • the modified application capabilities are sent with a SIP/2.0 200 OK message to P/I/S-CSCF and further with a SIP/2.0 200 OK message to MT1.
  • MT1 notifies an adjacent external device (e.g. PC/laptop) about the application capabilities of the remote party as well as the application capabilities of its own.
  • PC/laptop compares its local application capabilities to the application capabilities of the remote party and opens a view that presents the supported remote applications to the end-user.
  • MT2 may request application capabilities of the user of MT1 by sending an OPTIONS tel:+358-40- 3020100 message to P/I/S-CSCF. After that the signaling flow may continue as in case of MT1 above.
  • Figure 7 illustrates an example of a more detailed signalling scheme for implementing the connection establishment request for a specific application in a situation (e.g. after the application capability exchange shown in Figure 6) where the user of MT#1 wants to use a specific application (e.g. Win- dows NetMeeting) that is installed to both PCs, but applications are not up and running (i.e. status inactive).
  • a specific application e.g. Win- dows NetMeeting
  • the remote party e.g. for a Windows Net- Meeting session.
  • the PC/laptop starts up the specific application (e.g. the NetMeeting application) if it is not already running.
  • the PC/laptop sends to MT1 a request to start up the specific application and perform connection establishment to the PC/laptop of the remote party.
  • MT1 sends a REFER tel:+3585116002 SIP/2.0 message to P/I/S-CSCF that sends then a REFER sip:frans.tuomela@194.142.21.55 SIP/2.0 message to MT2.
  • MT2 request the adjacent PC/laptop to start up the specific application and to establish a connection to the caller.
  • the PC/laptop acknowledges the received request
  • MT2 acknowledges with a SIP/2.0 202 Accepted message to P/f/S-CSCF
  • P/I/S- CSCF acknowledges with a SIP/2.0 202 Accepted message to MT1
  • MT1 notifies the adjacent PC/laptop that the request has been received.
  • the remote PC/laptop sends to MT2 a status report indicating that the application is up and running and initiates the connection to the caller.
  • MT2 sends a NOTIFY mes- sage to P/I/S-CSCF, P/I/S-CSCF forwards a NOTIFY to MT1, and MT1 sends a status report indicating the application is up and running and initiates a connection to the caller. Then MT1 acknowledges with a SIP/2.0 200 OK to P/I/S- CSCF, and P/I/S-CSCF acknowledges with a SIP/2.0 200 OK to MT2. Then the connection is established for the specific application (e.g. Windows Net- Meeting).
  • the specific application e.g. Windows Net- Meeting
  • the techniques described herein may be implemented by various means. For example, these techniques may be implemented in hardware (one or more devices), firmware (one or more devices), software (one or more modules), or combinations thereof. For a firmware or software, implementation can be through modules (e.g., procedures, functions, and so on) that perform the functions described herein.
  • the software codes may be stored in any suitable, processor/computer-readable data storage medium(s) or memory unit(s) and executed by one or more processors/computers.
  • the data storage medium or the memory unit may be implemented within the processor/computer or exter- nal to the processor/computer, in which case it can be communicatively coupled to the processor/computer via various means as is known in the art.
  • components of systems described herein may be rearranged and/or complimented by additional components in order to facilitate achieving the various aspects, goals, advantages, etc., described with regard thereto, and are not limited to the precise configurations set forth in a given figure, as will be appreciated by one skilled in the art.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)

Abstract

L'invention concerne un échange d'informations de possibilité commune de terminaux de communication sans fil, lequel échange est amélioré en prenant en compte aussi des possibilités d'éventuels dispositifs externes adjacents (par exemple, ordinateur personnel ou portable) d'un utilisateur final. Un terminal sans fil transfert (14) des informations de possibilité qui lui sont propres, et celles d'un terminal sans fil distant et d'un dispositif externe distant à un dispositif externe adjacent (par exemple, ordinateur personnel ou portable) de l'utilisateur final. Le dispositif de données externe détermine (15), sur la base des informations de possibilité d'application reçues, ses propres possibilités d'application qui correspondent aux possibilités d'application indiquées par les informations de possibilité d'application reçues, et présente (16) les possibilités d'application concordantes à l'utilisateur final. Ainsi, les correspondants de communication peuvent voir et utiliser des possibilités d'application de leurs terminaux de communication sans fil et de dispositifs externes adjacents, par exemple durant une communication un à un à commutation de circuit ou à commutation de paquet.
PCT/FI2008/050427 2007-07-17 2008-07-11 Procédés d'échange d'informations WO2009010632A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP08787704.9A EP2168350B1 (fr) 2007-07-17 2008-07-11 Procédés d'échange d'informations
NO08787704A NO2168350T3 (fr) 2007-07-17 2008-07-11
DK08787704.9T DK2168350T3 (en) 2007-07-17 2008-07-11 Information exchange methods

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FI20075550 2007-07-17
FI20075550A FI120994B (fi) 2007-07-17 2007-07-17 Menetelmiä informaation vaihtamiseksi

Publications (1)

Publication Number Publication Date
WO2009010632A1 true WO2009010632A1 (fr) 2009-01-22

Family

ID=38331638

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FI2008/050427 WO2009010632A1 (fr) 2007-07-17 2008-07-11 Procédés d'échange d'informations

Country Status (5)

Country Link
EP (1) EP2168350B1 (fr)
DK (1) DK2168350T3 (fr)
FI (1) FI120994B (fr)
NO (1) NO2168350T3 (fr)
WO (1) WO2009010632A1 (fr)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8340635B2 (en) 2009-03-16 2012-12-25 Apple Inc. Capability model for mobile devices
EP2645666A1 (fr) * 2012-03-27 2013-10-02 Telefonaktiebolaget LM Ericsson (publ) Procédé et gestionnaire de capacités permettant de prendre en charge la fourniture de capacités
CN103782589A (zh) * 2011-08-01 2014-05-07 英特尔公司 用于适配视频通信的系统和方法
WO2016168217A1 (fr) * 2015-04-17 2016-10-20 Microsoft Technology Licensing, Llc Gestion d'événements de communication
US20180077215A1 (en) * 2016-09-12 2018-03-15 Bose Corporation Advertising media processing capabilities
EP2740265B1 (fr) * 2011-08-01 2019-01-23 Intel Corporation Système et procédé pour adapter des communications vidéos
US10693912B2 (en) 2013-11-06 2020-06-23 Telefonaktiebolaget Lm Ericsson (Publ) Methods and user equipment for exchanging service capabilities

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020132608A1 (en) * 2001-03-16 2002-09-19 Masahito Shinohara Transmission-origin mobile telephone capable of detecting the media a types and formats of a multimedia message that are receivable by destination mobile telephones in a multimedia communication system
US20040210657A1 (en) * 2003-04-15 2004-10-21 Sathya Narayanan Session endpoint management protocol
US20050060411A1 (en) * 2003-09-16 2005-03-17 Stephane Coulombe System and method for adaptation of peer-to-peer multimedia sessions
US20060223503A1 (en) * 2005-04-04 2006-10-05 Nokia Corporation Method and system for updating capabilities of a device
EP1720365A1 (fr) * 2005-05-06 2006-11-08 Siemens S.p.A. Procédé destiné à échanger des informations de capacitè entre des utilisateurs d'un réseau UMTS

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1148688A1 (fr) * 2000-04-20 2001-10-24 Telefonaktiebolaget L M Ericsson (Publ) Appareil et procédé avec un proxy
SE0402384D0 (sv) * 2004-10-01 2004-10-01 Ericsson Telefon Ab L M Terminal capability determination subject to call forwarding
EP1810475A1 (fr) * 2004-11-03 2007-07-25 Siemens Aktiengesellschaft Systeme et procede pour resolution de service

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020132608A1 (en) * 2001-03-16 2002-09-19 Masahito Shinohara Transmission-origin mobile telephone capable of detecting the media a types and formats of a multimedia message that are receivable by destination mobile telephones in a multimedia communication system
US20040210657A1 (en) * 2003-04-15 2004-10-21 Sathya Narayanan Session endpoint management protocol
US20050060411A1 (en) * 2003-09-16 2005-03-17 Stephane Coulombe System and method for adaptation of peer-to-peer multimedia sessions
US20060223503A1 (en) * 2005-04-04 2006-10-05 Nokia Corporation Method and system for updating capabilities of a device
EP1720365A1 (fr) * 2005-05-06 2006-11-08 Siemens S.p.A. Procédé destiné à échanger des informations de capacitè entre des utilisateurs d'un réseau UMTS

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP2168350A4 *

Cited By (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8620272B2 (en) 2009-03-16 2013-12-31 Apple Inc. Capability model for mobile devices
US8340635B2 (en) 2009-03-16 2012-12-25 Apple Inc. Capability model for mobile devices
EP2740265B1 (fr) * 2011-08-01 2019-01-23 Intel Corporation Système et procédé pour adapter des communications vidéos
CN103782589A (zh) * 2011-08-01 2014-05-07 英特尔公司 用于适配视频通信的系统和方法
EP2988494A1 (fr) * 2011-08-01 2016-02-24 Intel Corporation Système et procédé pour adapter des communications vidéo
US9860290B2 (en) 2011-08-01 2018-01-02 Intel Corporation System and method for adapting video communications
EP2645666A1 (fr) * 2012-03-27 2013-10-02 Telefonaktiebolaget LM Ericsson (publ) Procédé et gestionnaire de capacités permettant de prendre en charge la fourniture de capacités
US11457045B2 (en) 2013-11-06 2022-09-27 Telefonaktiebolaget Lm Ericsson (Publ) Methods and user equipment for exchanging service capabilities
US10693912B2 (en) 2013-11-06 2020-06-23 Telefonaktiebolaget Lm Ericsson (Publ) Methods and user equipment for exchanging service capabilities
US9716796B2 (en) 2015-04-17 2017-07-25 Microsoft Technology Licensing, Llc Managing communication events
WO2016168217A1 (fr) * 2015-04-17 2016-10-20 Microsoft Technology Licensing, Llc Gestion d'événements de communication
WO2018048722A1 (fr) * 2016-09-12 2018-03-15 Bose Corporation Capacités de traitement multimédia publicitaire
US10547660B2 (en) 2016-09-12 2020-01-28 Bose Corporation Advertising media processing capabilities
US20180077215A1 (en) * 2016-09-12 2018-03-15 Bose Corporation Advertising media processing capabilities

Also Published As

Publication number Publication date
FI20075550A0 (fi) 2007-07-17
EP2168350A1 (fr) 2010-03-31
FI120994B (fi) 2010-05-31
EP2168350B1 (fr) 2017-12-20
DK2168350T3 (en) 2018-03-26
NO2168350T3 (fr) 2018-05-19
EP2168350A4 (fr) 2010-11-17
FI20075550A (fi) 2009-01-18

Similar Documents

Publication Publication Date Title
US11082459B2 (en) System and method for determining trust for SIP messages
EP1673676B1 (fr) Libération de sessions auprès d'entités associées aux sessions et faisant partie d'un réseau
EP1627481B1 (fr) Systeme, appareil et procede de soutien multi-applications a l'aide d'une seule pile de protocoles
US9031067B2 (en) Routing messages
EP1884067B1 (fr) Procédé pour demander à un équipement utilisateur non inscrit de s'inscrire dans l'IMS
US20090067408A1 (en) Centralized call log and method thereof
US20040246965A1 (en) System and method for routing messages
EP2168350B1 (fr) Procédés d'échange d'informations
EP1849280A1 (fr) Procede, dispositif et produit de programme informatique pour gerer la fin d'un etat de suspension reseau d'un dispositif terminal
US10009747B2 (en) Emergency contact notification in IP multimedia subsystem (IMS)
US10638299B2 (en) Dynamic scrolling-ticker for initiating telecommunications services
KR101051826B1 (ko) 익명의 호출자에게 결합 서비스를 제공하기 위한 시스템 및 방법
CN1856167B (zh) 请求没有进行ims注册的用户进行注册的方法
WO2008084071A2 (fr) Système de communication avec une mobilité d'abonné transparente sur la base d'un enregistrement de groupe
EP2130347B1 (fr) Système et procédé pour fournir des services combinatoires à des appelants anonymes

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08787704

Country of ref document: EP

Kind code of ref document: A1

DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
WWE Wipo information: entry into national phase

Ref document number: 2008787704

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE