WO2009095069A1 - Procédés, appareils, système et produit programme informatique associé pour ouverture de session - Google Patents

Procédés, appareils, système et produit programme informatique associé pour ouverture de session Download PDF

Info

Publication number
WO2009095069A1
WO2009095069A1 PCT/EP2008/050967 EP2008050967W WO2009095069A1 WO 2009095069 A1 WO2009095069 A1 WO 2009095069A1 EP 2008050967 W EP2008050967 W EP 2008050967W WO 2009095069 A1 WO2009095069 A1 WO 2009095069A1
Authority
WO
WIPO (PCT)
Prior art keywords
request
associations
binding
sip
confirmation message
Prior art date
Application number
PCT/EP2008/050967
Other languages
English (en)
Inventor
Changpeng Fan
Carmelita GÖRG
Frank Pittmann
Umar Toseef
Asanga Udugama
Original Assignee
Nokia Siemens Networks Oy
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 Nokia Siemens Networks Oy filed Critical Nokia Siemens Networks Oy
Priority to PCT/EP2008/050967 priority Critical patent/WO2009095069A1/fr
Publication of WO2009095069A1 publication Critical patent/WO2009095069A1/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/1073—Registration or de-registration
    • 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]

Definitions

  • the present invention relates to session initiation e.g. in PS (packet switched) data and/or or communication networks. More specifically, the present invention relates to methods, apparatuses, a system and a related computer program product e.g. related to session initiation using e.g. SIP (session initiation protocol).
  • PS packet switched
  • SIP session initiation protocol
  • Internet capable mobile or portable devices are already a modern commodity while it is becoming all the more common that such devices are hosts to more than one wireless interface.
  • SIP is an application layer signaling protocol used to create, manage and terminate sessions in an IP based network.
  • a session could be a simple two-way telephone call or a collaborative multi-media conference.
  • SIP works in concert with several other protocols and is only involved in the signaling portion of a communication session.
  • SIP may act as a carrier for the Session Description Protocol (SDP) , which describes the media content of the session, e.g. what IP ports to use, the codec being used etc.
  • SIP "sessions" are typically packet streams of the Real-time Transport Protocol (RTP) .
  • RTP may be the carrier for the actual voice or video content itself .
  • SIP running entities are called UA (user agents).
  • UAC user agent client
  • UAS user agent server
  • the UAC is usually located in the user terminal side, e.g. a soft-phone application running on a PC or a messaging service running on an IP phone.
  • the UAC usually generates requests if a session with another UAC is to be established and may send these requests to a UAS in the network.
  • SIP servers There are three types of SIP servers, that enumeration not being exhaustive.
  • Proxy Server If the UAC is to send the very first SIP request, the UAC does not hold information on the current location (e.g. IP (Internet protocol) address) of the recipient. Thus, the UAC may send that SIP request to the proxy server which determines the recipient's current IP address and forwards the request to the recipient or sends the request just to another proxy server.
  • IP Internet protocol
  • Redirect Server - This server may, on receiving a session invitation request from the UAC, return a response to indicate that the recipient of this request has been relocated to a new address. The response also contains the new address of that recipient.
  • Registrar - A UAC may register its current location (or address) with a registrar server so that SIP requests for that UAC can be forwarded to the UAC at its current address. The UAC may refresh its location occasionally by registering (e.g. sending a special type of message) to the registrar server. In SIP messaging, the registrar servers retrieve and send participants' IP addresses and other pertinent information to the SIP proxy server.
  • Fig. IA shows a typical example of a SIP message exchange between two user equipments UE 101 and UE 103.
  • the user of UE 101 is referred to as "Alice”
  • the user of UE 103 is referred to as "Bob”.
  • the Alice's UE 101 may be a PC using a SIP application (referred to as a soft phone) to call, over the Internet, Bob's UE 103 being e.g. a SIP phone.
  • two SIP proxy servers 1021 and 1022 that act on behalf of UE 101 and UE 103 to facilitate the session establishment.
  • Alice's UE 101 may "call" Bob's UE 103 using the SIP identity of UE 103, the SIP identity being e.g. a type of URI (Uniform Resource Identifier) called a SIP URI.
  • the URI may have a form similar to that of an email address, typically containing a username and a host name.
  • the URI of Bob's UE 103 may be "sip :bob@biloxi . com", where biloxi.com may be the domain of Bob's SIP service provider.
  • Alice's UE 101 may have a SIP URI of "sip : alice ⁇ atlanta . com" .
  • step Sl the transaction may start with Alice's UE 101 making e.g. an INVITE request for Bob's UE 103. But Alice's UE 101 does not hold information on the exact location of Bob's UE 103 in the IP network. So Alice's UE 101 may pass the request to the proxy server 1021 which on behalf of Alice's UE 101 forwards an INVITE request for Bob's UE 103 to the proxy server 1022.
  • the proxy server 1021 may send a TRYING response to Alice's UE 101 informing that the proxy server 1021 is trying to reach Bob's UE 103.
  • the proxy server 1022 (“biloxi.com”) holds information on the exact location of Bob and forwards the INVITE request to the sip phone address of Bob's UE 103.
  • the UE 103 (being e.g. a SIP phone), on receiving the INVITE request, may start ringing in order to inform Bob that a call request has come.
  • step S3 Bob's UE 103 may return a RINGING response to the proxy server 1022 ("biloxi.com") which may forward the RINGING response to Alice's UE 101 through the proxy server 1021 ("atlanta.com"). So Alice's UE 101 may obtain a feedback that Bob's UE 103 has received the INVITE request.
  • biloxi.com a proxy server 1022
  • atlanta.com a proxy server 1021
  • step S4 as soon as Bob accepts the call, Bob's UE 103 may send an OK response to the proxy server 1022 ("biloxi.com"). Retracing the route of INVITE, the OK response may be forwarded to Alice's UE 101.
  • the proxy server 1022 "biloxi.com”
  • step S5 Alice's UE 101 (e.g. a soft-phone) may send an ACK message to confirm the setup of the call.
  • Alice's UE 101 e.g. a soft-phone
  • a media session may flow between the two endpoints, i.e. Alice's UE 101 and Bob's UE 103.
  • Media flow is controlled using protocols different from SIP, e . g . RTP .
  • step S7 when one party in the session decides to disconnect, it (Bob in this case) may send a BYE message to the other party.
  • step S8 the other party
  • (Alice in this case) may send an OK message to confirm the termination of the session.
  • Flow Management is usually used in a wide sense, e.g. flow management within a network, between networks or even within a router.
  • work flow management implies how a stream of data packets is directed through a certain path towards its destination.
  • a node connects to a network which is a part of the Internet (e.g. a computer connected to its ISP (Internet Service Provider))
  • ISP Internet Service Provider
  • all of the network traffic that originates from that node may take its path towards its destination through the network to which the node is connected to.
  • all IP packets that are destined to the node may be forwarded to the node through that network and this may be the only available way of routing that node's traffic.
  • the node may have to manage which type of traffic may take which network interface to be routed to the Internet. This is what is called the flow management.
  • flow management is the way a node directs its certain traffic flows to certain available network interfaces according to some predefined policies. Consequently, flow management is possible if a node has multiple connections to the Internet and if the node is capable of using all of the connections (or at least more than one) simultaneously.
  • Fig. IB shows how a UE 101 (or node) (which is connected to the Internet via WLAN and LAN) benefits from the WLAN and/or LAN resources.
  • a file download may be performed over a high speed LAN network (indicated by the dash-dotted line in Fig. IB) from a file server 1023, while a user at the UE 101 is performing e.g. voice call (such as VoIP (Voice over IP) , indicated by the dashed line in Fig. IB) over the second available connection via WLAN with a UE 103 (e.g. a SIP phone) .
  • Fig. IB depicts a pure Internet environment. However, it may also be possible to extend the scenario e.g. with a MNO' s (Mobile Network Operator) network infrastructure consisting of core and access networks that provide connectivity to the Internet .
  • MNO' s Mobile Network Operator
  • a UE 101 e.g. SIP UAC
  • SIP UAC SIP UAC
  • This register request which actually binds an address-of-record (sip :bob@biloxi . com) UAC with its current address (sip :bob@192.0.2.4) may have the following form:
  • This registration or binding has been performed with a registrar server (e.g. "sip : registrar .biloxi . com”) e.g. with a lifetime of 7200 seconds as mentioned in "Expires" header.
  • a registrar server e.g. "sip : registrar .biloxi . com”
  • proxy server may look up for bindings of UE 101 ("sip :bob@biloxi . com") and forwards that INVITE request to UE 101 (UAC) at e.g. sip :bob@192.0.2.4.
  • sip :bob@192.0.2.4 may be the only contact address at which INVITE request can be forwarded.
  • SIP also allows a UE 101 to register multiple contact addresses against one single address-of-record URI.
  • SIP register request creates two bindings for sip :bob@biloxi . com:
  • Each binding may have its own contact address, priority (represented by "q" field) and lifetime
  • the proxy server may forward that request to the binding address with the highest priority.
  • a further drawback resides in that a SIP user has no control over which binding may be used for which session type. This is because proxy server just blindly forwards all SIP INVITE requests to the user over the same binding. Thus, the user has no choice to specify his requirements, for example, to initiate voice call session over the one contact address and instant messaging session over the other.
  • the SIP user may have to change the priority of bindings quite frequently and very timely. This is because if the user could not change priority of the bindings just after receiving the session request, the next session request may also follow the same connection to him as did the earlier request and hence, the user may not have precise control in his hands .
  • This indirect controlling mechanism may not only be very complex, but also has the drawback that due to frequent updates in binding registration, data bandwidth resources may be wasted.
  • a further approach describes several media streams ("flows") used in one session together. All the example streams are based on the same pair of "local host” and "remote host”. However, there are several related open questions such as when and how the end-points (such as UEs 101 and 103) can be signaled to. Therefore, there is simply defined a media stream description format at the flow granularity without the related signaling mechanisms and deployment processes.
  • the present invention provides methods, apparatuses, a system and a related computer program product for session initiation.
  • this object is for example achieved by a method comprising: receiving a first request comprising a plurality of unique identification information each uniquely related to creation of a first association of a network resource identifier with a network contact address; creating a plurality of first associations based on the plurality of unique identification information received in the first request; sending a first confirmation message comprising the plurality of unique identification information and confirmation information relating to creation of the plurality of first associations; receiving, responsive to the first confirmation message, a second request comprising a plurality of unique registration information each uniquely related to registration of a second association of a filter rule with the network contact address based on the created first associations; and registering the plurality of second associations based on the plurality of unique registration information received in the second request.
  • the method further comprises sending a second confirmation message comprising the plurality of unique registration information and confirmation information relating to creation of the plurality of second associations;
  • the method further comprises receiving at least one third request comprising one or more network resource requirements; matching the one or more network resource requirements against the filter rule of each of the plurality of second associations; and assigning one of the plurality of second associations based on a result of matching;
  • the method further comprises splitting, prior to the matching, the at least one third request into at least two third requests each comprising one of the network resource requirements, if the at least one third request comprises at least two network resource requirement.
  • this object is for example achieved by a method comprising : creating a first request comprising a plurality of unique identification information each uniquely related to creation of a first association of a network resource identifier with a network contact address; sending the first request; receiving, responsive to the first request, a first confirmation message comprising the plurality of unique identification information and confirmation information relating to creation of the plurality of first associations; creating, responsive to the first confirmation message, a second request comprising a plurality of unique registration information each uniquely related to registration of a second association of a filter rule with the network contact address based on the created first associations; and sending the second request.
  • the method further comprises receiving, responsive to the second request, a second confirmation message comprising second confirmation information related to the successful registration of the plurality of second associations;
  • the unique identification information is a binding identifier
  • the first request is a session initiation protocol register message and the first confirmation message is a session initiation protocol confirmation message
  • the network resource identifier is a uniform resource identifier
  • the first association is a binding
  • the unique registration information is at least one of a flow identifier and a binding identifier
  • the second request is a session initiation protocol register message and the second confirmation message is a session initiation protocol confirmation message
  • the second association is a flow binding
  • this object is for example achieved by an apparatus comprising: means for receiving a first request comprising a plurality of unique identification information each uniquely related to creation of a first association of a network resource identifier with a network contact address; means for creating a plurality of first associations based on the plurality of unique identification information received in the first request; means for sending a first confirmation message comprising the plurality of unique identification information and confirmation information relating to creation of the plurality of first associations; wherein the means for receiving is configured to, responsive to the first confirmation message, a second request comprising a plurality of unique registration information each uniquely related to registration of a second association of a filter rule with the network contact address based on the created first associations; the apparatus further comprising means for registering the plurality of second associations based on the plurality of unique registration information received in the second request.
  • the means for sending is configured to send a second confirmation message comprising the plurality of unique registration information and confirmation information relating to creation of the plurality of second associations;
  • the means for receiving are configured to receive at least one third request comprising one or more network resource requirements
  • the apparatus further comprises means for matching the one or more network resource requirements against the filter rule of each of the plurality of second associations, and means for assigning one of the plurality of second associations based on a result of matching.
  • the apparatus further comprises means for splitting, prior to the matching performed by the means for matching, the at least one third request into at least two third requests each comprising one of the network resource requirements, if the at least one third request comprises at least two network resource requirement;
  • the apparatus is constituted by at least one of a proxy server and a registrar server.
  • this object is for example achieved by an apparatus comprising: means for creating a first request comprising a plurality of unique identification information each uniquely related to creation of a first association of a network resource identifier with a network contact address; means for sending the first request; means for receiving, responsive to the first request, a first confirmation message comprising the plurality of unique identification information and confirmation information relating to creation of the plurality of first associations; wherein the means for creating is configured to create, responsive to the first confirmation message, a second request comprising a plurality of unique registration information each uniquely related to registration of a second association of a filter rule with the network contact address based on the created first associations; and the means for sending is configured to send the second request.
  • the means for receiving is configured to receive, responsive to the second request, a second confirmation message comprising second confirmation information related to the successful registration of the plurality of second associations;
  • the apparatus is constituted by a user equipment.
  • the unique identification information is a binding identifier
  • the first request is a session initiation protocol register message and the first confirmation message is a session initiation protocol confirmation message
  • the network resource identifier is a uniform resource identifier
  • the first association is a binding
  • the unique registration information is at least one of a flow identifier and a binding identifier
  • the second request is a session initiation protocol register message and the second confirmation message is a session initiation protocol confirmation message
  • the second association is a flow binding
  • the third request is a session initiation protocol invite message
  • the apparatus is implemented as a chipset or module.
  • this object is for example achieved by a system comprising: an apparatus according to the third aspect; and at least one apparatus according to the fourth aspect .
  • this object is for example achieved by a computer program product comprising code means for performing method steps of a method according to the first and second aspects.
  • Fig. IA shows the above-described basic session setup example in SIP; [0047] Fig. IB shows two traffic flows taking different paths to the destination considering Fixed Mobile Convergence (FMC) .
  • FMC Fixed Mobile Convergence
  • FIG. 2 shows respective methods for session initiation according to the present invention
  • FIG. 3 shows respective apparatuses (e.g. UE and proxy/registrar server) for session initiation according to the present invention
  • Fig. 4 shows an example of an extended REGISTER message to transport flow bindings according to the present invention
  • Fig. 5 shows an example REGISTER request and response e.g. of a "fetchAll" flow binding message according to the present invention
  • Fig. 6 shows an example of splitting e.g. an INVITE request according to the present invention.
  • Fig. 7 shows a flow management scenario for a SIP user as an example scenario according to the present invention .
  • binding, flow binding, REGISTER request, INVITE message, binding identifier and flow identifier are examples for “first association, second association, first and second requests, third request, unique identification information and unique registration information", respectively, without restricting the latter-named terms to the special technical or implementation details imposed to the first-named terms.
  • session initiation protocol is used for descriptive purposes.
  • the present invention is not limited thereto, and any protocol following the same or similar principles as SIP may be applied.
  • Fig. 2 shows the methods according to the present invention. Signaling between elements is indicated in horizontal direction, while time aspects between signaling may be reflected in the vertical arrangement of the signaling sequence as well as in the sequence numbers. Furthermore, the time aspects indicated in Fig. 2 may not restrict any one of the method steps shown to the step sequence outlined. This applies in particular to method steps that are functionally disjunctive with each other .
  • a communication system 200 may comprise a UE 201 (also occasionally referred to as “Bob” hereinafter) , a network 202 and an external client 203 (also occasionally referred to as "Alice” hereinafter) .
  • the network 202 in turn may comprise the optional redirect server 2021, a proxy server 2022 and a registrar server 2023.
  • the proxy server 2022 and the registrar server 2023 may also be disposed as an integral entity, as indicated by the dashed box surrounding the functional blocks of the proxy server 2022 and the registrar server 2 023 .
  • step S2-1 e.g. the UE 201 (Bob) may perform creating a first request (e.g. REGISTER) comprising a plurality of unique identification information (e.g. binding identifier bid) each uniquely related to creation of a first association (e.g. a binding) of a network resource identifier (e.g. URI) with a network contact address;
  • a first request e.g. REGISTER
  • unique identification information e.g. binding identifier bid
  • a first association e.g. a binding
  • a network resource identifier e.g. URI
  • step S2-2 e.g. the UE 201 may perform sending the first request which may be received in step Sl-I e.g. by the proxy/registrar server 2022/2023.
  • step Sl-2 e.g. the proxy/registrar server 2022/2023 may perform creating a plurality of first associations (e.g. bindings) based on the plurality of unique identification information (e.g. binding identifiers bid) received in the first request.
  • first associations e.g. bindings
  • unique identification information e.g. binding identifiers bid
  • step Sl-3 e.g. the proxy/registrar server 2022/2023 may perform sending a first confirmation message (e.g. SIP OK) comprising the plurality of unique identification information and confirmation information relating to creation of the plurality of first associations.
  • step S2-3, e.g. the UE 201 may perform receiving the first confirmation message.
  • step S2-4 e.g. the UE 201 may perform creating (S2-4), responsive to the first confirmation message, a second request (e.g. REGISTER) comprising a plurality of unique registration information (e.g. flow identifier fid, binding identifier bid) each uniquely related to registration of a second association (e.g. flow bindings) of a filter rule with the network contact address based on the created first associations (e.g. bindings).
  • a second request e.g. REGISTER
  • unique registration information e.g. flow identifier fid, binding identifier bid
  • step S2-5 e.g. the UE 201 may perform sending of the second request which may be received by the proxy/registrar server 2022/2023 in step Sl-4.
  • step Sl-5 e.g. the proxy/registrar server 2022/2023 may perform registering the plurality of second associations (e.g. flow bindings) based on the plurality of unique registration information (e.g. flow identifiers fid, binding identifiers bid) received in the second request (e.g. REGISTER) .
  • the plurality of second associations e.g. flow bindings
  • unique registration information e.g. flow identifiers fid, binding identifiers bid
  • the method may further comprise sending (optional step Sl-6) a second confirmation message (e.g. SIP OK) comprising the plurality of unique registration information and confirmation information relating to creation of the plurality of second associations.
  • the method may also comprise receiving (optional step Sl-7) at least one third request (e.g. SIP INVITE message) comprising one or more network resource requirements (or session parameter (s) ) e.g. from Alice's external client 203.
  • the proxy/registrar server 2022/2023 may perform matching (optional step Sl-8) the one or more network resource requirements against the filter rule of each of the plurality of second associations, and assigning (optional step Sl-9) one of the plurality of second associations (e.g. flow bindings) based on a result of matching (e.g. based on application type or bandwidth requirements) .
  • the method may further comprise splitting (optional step Sl-7a) , prior to the matching, the at least one third request into at least two third requests each comprising one of the network resource requirements, if the at least one third request comprises at least two network resource requirement .
  • the method may further comprise receiving (optional step S2-6) , responsive to the second request, the second confirmation message (e.g. SIP OK message) comprising second confirmation information related to the successful registration of the plurality of second associations.
  • the second confirmation message e.g. SIP OK message
  • the unique identification information may be a binding identifier
  • the first request may be a session initiation protocol register message
  • the first confirmation message may be a session initiation protocol confirmation message
  • the network resource identifier may be a uniform resource identifier (URI)
  • the first association may be a binding.
  • the unique registration information may be a flow identifier and/or a binding identifier
  • the second request may be a session initiation protocol register message
  • the second confirmation message may a session initiation protocol confirmation message
  • the second association may be a flow binding.
  • the third request may be a session initiation protocol invite message.
  • FIG. 3 shows respective apparatuses (e.g. proxy/registrar server 2022/2023 and/or UE 201) for session initiation according to the present invention.
  • apparatuses e.g. proxy/registrar server 2022/2023 and/or UE 201 for session initiation according to the present invention.
  • Fig. 3 for ease of description, means or portions providing main functionalities are depicted with solid functional blocks and a normal font, while means or portions providing optional functions are depicted with dashed functional blocks and an italic font.
  • the UE 201 may comprise a CPU or core functionality CF (referred to as "CPU” hereinafter) 2011, a memory 2012, a sender (or means for sending) Tx 2013, a receiver (or means for receiving) Rx 2014 and a creator (or means for creating) 2015.
  • CPU central processing unit
  • CF central processing unit
  • the proxy server 2022 may comprise a CPU or core functionality CF (referred to as "CPU” hereinafter) 20221, a memory 20222, a sender (or means for sending) Tx 20223, a receiver (or means for receiving) Rx 20224, a creator (or means for creating) 20225, a registrator (or means for registering) 20226, an optional matcher (or means for matching) 20227, an optional assigner (or means for assigning) 20228 and an optional splitter (or means for splitting) 20229.
  • CPU CPU or core functionality
  • the registrar server 2023 may comprise a CPU 20231, a memory 20232, a sender (or means for sending) Tx 20233 and a receiver (or means for receiving) Rx 20234.
  • the means for creating 2015 of the UE 201 as well as the means for creating 20225, the means for registering 20226, the means for matching 20227, the means for assigning 20228 and the means for splitting 2029 of the proxy/registrar server 2022/2023 may be functionalities running on the CPUs 2011 and 20221; 20231 or may alternatively be separate functional entities or means.
  • the CPUs 20x1 may respectively be configured to process various data inputs and to control the functions of the memories 20x2, the senders 202x3 and the receivers 20x4 (and the means for creating 2015 of the UE 201 as well as the means for creating 20225, the means for registering 20226, the means for matching 20227, the means for assigning 20228 and the means for splitting 20289 of the proxy/registrar server 2022/2023) .
  • the memories 20x2 may respectively serve e.g. for storing code means for carrying out e.g. the respective method according to the invention, when run on the CPUs 20x1.
  • the senders 20x3 and the receivers 20x4 may alternatively be provided as respective integral transceivers (not shown) .
  • the senders/receivers may be implemented i) as physical senders/receivers for transceiving e.g. via the air interface (e.g. in case of UE 201 towards the proxy/registrar server 2022/2023), or ii) as routing entities e.g. for sending/receiving data packets e.g. in a PS network (e.g.
  • proxy server 2022 and the registrar server 2023 when disposed as separate network entities are disposed as separate network entities
  • iii) as functionalities for writing/reading information into/from a given memory area e.g. in case of shared/common CPUs (as shown) or memories e.g. the proxy server 2022 and the registrar server 2023 when disposed as an integral network entity
  • iv) as any suitable combination of i) to iii) e.g. in case of shared/common CPUs (as shown) or memories e.g. the proxy server 2022 and the registrar server 2023 when disposed as an integral network entity
  • the proxy server 2022 and the registrar server 2023 may also be implemented as an integral/combined entity, as mentioned above.
  • the CPUs 20221, 20231, the memories 20222, 20232, the senders 20223, 20233 and the receivers 20224, 20224 may respectively be common and/or shared resources, as exemplary shown in Fig. 3 for the CPU 20221; 20231, the means for sending 20223; 20233 and the means for receiving 20224; 20234.
  • the means for creating 2015 in conjunction with the CPU 2011 of the UE 201 may be configured to create a first request (e.g. SIP REGISTER request) comprising a plurality of unique identification information (e.g. binding identifiers bid) each uniquely related to creation of a first association (e.g. binding) of a network resource identifier (URI) with a network contact address.
  • a first request e.g. SIP REGISTER request
  • a plurality of unique identification information e.g. binding identifiers bid
  • URI network resource identifier
  • the means for sending 2013 of the UE 201 may be configured to send the first request. Consequently, e.g. the means for receiving 20224; 20234 of the proxy/registrar server 2022/2023 may be configured to receive the first request.
  • the means for creating 20225 of the proxy/registrar server 2022/2023 may be configured to create a plurality of first associations (e.g. bindings) based on the plurality of unique identification information (e.g. binding identifiers bid) received in the first request (e.g. SIP REGISTER) .
  • first associations e.g. bindings
  • unique identification information e.g. binding identifiers bid
  • the means for sending 20223; 20233 may be configured to send a first confirmation message (e.g. SIP OK message) comprising the plurality of unique identification information (e.g. bids) and confirmation information relating to creation of the plurality of first associations. Consequently, e.g. the means for receiving 2014 of the UE 201 may be configured to receive the first confirmation message.
  • a first confirmation message e.g. SIP OK message
  • the plurality of unique identification information e.g. bids
  • confirmation information relating to creation of the plurality of first associations e.g. the means for receiving 2014 of the UE 201
  • the means for creating 2015 of the UE 201 may be configured to create, responsive to the first confirmation message, a second request (e.g. SIP REGISTER) comprising a plurality of unique registration information (e.g. flow identifier fid, binding identifier bid) each uniquely related to registration of a second association (e.g. flow bindings) of a filter rule with the network contact address based on the created first associations (e.g. bindings).
  • a second request e.g. SIP REGISTER
  • a plurality of unique registration information e.g. flow identifier fid, binding identifier bid
  • a second association e.g. flow bindings
  • the means for sending 2013 of the UE 201 may be configured to send the second request. Consequently, e.g. the means for receiving 20224; 20234 of the proxy/registrar server 2022/2023 may configured to receive the second request.
  • the means for registering 20226 of the proxy/registrar server 2022/2023 may be configured to register the plurality of second associations (e.g. flow bindings) based on the plurality of unique registration information (e.g. fids, bids) received in the second request (e.g. SIP REGISTER) .
  • the plurality of second associations e.g. flow bindings
  • unique registration information e.g. fids, bids
  • the sender 20223; 20233 may be configured to send a second confirmation message (e.g. SIP OK) comprising the plurality of unique registration information (e.g. fids, bids) and confirmation information relating to creation of the plurality of second associations.
  • a second confirmation message e.g. SIP OK
  • the means for receiving 20224; 20234 may be configured to receive at least one third request (e.g. SIP INVITE message) comprising one or more network resource requirements (or session parameter) e.g. from Alice's external client 203.
  • the proxy/registrar server 2022/2023 may further comprise the means for matching 20227 configured to match the one or more network resource requirements against the filter rule of each of the plurality of second associations.
  • the means for assigning 20228 configured to assign one of the plurality of second associations (e.g. flow bindings) based on a result of matching (e.g. based on application type or bandwidth requirements) .
  • the proxy/registrar server 2022/2023 may further comprise the means for splitting 20229 configured to split, prior to the matching performed by the means for matching 20227, the at least one third request (e.g. SIP INVITE) into at least two third requests each comprising one of the network resource requirements, if the at least one third request comprises at least two network resource requirement .
  • SIP INVITE SIP INVITE
  • the means for receiving 2014 of the UE 201 may further be configured to receive, responsive to the second request, the second confirmation message (e.g. SIP OK message) comprising second confirmation information related to the successful registration of the plurality of second associations.
  • the second confirmation message e.g. SIP OK message
  • the unique identification information may be a binding identifier
  • the first request may be a session initiation protocol register message
  • the first confirmation message may be a session initiation protocol confirmation message
  • the network resource identifier may be a uniform resource identifier (URI)
  • the first association may be a binding.
  • the unique registration information may be a flow identifier and/or a binding identifier
  • the second request may be a session initiation protocol register message
  • the second confirmation message may a session initiation protocol confirmation message
  • the second association may be a flow binding.
  • the third request may be a session initiation protocol invite message.
  • the present invention is described as an extension to the SIP in order to incorporate flow management functionality.
  • the present invention is not limited thereto, and any protocol following the same or similar principles as SIP may be applied.
  • user "Bob” is occasionally used also for referring to the first UE 201 directly
  • user "Alice” is occasionally used also for referring to the external client 203 directly.
  • Binding An association of an address-of-record URI with a contact address.
  • a new parameter "bid” is introduced in the contact header field.
  • the value of "bid” (abbreviation for binding identifier) parameter is a number indicating identity of that binding. This parameter may be included and may be have a unique value for each binding of an address-of-record URI.
  • REGISTER message requests add, remove, and query bindings.
  • the REGISTER message body is used for flow binding transportation. These flow bindings may be written in SDP syntax with customized semantics and will be discussed later. If flow bindings are present in REGISTER message body, this message header may have "Content-Type” header field with value "application/sdp" and "Content-Length” header field with byte count of message body.
  • flow binding description is conveyed by REGISTER message body, many flow binding descriptions may be concatenated together
  • a flow binding therefore may consist of following four parts
  • ⁇ fid> - a unique number that is used to identify a flow binding. The uniqueness of this number may be maintained across all flow bindings of an address-of-record URI.
  • ⁇ priority> - indicates the priority of this filter rule in order to solve conflict between the overlapping filter rules.
  • An overlap can occur when one session matches multiple filter rules.
  • the manner of managing the overlapping of filter rules may be solely determined by the UAC, and the registrar server may not issue any warning or error related to filter rule overlapping.
  • Filter rules with the same priority may be set in chronological order.
  • ⁇ priority> may be a decimal digit from 0 to 1.0. For example, the higher the number, the more preferable the flow binding.
  • ⁇ action> how a session invitation request that matches with filter rule of this flow binding may be treated.
  • ⁇ action> can be one of the following: forward - all session INVITE requests that match filter rule of this flow binding may be forward to the contact address of binding associated with this flow binding.
  • drop all session INVITE request that match filter rule of this flow binding may be not be forwarded to UAC.
  • the proxy server may send a response e.g. with 480 (Temporarily Unavailable) to the issuer of the INVITE request .
  • the final part is the most important one and may give the session description parameters in SDP syntax and semantics that may be matched by session parameters of the INVITE request to come under that filter rule.
  • a filter rule may not have more than one media descriptions.
  • the binding registration mechanism may have to be extended to incorporate flow binding registration.
  • a flow binding may have to be associated with another binding used to assign contact address to an address-of-record URI.
  • the registrar server therefore may allow flow bindings that are included in REGISTER message body, process them and store them in a database of the registrar server until associated bindings are active.
  • the UAC may send e.g. a REGISTER message to its register server which includes flow binding (s) .
  • the binding to which this flow binding is associated may have already been registered successfully with the registrar server before the processing for this flow binding starts.
  • the "bid” number referred by this flow binding may be associated to an active binding.
  • the flow binding may include all four parts mentioned above.
  • the value for "sfbCmd" attribute may be "add" to indicate an add operation.
  • ⁇ fid> may be a unique number that will be used to identify this flow binding
  • ⁇ bid> may be an identifier of a valid binding
  • ⁇ priority> may also be given proper values as specified above.
  • the fourth part of the flow binding may specify a filter rule to indicate e.g. the session INVITE requests to be accepted by this flow binding.
  • the filter rule construction has been described above.
  • a REGISTER request may be sent with message body including a flow binding.
  • This flow binding may have ⁇ fid> as "fid” of the flow binding being modified as well as “sfbCmd” may have value "replace”.
  • This flow binding may overwrite the existing flow binding with same "fid” number.
  • flow binding modification is essentially a process where an existing flow binding is removed and a new flow binding (included in the message) may be added and given the same "fid” as that of the flow binding that was removed.
  • a REGISTER request may be sent with message body to include flow binding consisted of first three parts.
  • the "sfbCmd” may have value “remove” to indicate delete operation.
  • “sfbHeader” may have at least first three values same as that of the flow binding which is intended to be removed. There is no need to include fourth part of the flow binding. This may provide enough information to the registrar server in order to locate the flow binding with "fid” and remove it.
  • a REGISTER request may be sent with a message body to include flow binding consisted of the first two parts only.
  • the "sfbCmd” may have value "flushAll" followed by one of the three arguments mentioned above. There may not be any third and fourth part for this flow binding. This operation can be helpful for a UAC that has undergone through a reboot cycle and is in an unknown state to start flow management.
  • a flow binding may not have its own lifetime. Actually, lifetime of a flow binding is the same as that of the associated binding. Therefore, a flow binding gets refreshed automatically when its associated binding is refreshed and is removed when its associated binding is no more active.
  • a registrar server may be required to acknowledge each flow binding received.
  • the binding response message may be extended to carry the flow binding acknowledgements in its body.
  • Flow binding acknowledgement message will consist of up to first three parts mentioned above. The second part will have "sfbStatus" attribute followed by a proper status code as mentioned above. The third part will be the same as it was in the corresponding flow binding request. If a REGISTER message had multiple flow binding requests, the response message may contain individual acknowledgement for each flow binding request. The order of flow binding acknowledgements in binding response may be the same as that of the flow binding requests in a REGISTER message.
  • a REGISTER request will be sent with message body to include flow binding consisted e.g. of first two parts only.
  • the "sfbCmd" may have the value "fetchAll".
  • This flow binding may be the last one if multiple flow bindings are included in a single message body. If the flow binding request is processed successfully, a complete list of active flow bindings may be included in the response message body. Each of these flow bindings will be composed of the first, third and fourth part. For example, a fetchAll flow binding request and its successful response may have the form shown in Fig. 5.
  • each binding may have its unique "bid" number that may always be included by sender whenever adding, refreshing, removing and fetching bindings .
  • a session INVITE request contains multiple media descriptions, for example, to start audio and video streams
  • this request may be split by proxy server into individual requests, one for each media description, and then to apply filter rules on all requests individually.
  • each split request will be sharing the same session level description as it was in the original INVITE request.
  • only one media description may be kept and others may be given port number as zero.
  • filter rules are applied on each split request, the invitee might get multiple INVITE requests with identical Call-ID and CSeq, but it may respond to all of these requests properly. The inviter might also get multiple responses to its single INVITE request but it may accept all of them.
  • a sender of an INVITE request with multiple media descriptions may wait equal to timeout of a request on receiving a split response in order to collect all possible responses. It is outside the scope of this document how inviter can use this feature to start separate media sessions corresponding to each split request response.
  • a SIP user Bob has an address-of-record URI as "sip :bob@biloxi . com" and another SIP user, named Alice, has a URI as "sip:alice@atlanta.com".
  • Bob's UE 201 e.g. a PC
  • Bob's UE 201 has two connections from two networks and therefore, Bob's UE 201 has two contact addresses, i.e. "sip :bob@134.104.144.14" and "sip:bob@132.102.122.12”.
  • Bob's UE 201 may send a REGISTER request to its registrar server 2023 to register both of his contact addresses.
  • Bob's UE may create two bindings. For contact address "sip:bob@134.104.144.14", Bob (or the UE 201) may choose 4400 seconds as lifetime, 0.4 as priority and 44 as bid number. As for the contact address "sip:bob@132.102.122.12", Bob (or the UE 201) may choose 2200 seconds as lifetime, 0.2 as priority and 22 as bid number. In this way, the REGISTER request sent by the UE 201 to the registrar server may have the following form:
  • the registrar server 2023 may receive the request, process the request and add two bindings for Bob's "sip:bob@biloxi.com" URI.
  • the registrar server 2023 may acknowledge the REGISTER request by sending a success response message having e.g. the following form:
  • Bob may have to create a REGISTER request that may be carrying the above-described two flow bindings in the message body.
  • This REGISTER request may have the following form:
  • the registrar server 2023 after having successfully processed this request, may register the flow bindings and send a response message back to Bob' s UE 201.
  • the response message may contain a complete list of registered bindings in the message header.
  • the response message body may be carrying acknowledgements of flow bindings.
  • the complete response message may have the following form:
  • Bob's UE 201 may, on receiving this response message, hold information that both of the flow bindings have been added successfully.
  • Alice may want to talk to Bob using e.g. a SIP application and hence, Alice's UE 203 may send e.g. an INVITE request to Bob's SIP URI "sip :bob@biloxi . com" .
  • This request is received by Bob's proxy ("biloxi.com") and may have the following form:
  • the proxy server 2022 may, on receiving the above request, fetch the contact addresses registered against "sip :bob@biloxi . com" address-of-record URI as well as the flow bindings associated with each contact address binding.
  • the proxy server 2022 may determine that flow binding with fid 444 has a filter rule which matches with the session description of the above INVITE request.
  • the proxy server 2022 may forward the above INVITE request to Bob's UE 201 at its contact address "sip:bob@134.104.144.14" associated with flow binding of fid 444.
  • Bob's UE 201 may receive that forwarded INVITE request and respond to Alice's UE 203 to initiate the audio session.
  • the proxy server 2022 may, on receiving the above request, again fetch the registered contact addresses against Bob's UE 201, i.e. sip URI sip :bob@biloxi . com, as well as the flow bindings associated with each contact address binding.
  • the proxy server 2022 may now determine that the filter rule of flow binding with fid 222 matches with the session description contained by the above INVITE request. Therefore, the proxy server 2022 may forward the received INVITE request to Bob at contact address "sip :bob@132.102.122.12" associated with flow binding of fid 222.
  • Bob's UE 201 may receive the forwarded INVITE request and respond accordingly to start an ftp session with Alice's UE 203 and download the intended file.
  • the present invention solves the above stated problem in a very efficient way and enables a SIP user to use all of its connections for session traffic as well as perform session filtering.
  • some extensions have been proposed to the standard SIP protocol. Namely, the registration process has been extended to accept some extra parameters related to filter rules and redirect/forward mechanism has been extended to incorporate filtering functionality.
  • This invention enables SIP user to register filter rules for his binding contact addresses. This filter rule will include session parameters (e.g. media type, incoming IP address and port number etc.) that may be matched by incoming session request to be accepted at that binding contact address.
  • a SIP user has two bindings and it wants to use one binding contact address for VoIP sessions and second for instant messaging, he will construct one filter rule with session parameters which describe the VoIP session to register it with first binding and will construct another filter rule with session parameters which describe the instant messaging session to register it with second binding.
  • proxy/redirect server of that SIP user When proxy/redirect server of that SIP user receives a VoIP session invitation message for him, it will evaluate depending on the registered filter rules which binding contact address may be used to forward/redirect this INVITE request. In this way SIP user will receive the VoIP session invitation request and hence he can accept the request to initiate VoIP session at the address he wanted to start.
  • the present invention is related to the syntax and semantics of filter rules as well as to how these filter rules can be registered, removed and modified.
  • the present invention is also related to the expected behavior of UAC and UAS to support this functionality.
  • the proxy server 2022, the registrar server 2023 and/or the UE 201 may be implemented as a chipset or module.
  • the present invention also relates to a system which may comprise at least one UE 201 and a proxy/registrar server 2022/2023.
  • an access technology may be any technology by means of which a user equipment can access an access network (or base station, respectively) .
  • Any present or future technology such as WiMAX (Worldwide Interoperability for Microwave Access) or WLAN (Wireless Local Access Network) , BlueTooth, Infrared, and the like may be used; although the above technologies are mostly wireless access technologies, e.g. in different radio spectra, access technology in the sense of the present invention may also imply wirebound technologies, e.g. IP based access technologies like cable networks or fixed line.
  • a network may be any device, unit or means by which a station entity or other user equipment may connect to and/or utilize services offered by the access network; such services include, among others, data and/or (audio-) visual communication, data download etc.;
  • the present invention may be applicable in those network/user equipment environments relying on a data packet based transmission scheme according to which data are transmitted in data packets and which are, for example, based on the Internet Protocol IP.
  • IP Internet Protocol
  • the present invention is, however, not limited thereto, and any other present or future IP or mobile IP (MIP) version, or, more generally, a protocol following similar principles as
  • a user equipment may be any device, unit or means by which a system user may experience services from an access network;
  • any method steps and/or devices, units or means likely to be implemented as hardware components at the proxy server, the registrar server and/or the UE, or any module (s) thereof, are hardware independent and can be implemented using any known or future developed hardware technology or any hybrids of these, such as MOS (Metal Oxide Semiconductor), CMOS (Complementary MOS), BiMOS (Bipolar MOS), BiCMOS (Bipolar CMOS), ECL (Emitter Coupled Logic), TTL (Transistor-Transistor Logic), etc., using for example ASIC (Application Specific IC (Integrated Circuit)) components, FPGA (Field- programmable Gate Arrays) components, CPLD (Complex Programmable Logic Device) components or DSP (Digital Signal Processor) components; in addition, any method steps and/or devices, units or means likely to be implemented as software components may alternatively be based on any security architecture capable e.g. of authentication, authorization, keying and/or traffic protection;
  • - devices, units or means can be implemented as individual devices, units or means, but this does not exclude that they are implemented in a distributed fashion throughout the system, as long as the functionality of the device, unit or means is preserved.

