Patent Application
20100131621
For reasons of security, QoS control, NAPT (Network Address and/or Port number) traversal, etc. many VoIP and IP multimedia service providers are starting to require session controller nodes to be placed at the border between their VoIP/IP Multimedia core network and 1) an access network for residential and enterprise customers, as well as 2) at the network borders towards other service providers VoIP/Multimedia networks.
Session Controller, Session Border Controller, Border Controller, Boundary Traversal Unit, etc.—all are different names assigned by vendors of products belonging to a new category of VoIP and Multimedia related IP-IP gateways. This type of equipment has grown so quickly in popularity that products have reached commercialisation before the industry has agreed on uniform nomenclature. However, the industry now appears to be converging towards the term “Session Controller” for this type of equipment [Ref.1], and this term will be used in the present specification to cover any of the above devices.
Session Controllers are found at crossings between IP networks, where they funnel sessions—signalling together with associated media streams—of real time IP voice, video and other data across the borders between the IP networks, using IP signalling protocols such as H.323, SIP (Session Initiation Protocol), MGCP or Megaco/H.248. The aim of Session Controllers is to manage IP sessions—signalling and media streams together—across the IP network borders in order to ensure Security, Quality of Service, Service Level Agreements, Legal Intercept, NAPT/FW (FireWall) traversal, and other critical functions for IP streams.
With network border is here meant the handoff point of any IP-enabled infrastructure where a session passes from one network (or portion of the network) to another. A border can be defined as the edge of a carrier's network or the demarcation point between an enterprise and its carrier. Some borders may even occur within a single carrier's network, existing between different portions of that network. All session controllers deal with IP traffic crossing borders.
The Session Controller in a SIP network can be said to be logically and/or physically formed by two entities, a signalling proxy (SP), e.g. a SIP B2BUA (Back-to-back User Agent) and a MP (Media Proxy). Parts of the functionality provided by the B2BUA or the MP can be required in multimedia networks even without the presence of a complete session controller.
SIP clients in home and enterprise networks often sit behind a customer premises FW. This poses problems for inbound (to clients) SIP/RTP traffic, since inbound sessions (to clients) will be typically blocked—the FW can only be “opened” by outbound traffic.
One could statically open a wide range of client ports in the firewall to permit traffic from any external host towards internal hosts, but from a security point of view this would not normally be acceptable. Instead, the ports for the right protocols should be opened just when the SIP and pertaining media sessions require it, and closed again when the session terminates.
The situation becomes even more complex when a firewall also performs NAPT, which is used when a network's internal IP addresses cannot be used outside the network either because they are invalid for use outside the network (e.g. private addresses), or because the internal addressing must be hidden from external networks e.g. for security reasons. NAPTs are also used to map a large address space inside a private network to a smaller set of addresses on the outside, and NAPTs are furthermore useful to hide external (ISP) network topology changes. NAPT allows hosts in a private network to transparently communicate with destinations in external networks, and vice versa. In other words, NAPT devices provide or support transparent routing of IP packets between disparate address realms, by modifying address contents in the IP header to be valid in the address realm into which the IP packet is routed.
A problem with a dynamic FW/NAPT is that it sets up address translation bindings when a user (SIP client) starts to send an IP packet towards a public IP address, but a binding is only kept as long as there is a regular flow of IP packets to, or from, the user. If the user is inactive for a while—often in the range of a minute—the NAPT will remove the binding and perform a new binding the next time the user starts to send IP packets. The client will thus not be reachable from the public network domain once the binding has been taken down, and the client address seen from outside will vary over time.
The problem with FW/NAPT traversal is well known and many different solutions exist, using special protocols and NAPT traversal servers such as STUN and TURN. However, having a session controller interfacing the public side of the FW/NAPT makes it possible to solve the FW/NAPT traversal without special protocols such as STUN or TURN and without additional equipment in form of STUN and TURN servers or tunnel clients within the customer premises domain. To handle FW/NAPT in the session path the following is supported.
1 In connection with receiving a REGISTER message from a SIP client, the signalling proxy inspects the source address/port of the IP packet in which the REGISTER message arrived. If this address is not the same as the address in the SIP Contact-header of the REGISTER message, then there is a NAPT in the path towards the SIP client, and the source address of the IP packet is to be used for all SIP messages towards the client instead of the address in the contact header.
2 The firewall, and address bindings, in the NAPT must be kept open permanently after the initial registration, to enable INVITES towards the clients to pass through the FW/NAPT and reach the correct location. There exist several methods for keeping the FW/NAPT bindings for a client open. SIP clients and modern home FW/NAPT products often supports UPNP (universal plug and play), which means that the client can keep the FW/NAPT bindings open without involving Session Controller; this is however not sufficient if there is a NAPT further down in the session path.
Instead, if UPNP is not supported, keeping the FW/NAPT bindings open are commonly accomplished by the different clients, on customer premises, periodically sending IP packets to the SIP port on the Session Controller, frequently enough (often every 30 sec) for the binding in the FW/NAPT not to time-out. The general way of doing this is for clients to set their re-register interval to a value low enough for the periodic re-registration to keep the FW/NAPT bindings open. Since this will be heavy load on the Session Controller, modern SIP clients (like the HotSIP Active Contact client) can as alternative send empty UDP packets (when SIP over UDP) SIP line feed “CRLF” character (when SIP over TCP).
See also RFC3581 for symmetric response routing.
Note: To alleviate the load from frequent re-registrations from clients, enterprise customers often also place a customer premises ALG between the clients and the enterprise FW/NAPT. The ALG funnels all SIP signalling through the FW/NAPT over one single IP address, and thus only need to keep one single FW/NAPT binding open for SIP signalling.
3 The Session Controller must only forward re-registration messages towards the CSCF at the re-registration interval specified by the CSCF in its response to the initial register message.
4 On a per media stream basis the session controller allocates the address/ports for ingress media when receiving SDP parameters from the SIP INVITE; the SDP answer will contain the address/port-numbers allocated by the session controller. However, the egress address/port to use is unknown if there is a FW/NAPT in the path of the media stream. Therefore the media proxy must start to monitor for incoming RTP media packets on the allocated ingress address/port. When the first incoming media packet arrives in the inbound port, the media proxy must read the source address/port field of the packet and set the media proxy egress address/port bindings to this; this is often referred to as “RTP port latching” or “latching to a media plane address and port”.
The B2BUA part of the session controller needs a method for controlling the MP part of the session controller and 11.248 has been used for this purpose. In an ETSI TISPAN/MSF contribution [2] a NAPT traversal package containing a specific H.248 property called “NAPT Processing” was proposed. When this property is applied to a termination it overrides any addresses that may be passed in the Remote descriptor for the termination. Instead the MG will use the source address and source port seen in the incoming media stream as the destination address and destination port of the outgoing media stream. The incoming media stream in this case can be classified only by destination address and destination port (as both source address and port are unknown prior to the arrival of the stream).
The present inventors have appreciated that the NAPT traversal package contribution does not cater for the case when the SIP client changes its IP address or port during a call. This behaviour from the client is allowed in a SIP network.
If the B2BUA, in the event of the SIP client changing address and/or port, did not take any action towards the MP it would lead to an unwanted stop in the media flow since the client changing address/port would lead to a change in external IP address and port of the NAPT which would not be recognized by the MP and the traffic from the NAPT would thus be blocked out and the traffic to the NAPT would be sent to wrong address/port.
The inventors have further appreciated that problems may occur if the B2BUA, in the event of the SIP client changing address and/or port, once again instructed the MP to latch, since it would be likely in such circumstances that there is still hysteresis media floating from the previously used source and that the MP thus would latch to the “old” source again.
One or more aspects of the invention is/are set out in the independent claim(s). Apparatus aspects corresponding to method aspects disclosed herein are also provided, and vice versa.
Some preferred embodiments of the invention will now be described by way of example only and with reference to the accompanying drawing, which shows a simplified diagram of an embodiment of the present invention. When the B2BUA 10 detects that a SIP client 40 behind a NAPT 30 is changing its IP address and/or port for an ongoing media session, the B2BUA 10 instructs the MP 20 to perform an operation which will herein be referred to as “RE-LATCH”. Re-latching means that the MP 20 will continue sending and receiving media to/from the currently used external port in the NAPT 30 but the MP 20 will also start looking for media arriving to the open port in the MP 20 with any new address/port source. Once the first IP packet with a different source address/port than the MP 20 is currently latched to arrives, the MP 20 will re-latch to the new source and start sending its media to the new source and only accept media from this new source.
The B2BUA instructing the MP to behave this way, if 11.248 is used between B2BUA and MP, could use an H.248 property “NAPT Processing” with the following characteristics:
Description: Instructs the MP to apply NAPT processing to the incoming flow.
Values: OFF (default), LATCH, RELATCH
The NAPT Processing property allows the MP to be configured to support media flows that have passed through an unknown number of CPE or network based NAPT devices. It should be noted that when Early Media (18×) is indicated then it may not be possible to perform latching, as there may be no forward media from which to detect the address and port. If any packets are received under these circumstances then they will be used for latching and then discarded.
When the NAPT Processing property is set to OFF then the MP will open a pinhole for the IP address and port defined in the received remote SDP.
When the NAPT Processing property is set to LATCH then this results in the MP ignoring the addresses received in the Remote SDP. Instead the MP will use the source address and source port seen in the incoming media stream as the destination address and destination port of the outgoing media stream. The incoming media stream in this case can be classified only by destination address and destination port, as both source address and port are unknown prior to the arrival of the stream.
When the NAPT Processing property is set to RELATCH then the MP will perform a similar process to the latching process described above. The difference is that the MP will check for a change of remote IP address/port on the received stream. If/when a new remote IP address and/or port are detected then they will be used for future outgoing packets. After relatching any packets received on the old address and port combination will be considered as malicious and will be treated accordingly (discarded and counted).
The NAPT Processing property is passed in the LocalControl descriptor. When no latching/relatching is to be performed then the property can be included in the LocalControl descriptor with value OFF or omitted from the descriptor. If latching is to be performed then the property will be included with value LATCH. The value will be present in all subsequent Local Control descriptors in order to maintain the latched to values. If relatching is to be performed then the property will contain the RELATCH value. Subsequent LocalControl descriptors will contain the LATCH value in order to maintain the relatched values.
It will be understood that during the course of the above relatching technique the MP 20 extracts the new remote IP address and/or port from the received stream without receiving the new remote IP address and/or port in a (separate) notification. Thus no notification (whose only purpose it is to inform the MP of the new remote IP address and/or port) takes place. However, in preferred embodiments of the invention the MP is notified of the fact that the client 40 is changing or has changed its IP address and/or port so that the MP can monitor the incoming stream for a change of remote IP address/port.
As a refinement of the above embodiment, the SP detects from the SIP signalling what type of media the client is intending to send after the address and/or port change. This may be the same type as before the address and/or port change or of a different type. The SP then notifies the MP of the type of media expected, and the MP will only RELATCH to the new source if the media type of the media received by the MP after receiving the RELATCH instruction matches the type of media as notified by the SP.
Whilst in the foregoing text embodiments have been described where use has been made of a NAPT Processing property for performing the re-latch operation, in alternative embodiments use is made of a “signal” for performing the re-latch operation. If H.248 is used, then the signal could have the following characteristics:
Signal ID: latch
Description: This signal orders NAPT Traversal processing
Duration: Not applicable
Additional parameters:
The Signal Type and Duration are default values specified by the package (in this case “ipnapt”), although these could be modified according to 11.248 standard signal procedures. Preferably, the package is H.248.37 (IP NAPT Traversal Package).
In a preferred embodiment based on the above technique, a time-out mechanism for the latch/re-latch is introduced. To this end the Signal Type is defined as, or modified to, “TimeOut” instead of “Brief”, and the “Duration” is set to a chosen value. This closes the possibility to latch/relatch after the time-out (i.e. a period of time corresponding to the set “Duration” value). This can be particularly useful e.g. when a client decides to change its address and/or port and signals this in a “SIP Re-INVITE” message, but the NAPT does not change the outgoing source address and/or port. Using the technique according to this preferred embodiment the MP would only open the relatch possibility for a short period of time (as specified by “Duration”). This contrasts with the case in which the Signal Type is set to “Brief”, where it is possible that the relatching window remains open throughout the duration of the call (e.g. if the NAPT neither changes its address nor its port), making the technique more vulnerable to a “malicious relatch” (i.e. a malicious source sending their own stream towards the MP to “take the session between the client and the MP over”).
In a particularly preferred embodiment the relatch possibility remains open only for a specified duration, but is closed immediately once the relatch has been performed (i.e. without there being the possibility of a further relatch before the end of the specified duration).
Alternatively, or in addition, other additional parameters could be defined:
An Off-set Timer parameter could be used to ensure that the possibility to latch/relatch will only be open after expiry of a (pre)defined period of time (e.g. 1, 2, 5 or 10 seconds). This may be useful e.g. in a “SIP forking case” and multiple clients are sending “Early Media” (SIP 180 Ringing). When one client picks up the phone it might take some time before the other client stops sending “Early Media”. In order to ensure that the correct/wanted media source will be latched to, the MP will only open the latch/relatch possibility after this off-set timer has elapsed. Of course, the Off-set Timer parameter may find application in other contexts.
Specifying the re-latch operation as a signal rather than a property may have distinct advantages: It is sometimes necessary to perform a latch/re-latch operation in two subsequent commands (e.g. in SIP forking cases). If the NAPT processing is specified as a “property” one would normally need to add an extra MODIFY command to the signalling and set the property to OFF in-between the subsequent commands. This is not necessary if the NAPT processing is specified as a “signal”.
Further, implementing the re-latch mechanism by means of a “signal” means that the “signal” does not need to be included in every subsequent message, whereas this would normally be the case if the re-latch mechanism is implemented by means of a “property”.
Whether the re-latch mechanism is implemented by means of a “signal” or a “property”, in preferred embodiments the session controller is notified when latch/re-latch has taken place, and preferably also to which address and/or port.
Further, preferably the SP is notified by the MP application over H.248 when latch/re-latch has taken place, and preferably also to which address and/or port.
In preferred embodiments the re-latch is only performed if the address stays the same but the port changes. In this way it can be ensured that only traffic from the same NAPT will be accepted. In this way it can be ensured that traffic from a different address can be discarded, such traffic indicating fraudulent/malicious behaviour.
This concept is taken further if, according to further preferred embodiments, an address and/or port range is specified as part of a latch/relatch function so that a latch/relatch is only accepted from media sources within the specified range or ranges. The range or ranges is/are specified/configured by the node provider/operator in conjunction with setting up/defining the network connection towards the access network. The range/ranges may be chosen such that only “well known” NAPT's would be allowed to send media towards the session controller.
It will be appreciated that the MP and the SP could be physically separate entities, or could be combined into one entity. In particular in the case of the MP and the SP being so combined, it may not be necessary to use H.248 for the communication between the SP and the MP. In any event, whilst the use of H.248 is preferred by the present inventors, it will be appreciated that other protocols could be used instead.
While the above description has been made with reference to NAPT (i.e. a Translator which translates the Network Address and/or Port number), it will be appreciated that the invention can also be used in connection with a NAT (Network Address Translator). Further, the above description has been made using a SIP client as an example, but it will be appreciated that it is also applicable to other clients, e.g. multimedia clients.
Although the invention has been described in terms of preferred embodiments as set forth above, it should be understood that these embodiments are illustrative only and that the claims are not limited to those embodiments. Those skilled in the art will be able to make modifications and alternatives in view of the disclosure which are contemplated as falling within the scope of the appended claims. Each feature disclosed or illustrated in the present specification may be incorporated in the invention, whether alone or in any appropriate combination with any other feature disclosed or illustrated herein.
| Number | Date | Country | Kind |
|---|---|---|---|
| 0427103.7 | Dec 2004 | GB | national |
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/EP05/56707 | 12/10/2005 | WO | 00 | 10/10/2007 |
