Call set-up systems

Abstract

A call set-up system sets up a call, which may be a voice call, between terminals through a plurality of packet switched networks using call agents. The networks are interconnected by network address translation (NAT) devices, and the messages to successive call agents include media addresses in the associated networks for the actual data packets of the call when it has been set up. The call set-up message includes the media address sent to at least some preceding call agents enabling NAT resources to be saved. The call agents can be incorporated into NAT devices, and the media addresses can be encrypted or in the form of a reference.

Claims

1. A method for setting up calls across a plurality of packet-switched networks communicatively connected by network address translation (NAT) devices, the method performed at a first call agent circuit disposed in a packet-switched network and comprising: sending messages to and receiving messages from other call agent circuits to define a media path for a call, wherein the messages comprise address information for media packets within the packet-switched networks associated with the other call agent circuits, wherein at least one of the received messages includes address information for media packets received at a preceding call agent circuit involved in the set-up of the call, and wherein the messages sent to the other call agent circuits, and the messages received from the other call agent circuits, are of different message types; selecting a set of predetermined rules with which to modify the at least one of the received messages based on a message type for the at least one of the received messages; and modifying the at least one of the received messages according to the selected set of pre-determined rules by adding address information to, and deleting address information from, the at least one of the received messages.

2. The method of claim 1 wherein the messages that are sent by the first call agent circuit comprise offer messages, and wherein the received messages that are received at the first call agent circuit comprise answer messages.

3. The method of claim 1 wherein the first call agent circuit is incorporated in a NAT device.

4. A call agent device configured for setting up calls across a plurality of packet-switched networks communicatively connected by network address translation (NAT) devices, the call agent device disposed in a packet-switched network and comprising: circuitry configured to: send messages to and receive messages from another call agent device to define a media path for a call, wherein the messages comprise address information for media packets within the packet-switched networks associated with the other call agent devices, wherein at least one of the received messages includes address information for media packets received at a preceding call agent device involved in the set-up of the call, and wherein the messages sent to the other call agent circuits, and the received messages received from the other call agent circuits, are of different message types; select a set of predetermined rules with which to modify at least one of the received messages based on a message type for the at least one of the received messages; and modify the at least one of the received messages according to the selected set of pre-determined rules by adding address information to, and deleting address information from, the at least one of the received messages.

5. The call agent device of claim 4 wherein the circuitry is incorporated in a NAT device.

6. The call agent device of claim 4 wherein the messages sent by the circuitry comprise offer messages, and wherein the received messages received by the circuitry comprise answer messages.

7. A network address translation (NAT) device for setting up calls across a plurality of packet-switched networks communicatively connected to each other by NAT devices, the NAT device comprising: call agent circuitry configured to send messages to and receive messages from a plurality of remote call agents to define a media path for a call, wherein the messages comprise address information for media packets within the packet-switched networks associated with the remote call agents, wherein at least one of the received messages includes address information for media packets received at a preceding call agent involved in the set-up of the call, and wherein the messages sent to the other call agent circuits, and the received messages received from the other call agent circuits, are of different message types; select a set of predetermined rules with which to modify at least one of the received messages based on a message type for the at least one of the received messages; and modify the at least one of the received messages according to the selected set of pre-determined rules by adding address information to, and deleting address information from, the at least one of the received messages.

8. The NAT device of claim 7 wherein the messages sent by the call agent circuitry comprise offer messages, and wherein the received messages received by the call agent circuitry comprise answer messages.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) Call set-up systems in accordance with the invention will now be described in detail, by way of example, with reference to the accompanying drawings, in which:

(2) FIG. 1 shows the set-up of a call using SIP signalling between two networks.

(3) FIG. 2 shows the set-up of a call using SIP signalling between three networks.

(4) FIG. 3 which shows the set-up of a call using modified SIP signalling according to the invention;

(5) FIG. 4 shows the rules applied in the modified SIP signalling;

(6) FIG. 5 shows the set-up of a call using the modified SIP signalling for a series of networks, in which the call traverses several networks but does not re-enter an earlier network;

(7) FIGS. 6 to 8 show the set-up of calls using the modified SIP signalling for a series of networks, in which the call does re-enter an earlier network; and

