WO2009095069A1

WO2009095069A1 - Methods, apparatuses, system, and related computer program product for session initiation

Info

Publication number: WO2009095069A1
Application number: PCT/EP2008/050967
Authority: WO
Inventors: Changpeng Fan; Carmelita GÖRG; Frank Pittmann; Umar Toseef; Asanga Udugama
Original assignee: Nokia Siemens Networks Oy
Current assignee: Nokia Solutions and Networks Oy
Priority date: 2008-01-28
Filing date: 2008-01-28
Publication date: 2009-08-06
Anticipated expiration: 2010-07-28

Abstract

It is disclosed 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.

Description

TITLE OF THE INVENTION

METHODS, APPARATUSES, SYSTEM, AND RELATED COMPUTER PROGRAM PRODUCT FOR SESSION INITIATION

FIELD OF THE INVENTION

[0001] 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).

BACKGROUND

[0002] 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.

[0003] With reference to Figs. IA and IB, a brief introduction may be presented about SIP and flow management .

[0004] SIP (Session Initiation Protocol)

[0005] For descriptive purposes, SIP is described in the following, to which protocol, however, the present invention is not to be restricted to.

[0006] 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 .

[0007] SIP running entities are called UA (user agents). Typically, there are two types of user agent i.e. UAC (user agent client) and 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. There are three types of SIP servers, that enumeration not being exhaustive.

1. 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.

2. 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. 3. 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.

[0008] It is to be noted that all these servers are just logical and may be implemented in a single entity.

[0009] Fig. IA shows a typical example of a SIP message exchange between two user equipments UE 101 and UE 103. In the following, the user of UE 101 is referred to as "Alice", while the user of UE 103 is referred to as "Bob". In this example, 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. Also shown are 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. In this example case, 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" .

[0010] In 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.

[0011] In step S2, 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.

[0012] In 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.

[0013] In 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.

[0014] In step S5, Alice's UE 101 (e.g. a soft-phone) may send an ACK message to confirm the setup of the call.

[0015] Then, in step S6, once the connection has been setup, 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 .

[0016] In 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. IN step S8, the other party

(Alice in this case) may send an OK message to confirm the termination of the session.

[0017] FLOW MANAGEMENT