Abstract

L'invention porte sur un procédé qui consiste : à recevoir une première demande comprenant une pluralité d'informations d'identification uniques liées chacune de façon unique à la création d'une première association entre un identificateur de ressource de réseau et une adresse de contact réseau; à créeer une pluralité de premières associations sur la base de la pluralité d'informations d'identification uniques reçues dans la première demande; à envoyer un premier message de confirmation comprenant la pluralité d'informations d'identification uniques et d'informations de confirmation liées à la création de la pluralité de premières associations; à recevoir, en réponse au premier message de confirmation, une seconde demande comprenant une pluralité d'informations d'enregistrement uniques liées chacune de façon unique à l'enregistrement d'une seconde association entre une règle de filtrage et l'adresse de contact réseau sur la base des premières associations créées; et à enregistrer la pluralité de secondes associations sur la base de la pluralité d'informations d'enregistrement uniques reçues dans la seconde demande.
PCT/EP2008/050967 2008-01-28 2008-01-28 Procédés, appareils, système et produit programme informatique associé pour ouverture de session WO2009095069A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/EP2008/050967 WO2009095069A1 (fr) 2008-01-28 2008-01-28 Procédés, appareils, système et produit programme informatique associé pour ouverture de session

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2008/050967 WO2009095069A1 (fr) 2008-01-28 2008-01-28 Procédés, appareils, système et produit programme informatique associé pour ouverture de session