(8) FIG. 9 shows the set-up of calls using the modified SIP signalling for a series of networks, in which the call does re-enter an earlier network, but in which various of the network address translation devices and their controlling call agents are legacy devices using unmodified SIP signalling.

DETAILED DESCRIPTION

(9) All SIP signalling messages are shown in FIG. 3, but only extracts from the text of messages are shown below. The basic format of SIP messages can be seen from IETF call examples documents.

(10) As with the example of known SIP signalling described with reference to FIG. 1, network 1 could be a private network, and network 2 could be the internet. User agent P initiates a call by sending an SIP Invite message to its local call agent Q. This message contains a session description indicating the media characteristics and the address (1.1.1.1) at which user agent P wishes to receive media packets. For convenience, only the last two segments of this address, and of other addresses, are shown in FIG. 3.

(11) The full text of a typical Invite message is as follows, following a standard in IETF documents:

(12) INVITE sip:xxx@uax.middle.com SIP/2.0

(13) Via: SIP/2.0/UDP uap.edge.com:5060;branch=z9hG4bK74bf9

(14) Max-Forwards: 70

(15) From: UserP;tag=9fxced76sl

(16) To: UserX

(17) Call-ID: 3848276298220188511@uap.edge.com

(18) CSeq: 2 INVITE

(19) Contact: <sip:ppp@uap.edge.com

(20) Content-Type: application/sdp

(21) Content-Length: 151

(22) v=0

(23) o=ppp

(24) s=

(25) c=IN P4 1.1.1.1

(26) t=0 0

(27) m=audio 49172 RTP/AVP 0

(28) a=rtpmap:0 PCMU/8000

(29) Call agent Q responds with a SIP 100: trying message.

(30) Call agent Q determines that the destination of the call is in the central network 2, and that this is reached via a NAT device R which it controls. It therefore opens a pinhole in NAT device R to permit a media flow from the central network to the media address of user agent P (1.1.1.1). The address returned by NAT device R (2.2.2.1) is then used in an Invite message sent to call agent S in the central network.

(31) INVITE sip:xxx@uax.middle.com SIP/2.0

(32) Via: SIP/2.0/UDP caq.edge.com:5060;branch=298bnsdhj2ka

(33) Via: SIP/2.0/UDP uap.edge.com:5060;branch=z9hG4bK74bf9

(34) Max-Forwards: 69

(35) From: UserP;tag=9fxced76sl

(36) To: UserX

(37) Call-ID: 3848276298220188511@uap.edge.com

(38) CSeq: 2 INVITE

(39) Contact: <sip:ppp@uap.edge.com

(40) Content-Type: multipart/mixed

(41) Boundary: ****part separator****

(42) Content-Type: application/sdp

(43) Content-Length: 151

(44) v=0

(45) o=ppp

(46) s=

(47) c=IN IP4 2.2.2.1

(48) t=0 0

(49) m=audio 5378 RTP/AVP 0

(50) a=rtpmap:0 PCMU/8000

(51) ****part separator****

(52) Content-Type: application/localswitchstack

(53) NetworkID: edge.com

(54) v=0

(55) o=ppp

(56) s=

(57) c=IN IP4 1.1.1.1

(58) t=0 0

(59) m=audio 49172 RTP/AVP 0

(60) a=rtpmap:0 PCMU/8000

(61) ****part separator****

(62) The SIP message syntax requires a string to be defined to separate the various attachments to the message.

(63) As with a typical SIP Invite message, the message contains the address c=IN IP4 2.2.2.1 at which the NAT device R receives messages for transmission to User Agent P.

(64) However, in accordance with the invention, call agent Q also places the previous session description within a stack structure as a multipart attachment to the SIP message, and this contains the network ID (in this case, edge.com), and the address in the edge network 1, c.dbd.IN IP4 1.1.1.1, at which the User Agent P wished to receive media packets. This is shown in FIG. 3 in the first arrow in a descending direction extending from call agent Q to call agent S. The protocol relies on each address region (between NAT devices) having a globally unique identifier that can be recognised by all call set-up devices within that region. For SIP, this may in many cases derived from the domain name of the SIP server (as used in the SIP global call reference identifier). Call agent S responds with a 100: trying message.