[0018] The term Flow Management (FM) is usually used in a wide sense, e.g. flow management within a network, between networks or even within a router. However, for this description, work flow management implies how a stream of data packets is directed through a certain path towards its destination. When a node connects to a network which is a part of the Internet (e.g. a computer connected to its 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. Similarly, 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. But for a node that is connected to the Internet through two or more access technologies/networks (e.g. WLAN and Ethernet) and is to make use of both access networks, 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. In other words, 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.

[0019] 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 .

[0020] A UE 101 (e.g. SIP UAC) is always required to register its current location with its registrar server which is usually located in the home domain network of the 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:

REGISTER sipiregistrar .biloxi .com SIP/2.0

Via: SIP/2.0/UDP bobspc.biloxi.com: 5060; branch z9hG4bKnashds7

Max-Forwards: 70

To: Bob <sip :bob@biloxi . com>

From: Bob <sip :bob@biloxi . com>; tag=456248

Call-ID: 8438176376842300998sdasdhO 9

CSeq: 1826 REGISTER

Contact: <sip :bob@192.0.2.4> Expires: 7200 Content-Length: 0

[0021] 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.

[0022] After the successful binding registration, when proxy server receives a SIP INVITE request e.g. for UE 101 ("sip :bob@biloxi . com") , then the 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. In this particular case, sip :bob@192.0.2.4 may be the only contact address at which INVITE request can be forwarded.

[0023] SIP also allows a UE 101 to register multiple contact addresses against one single address-of-record URI. For example, the following SIP register request creates two bindings for sip :bob@biloxi . com:

REGISTER sip:registrar. biloxi. com SIP/2.0

Via: SIP/2.0/UDP bobspc.biloxi.com: 5060; branch z9hG4bKnashds7

Max-Forwards: 70

To: Bob <sip :bob@biloxi . com>

From: Bob <sip :bob@biloxi . com>; tag=456248

Call-ID: 843817637684230Θ 998sdasdhO 9

CSeq: 1826 REGISTER

Contact: <sip :bob@192.0.2.4>; q=0.1; expires=7200,

<sip:bob@192.1.2.4>; q=0.2; expires=9600 Content-Length: 0 [0024] Each binding may have its own contact address, priority (represented by "q" field) and lifetime

(represented by "expires" field) . Now, the proxy server

2021 ("sip :bob@biloxi . com") of UE 101, on receiving e.g. a SIP INVITE request for the UE' s address-of-record URI, the proxy server may forward that request to the binding address with the highest priority.

[0025] In this way, although SIP allows to register multiple bindings for a single address-of-record URI, all SIP requests are forwarded to a single binding contact address (e.g. one with the highest priority), while other bindings are used a backup links and can be used to recover from the loss of Internet connectivity.

[0026] Consequently, a drawback resides in the fact that the SIP protocol allows a sip user to register multiple bindings, but it is not possible for the user to use all of these bindings for traffic reception/transmission. Instead, only one single binding with the highest priority is used to connect the user. Due to this limitation, a user or UE cannot take full advantage of bandwidth resources available to the UE in the form of multiple connections to the Internet. It is also not possible for him to perform load-balancing of his traffic over the available connections to the Internet.

[0027] 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.

[0028] Approaches related to session initiation have been perceived.

[0029] In the SIP protocol, the only possible way to use more than one binding simultaneously can be if a user, after setting up one session over one of his bindings, changes the priority of that binding so that next session invitation request may be forwarded to him over another binding. However this solution has following drawback.

• 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 .

• The user cannot assign a session to a certain connection according its QoS requirements. Instead, this assignment may always be assigned to the current highest-priority connection and thus, there can be a QoS mismatch.

• The user cannot stop the unwanted or low priority session invitation requests when available bandwidth resources become scarce.

• 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.

[0030] 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.

[0031] In consideration of the above, it is an object of the present invention to overcome one or more of the above drawbacks. In particular, the present invention provides methods, apparatuses, a system and a related computer program product for session initiation.

[0032] According to the present invention, in a first aspect, 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.

[0033] According to further refinements of the invention as defined under the above first aspect, 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.

[0034] According to the present invention, in a second aspect, 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.

[0035] According to further refinements of the invention as defined under the above second aspect,

- 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;

[0036] According to further refinements of the invention as defined under the above first and second aspects,

- 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, and 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, and the second association is a flow binding;

- the third request is a session initiation protocol invite message. [0037] According to the present invention, in a third aspect, 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.

[0038] According to further refinements of the invention as defined under the above third aspect,

- 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, and 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.

[0039] According to the present invention, in a fourth aspect, 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.

[0040] According to further refinements of the invention as defined under the above fourth aspect, 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.

[0041] According to further refinements of the invention as defined under the above third and fourth aspects,

- the third request is a session initiation protocol invite message;

- the apparatus is implemented as a chipset or module.

[0042] According to the present invention, in a fifth aspect, 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 .

[0043] According to the present invention, in a sixth 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.

[0044] In this connection, it has to be pointed out that the present invention enables one or more of the following :

- Efficiently using multiple flows by using multiple wireless and wired interfaces simultaneously;

Distributing active flows across the available interfaces;

Seamless transfer of the flows between the interfaces in mid-session without interruption;

Flow management for a SIP user who has multiple connections to the Internet;

Using all connections for sessions, but also controlling the type of sessions the user wants to initiate over a certain connection;

- Providing flow granularity handling.

BRIEF DESCRIPTION OF THE DRAWINGS

[0045] Embodiments of the present invention are described herein below with reference to the accompanying drawings, in which:

[0046] 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) .

[0048] Fig. 2 shows respective methods for session initiation according to the present invention;

[0049] Fig. 3 shows respective apparatuses (e.g. UE and proxy/registrar server) for session initiation according to the present invention;

[0050] Fig. 4 shows an example of an extended REGISTER message to transport flow bindings according to the present invention;

[0051] Fig. 5 shows an example REGISTER request and response e.g. of a "fetchAll" flow binding message according to the present invention;

[0052] Fig. 6 shows an example of splitting e.g. an INVITE request according to the present invention; and

[0053] Fig. 7 shows a flow management scenario for a SIP user as an example scenario according to the present invention .

DETAILED DESCRIPTION OF EMBODIMENTS OF THE PRESENT INVENTION

[0054] The embodiments of the present invention are described herein below by way of example with reference to the accompanying drawings .

[0055] It is to be noted that for this description, the terms "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.

[0056] It is further to be noted that for this description, the session initiation protocol is used for descriptive purposes. The present invention, however, is not limited thereto, and any protocol following the same or similar principles as SIP may be applied.