Publications (1)

Publication Number Publication Date
WO2009095069A1 true WO2009095069A1 (fr) 2009-08-06

Family

ID=39864932

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2008/050967 WO2009095069A1 (fr) 2008-01-28 2008-01-28 Procédés, appareils, système et produit programme informatique associé pour ouverture de session

Country Status (1)

Country Link
WO (1) WO2009095069A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2504772A1 (fr) * 2009-11-23 2012-10-03 Hewlett-Packard Development Company, L.P. Affectation de ressources dans un environnement informatique partagé

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040230697A1 (en) * 2003-05-13 2004-11-18 Nokia Corporation Registrations in a communication system
US20070081518A1 (en) * 2005-08-10 2007-04-12 Rajnish Jain Open programmable software protocol stack for use with an Internet telephony system
US20070217418A1 (en) * 2006-03-14 2007-09-20 Avaya Technology Llc Contact priority reordering

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040230697A1 (en) * 2003-05-13 2004-11-18 Nokia Corporation Registrations in a communication system
US20070081518A1 (en) * 2005-08-10 2007-04-12 Rajnish Jain Open programmable software protocol stack for use with an Internet telephony system
US20070217418A1 (en) * 2006-03-14 2007-09-20 Avaya Technology Llc Contact priority reordering

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ROSENBERG J ET AL: "SIP: Session Initiation Protocol", 20020601; 20020600, 1 June 2002 (2002-06-01), pages 1 - 269, XP015009039 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2504772A1 (fr) * 2009-11-23 2012-10-03 Hewlett-Packard Development Company, L.P. Affectation de ressources dans un environnement informatique partagé
EP2504772A4 (fr) * 2009-11-23 2013-07-31 Hewlett Packard Development Co Affectation de ressources dans un environnement informatique partagé
US8838800B2 (en) 2009-11-23 2014-09-16 Hewlett-Packard Development Company, L.P. Binding resources in a shared computing environment