(65) Call agent S determines that user X has requested that their calls be forwarded to user agent V, and that the new destination is reached via call agent U in private network 1. User X could be a home telephone number accessible via the internet, and the user could have set up an arrangement for their calls to be forwarded to their office in the private network 1. It therefore passes on the Invite with a changed URI. The stack structure described above is however retained.

(66) Call agent U responds with a 100: trying message.

(67) Call agent U recognises that the call has arrived from a different network via NAT device T that it controls. It notices that the SIP message contains a local switching stack, and examines the Network ID values of the entries in the stack to see if the call has passed through this network before. In this case it finds an entry for its own network (edge.com), and therefore uses the session description from this stack entry in the message it passes. No pinhole therefore needs to be opened in NAT device T. The Invite message sent to User Agent V just therefore contains the address (1.1.1.1) in network 1, that is, just the local address, rather than the stack. This Invite message is as follows.

(68) INVITE sip:vvv@uay.edge.com SIP/2.0

(69) Via: SIP/2.0/UDP cau.edge.com:5060,branch=7tfvjyufh67

(70) Via: SIP/2.0/UDP cas.middle.com:5060;branch=345hg2kuffs

(71) Via: SIP/2.0/UDP caq.edge.com:5060;branch=298bnsdhj2ka

(72) Via: SIP/2.0/UDP uap.edge.com:5060;branch=z9hG4bK74bf9

(73) Max-Forwards: 67

(74) From: UserP;tag=9fxced76sl

(75) To: UserX

(76) Call-ID: 3848276298220188511@uap.edge.com

(77) CSeq: 2 INVITE

(78) Contact: <sip:ppp@uap.edge.com

(79) Content-Type: application/sdp

(80) Content-Length: 151

(81) v=0

(82) o=ppp

(83) s=

(84) c=IN IP4 1.1.1.1

(85) t=0 0

(86) m=audio 49172 RTP/AVP 0

(87) a=rtpmap:0 PCMU/8000

(88) The call has now reached its destination. User agent V responds with a 180: ringing message that is passed back to the caller via the chain of call agents.

(89) When the call is answered, user agent V sends a 200: OK message back to call agent U. The message contains a session description indicating the media characteristics and the address (1.4) at which user agent V wishes to receive media packets. A typical message would read as follows.

(90) SIP/2.0 200 OK

(91) Via: SIP/2.0/UDP cau.edge.com:5060;branch=7tfvjyufh67

(92) Via: SIP/2.0/UDP cas.middle.com:5060;branch=345hg2kuffs

(93) Via: SIP/2.0/UDP caq.edge.com:5060;branch=298bnsdhj2ka

(94) Via: SIP/2.0/UDP uap.edge.com:5060;branch=z9hG4bK74bf9

(95) From: UserP;tag=9fxced76sl

(96) To: UserX

(97) Call-ID: 3848276298220188511@uap.edge.com

(98) CSeq: 2 INVITE

(99) Contact: <sip:vvv@uay.edge.com

(100) Content-Type: application/sdp

(101) Content-Length: 151

(102) v=0

(103) o=vvv

(104) s=

(105) c=IN IP4 1.1.1.4

(106) t=0 0

(107) m=audio 45678 RTP/AVP 0

(108) a=rtpmap:0 PCMU/8000

(109) Call agent U recognises that this message is for a call for which it invoked the local switching function. To allow compatibility with call agents that have not implemented the local switching functions (i.e. using unmodified SIP signalling), it constructs a stack containing a copy of the session description provided by user agent V, and sends this 200 OK message to call agent S, which passes it back to call agent Q. Call agent Q recognises that this call passes through NAT device R that it controls, and that the message contains a local switching stack. It therefore examines the stack to find entries for its own network. A matching entry is found, and is popped from the stack, that is, all higher entries on the stack are removed and discarded, the matching entry is used as the new SDP, and any remaining lower entries are left on the stack, to form the session description in the SIP message that will be passed to user agent P. Since local switching has been invoked, the pinhole that was created during processing of the Invite message is no longer required, and is therefore deleted.

(110) User agent P then completes the SIP signalling sequence by sending an ACK message. This is passed along the chain of call agents to the called user agent. The user agents have each received an address within their local network to which media packets should be sent. Since local switching has been invoked, this is the address of the other user agent. Single local media path 11 is used for the traffic. All superfluous pinholes within the NAT devices have been closed.

