Patent Description:
The embodiments described below are not limited to implementations which solve any or all of the disadvantages of known session border controllers.

<CIT> describes a network node comprising a core processing part to perform a core processing function, an ingress processing part to receive incoming signaling messages, an egress processing part to output signaling messages for transmission from the network node, and a message manipulation function to manipulate signaling messages. In a first configuration, the message manipulation function is comprised in the ingress processing part, and in a second configuration the message manipulation function is comprised in the egress processing part. In the first configuration, an egress characteristic is determined, indicative of how an outgoing signaling message is to be outputted, and an incoming signaling message is manipulated based on the egress characteristic. In the second configuration, an ingress characteristic is determined, indicative of how an incoming signaling message has been received, and an outgoing signaling message is manipulated based on the ingress characteristic.

<CIT> describes systems, methods, and computer program products for modifying a Session Initiation Protocol (SIP) messages. The method includes providing a scripting-type computer programming language that includes contexts that reference pre-defined portions of data of a SIP message and variables that store data associated with a SIP message flow. An interface for configuring rules to be executed when processing SIP messages is provided. Each rule includes an action that describes a modification to be made to a particular SIP message. When a SIP message is received, it is parsed to determine at least a context of a portion of the message. The parsing includes associating the portion of the message with a particular context. It is then determined whether a rule should be applied to the data associated referenced by the contexts, and if so, the SIP message is modified based on the actions associated with the rule. <CIT> describes systems, apparatus and methods for the computation and use of session, device and/or user signatures for determining communications session types, device types, and/or user signatures. An exemplary system in accordance with an embodiment of the invention includes: a first device, the first device including: a receiver that receives a first set of session control messages belonging to a first communications session, said first set of session control messages including at least one session control message; a feature extractor that extracts a first set of device features from the first set of session control messages; and a first neural network that determines a device signature from the first set of session control messages based on said set of device features.

The following presents a simplified summary of the disclosure in order to provide a basic understanding to the reader. This summary is not intended to identify key features or essential features of the claimed subject matter nor is it intended to be used to limit the scope of the claimed subject matter. Its sole purpose is to present a selection of concepts disclosed herein in a simplified form as a prelude to the more detailed description that is presented later.

In various examples there is a session border controller which has a processor operable to receive a message from a connected peer node. The processor inputs the message to a Message Manipulation Function, MMF, which identifies the message as a SIP message, and in response obtains external state data associated with the message from a source independent from the message. The external state data is provided to the MMF. The SIP message is modified using the MMF according to one or more conditions or rules associated with the received external state data; and the modified message is output.

The detailed description provided below in connection with the appended drawings is intended as a description of the present examples and is not intended to represent the only forms in which the present examples are constructed or utilized. The description sets forth the functions of the examples and the sequence of operations for constructing and operating the examples. However, the same or equivalent functions and sequences may be accomplished by different examples.

SBCs are network elements at a point of demarcation between different parts of a communications network, such as a firewall between an intranet of an enterprise and the public Internet, or a filtering router between regions of a communications network having different security provisions. Sessions between parties in the different regions of the communications network traverse the SBC and the SBC is able to influence packets in those sessions for various purposes such as security, connectivity, quality of service, emergency call prioritization, media services and more. An SBC is typically inserted into a media or signaling path between endpoints in a VoIP call. The inventors have recognized that extending the functionality of an SBC is beneficial as described in more detail below.

In various examples an SBC has a component comprising message manipulation function. Message manipulation function MMF is a programming language that is used to carry out detailed manipulation of protocol messages. For example, an MMF component can be configured on a SIP network device to add, remove, or alter a SIP request line, header, or SIP message body. A programmer is able to create code using MMF and deploy that on an SBC in order to solve unanticipated problems quickly.

The inventor has recognized that a component comprising MMF within an SBC is generally limited in functionality. A programmer is able to create code using MMF such as by writing rules or conditions for identifying particular packets and treating them in a way specified in the rule. Functionality is limited since the MMF only has access to internal state data. The term "internal state" is used to refer to data available in messages within a SIP session traversing an SBC. Since this type of data is available within the SBC it is referred to as internal state data.