Similar Documents

Publication Publication Date Title
US9473403B2 (en) Function mode routing
US8416753B2 (en) System and method for pushing content to a terminal utilizing a network-initiated data service technique
JP5363461B2 (ja) グループ呼機能の問い合わせ
US8195212B2 (en) Push-to-talk optimization
US7697471B2 (en) Address translation in a communication system
US7512118B1 (en) CODEC negotiation considering quality and costs
US8423652B2 (en) Service templates for an IP multimedia subsystem
US20110194554A1 (en) Systems and methods for implementing call pick up using gruu an ims network
US7953123B2 (en) Method and system for controlling the establishment of communications channels for allowing transmission of multimedia information
WO2004086722A1 (fr) Procedes et appareils de demande d'un service au nom d'un tiers
EP1902570B1 (fr) Systeme et procede d'enregistrement combine a l'abonnement dans un environnement de protocole d'ouverture de session (sip)
EP2068524A1 (fr) Procede et systeme d'acquisition du trajet de transmission du message sip
US20070030849A1 (en) Voice over internet protocol (VoIP) terminal and information management method thereof
CN102484641B (zh) 用于选择网络资源的方法
US9762621B2 (en) Call routing for IP multimedia subsystem users
EP1709777B1 (fr) Signalisation de protocole d'ouverture de session
AU2001272428B2 (en) Optimal routing when two or more network elements are integrated in one element
WO2009095069A1 (fr) Procédés, appareils, système et produit programme informatique associé pour ouverture de session
AU2001272428A1 (en) Optimal routing when two or more network elements are integrated in one element
JP5226798B2 (ja) イベントパケット処理の方法
Nurmela Session initiation protocol
EP2745486B1 (fr) Suppression d'appel de service camel des utilisateurs redirigés
KR100636279B1 (ko) 브이오아이피 시스템의 자원정보를 이용한 호제어 시스템및 그 방법

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: 08708285

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08708285

Country of ref document: EP

Kind code of ref document: A1