[0057] 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 .

[0058] As shown in Fig. 2, 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 .

[0059] In 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;

[0060] In 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.

[0061] In 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.

[0062] In 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. In step S2-3, e.g. the UE 201 may perform receiving the first confirmation message.

[0063] In 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).

[0064] In 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.

[0065] In 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) .

[0066] According to further refinements of the method relating to the proxy/registrar server 2022/2023 according to the first embodiment of the present invention, 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. Furthermore, 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) . In addition, 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 .

[0067] According to further refinements of the method relating to the UE 201, 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.

[0068] In addition or as a supplement to all above- defined items, 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), and the first association may be a binding. Furthermore, 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, and the second association may be a flow binding. Finally, the third request may be a session initiation protocol invite message.

[0069] Fig. 3 shows respective apparatuses (e.g. proxy/registrar server 2022/2023 and/or UE 201) for session initiation according to the present invention. Within 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.

[0070] 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.

[0071] 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. 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. As indicated by the dashed extensions of the functional blocks of the CPUs 2011 and 20221; 20231, 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. Furthermore, all the means 20225 to 20229 are interchangeably disposable between the proxy server 2022 and the registrar server 2023, in case the server 2022 and the registrar server 2023 are disposed as separate entities or as a single/combined entity. [0072] The CPUs 20x1 (wherein x = 1, 22, and 23) 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. It is to be noted that the senders 20x3 and the receivers 20x4 may alternatively be provided as respective integral transceivers (not shown) . It is further to be noted that 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. between the proxy server 2022 and the registrar server 2023 when disposed as separate network entities) , or 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) , or iv) as any suitable combination of i) to iii) .

[0073] Furthermore, as indicated by the dashed connections between the functional blocks of the proxy server 2022 and the registrar server 2023, it is to be noted that the proxy server 2022 and the registrar server 2023 may also be implemented as an integral/combined entity, as mentioned above. In that case, 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.

[0074] For example, e.g. 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.

[0075] Then, e.g. 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.

[0076] Thus, e.g. 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) .

[0077] Then, e.g. 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.

[0078] For example, 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).

[0079] Then, e.g. 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.

[0080] And, e.g. 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) .

[0081] According to further refinements of the proxy/registrar server 2022/2023 according to the present invention, 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. Furthermore, e.g. 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. Furthermore, 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. In addition, there may also be comprised 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) . Moreover, 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 .

[0082] According to further refinements of the UE 201 according to the present invention, 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.

[0083] In addition or as a supplement to all above- defined items, 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), and the first association may be a binding. Furthermore, 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, and the second association may be a flow binding. Finally, the third request may be a session initiation protocol invite message.

[0084] In the following, the present invention is described as an extension to the SIP in order to incorporate flow management functionality. However, the present invention is not limited thereto, and any protocol following the same or similar principles as SIP may be applied. It is to be noted that in the following, user "Bob" is occasionally used also for referring to the first UE 201 directly, while user "Alice" is occasionally used also for referring to the external client 203 directly.

[0085] TERMINOLOGY

[0086] The following terms are defined in this document: Binding - An association of an address-of-record URI with a contact address.

Flow binding - An association of a filter rule with a contact address.

[0087] SIP EXTENSIONS

[0088] This section introduces the extensions to SIP protocol that are needed to support flow management functionality according to the present invention. [0089] Contact Header Extension

[0090] As shown in Fig. 4, according to the present invention, 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.

[0091] REGISTER Message Extension

[0092] In the SIP protocol, REGISTER message requests add, remove, and query bindings. According to the present invention, 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.

[0093] Flow Binding

[0094] A flow binding may be completely described using the SDP syntax of <type>=<value> . When flow binding description is conveyed by REGISTER message body, many flow binding descriptions may be concatenated together

(the ^Λv=' line indicating the start of a flow binding description terminating the previous description) . A flow binding therefore may consist of following four parts

(while flow acknowledgement message always consists of first three parts) [0095] i) The first part is just the indication of beginning of a flow binding. It occupies only a single line that starts with ^Λv=' . All flow bindings may have this part.

[0096] ii) In case of flow binding request, the second part indicates the processing requested by this flow binding e.g. adding, removing or modifying of this flow binding. It occupies a single line which starts with ^Λa=sfbCmd:'. Possible values for the ^ΛsfbCmd' attribute with their details are given in the following: add - add or register this new flow binding. remove - delete the flow binding with ^Λbid' number mentioned in ^ΛsfbHeader' attribute. UAC may not issue a remove request for nonexistent flow binding. replace - overwrite the existing flow binding, with "fid" mentioned in "sfbHeader" attribute of this flow binding, with contents of this flow binding. UAC may not issue a replace request for nonexistent flow binding. flushAll - This value may be followed by one of the following arguments:

* - It indicates that all flow bindings may be flushed. <q> - It indicates that all of the flow bindings with priority equal to <q> may be removed.

<bid> - It indicates that all of the flow bindings with "bid" equal to <bid> may be flushed. fetchAll — This value indicates that sender wants a complete list of active flow bindings in response message of this request.

[0097] In case of flow binding acknowledgement, the second part may indicate the status of the request operation in the corresponding flow binding. It may start with "a="sfbStatus : " and may be followed by one of the following values - 200 OK - Flow binding processed successfully

- 401 Unauthorized to send flow binding

- 440 Rejected, reason unspecified

- 441 Flow binding poorly formed

- 442 "fid" already in use

- 443 "fid" not found

- 444 drop function is not supported

The codes from 440 to 444 are newly proposed by the present invention.

[0098] iii) The third part may indicate the essential information about the filter rule included in this flow binding. It may start with "a=sfbHeader : " and may have following four values in the given order

<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. <bid> - identification number ("bid") of the binding to which this flow binding is associated.

<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 .

[0099] iv) 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 describe a session in the same way as is mentioned in SDP. However, it is possible to use wildcard character (*) as value to indicate that this part of value will not be considered while performing filter rule match with a session description parameters e.g. m=video * RTP/AVP * may indicate that a video session with RTP/AVP protocol may be matched without concerning the port number and format options. It is also not necessary to include all possible session description parameters while defining a filter rule. Instead, only those parameters that are needed to be matched may be listed. The following table lists the available parameters:

[0100] Table 1: Possible parameters from SDP specification

R <repeat interval> <active duration> <offset>

The parts of a value marked with ⁺ are optional where wildcard (*) can be used as a value. Moreover a filter rule may not have more than one media descriptions.

[0101] Protocol Operation

[0102] This section details the important aspects of proposed flow management functionality as an extension to the SIP protocol.

^0103] Flow Binding Registration [0104] 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.

[0105] Adding a Flow Binding

[0106] When adding a flow binding, 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. In other words, 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. In "sfbHeader" attribute values <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> and <action> may also be given proper values as specified above.

[0107] 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.

[0108] Modifying a Flow Binding [0109] When modifying a flow binding (either "bid" or other parameters of session description) , 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. Hence, 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.

[0110] Removing a Flow Binding

[0111] When removing a flow binding, e.g. 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. And "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.

[0112] Flushing Flow Bindings

[0113] When flushing multiple flow bindings, 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.

[0114] Refreshing a Flow Binding

[0115] 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.

[0116] Acknowledging a Flow Binding

[0117] A registrar server may be required to acknowledge each flow binding received. According to the present invention, 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.

[0118] Fetching Flow Bindings

[0119] As shown in Fig. 5, when fetching flow bindings, 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.

[0120] If registrar encounters any failure during the processing of this request, only the status may be sent back and no flow binding list will be included.

[0121] Adding, Refreshing, Removing and Fetching Bindings

[0122] According to the present invention, a restriction may be imposed that each binding may have its unique "bid" number that may always be included by sender whenever adding, refreshing, removing and fetching bindings .

[0123] Session Requests with Multiple Media Descriptions

[0124] As shown in Fig. 6, if e.g. 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. In this case, each split request will be sharing the same session level description as it was in the original INVITE request. In each split request, only one media description may be kept and others may be given port number as zero. [0125] When 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, therefore, 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.

[0126] A Working Example

[0127] In the following, a use case according to the present invention is described. However, the detail level in the following only serves for illustration, not for limitation of the present invention.

[0128] As shown in Fig. 7, for example, 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) 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. For this purpose, 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:

REGISTER sip:registrar. biloxi.com SIP/2.0

Via: SIP/2. O/UDP bobspc.biloxi.com:5060 ;branch⁼z9hG4bKnashds7

Max-Forwards: 70

To: Bob <sip :bob@biloxi . com>

From: Bob <sip :bob@biloxi . com>; tag=456248

Call-ID: 843817637684230Θ 998sdasdhO 9

CSeq: 1826 REGISTER

Contact :