(111) In normal SIP operation, the NAT controller re-writes the SDP (Session Description Protocol (RFC 2616)) address information and discards the incoming address. If the call subsequently loops back into the originating network, the address information from that network has been lost and a local connection cannot be made. The scheme according to the invention with local switching avoids loss of information by pushing the previous session description onto a stack carried forward in the SIP signalling messages. When a call enters a new network, the stack is scanned for entries previously inserted by this network. If an entry is found and local switching is permitted, then the stack is popped back to the original state in this network region. This means that the pinhole most recently allocated during re-entry to the region will not be required, and can be closed immediately.

(112) It will be appreciated that the invention is an addition to SIP that permits flexible control of local switching where calls traverse a number of NAT devices. It should be noted that the SIP signalling performed by the user agents is unchanged by the presence of the local switching function, but that the media paths have been optimised. The protocol is implemented by the call agents that control the transit of SIP media flows through the NAT devices, and these may be separate devices as in the embodiment of FIG. 3, or incorporated in the NAT devices, as in the embodiments of FIGS. 5 to 9. Further, the call agents Q and U may be in the network 2 instead of in the network 1, if desired. This could be useful in the case of a small office edge network, where call agents in the internet 2 could be used. The embodiments may also incorporate legacy call set-up devices such as in FIG. 9, and such legacy devices need only transit the additional information generated by the call set-up devices.

(113) While the description above has been in relation to SIP signalling, the principle may be extended to other signalling protocols based on offer/answer session descriptions to obtain the same benefits. Whatever the signalling protocol, the address region (between NAT devices) must have a globally unique identifier that can be recognised by all call set-up devices within that region.

(114) For SIP, the identifier may in many cases derived from the domain name of the SIP server (as used in the SIP global call reference identifier). SIP uses an offer/answer protocol (RFC 3264) to convey bearer information. A session description is sent in each direction, indicating the media channels, addresses and codecs to be used. A NAT control device (such as an ALG (Application Level Gateway)) re-writes the address information in the session descriptions to match the address translations configured in its local NAT device.

(115) If features are present that require local switching to be inhibited they should simply delete the stack as they transit the message. This will force the media flow through the local network address. This approach could be applied independently for each direction of session description, but in some cases this would result in different NAT devices being used for each direction, and would result in bypassed pinholes remaining open. Processing of the stack is therefore modified for the backward session description.

(116) The invention will now be further explained with reference to FIGS. 4 to 9. FIG. 4 shows the rules and actions to be applied at each at each call agent. The rules should be checked in the order shown until a matching rule is found. It can be seen that the rules are the same in both directions, except that rules 1 and 3 will never apply for an offer message, and need not be checked. The rule number used when processing a message at each NAT device is shown within a hexagon in each of the following embodiments described with reference to FIGS. 5 to 9.

(117) In the embodiments of FIGS. 5 to 9, the call agents are incorporated in the NAT devices, and are not shown separately. In the embodiment of FIG. 5, there are five networks 12-16, joined by four NAT devices 17-20. The letters A and K represent addresses of user terminals 21,22, and the letters B-J represent addresses of pinholes through the NAT devices. None of the networks is common to more than one pair of NAT devices. As with the embodiment of FIG. 3, the call agents in the NAT devices place the previous session description within a stack structure as a multipart attachment to the SIP Invite message sent to each successive NAT device. For example, the Invite SIP message sent to NAT device 18 includes the address C of the pinhole opened through the NAT device 17, but also the address A of the user terminal 21 in network 12 (see second arrow to the right in first line of arrows in FIG. 5).

(118) While the previous session description is passed along, there are no shortcuts possible for the media path between the terminals 21 and 22 because of the lack of common networks. Only Rule 4 applies. The address received in the session description is sent to the NAT device, and replaced by the address from the NAT device in the message passed on by the call agent. This can be viewed as translating the address within the SDP, and it must match the address translation that will be performed on media packets by the NAT device itself.

(119) The embodiment of FIG. 5 is to demonstrate that the invention does not disrupt calls that traverse several networks but do not re-enter an earlier network. Referring to the embodiment of FIG. 6, there are three networks 23-25, joined by NAT devices 17-20. Network 23 is common to NAT devices 17 and 20, and network 24 is common to NAT device pairs 17,18 and 19,20.