<FIG> is a schematic diagram of an apparatus allowing for greater flexibility in the state that an MMF component is configured to access. There is shown in <FIG> a first network arrangement <NUM>. The first network arrangement <NUM> comprises a Session Border Controller (SBC) <NUM> comprising a message manipulation function MMF <NUM> as well as external state data <NUM>. The term "external state data" is explained in detail below. The SBC is connected between a first peer node P1 and a second peer node P2. In an example, P1 is in a first network region and P2 is in a separate network region so that the SBC demarks the first and second network regions. Peer node P1 is part of a larger communications network which is not shown in <FIG>. Likewise, P2 is part of a larger communications network which is not shown in <FIG>. In an example, there is a communication session ongoing between an endpoint in P1's network and an endpoint in P2's network and which traverses the SBC. P1 and P2 are any type of communications network node such as a router, switch or other communications network node.

The MMF <NUM> is able to carry out detailed manipulation of the contents of a protocol message <NUM> received from a first peer node, P1, <NUM> on the basis of external state data <NUM> and optionally also internal state data. The term "external state data" refers to data which is logically independent from the contents and networking properties of a particular message.

The first peer node P1 <NUM> transmits the message <NUM> to the SBC <NUM> which processes the message with the MMF <NUM>. Having received the message <NUM>, the MMF <NUM> identifies the message as a SIP message, and in response to this verification, modifies the message according to one or more conditions or rules associated with one or more items of external state data <NUM>, optionally alongside one or more items of internal state data extracted from or relating to the message <NUM> itself. The MMF <NUM> is hence provided with external state data <NUM> in addition to internal state data.

The external state data <NUM> is available at the SBC in some cases such as where the SBC already has data which is logically independent from the contents and networking properties of a particular message. In other cases, the SBC has to actively obtain the external state data <NUM> by sending a query or request message to one or more remote entities such as management nodes, routers, switches or other nodes in the network of P1 and/or the network of P2. The requests are either sent "on the fly" when the external state data is needed by the MMF, or are sent on a regular basis in order to populate a store at the SBC. In some cases, the SBC receives the external state data from other nodes which send that data when it becomes available or is updated. The SBC then stores the external state data it receives in a store at the SBC for later use by the MMF.

Where the MMF uses only internal state data, it is used as a basic message manipulation function, and data used in such a manipulation is derived from the received message <NUM>. Standard MMF syntax gives operators access to variables, which they can then use both to test conditions, to set message values, and other similar purposes. For example, in an SIP MMF syntax, an example rule is:
IF (msg. request_uri. value == '<NUM>'):
SET msg. p_asserted_id. value = msg.

This rule sets the value of the SIP P-Asserted-Identity header to be whatever the value of the "SIP From header" currently is, if the Request Uniform Resource identifier (URI) is "<NUM>". This uses the values of particular SIP headers as variables, both for purposes of testing a condition, and setting a value.

Variables are drawn from one or more of the following sources: the contents of the message (e.g. the value of a particular header); networking properties of the message (e.g. the IP address to which the message is being sent); logical inferences from the above (e.g. msg. is_behind_nat might be False if the Via header matches the networking IP address, and True otherwise); and/or user-created variables derived from the above (whether stored for the lifetime of a message, a dialog, or a transaction).

However, a networking device, such as P1 <NUM>, has access to much more information that pertains to a particular message, but which is logically independent from the contents and networking properties of a particular message. This is particularly likely for devices dealing in stateful protocols such as SIP. This state may correspond to the interaction of the message with an external device configuration, the state of a transaction associated with the message, the state of networking devices associated with the message, or other similar state. It may also include combinations of the above. An external device configuration includes any device configuration other than MMF.