<sip:bob@134.104.144.14>; q=0.4; expires=4400 ; bid=44,

<sip:bob@132.102.122.12>; q=0.2; expires=2200 ; bid=22

Content-Length: 0

[0129] 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:

SIP/2.0 200 OK

Via: SIP/2. O/UDP bobspc .biloxi . com: 5060 ; branch=z9hG4bKnashds7; received=134.104.144.14.144

Max-Forwards: 70

To: Bob <sip:bob@biloxi.com>; tag=2493k59kd

From: Bob <sip :bob@biloxi . com>; tag=456248

Call-ID: 843817637684230@998sdasdh09

CSeq: 1826 REGISTER

Contact :

<sip:bob@134.104.144.14>; q=0.4; expires=4400 ; bid=44,

<sip:bob@132.102.122.12>; q=0.2; expires=2200 ; bid=22

Content-Length: 0 [0130] Just after receiving the above success response from the registrar server 2023, Bob may want to make use of the flow management functionality and decide to receive VoIP sessions from WLAN network (e.g. at contact address "sip :bob@134.104.144.14" with bid=44) and data sessions from Ethernet network (e.g. at contact address "sip:bob@132.102.122.12" with bid=22). To achieve this, Bob's UE 201 may build two flow bindings: i) For contact address "sip :bob@134.104.144.14" and bid=44, Bob's UE 201 may build a flow binding with fid 444, priority 0.1 and a filter rule to accept audio sessions . ii) For contact address "sip :bob@132.102.122.12" and bid=22, Bob's UE 201 may build a flow binding with fid 222, priority 0.1 and a filter rule to accept data sessions .

[0131] 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:

REGISTER sip:registrar. biloxi.com SIP/2.0

Via: SIP/2.0/UDP bobspc .biloxi . com: 5060 ,-branch = z9hG4bKnashds7

Max-Forwards: 70

To: Bob <sip :bob@biloxi . com>

From: Bob <sip :bob@biloxi . com>; tag=456248

Call-ID: 8438176376842300998sdasdhO 9

CSeq: 1827 REGISTER

Content-Length: 127

Content-Type: application/sdp

v=0 a=sfbCmd: add a=sfbHeader: 444 44 0.1 forward m=audio * RTP/AVP * v=0 a=sfbCmd: add a=sfbHeader: 222 22 0.1 forward m=data * TCP *

[0132] 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. Note that above request did not have any "Contact" header, but 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:

SIP/2.0 200 OK

Via: SIP/2.0/UDP bobspc .biloxi . com: 5060 ; branch=z9hG4bKnashds7; received=134.104.144.14.144

Max-Forwards: 70

To: Bob <sip:bob@biloxi.com>; tag=2493k59kd

From: Bob <sip :bob@biloxi . com>; tag=456248

Call-ID: 8438176376842300998sdasdhO 9

CSeq: 1827 REGISTER

Contact :

<sip:bob@134.104.144.14>; q=0.4; expires=4400 ; bid=44,

<sip:bob@132.102.122.12>; q=0.2; expires=2200 ; bid=22

Content-Length: 103

Content-Type: application/sdp

v=0 a=sfbStatus: 200 OK a=sfbHeader: 444 44 0.1 forward v=0 a=sfbStatus: 200 OK a=sfbHeader: 222 22 0.1 forward

[0133] Bob's UE 201 may, on receiving this response message, hold information that both of the flow bindings have been added successfully.

[0134] For example, in a few seconds, 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:

INVITE sip:bob@biloxi.com SIP/2.0

Via: SIP/2.0/UDP pc33.atlanta.com ;branch=z9hG4bKnashds8

Max-Forwards: 70

To: Bob <sip :bob@biloxi . com>

From: Alice <sip : aliceΘatlanta . com>; tag=1928301774

Call-ID: a84b4c76e66710

CSeq: 314159 INVITE

Content-Length: 88

Content-Type: application/sdp

v=0 o=alice 536 2337 IN IP4 h3.atlanta.com

C=IN IP4 h3.atlanta.com m=audio 3456 RTP/AVP 0 1

[0135] 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.

Thus, 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.

[0136] While the audio session is going on, Alice may want to send a data file to Bob and hence may send another INVITE request to Bob's UE 201, i.e. to SIP URI sip :bob@biloxi . com. This request may be again received by Bob's proxy server 2022 (biloxi.com) and have the following form:

INVITE sip:bob@biloxi.com SIP/2.0