(120) Thus, when the SIP Invite message is passed from the call agent for network 25 to the call agent for network 24, Rule 2 applies, the stack of session descriptions is scanned through and replaced with the part of the stack that is headed by the earliest preceding session description for the network 24. Thus, the stack of (G) [E,C,A] is replaced by (C)[A]. No pinhole is required to re-enter network 24, as indicated by circle 26.

(121) Equally, the session description reverts to that of network 23 when the Invite SIP message is passed to the call set-up device associated with re-entry into network 23. Rule 2 applies, and the stack of addresses (J)[C,A] is replaced just by (A) [ ], and the pinhole for re-entry into region 23 is closed. The media path of the call thus set up takes place wholly within the network 23, as path 27.

(122) A pinhole is closed due to the operation of Rule 3 on the O.K. answer message. There are multiple Ks, not just one, in the answer path, arising from processing rules 1 & 3, which duplicate the session descriptions on the stack. It is needed in order to handle networks (like FIG. 9) containing old call agent/NATs that do not implement the invention. Without this action the SDP could be lost when it passes through an old call agent. However, when it is not lost this action results in multiple copies of the SDP on the stack. These are discarded during subsequent processing if the call loops back into a previous network.

(123) In the embodiment of FIG. 7, terminals and NAT devices 28-33 are joined by networks 34-36, and the resulting media path has three sections 37-39. The offer/answer messages, and the Rules applicable when processing a message at the NAT device, are shown in FIG. 7.

(124) The embodiment of FIG. 8 has one further NAT device, so that the terminals and NAT devices are designated 40-46, and there are still only three networks 47-49, since the network 47 is common to both terminals 40,46, allowing a single local media path 50 for the call eventually set up. The offer/answer messages, and the Rules applicable when processing a message at the NAT device, are shown in FIG. 8.

(125) The session description stack may reveal details of a call to other networks that some operators wish to keep private. Since the only requirement on the format of stack entries is that a network can traverse the stack and recognise its own entry, there is nothing to prevent network devices from using encryption to ensure privacy of their stack data. Alternatively, networks may send a reference (URL) to the stack data as it appeared in their network in place of the session description. This requires that they hold the call state in a way that can be interrogated by any future call receiving the reference in the bearer info stack (e.g XML (Extensible Markup Language) document retrievable via HTTP (Hypertext Transfer Protocol (RFC 2616))). The use of URLs will, however result in additional signalling between call handling devices in any network using this technique.

(126) NAT controllers (call agents such as Q, T but not S) and SIP servers are already widely deployed without support for the local switching technique described here. FIG. 9 illustrates the impact that such devices may have on local switching. The embodiment is identical to that of FIG. 8, but successive pairs of lines show the effect when various of the NAT devices are legacy equipment using conventional, not modified, SIP signalling. Thus, the first pair of lines shows the situation when the NAT device 41 is legacy equipment. The Invite message to the call set-up device associated with network 48 simply replaces the address (A) with the address (C). The various applicable Rules when processing a message at the NAT device, are shown.

(127) SIP devices (other than NAT controllers) may either transit the stack information unchanged, or delete the stack information. If the stack is transited unchanged, then local switching will operate normally. If the stack is deleted, then the media will be forced to traverse the network containing the incompatible device. Incompatible NAT controllers may transit the stack unchanged, or delete the stack. It is assumed that no NAT controller would try to translate possible address fields in sections of the SIP message that it did not understand. If this did occur, other networks could prevent the problem by using simple data scrambling within stack entries. This would operate in the same way as the encryption technique described in the section on data hiding. If the stack is deleted, then the media will be forced to traverse the NAT controlled by the incompatible controller. If the stack is transited unchanged, then local switching may be inhibited in some regions, and pinholes may remain open even if they are not subsequently used. In all cases in FIG. 9 both directions of media flow are set up, but the optimum local switching path is not always found, and some unused pinholes are not closed.

(128) The present invention may, of course, be carried out in other ways than those specifically mentioned herein without departing from the essential scope and characteristics of the invention. Therefore, the present embodiments are to be considered in all respects as illustrative and not restrictive, and all changes coming within the meaning and equivalency range of the appended Claims are intended to be embraced therein.