In various embodiments, specialized MMF syntax is used give access to the external state of P1 <NUM> pertaining to the message. This provides an advantage by allowing the MMF to use and make decisions based on external state data related to the processing of the message flows, and/or related calls, that has not conventionally been considered part of the scope of MMF. This allows for much richer processing.

In one example, an SBC might obtain external state data corresponding to one or more of: whether the call on which the message was received is carrying out transcoding, whether the message has triggered a ban listing rule, whether the call on which the message was received is currently ringing, and/or whether the message originates from a registered subscriber.

Such external state may be useful in crafting MMF rules. For example, it allows an operator to apply different MMF on messages from registered subscribers compared to messages not from registered subscribers.

Using the external state, the SBC implements one or more of the abovementioned rules to yield an output message. The output message, which is a modified version of the received message <NUM>, is then forwarded to P2 as part of the ongoing session traversing P1, the SBC and P2.

In one example, a message received on a SIP call can have MMF syntax applied on that message which includes use of the device's external state for the call, such as whether the call is from a registered subscriber. The state made available to the MMF for such use may be all external states, or a subset thereof.

For example, an SBC vendor might wish to restrict the external state available to the MMF to only be a subset of state. This might be because one or more of the external states is proprietary, technically unstable, etc. A network operator might wish to restrict the external state available to particular users configuring the device. For example, some users are not authorized to access whether a particular call is subject to Lawful Intercept.

The external state may be made available for testing conditions, for setting message values, or even for being changed.

For example, if testing conditions, considering whether a message is from a registered subscriber, and if it is, do "X". Otherwise, do "Y". In a further example, when the external state is used for setting message values, the message's SIP Contact header can be set to the IP address of the registered subscriber it comes from. In a further example, when the external state is used for changing external values, the IP address of the registered subscriber associated with this message can be set to be the IP address in the SIP Contact header.

Different subsets of state may be made available for the abovementioned purposes.

Different subsets of state may be available to different tiers of users. For example, in one implementation, most external states will only be available to classes of super-users so that approved users can write MMF rules solving customer problems, but customers themselves cannot set rules which might negatively impact performance.

The disclosure herein may allow more problems to be solved purely via MMF, rather than necessitating feature development, by allowing richer MMF rules to be written. For example, a network operator might wish to configure different session description protocol (SDP) manipulation depending on whether the call is using transcoding, or not.

The or each embodiment as disclosed herein may be used individually or in combination with other MMF features, including allowing the outputs of one set of MMF to be inputs for another. For example, one embodiment requires complex behavior on emergency calls from unregistered endpoints. This required significant time and complexity to be produced. However, with an appropriate combination of MMF features, it was entirely delivered via MMF. This allows feature delivery in a far cheaper and more agile manner.

The ability to use external state within the MMF improves the functioning of the underlying SBC. The functioning of the SBC is improved since in response to identifying the message as a SIP message, external state data associated with the message from a source independent from the message is provided to the MMF. The MMF is able to modify the message according to one or more conditions or rules associated with the received external state data; and output the modified message.

In <FIG>, there is shown schematic diagram of the apparatus of <FIG> in electronic communication with further apparatus, referred to collectively a second network arrangement <NUM>. This second network arrangement <NUM> comprises the network of the first network arrangement <NUM> as well as some further apparatus used to enhance the function of the arrangement.

This further apparatus includes an interface <NUM>, shown in electronic communication with the SBC <NUM>. This interface <NUM> is used to implement any of the permission-based controls outlined above. The interface <NUM> comprises one or more rules which check login details of users and records of what permissions different users are entitled to. The interface is either part of the SBC <NUM> or is a separate component connected to the SBC.

The SBC <NUM> of this embodiment is also in electronic communication with a second peer node, P2 <NUM>. Similarly to P1 <NUM>, P2 <NUM> is operable to transmit a message <NUM> to the SBC <NUM>. This message <NUM> can be modified by the SBC <NUM> in a similar manner to that of the message <NUM> from P1 <NUM>, according to one or more conditions or rules associated with one or more items of external state data <NUM>. It is understood that one or more further peer nodes P3-PX etc. can be connected to the SBC <NUM>.