Via: SIP/2.0/UDP pc33. atlanta . com;branch=z9hG4bKnashds8

Max-Forwards: 70

To: Bob <sip :bob@biloxi . com>

From: Alice <sip : aliceΘatlanta . com>; tag=1928301774

Call-ID: a84b4c76e22210

CSeq: 314160 INVITE

Content-Length: 85

Content-Type: application/sdp

v=0 o=alice 537 2447 IN IP4 h3.atlanta.com

C=IN IP4 h3.atlanta.com m=data 21 TCP ftp/2.0

[0137] 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.

[0138] This simple example shows how easily and efficiently a sip user can manage its sessions and use all of its contact addresses to have sessions of his choice .

[0139] Without being restricted to the details following in this section, the first and second embodiments of the present invention may be summarized as follows: 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. To achieve this purpose 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. For example if 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. 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.

[0140] According to the present invention, the proxy server 2022, the registrar server 2023 and/or the UE 201 may be implemented as a chipset or module.

[0141] Finally, the present invention also relates to a system which may comprise at least one UE 201 and a proxy/registrar server 2022/2023.

[0142] [Further embodiments]

[0143] For the purpose of the present invention as described herein above, it may be noted that

- 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.;

- generally, 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. 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

(M) IPv4/6, is also applicable;

- a user equipment may be any device, unit or means by which a system user may experience services from an access network;

- method steps likely to be implemented as software code portions and being run using a processor at the network element, are software code independent and can be specified using any known or future developed programming language as long as the functionality defined by the method steps is preserved; generally, any method step is suitable to be implemented as software or by hardware without changing the idea of the present invention in terms of the functionality implemented;

- 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 (e.g. proxy/registrar server, UE) 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.

[0144] LIST OF ABBREVATIONS

ATM Asynchronous Transfer Mode

CN Correspondent Node

EPS Evolved Packet System

FH Fragment Header

FIDF Flow ID Flag

FL Fragment List

FM Flow Management

FN Foreign Network

FR Foreign Router - A l -

FTP File Transfer Protocol

GW Gateway

HA Home Agent

HN Home Network

HR Home Router

ID Identifier

MAP Mobility Anchor point

MEXT Mobility EXTension

MlPvβ Mobile Internet Protocol version 6

MN Mobile Node

MNO Mobile Network Operator

Monamiβ Mobile Nodes and Multiple Interfaces in IPv6

MTU Maximum Transmission Unit

NE Network Entity

PDN Packet Data Network

PPPoE Point-to-Point over Ethernet

UE User Equipment

WG Working Group

Claims

CLAIMS :

1. 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.

2. The method according to claim 1, further comprising: sending a second confirmation message comprising the plurality of unique registration information and confirmation information relating to creation of the plurality of second associations.

3. The method according to claims 1 or 2, further comprising : 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.

4. The method according to claim 3, further comprising: 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.

5. 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.

6. The method according to claim 5, further comprising 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.

7. The method according to any one of the preceding claims, wherein 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, and the first association is a binding.

8. The method according to any one of claims 2 to 7, wherein 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, and the second association is a flow binding.

9. The method according to any one of claims 3 to 7, wherein the third request is a session initiation protocol invite message.

10. 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.

11. The apparatus according to claim 10, wherein: 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.

12. The apparatus according to claims 10 or 11, wherein: the means for receiving are configured to receive at least one third request comprising one or more network resource requirements; the apparatus further comprising: 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.

13. The apparatus according to claim 12, further comprising : 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.

14. 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.

15. The apparatus according to claim 14, wherein 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 .

16. The apparatus according to any one of claims 10 to

15, wherein 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, and the first association is a binding.

17. The apparatus according to any one of claims 11 to

16, wherein 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, and the second association is a flow binding.

18. The apparatus according to any one of claims 12 to

17, wherein the third request is a session initiation protocol invite message.

19. The apparatus according to any one of claims 10 to 13, and 16 to 18 when dependent on claim 10, wherein the apparatus is constituted by at least one of a proxy server and a registrar server.

20. The apparatus according to claims 14 or 15, and claims 16 to 18 when dependent on claim 14, wherein the apparatus is constituted by a user equipment.

21. The apparatus according to any one of claims 10 to 20, wherein the apparatus is implemented as a chipset or module .

22. A system, comprising: an apparatus according to claim 10; and at least one apparatus according to claim 14.

23. A computer program product comprising code means for performing method steps of a method according to any one of the claims 1 to 9, when run on a computer.