Preferred embodiments of the subject matter described herein will now be explained with reference to the accompanying drawings of which:
In accordance with the subject matter described herein, methods, systems, and computer program products are provided for making call association across elements of a converged network. Call association may be effectuated by encoding a call association (CA) data element in a signaling message, such as a SIP request message. The CA data element may function by uniquely identifying the call itself, by identifying the originating and terminating network nodes of the call, or both. The originating and terminating network nodes of a call may be, for example, the media gateway associated with the caller and the media gateway associated with the cal lee, respectively. Alternatively, they may, for example, refer to the media gateway associated with the caller and a SIP application server, respectively.
In a node hairpin situation, signaling message M1 may be sent to a second signaling node located in packet network 106; the second signaling node copies identifier ID1 into a signaling message M2 for setting up call leg L2, which is sent to network node N 300.
In a network hairpin situation, signaling message M1 may enter packet network 106, be routed through the network, and eventually emerge as message M2—still containing identifier ID1.
In step 306, network node N 300 receives signaling message M2 for setting up call leg L2. Call association module 302 may associate the value of identifier ID1 with call leg L2. At this point in this example there are two call legs, each representing an ingress or egress portion of a call, and possibly representing the ingress and egress portion of the same call.
In step 308, call association module 302 compares the identifiers associated with call legs L1 and L2. The comparison may be triggered by receipt of message M2 by N 300. The comparison may analyze the identifiers associated with the call legs by looking for a predetermined relationship with respect to each other. For example, if the identifier is a call-association value associated with a call leg, the comparison may involve looking for an exact match between identifiers; if the identifier is a combination of the origination and termination addresses of the bearer nodes associated with a call leg, the comparison may involve comparing the origination address of one call leg with the termination address of another, and vice versa. Other predetermined relationships may be used.
In step 310, if the identifiers are found to have a predetermined relationship with respect to each other, then the flow moves to step 312, in which call legs L1 and L2 are associated with each other. The association may be in the form of an entry in a table or database, or in the form of a storage location in memory or other storage device. If the identifiers are not found to have a predetermined relationship with respect to each other, no association is made. In
The details of associating two call legs together may depend upon the specific architecture of the call association module 302. For example, a call manager may keep track of all live calls, perform a search using each identifier associated with a call leg, and make an association between call legs whose identifier matches or otherwise has a predetermined relationship. Alternatively, each call leg may be associated with call instances, which communicate with each other to make associations between call legs.
Turning now to a detailed description of the format of messages used, an exemplary SIP loose routing header including call association data suitable for use with embodiments of the subject matter described herein is shown below:
Route:<sip: {CAID}{LC}{GID}-CA@{SIPaddr};lr>
where {CAID} is an 8-digit hexadecimal call association identifier, {LC} is a 2-digit decimal loop counter, {GID} is a 2-digit decimal preferred media gateway identifier, and {SIPaddr} is the IP address of the SIP signaling interface of the MGC in dotted format (x.x.x.x). The string “-CA” is an example of a marker used to identify this header as one containing call association information. For illustrative purposes, we consider a message sent from MGC 108 to SAS 104 in
Call Association Identifier CAID uniquely identifies a call being generated or processed by a node, and is saved in the dialog for that call leg. This identifier allows MGC 108 to determine which call instance sent out this call to SAS 104.
Loop Counter LC is used to indicate the number of times that the call has entered into the terminating node, which in this example is SAS 104. It is first set to “1”, and is incremented by 1 each time the call is routed back to SAS 104, to prevent MGC 108 from routing the call an unlimited number of times to SAS 104.
Finally, the Preferred Media Gateway number GID is used to indicate which media gateway, of the potentially many media gateways that are controlled by MGC 108, will be used to processes the real time protocol (RTP) stream for this call.
It will be appreciated that both the individual components of the call association data, as well as the call association data taken as a whole, may take many possible formats, and that the exemplary format described here is for illustrative purposes only and is not intended to limit the scope of the invention. For example, CAID need not be limited 8 digits, nor to hexadecimal digits only, but could be a combination of letters, numbers, punctuation, and so on. The formats of LC, GID, and the marker used to identify the header as one containing call association information are similarly unconstrained. The format of SIPaddr could be numeric (e.g., “192.168.1.17”) or other (e.g., “mgc3.area15.pop10”), for example.
To allow the possibility of elimination of a hairpin condition, it is desirable to have both legs of a call go through the same media gateway, such as is shown in
For a distributed architecture, the two call instances may exist on different media gateway controller nodes. In this scenario the two call instances may communicate with each other using an internal call manager message protocol (CCMP). This call association mechanism allows the media gateway controller to associate multiple call instances of a single call when this call is routed out to an external application server and looped back to the media gateway controller again.
It may be unnecessary, or prohibitively expensive, to attempt to initiate call association for every call. A system may use a variety of mechanisms to limit call association to a selected subset of calls. According to one embodiment, call association is performed based on trunk group, which is provisioned when call association is activated. Referring to the network in
A call association initiating (CAI) network element may be for example a media gateway controller, a media gateway, or combination of the two. It may also be an application server or some other network element that has basic call association capability. The call association capability may be combined or separated into different physical or logical system modules. An example of one such implementation is shown in
The responsibilities of call manager 502 may include initiating call association, managing call instances, and initiating a search for a call leg based on the value of an identifier extracted from an incoming call setup message. In one implementation, a call processing instance may be created for each leg of a call, and multiple call instances may be created for multiple legs of a call. Call manager 502 may be responsible for monitoring the event or condition that will trigger the call association capability and associated operations.
The responsibilities of signaling module 504 may include creating an outgoing call setup message for setting up a call leg, encoding into the outgoing message an identifier associated with the call leg, and sending the outgoing message; and receiving an incoming call setup message for setting up a call leg and extracting from the incoming message an identifier associated with the call leg.
The responsibilities of call association module 506 may include creating the identifier associated with a call leg that is to be encoded in an outgoing call setup message, interpreting the identifier associated with a call leg element extracted from an incoming call setup message, and performing a search for a call leg based on the value of the identifier extracted from the incoming call setup message.
It will be understood that various details of the invention may be changed without departing from the scope of the invention. Furthermore, the foregoing description is for the purpose of illustration only, and not for the purpose of limitation.
This application claims the benefit of a U.S. Provisional Patent Application Ser. No. 60/837,597, filed Aug. 11, 2006; the disclosure of which is incorporated herein by reference in its entirety.
Number | Date | Country | |
---|---|---|---|
60837597 | Aug 2006 | US |