The SBC <NUM> is also be connected to a distributed access manager (DAM) <NUM>. The role of the DAM <NUM> is to provide a connection between a first SBC <NUM> and one or more further SBCs <NUM>', <NUM>", etc. In such a way, the functionality of one or more of the SBCs <NUM>, <NUM>', <NUM>" is enhanced. For example, the capacity requirements of each node P1 <NUM>, P2 <NUM> etc. are considered and a message from the one or more nodes is rejected if capacity is at risk of being exceeded. Further, data relevant to one or more of the received messages may only be found within a separate SBC. For example, data relevant to the peer node P1 <NUM> and the received message <NUM> may be found by SBC <NUM>'. In such a case, the relevant data is transmitted from SBC <NUM>' to SBC <NUM> so that it is used by the MMF <NUM> to modify the output message <NUM>.

<FIG> illustrates a telephony-specific arrangement for message manipulation, referred to as a third network arrangement <NUM>. In this third network arrangement <NUM>, the MMF is divided into two parts and is distinct from the SBC processing unit <NUM>. In this embodiment, a received message <NUM> is transmitted from a first device <NUM> such as user equipment. The received message <NUM> is transmitted to an ingress MMF <NUM> which at least partially rewrites the inbound received message <NUM>. The SBC processing unit <NUM> then processes the message as though it had received the message straight from the first device <NUM>. Once processed by the SBC processing unit <NUM>, the message is passed to the egress MMF <NUM>, which then further processes the message according to one or more rules into an output message <NUM>. The output message <NUM> is then transmitted to a second device <NUM> such as a user equipment.

Ingress MMF <NUM> rules are configured for received messages, or for a subset of received messages, based on the contents of the message and the way in which it was received (e.g. the IP address/port it was received on, the IP address/port it was received from, etc). Similarly, egress MMF <NUM> rules are configured for messages or for a subset thereof, based on the contents of the message and the way in which it is to be sent.

<FIG> is a flow diagram of a method for message manipulation using an MMF. In an example the method of <FIG> is performed by an SBC. In this embodiment, a message is received in step <NUM> from a connected peer node. The message is then input in step <NUM> to a Message Manipulation Function, MMF, which identifies the message as a SIP message. In response, the MMF also receives external state data associated with the message from a source independent from the message in step <NUM>. Using the received external state data associated with the message from a source independent from the message, step <NUM> modifies the message using the MMF. The modified message is then output in step <NUM>, optionally to the connected peer node.

Any computer executable instructions required to perform the method or provide the SBC as disclosed herein may be provided using any computer-readable media that is accessible by a computing based device. Computer-readable media includes, for example, computer storage media such as memory and communications media. Computer storage media, such as memory, includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or the like. Computer storage media includes, but is not limited to, random access memory (RAM), read only memory (ROM), erasable programmable read only memory (EPROM), electronic erasable programmable read only memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that is used to store information for access by a computing device.

A further implementation relates to a method for modifying a Session Initiation Protocol (SIP) message by a Message Manipulation Function (MMF) component executing on a computing device, the MMF component configured to identify SIP messages and update the messages based on one or more conditions or rules, method comprising: receiving a SIP message from a connected peer node; accessing external state data associated with the SIP message from a source that is external to the SIP message, wherein the external state data cannot be logically derived from contents and networking properties of the SIP message; modifying the SIP message using the external state data; and outputting the modified SIP message.

Claim 1:
A session border controller (<NUM>) for modifying a Session Initiation Protocol, SIP, message, comprising:
a processor operable to:
receive a message from a connected peer node (<NUM>);
input the message to a Message Manipulation Function, MMF (<NUM>);
identify the message as a SIP message;
in response to identifying the message as a SIP message, receive external state data associated with the message from a source independent from the message and provide the external state data to the MMF (<NUM>);
modify the message using the MMF(<NUM>) according to one or more conditions or rules associated with the received external state data; and
output the modified message.