US20060245575A1 - Call path reduction via correlation of call legs in a hairpin loop scenario - Google Patents
Call path reduction via correlation of call legs in a hairpin loop scenario Download PDFInfo
- Publication number
- US20060245575A1 US20060245575A1 US11/398,074 US39807406A US2006245575A1 US 20060245575 A1 US20060245575 A1 US 20060245575A1 US 39807406 A US39807406 A US 39807406A US 2006245575 A1 US2006245575 A1 US 2006245575A1
- Authority
- US
- United States
- Prior art keywords
- call
- call leg
- hairpin loop
- switch
- leg
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
- H04M15/41—Billing record details, i.e. parameters, identifiers, structure of call data record [CDR]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
- H04M15/58—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP based on statistics of usage or network monitoring
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M3/00—Automatic or semi-automatic exchanges
- H04M3/22—Arrangements for supervision, monitoring or testing
- H04M3/2281—Call monitoring, e.g. for law enforcement purposes; Call tracing; Detection or prevention of malicious calls
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M2203/00—Aspects of automatic or semi-automatic exchanges
- H04M2203/65—Aspects of automatic or semi-automatic exchanges related to applications where calls are combined with other types of communication
- H04M2203/651—Text message transmission triggered by call
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
- H04M2215/01—Details of billing arrangements
- H04M2215/0164—Billing record, e.g. Call Data Record [CDR], Toll Ticket[TT], Automatic Message Accounting [AMA], Call Line Identifier [CLI], details, i.e. parameters, identifiers, structure
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
- H04M2215/01—Details of billing arrangements
- H04M2215/0188—Network monitoring; statistics on usage on called/calling number
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M3/00—Automatic or semi-automatic exchanges
- H04M3/42—Systems providing special services or facilities to subscribers
- H04M3/42204—Arrangements at the exchange for service or number selection by voice
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M3/00—Automatic or semi-automatic exchanges
- H04M3/42—Systems providing special services or facilities to subscribers
- H04M3/48—Arrangements for recalling a calling subscriber when the wanted subscriber ceases to be busy
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M3/00—Automatic or semi-automatic exchanges
- H04M3/42—Systems providing special services or facilities to subscribers
- H04M3/487—Arrangements for providing information services, e.g. recorded voice services or time announcements
- H04M3/493—Interactive information services, e.g. directory enquiries ; Arrangements therefor, e.g. interactive voice response [IVR] systems or voice portals
- H04M3/4931—Directory assistance systems
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04M—TELEPHONIC COMMUNICATION
- H04M3/00—Automatic or semi-automatic exchanges
- H04M3/42—Systems providing special services or facilities to subscribers
- H04M3/54—Arrangements for diverting calls for one subscriber to another predetermined subscriber
Definitions
- the technical field relates generally to circuit switched networks.
- the field relates to reducing call path in a switched network such as a telecommunications network.
- a switch may redirect a call.
- a hairpin loop routing scenario can arise. For example, a first switch might redirect a call to a second switch for service processing. Upon completion of the service processing by the second switch, the call might then be routed back to the first switch for further processing, resulting in a hairpin loop.
- the hairpin loop scenario can be avoided.
- a correlation key can be passed between a switch requesting service from a service platform switch and the service platform switch.
- the call legs can be processed as a hairpin loop, and a hairpin loop can be avoided for the call path.
- a call leg can be removed. In this way, the call's path length can be reduced. Normal call processing can follow as the call is routed to its destination.
- the value of the correlation key is an identity of the calling party.
- a billing identity can be used.
- a dynamically assigned value can be used.
- the dynamically assigned value can be temporarily inserted for use in calling line identity or billing fields.
- the correlation information can be collected from available call setup signaling parameters; therefore, the technologies can be used with switch systems not having specialized signaling protocols designed to avoid hairpin loops.
- a switch can map an incoming call from a service platform switch to an existing outgoing call using trunk group characteristics (e.g., trunk type or trunk group membership) to determine the correlation key. If desired, only designated trunk groups need be checked. In this way, the number of trunks being checked during correlation can be reduced.
- trunk group characteristics e.g., trunk type or trunk group membership
- a single party might be associated with multiple simultaneous calls.
- an identity selected from a pool of dedicated identities can be substituted for the actual identity in a call setup signaling parameter. Correlation can then take place based on the selected identity.
- FIG. 1 is a block diagram showing a hairpin loop scenario in a telecommunications system having at least two switches.
- FIG. 2 is a flow chart showing an exemplary method for avoiding a hairpin loop scenario.
- FIG. 3 is a data flow diagram showing exemplary inputs for hairpin loop detection and avoidance.
- FIGS. 4, 5 , 6 , and 7 are block diagrams showing an exemplary telecommunications network in which a hairpin loop scenario is detected and avoided.
- FIG. 8 is a block diagram showing an exemplary telecommunications network in which ports are depicted.
- FIG. 9 is flow chart showing an exemplary method for avoiding a hairpin loop scenario.
- FIG. 10 is a flow chart showing an exemplary method for avoiding a hairpin loop scenario in a directory assistance call completion situation.
- FIGS. 11A and 11B are signaling diagrams showing an exemplary implementation for avoiding a hairpin loop scenario in a directory assistance call completion situation.
- FIG. 12 is a block diagram showing an exemplary switch system for avoiding a hairpin loop scenario.
- FIG. 13 is a flow chart showing an exemplary method for avoiding a hairpin loop scenario, including simultaneous multi-call per subscriber support.
- FIG. 1 An exemplary hairpin loop scenario is shown in FIG. 1 .
- a telecommunications system 100 having at least two switches 124 and 126 is shown.
- a first telecommunications device (e.g., telephone) 112 establishes an incoming leg 132 to switch A 124 (e.g., as a result of a subscriber who initiates a telephone call).
- the call is routed to switch B 126 (e.g., because switch A 124 is unable to handle a requested service such as directory assistance with call completion, network-based voice-activated dialing, voicemail callback, or prepaid calling services).
- the call leg 134 is thus established.
- a destination is determined.
- the call is routed back to switch A 124 .
- Another call leg 136 is thus established or attempted. Because the call returns to a switch that redirected it, the call leg scenario 142 is sometimes called a “hairpin loop.”
- correlation between the call legs in the hairpin loop scenario 142 can be accomplished. Based on the correlation, the hairpin loop scenario 142 is avoided. Avoiding the hairpin loop scenario can include preventing formation of a hairpin loop scenario. Alternatively, avoiding the hairpin loop scenario can include removing the hairpin loop scenario after it has been formed. In some cases, avoiding the hairpin loop scenario includes removing an incompletely formed (e.g., formed for a call leg but not formed for a voice path) hairpin loop.
- FIG. 2 An exemplary method 200 for avoiding a hairpin loop scenario is shown in FIG. 2 .
- Such a method can be implemented, for example, in a telecommunications architecture involving at least two switches.
- information is stored for an outgoing call leg.
- the stored information is sometimes called “correlation information” because it can later be used to correlate the call leg with an incoming leg to detect a potential hairpin loop scenario.
- the information can take a variety of forms, such as party identification (e.g., phone number), billing number, or other identifier (e.g., dynamically assigned when the call leg is formed).
- party identification e.g., phone number
- billing number e.g., dynamically assigned when the call leg is formed.
- the outgoing call leg can be, for example, a call leg routed from a redirecting switch to a service platform switch.
- call setup signaling information might indicate a party identification, billing number, or other information.
- the call setup signaling can indicate a destination (e.g., a destination determined as a result of service processing).
- Correlation can be achieved, for example, by detecting a match between information stored at 212 and the call setup signaling information related to the incoming leg.
- At 216 as a result of correlating the call legs and detecting the potential hairpin loop scenario, at least one hairpin loop call leg (e.g., the outgoing leg, the incoming leg, or both) is released while the call is routed to its destination.
- the example only mentions two legs, other legs can be involved in the call (e.g., an incoming leg from a subscriber to the redirecting switch, which redirects the call to a second switch for servicing), some or all of which may or may not be released.
- Release of the outgoing hairpin loop call leg can be accomplished in an indirect fashion (e.g., by releasing the incoming leg, which triggers release of the outgoing leg).
- Call signaling information for a first leg 304 and call signaling information for a second leg 306 are used for hairpin loop detection and avoidance 308 .
- Call signaling information can be any of a variety of information, including call set up signaling information, such as a calling party's identity (e.g., telephone number), billing identifier, or another identifier, such as a dynamically generated identifier.
- a dynamically generated identifier can be temporarily placed in calling party identity or billing fields.
- Identifiers can be stored in a list to be consulted for later processing (e.g., correlation).
- additional data can be used for the hairpin loop detection and avoidance 308 , such as trunk type for incoming call legs, the destination of a call, and other information.
- trunk type a trunk can be designated to be of a type (e.g., incoming hairpin loop type or outgoing hairpin loop type) to be monitored for hairpin loop scenarios.
- call legs can additionally be checked to determine if they are on a trunk being of a type to be monitored. In this way, checking for hairpin loop scenarios need not take place for trunks not of the designated type.
- call signaling information for outgoing call legs can be stored based on whether the call leg is going out on a trunk of type “outgoing hairpin loop,” and call signaling information for incoming call legs can be correlated based on whether the call leg is coming in on a trunk of type “incoming hairpin loop.”
- trunk type “outgoing hairpin loop” need be checked for correlation. Trunks of type “incoming hairpin loop” need not be checked; thus, the number of trunks to be checked can be reduced.
- FIGS. 4-7 are block diagrams showing an exemplary telecommunications system 400 in which a hairpin loop scenario is avoided.
- a telecommunications device 412 is employed by a customer to make a call requiring a service not to be processed by switch A 424 , which receives the call via the incoming call leg 432 .
- the telecommunications device 412 can be a wireless telephone or a landline telephone.
- switch A 424 routes the call to switch B 426 to facilitate performance of the service, forming the call leg 534 .
- the call leg 534 can be described as the first leg in a potential two-leg hairpin loop scenario. Because switch A 424 redirects the call, it is sometimes called a “redirecting switch.” Because switch B 426 performs call servicing, it is sometimes called a “service platform switch.”
- Switch B 426 can be any of a variety of switches in a variety of locations (e.g., a single DS1 adjunct platform collated with switch A 424 or a Service Switching Point for a large network service center at a distant location).
- switch B 426 routes the call back to switch A 424 , requesting that the call leg 636 be formed, which would result in a hairpin loop scenario (i.e., for the call legs 534 and 636 ).
- the call legs 534 and 636 can be correlated via correlation information. Based on the correlation indicating detection of the potential hairpin loop scenario, the hairpin loop scenario can be avoided as shown in FIG. 7 by removing the call legs 534 and 636 .
- the call can then be routed to the destination device 414 (e.g., via the call leg 738 ).
- the identity of the destination device 414 can be determined by examination of a parameter (e.g., a “called party” parameter) contained in the request to form the call leg 636 .
- FIG. 8 shows an exemplary telecommunications system 800 , including an illustration of various ports. Although input and output ports are shown in the example, bidirectional ports can be used.
- a telecommunications device originates a call (e.g., a customer initiates a telephone call), which is directed to the port 842 A of the switch 824 , resulting in an incoming call leg 832 .
- the call is directed from port 842 C to the service platform 826 , resulting in an outgoing call leg 834 .
- the service platform can route the call back to the port 842 D of the switch 824 , resulting in an attempted incoming call leg 836 , which would form a hairpin loop scenario.
- the various ports can be handled appropriately.
- correlation information can be stored that can be compared for ports 842 C and 842 D to determine that the same call (e.g., the same calling party, same billing identifier, or other identifying information) is involved.
- the port on which the call arrived 842 A can be parked while the other ports 842 C and 842 D are released.
- silence can be applied to the voice path.
- the call can then be routed out the port 842 B to its destination 814 , forming the call leg 838 .
- FIG. 9 An exemplary method 900 for processing a call while avoiding a hairpin loop scenario is shown in FIG. 9 .
- the method can be used, for example, in a telecommunications network comprising at least a redirecting switch and a service platform switch.
- a call is routed out a port from the redirecting switch to the service platform switch.
- it can be determined whether hairpin loop scenario detection is to be performed (e.g., by checking whether the outgoing trunk associated with the call is designated as being of a type for which hairpin loop detection is to be performed). If so, correlation information can be collected from call setup signaling information. For example, information indicating the calling party's identity, billing identifier, or other information can be stored.
- the port out of which the call is being routed e.g., from the redirecting switch
- an indication of the port on which the call arrived can be stored. Alternatively, such information can be determined later (e.g., as described below).
- a destination for the call is determined. For example, if the service platform switch is related to directory assistance call completion, a calling customer typically requests a search for the number of a called party. Or, in the case of network-based voice-activated dialing, the spoken word “home” can be translated into a home telephone number. The call can then be directed to the destination number.
- the trunk type can be checked to see if the call is to be checked for hairpin loop avoidance. If so, call set up signaling information can be collected (e.g, party identity, billing identifier, or other information) and checked against correlation information stored earlier for the call at 918 . If there is a match, a potential hairpin loop scenario is indicated. For example, if the party identity for an outgoing call routed from the redirecting switch to the service platform switch matches the party identity for an incoming call arriving at the redirecting switch, the calls are actually the same call forming a hairpin loop scenario.
- call set up signaling information can be collected (e.g, party identity, billing identifier, or other information) and checked against correlation information stored earlier for the call at 918 . If there is a match, a potential hairpin loop scenario is indicated. For example, if the party identity for an outgoing call routed from the redirecting switch to the service platform switch matches the party identity for an incoming call arriving at the redirecting switch, the calls are actually the same call forming a hair
- the appropriate ports can be parked and released at 922 .
- the port at which the call originally arrived e.g., at the first switch
- a release signal can be sent to the service platform switch for the incoming leg, which in turn will lead to a release of the outgoing call leg from the first switch to the service platform switch.
- the call can then be routed to its determined destination at 932 .
- FIGS. 10 and 11 show exemplary methods and systems for avoiding a hairpin loop scenario in a directory assistance call completion situation.
- a telecommunications network 1100 A and 1100 B comprises access to a public switched telephone network 1112 , a mobile telecommunications device 1114 , a redirecting switch 1116 , and a service platform switch 1118 for processing directory assistance call completion.
- the service platform switch 1118 can provide other or additional services (e.g., voice-activated dialing, voicemail callback, or prepaid services), and the illustrated methods work in a similar manner. Hairpin loop detection and avoidance can be performed transparently to the service platform switch 1118 .
- the service platform switch 1118 need not include functionality related to hairpin loop detection and avoidance.
- ISUP signaling e.g., for an SS7 network
- ISDN-PRI ISDN-PRI
- ISDN-BRI ISDN-BRI
- R1 Feature Group-D or GSM-based implementations
- FIGS. 11A and 11B depict a Charge Number parameter, any number of other parameters (e.g., a calling party number or call reference parameter) can be used in its place for correlation.
- a method 1000 for processing a call is shown in FIG. 10 .
- a directory assistance call is received (e.g., at the redirecting switch 1116 from a subscriber using the device 1114 ). For example, a subscriber at the telephone number “425-555-1234” might dial “411,” resulting in call setup information being sent to the redirecting switch.
- call processing determines that the call is to be routed over an outgoing hairpin trunk group (e.g., type “outgoing hairpin loop trunk”), so the billing identity parameter is populated with Automatic Number Identification (“ANI”) information (e.g., from the incoming call above) and the call is routed to a service platform switch (e.g., the switch 1118 ).
- ANI Automatic Number Identification
- a service platform switch e.g., the switch 1118
- IAM Initial Address Message
- billing information e.g., the subscriber's phone number
- a voice path is established from the communications device (e.g., the device 1114 ) to the directory assistance operator.
- the voice path involves two call legs.
- the subscriber requests that the directory assistance operator complete the call to the destination (e.g., a phone number).
- the service platform switch then routes the call back and attempts to establish an incoming call leg to the redirecting switch 1116 via call setup signaling, indicating the ultimate destination of the call at 1018 .
- the attempt is shown as the “IAM-3” signal.
- billing information (e.g., a billing number or charge number) is extracted from the call setup signaling.
- the billing information from the incoming call (e.g., call leg 3) is then mapped to a call on the outgoing trunk to identify the associated outgoing call leg (e.g., call leg 2 in the example). Having found the outgoing call leg, the system can then also identify the associated incoming call leg from the device (e.g., call leg 1 in the example).
- Information about the destination e.g., the telephone number of the called party
- the appropriate incoming call leg from the device is parked (e.g., call leg 1 in the example), and the leg is disassociated (e.g., from call leg 2). Silence can be applied while the call is parked.
- the incoming call leg from the service platform switch (e.g., call leg 3) is released. Release of the incoming call leg from the service platform switch triggers release of the outgoing leg to the service platform switch (e.g., call leg 2).
- the parked call is rerouted based on the destination number (e.g., determined from the “called number” parameter of call leg 3), establishing a call leg from the redirecting switch directed to the destination (e.g., in the example, the call is directed to the phone number “2065559876” via the public switched telephone network 1112 ).
- the destination number e.g., determined from the “called number” parameter of call leg 3
- establishing a call leg from the redirecting switch directed to the destination e.g., in the example, the call is directed to the phone number “2065559876” via the public switched telephone network 1112 ).
- FIGS. 11A and 11B show an exemplary signaling arrangement for avoiding a hairpin loop scenario in a directory assistance call completion situation.
- call setup information e.g., “411”
- IAM e.g., including a called party parameter of “800555111” and a charge number parameter of “4255551234”
- IAM-2 the service platform switch 1118
- a voice path is established by which the caller can ask for directory assistance (shown with reference to call legs 1 and 2).
- IAM-3 As a result of determining the call's destination, another IAM (e.g., including a called party parameter of “2065559876” and a charge number of “4255551234”) is sent from the service platform switch 1118 to the redirecting switch 1116 (shown as “IAM-3”). As a result, construction of call leg 3 is attempted.
- IAM-3 a called party parameter of “2065559876” and a charge number of “4255551234
- hairpin loop processing takes place.
- various release signaling shown as REL- 3 , RLC- 3 , REL- 2 , and RLC- 2 takes place.
- call leg 1 can be parked and silence applied to the call during release. Parking the call leg can prevent it from being released.
- IAM e.g., including a called party parameter of “2065559876”
- IAM-4 the network 1112
- a voice path is established (shown with reference to call legs 1 and 4).
- other release signaling can take place (e.g., including RELEASE- 1 , REL- 4 , RLC- 4 , and RELEASE COMPLETE- 1 as shown in the example).
- FIG. 12 shows an exemplary switch system 1200 .
- the system can be used to avoid hairpin loop scenarios.
- the switch system 1200 can be used as an implementation of a redirecting switch (e.g., switch 424 , switch 824 , or switch 1116 ).
- the switch system 1200 can be implemented, for example, as a Mobile Switching Center or a Class 5 Switch.
- Various ports 1206 A, 1206 B, and 1206 N are shown. More ports can be implemented as desired.
- the switch system 1200 can be implemented in any of a variety of switch hardware by adding a software upgrade or modification by which the switch system 1200 can identify and avoid a hairpin loop scenario.
- information can also be stored for other call legs, in the example, correlation keys store 1212 stores the correlation keys for call legs directed from the switch 1200 to a service platform switch. In the example, correlation keys are stored only for those calls going out on trunks listed in the trunk list store 1222 .
- the trunk list store 1222 can be implemented in a variety of ways. For example, a trunk can be given a particular type (e.g., type “outgoing hairpin loop”). Trunks having the type are then considered to be in the list. Or, trunk identifiers can be stored in a list as a trunk group.
- type e.g., type “outgoing hairpin loop”.
- the correlation keys store 1212 and the trunk list store 1222 information is already available and separate stores are not required.
- the switch system 1200 might support a software request to locate a call instance on an outgoing hairpin loop trunk group matching a supplied parameter (e.g., billing information for a call coming in on an incoming hairpin loop trunk group).
- the compare logic 1232 is operable to compare information (e.g., billing party identifier, or other information) with that stored in the correlation keys store 1212 . Although comparison could be done for more call legs, in the example, comparisons are done only for call legs coming in on trunks listed in the trunk list 1222 .
- the trunk list store 1222 can designate such trunks in a variety of ways. For example, a trunk can be given a particular type (e.g., type “incoming hairpin loop”). Trunks having the type are then considered to be in the list. Or, trunk identifiers can be stored in a list of trunks (e.g., in the same list as the outgoing hairpin loop trunks or in a separate list).
- the compare logic 1232 finds a correlation (e.g., match) between an outgoing call leg and an incoming call leg, a potential hairpin loop scenario is indicated. Responsive to detecting a correlation by the compare logic 1232 , the hairpin avoidance logic 1242 is activated.
- the hairpin avoidance logic 1242 is operable to avoid the hairpin loop scenario. For example, the logic 1242 can park a call leg (e.g., an incoming call leg from a subscriber) and then release other legs, while directing the call to its destination. Silence can be applied to the call during release.
- the redirecting switch can be configured to have at least two special unidirectional trunk groups: an outgoing trunk group (e.g., used for calls routed from the redirecting switch to the service platform switch) and an incoming trunk group (e.g., used for calls returning from the service platform switch to the redirecting switch).
- an outgoing trunk group e.g., used for calls routed from the redirecting switch to the service platform switch
- an incoming trunk group e.g., used for calls returning from the service platform switch to the redirecting switch.
- bi-directional trunks can be used.
- Trunk configuration for any of the examples can be done to ensure calls are handled properly and to avoid unnecessary processing (e.g., checking for hairpin loops scenarios in situations where such scenarios are not likely or impossible to occur).
- the interface between a redirecting switch and the service platform switch can use call setup signaling capable of transmitting any of a variety of information useable as correlation information (e.g., calling party identity, billing number, or both).
- ANI can be used.
- signaling interfaces that can be used include ANSI-ISUP signaling (e.g., the Calling Party Number, Charge Number, or some combination of the parameters are supported in the IAM), ISDN-PRI signaling (e.g., the Calling Party Number is supported in the Setup Message), ISDN-BRI signaling, R1 Feature Group-D Signaling (e.g., ANI delivery is supported).
- ITU-ISUP e.g., calling party number is supported
- the call reference parameter for ISDN/ISUP signaling can be used for correlation.
- the service platform switch can return the correlation information unmodified in the same signaling parameter as received from the redirecting switch, but other arrangements are possible.
- FIG. 13 shows a method 1300 for avoiding a hairpin loop scenario, including optional support for a situation in which a caller can have more than one call active at a time.
- the method can be used with any of the depicted telecommunications systems.
- a parameter e.g., billing identity or calling party identity
- a parameter e.g., billing identity or calling party identity
- the unique value can be a subscriber's calling identity (e.g., Directory Number (DN), Mobile Directory Number (MDN), Mobile Station ISDN number (MSISDN), Mobile Identification Number (MIN), Mobile Station Identifier (MSI), or a dynamically generated identifier such as Temporary Mobile Station Identifier (TMSI)).
- DN Directory Number
- MDN Mobile Directory Number
- MSISDN Mobile Station ISDN number
- MIN Mobile Identification Number
- MSI Mobile Station Identifier
- TMSI Temporary Mobile Station Identifier
- a pool of dedicated identities e.g., billing identities
- a billing identity can be selected out of a pool of dummy (e.g., not identifying an actual subscriber) identities and used for a call.
- the selected identity can be temporarily associated with the actual identity for billing purposes.
- the selected identity can be substituted for the actual identity in hairpin loop call legs.
- An example in which such an arrangement can be useful is in situations involving multi-line capability for the same directory number or call termination services.
- call termination services multiple callers may be redirected to the service platform switch before being redirected away from the subscriber (e.g., routing terminating calls to a prepaid service system before delivery to a voicemail system).
- the use of dedicated billing identities can also aid in identifying call records associated with the hairpin loop for removal in downstream billing processing.
- calls arriving on the incoming hairpin loop trunk group trigger an event to locate the call instance for the corresponding outgoing hairpin loop trunk group matching the configured correlation parameter.
- hairpin loop processing can take place.
- the switch parks the original call leg that triggered the redirection to the service platform switch. Once parked, the switch can release the call leg to the service platform switch.
- the switch uses the called number (e.g., destination number) from the incoming call from the service platform switch call that was released.
- the switch treats the number as a redirection operation for the original call leg. If the calling party identity or billing identity were modified for call processing (e.g., to be one of a dedicated group of billing identities), the switch can restore the calling party identity.
- the switch can restore the calling party identity (e.g., for signaling when the call is directed to its destination).
- One useful application of the described technologies is upgrading equipment in conventional networks. For example, hairpin avoidance processing (e.g., releasing call legs) can be done transparently to service platform switches. Accordingly, such service platform switches need not be upgraded. Further, the illustrated technologies can be used in systems not having special provisions for avoiding hairpin loops. As a result, conventional switches using ordinary call setup signaling and conventional interfaces can be easily upgraded without the added expense of incorporating supplementary services, new signal protocols, new interfaces, or new parameters.
- the described technologies can be applied for use in any of a variety of landline or mobile telecommunications networks.
- the technologies can be applied for use in GSM networks.
- additional (e.g., intermediary) switches may be involved in the technologies.
- the examples have been discussed primarily in the context of telecommunications networks, the technologies are equally applicable to any circuit-switched networks.
- a hairpin loop scenario can be detected and avoided (e.g., by removing legs).
- identifiers used by a network to identify users or transactions can be used. Providing an exhaustive list is beyond the scope of this document, but some other examples of suitable identifiers include Electronic Serial Number (ESN), International Mobile Station Identifier (IMSI), and IAM-EI.
- ESN Electronic Serial Number
- IMSI International Mobile Station Identifier
- Other identifiers include, for example, Directory Number (DN), Mobile Directory Number (MDN), Mobile Station ISDN number (MSISDN), Mobile Identification Number (MIN), Mobile Station Identifier (MSI), or a dynamically generated identifier such as Temporary Mobile Station Identifier (TMSI). Any other identifier, such as an Internet domain name or Internet address can also be used.
- a combination of identifiers can be used for correlation (e.g., combination of calling party number and charge number).
- trunks can be designated for call setup signaling from a particular (e.g., incoming) direction. In this way, the number of trunks being checked during correlation can be reduced. For example, when correlating for an incoming call leg, only identifiers for outgoing call legs need be checked. Alternatively, trunks need not be so designated. For example, a trunk might both initiate and receive calls.
- call setup signaling e.g., ISUP
- other types of call setup signaling e.g., any signaling for initiating and establishing calls, such as that for ISDN-PRI, ISDN-BRI, R1 Feature Group-D, or GSM-based implementations
- ISUP call setup signaling
- other types of call setup signaling e.g., any signaling for initiating and establishing calls, such as that for ISDN-PRI, ISDN-BRI, R1 Feature Group-D, or GSM-based implementations
- an identifier is correlated with another identifier passed via the same parameter.
- the correlation can be done via different parameters.
- a called party parameter can be correlated with a charge number parameter.
- more than one parameter can be combined for correlation.
- correlation can be done even though the values of identifiers being correlated are not identical. For example, in a prepaid scenario, additional information may be prepended to an identifier.
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Computer Security & Cryptography (AREA)
- Technology Law (AREA)
- Physics & Mathematics (AREA)
- Probability & Statistics with Applications (AREA)
- Telephonic Communication Services (AREA)
Abstract
A variety of methods and systems can be used to avoid a hairpin loop scenario. For example, in a system involving a redirecting switch and a service platform switch, correlation between calling party identities for outgoing and incoming call legs can be done to identify a potential hairpin loop scenario. Upon detection of such a scenario, appropriate call legs can be released while routing the call to its destination. Correlation information can be collected from available call setup signaling parameters. The methods and systems can be applied, for example, to systems involving directory assistance call completion, voice-activated dialing, voicemail callback, and prepaid services.
Description
- This application is a divisional of U.S. patent application Ser. No. 10/085,491 entitled “CALL PATH REDUCTION VIA CORRELATION OF CALL LEGS IN A HAIRPIN LOOP SCENARIO” filed Feb. 27, 2002, which is hereby incorporated herein by reference.
- The technical field relates generally to circuit switched networks. In particular, the field relates to reducing call path in a switched network such as a telecommunications network.
- During call processing related to various telecommunications services, a switch may redirect a call. After redirection, a hairpin loop routing scenario can arise. For example, a first switch might redirect a call to a second switch for service processing. Upon completion of the service processing by the second switch, the call might then be routed back to the first switch for further processing, resulting in a hairpin loop.
- In cases where service processing by the second switch relates to call setup features (e.g., determining a destination phone number), additional interaction with the second switch is typically not required after the call is routed to its destination. Therefore, connection through the second switch for the duration of the call is often unnecessary. Reducing such unnecessary use of switch resources is desirable because the presence of the hairpin loop consumes switch capacity and transport requirements for both the first and second switch.
- In disclosed embodiments, the hairpin loop scenario can be avoided. For example, a correlation key can be passed between a switch requesting service from a service platform switch and the service platform switch. Upon correlation of call legs, the call legs can be processed as a hairpin loop, and a hairpin loop can be avoided for the call path. For example, a call leg can be removed. In this way, the call's path length can be reduced. Normal call processing can follow as the call is routed to its destination.
- In certain embodiments, the value of the correlation key is an identity of the calling party. Alternatively, a billing identity can be used. Or, a dynamically assigned value can be used. For example, the dynamically assigned value can be temporarily inserted for use in calling line identity or billing fields. The correlation information can be collected from available call setup signaling parameters; therefore, the technologies can be used with switch systems not having specialized signaling protocols designed to avoid hairpin loops.
- In illustrated embodiments, a switch can map an incoming call from a service platform switch to an existing outgoing call using trunk group characteristics (e.g., trunk type or trunk group membership) to determine the correlation key. If desired, only designated trunk groups need be checked. In this way, the number of trunks being checked during correlation can be reduced.
- In some situations (e.g., call termination), a single party might be associated with multiple simultaneous calls. In such a case, an identity selected from a pool of dedicated identities can be substituted for the actual identity in a call setup signaling parameter. Correlation can then take place based on the selected identity.
- The foregoing and other features and advantages will become more apparent from the following detailed description of disclosed embodiments, which proceeds with reference to the accompanying drawings.
-
FIG. 1 is a block diagram showing a hairpin loop scenario in a telecommunications system having at least two switches. -
FIG. 2 is a flow chart showing an exemplary method for avoiding a hairpin loop scenario. -
FIG. 3 is a data flow diagram showing exemplary inputs for hairpin loop detection and avoidance. -
FIGS. 4, 5 , 6, and 7 are block diagrams showing an exemplary telecommunications network in which a hairpin loop scenario is detected and avoided. -
FIG. 8 is a block diagram showing an exemplary telecommunications network in which ports are depicted. -
FIG. 9 is flow chart showing an exemplary method for avoiding a hairpin loop scenario. -
FIG. 10 is a flow chart showing an exemplary method for avoiding a hairpin loop scenario in a directory assistance call completion situation. -
FIGS. 11A and 11B are signaling diagrams showing an exemplary implementation for avoiding a hairpin loop scenario in a directory assistance call completion situation. -
FIG. 12 is a block diagram showing an exemplary switch system for avoiding a hairpin loop scenario. -
FIG. 13 is a flow chart showing an exemplary method for avoiding a hairpin loop scenario, including simultaneous multi-call per subscriber support. - An exemplary hairpin loop scenario is shown in
FIG. 1 . In the example, atelecommunications system 100 having at least twoswitches incoming leg 132 to switch A 124 (e.g., as a result of a subscriber who initiates a telephone call). - In the example, the call is routed to switch B 126 (e.g., because switch A 124 is unable to handle a requested service such as directory assistance with call completion, network-based voice-activated dialing, voicemail callback, or prepaid calling services). The
call leg 134 is thus established. As a result of the service provided by the switch B 126 (e.g., determining that the call is to be routed to another destination, such as the device 114), a destination is determined. Then, the call is routed back to switch A 124. Anothercall leg 136 is thus established or attempted. Because the call returns to a switch that redirected it, thecall leg scenario 142 is sometimes called a “hairpin loop.” - In disclosed embodiments, correlation between the call legs in the
hairpin loop scenario 142 can be accomplished. Based on the correlation, thehairpin loop scenario 142 is avoided. Avoiding the hairpin loop scenario can include preventing formation of a hairpin loop scenario. Alternatively, avoiding the hairpin loop scenario can include removing the hairpin loop scenario after it has been formed. In some cases, avoiding the hairpin loop scenario includes removing an incompletely formed (e.g., formed for a call leg but not formed for a voice path) hairpin loop. - An
exemplary method 200 for avoiding a hairpin loop scenario is shown inFIG. 2 . Such a method can be implemented, for example, in a telecommunications architecture involving at least two switches. - At 212 information is stored for an outgoing call leg. The stored information is sometimes called “correlation information” because it can later be used to correlate the call leg with an incoming leg to detect a potential hairpin loop scenario. The information can take a variety of forms, such as party identification (e.g., phone number), billing number, or other identifier (e.g., dynamically assigned when the call leg is formed). The outgoing call leg can be, for example, a call leg routed from a redirecting switch to a service platform switch.
- At 214, based on call setup signaling information for an incoming leg and the stored correlation information, an attempt to establish an incoming leg forming a hairpin loop scenario in conjunction with the outgoing leg is detected and correlated. For example, call setup signaling information might indicate a party identification, billing number, or other information. Further, the call setup signaling can indicate a destination (e.g., a destination determined as a result of service processing).
- Correlation can be achieved, for example, by detecting a match between information stored at 212 and the call setup signaling information related to the incoming leg.
- At 216, as a result of correlating the call legs and detecting the potential hairpin loop scenario, at least one hairpin loop call leg (e.g., the outgoing leg, the incoming leg, or both) is released while the call is routed to its destination. Although the example only mentions two legs, other legs can be involved in the call (e.g., an incoming leg from a subscriber to the redirecting switch, which redirects the call to a second switch for servicing), some or all of which may or may not be released. Release of the outgoing hairpin loop call leg can be accomplished in an indirect fashion (e.g., by releasing the incoming leg, which triggers release of the outgoing leg).
- An
exemplary data flow 300 for avoiding a hairpin loop scenario is shown inFIG. 3 . Call signaling information for afirst leg 304 and call signaling information for asecond leg 306 are used for hairpin loop detection andavoidance 308. Call signaling information can be any of a variety of information, including call set up signaling information, such as a calling party's identity (e.g., telephone number), billing identifier, or another identifier, such as a dynamically generated identifier. For example, a dynamically generated identifier can be temporarily placed in calling party identity or billing fields. Identifiers can be stored in a list to be consulted for later processing (e.g., correlation). - In some cases, additional data can be used for the hairpin loop detection and
avoidance 308, such as trunk type for incoming call legs, the destination of a call, and other information. In the case of trunk type, a trunk can be designated to be of a type (e.g., incoming hairpin loop type or outgoing hairpin loop type) to be monitored for hairpin loop scenarios. In such an arrangement, call legs can additionally be checked to determine if they are on a trunk being of a type to be monitored. In this way, checking for hairpin loop scenarios need not take place for trunks not of the designated type. - For example, call signaling information for outgoing call legs can be stored based on whether the call leg is going out on a trunk of type “outgoing hairpin loop,” and call signaling information for incoming call legs can be correlated based on whether the call leg is coming in on a trunk of type “incoming hairpin loop.”
- Further, or alternatively, when correlating an identifier for an incoming call, only identifiers associated with trunk type “outgoing hairpin loop” need be checked for correlation. Trunks of type “incoming hairpin loop” need not be checked; thus, the number of trunks to be checked can be reduced.
-
FIGS. 4-7 are block diagrams showing anexemplary telecommunications system 400 in which a hairpin loop scenario is avoided. In thetelecommunications system 400 ofFIG. 4 , atelecommunications device 412 is employed by a customer to make a call requiring a service not to be processed byswitch A 424, which receives the call via theincoming call leg 432. Thetelecommunications device 412 can be a wireless telephone or a landline telephone. - As shown in
FIG. 5 , switch A 424 routes the call to switchB 426 to facilitate performance of the service, forming thecall leg 534. Thecall leg 534 can be described as the first leg in a potential two-leg hairpin loop scenario. Becauseswitch A 424 redirects the call, it is sometimes called a “redirecting switch.” Becauseswitch B 426 performs call servicing, it is sometimes called a “service platform switch.”Switch B 426 can be any of a variety of switches in a variety of locations (e.g., a single DS1 adjunct platform collated withswitch A 424 or a Service Switching Point for a large network service center at a distant location). - Then, as shown in
FIG. 6 , after performing service processing and possibly determining a new destination, switchB 426 routes the call back to switch A 424, requesting that thecall leg 636 be formed, which would result in a hairpin loop scenario (i.e., for thecall legs 534 and 636). - However, the
call legs FIG. 7 by removing thecall legs - The call can then be routed to the destination device 414 (e.g., via the call leg 738). The identity of the
destination device 414 can be determined by examination of a parameter (e.g., a “called party” parameter) contained in the request to form thecall leg 636. -
FIG. 8 shows anexemplary telecommunications system 800, including an illustration of various ports. Although input and output ports are shown in the example, bidirectional ports can be used. In the example, a telecommunications device originates a call (e.g., a customer initiates a telephone call), which is directed to theport 842A of theswitch 824, resulting in anincoming call leg 832. As a result of determining that the call is to be directed to a service platform for processing, the call is directed fromport 842C to theservice platform 826, resulting in anoutgoing call leg 834. - After performing service processing, the service platform can route the call back to the
port 842D of theswitch 824, resulting in an attemptedincoming call leg 836, which would form a hairpin loop scenario. Upon detection of the potential hairpin loop scenario, the various ports can be handled appropriately. - For example, correlation information can be stored that can be compared for
ports other ports port 842B to itsdestination 814, forming thecall leg 838. - An
exemplary method 900 for processing a call while avoiding a hairpin loop scenario is shown inFIG. 9 . The method can be used, for example, in a telecommunications network comprising at least a redirecting switch and a service platform switch. - At 912, a call is routed out a port from the redirecting switch to the service platform switch. At such time, it can be determined whether hairpin loop scenario detection is to be performed (e.g., by checking whether the outgoing trunk associated with the call is designated as being of a type for which hairpin loop detection is to be performed). If so, correlation information can be collected from call setup signaling information. For example, information indicating the calling party's identity, billing identifier, or other information can be stored. Also, the port out of which the call is being routed (e.g., from the redirecting switch) can be stored. Further, an indication of the port on which the call arrived (e.g., at the first switch) can be stored. Alternatively, such information can be determined later (e.g., as described below).
- At 914, a destination for the call is determined. For example, if the service platform switch is related to directory assistance call completion, a calling customer typically requests a search for the number of a called party. Or, in the case of network-based voice-activated dialing, the spoken word “home” can be translated into a home telephone number. The call can then be directed to the destination number.
- At 916, as the call is forwarded back to the redirecting switch, appearing to be a new call on another port, the trunk type can be checked to see if the call is to be checked for hairpin loop avoidance. If so, call set up signaling information can be collected (e.g, party identity, billing identifier, or other information) and checked against correlation information stored earlier for the call at 918. If there is a match, a potential hairpin loop scenario is indicated. For example, if the party identity for an outgoing call routed from the redirecting switch to the service platform switch matches the party identity for an incoming call arriving at the redirecting switch, the calls are actually the same call forming a hairpin loop scenario.
- Responsive to correlating the call on the ports, the appropriate ports can be parked and released at 922. For example, the port at which the call originally arrived (e.g., at the first switch) can be parked and silence applied to the call. A release signal can be sent to the service platform switch for the incoming leg, which in turn will lead to a release of the outgoing call leg from the first switch to the service platform switch. The call can then be routed to its determined destination at 932.
-
FIGS. 10 and 11 show exemplary methods and systems for avoiding a hairpin loop scenario in a directory assistance call completion situation. In the example, atelecommunications network telephone network 1112, amobile telecommunications device 1114, a redirectingswitch 1116, and aservice platform switch 1118 for processing directory assistance call completion. Theservice platform switch 1118 can provide other or additional services (e.g., voice-activated dialing, voicemail callback, or prepaid services), and the illustrated methods work in a similar manner. Hairpin loop detection and avoidance can be performed transparently to theservice platform switch 1118. For example, theservice platform switch 1118 need not include functionality related to hairpin loop detection and avoidance. - In the example, ISUP signaling (e.g., for an SS7 network) is shown, but other signaling interfaces (ISDN-PRI, ISDN-BRI, R1 Feature Group-D, or GSM-based implementations) or protocols can be used. Although
FIGS. 11A and 11B depict a Charge Number parameter, any number of other parameters (e.g., a calling party number or call reference parameter) can be used in its place for correlation. - A
method 1000 for processing a call is shown inFIG. 10 . At 1012, a directory assistance call is received (e.g., at the redirectingswitch 1116 from a subscriber using the device 1114). For example, a subscriber at the telephone number “425-555-1234” might dial “411,” resulting in call setup information being sent to the redirecting switch. - At 1014, call processing determines that the call is to be routed over an outgoing hairpin trunk group (e.g., type “outgoing hairpin loop trunk”), so the billing identity parameter is populated with Automatic Number Identification (“ANI”) information (e.g., from the incoming call above) and the call is routed to a service platform switch (e.g., the switch 1118). For example, an Initial Address Message (“IAM”) signal can be sent to the service platform switch (e.g., the switch 1118), including billing information (e.g., the subscriber's phone number) as part of the call set-up protocol.
- At 1016, a voice path is established from the communications device (e.g., the device 1114) to the directory assistance operator. As illustrated, the voice path involves two call legs. The subscriber requests that the directory assistance operator complete the call to the destination (e.g., a phone number). After the destination of the call is determined, the service platform switch then routes the call back and attempts to establish an incoming call leg to the redirecting
switch 1116 via call setup signaling, indicating the ultimate destination of the call at 1018. In the example, the attempt is shown as the “IAM-3” signal. - At 1022, billing information (e.g., a billing number or charge number) is extracted from the call setup signaling. The billing information from the incoming call (e.g., call leg 3) is then mapped to a call on the outgoing trunk to identify the associated outgoing call leg (e.g., call
leg 2 in the example). Having found the outgoing call leg, the system can then also identify the associated incoming call leg from the device (e.g., callleg 1 in the example). Information about the destination (e.g., the telephone number of the called party) can also be extracted and saved for later use. - At 1032, the appropriate incoming call leg from the device is parked (e.g., call
leg 1 in the example), and the leg is disassociated (e.g., from call leg 2). Silence can be applied while the call is parked. - At 1042, the incoming call leg from the service platform switch (e.g., call leg 3) is released. Release of the incoming call leg from the service platform switch triggers release of the outgoing leg to the service platform switch (e.g., call leg 2).
- At 1052, the parked call is rerouted based on the destination number (e.g., determined from the “called number” parameter of call leg 3), establishing a call leg from the redirecting switch directed to the destination (e.g., in the example, the call is directed to the phone number “2065559876” via the public switched telephone network 1112).
-
FIGS. 11A and 11B show an exemplary signaling arrangement for avoiding a hairpin loop scenario in a directory assistance call completion situation. In the example, call setup information (e.g., “411”) is sent from atelephone 1114 to a redirectingswitch 1116. Then, an IAM (e.g., including a called party parameter of “800555111” and a charge number parameter of “4255551234”) is sent to the service platform switch 1118 (shown as “IAM-2”). After various other signaling, a voice path is established by which the caller can ask for directory assistance (shown with reference to calllegs 1 and 2). - As a result of determining the call's destination, another IAM (e.g., including a called party parameter of “2065559876” and a charge number of “4255551234”) is sent from the
service platform switch 1118 to the redirecting switch 1116 (shown as “IAM-3”). As a result, construction ofcall leg 3 is attempted. - Having correlated the parameters from the IAM-2 and IAM-3, hairpin loop processing takes place. In the example, various release signaling shown as REL-3, RLC-3, REL-2, and RLC-2 takes place. Also, call
leg 1 can be parked and silence applied to the call during release. Parking the call leg can prevent it from being released. - An IAM (e.g., including a called party parameter of “2065559876”) is then sent to the network 1112 (shown as “IAM-4”). After appropriate additional signaling, a voice path is established (shown with reference to call
legs 1 and 4). After completion of the call, other release signaling can take place (e.g., including RELEASE-1, REL-4, RLC-4, and RELEASE COMPLETE-1 as shown in the example). -
FIG. 12 shows anexemplary switch system 1200. The system can be used to avoid hairpin loop scenarios. For example, theswitch system 1200 can be used as an implementation of a redirecting switch (e.g.,switch 424,switch 824, or switch 1116). Theswitch system 1200 can be implemented, for example, as a Mobile Switching Center or a Class 5 Switch.Various ports - The
switch system 1200 can be implemented in any of a variety of switch hardware by adding a software upgrade or modification by which theswitch system 1200 can identify and avoid a hairpin loop scenario. Although information can also be stored for other call legs, in the example, correlation keys store 1212 stores the correlation keys for call legs directed from theswitch 1200 to a service platform switch. In the example, correlation keys are stored only for those calls going out on trunks listed in thetrunk list store 1222. - The
trunk list store 1222 can be implemented in a variety of ways. For example, a trunk can be given a particular type (e.g., type “outgoing hairpin loop”). Trunks having the type are then considered to be in the list. Or, trunk identifiers can be stored in a list as a trunk group. - In some systems, the
correlation keys store 1212 and thetrunk list store 1222 information is already available and separate stores are not required. For example, theswitch system 1200 might support a software request to locate a call instance on an outgoing hairpin loop trunk group matching a supplied parameter (e.g., billing information for a call coming in on an incoming hairpin loop trunk group). - The compare
logic 1232 is operable to compare information (e.g., billing party identifier, or other information) with that stored in thecorrelation keys store 1212. Although comparison could be done for more call legs, in the example, comparisons are done only for call legs coming in on trunks listed in thetrunk list 1222. Thetrunk list store 1222 can designate such trunks in a variety of ways. For example, a trunk can be given a particular type (e.g., type “incoming hairpin loop”). Trunks having the type are then considered to be in the list. Or, trunk identifiers can be stored in a list of trunks (e.g., in the same list as the outgoing hairpin loop trunks or in a separate list). - If the compare
logic 1232 finds a correlation (e.g., match) between an outgoing call leg and an incoming call leg, a potential hairpin loop scenario is indicated. Responsive to detecting a correlation by the comparelogic 1232, thehairpin avoidance logic 1242 is activated. Thehairpin avoidance logic 1242 is operable to avoid the hairpin loop scenario. For example, thelogic 1242 can park a call leg (e.g., an incoming call leg from a subscriber) and then release other legs, while directing the call to its destination. Silence can be applied to the call during release. - In the example, the redirecting switch can be configured to have at least two special unidirectional trunk groups: an outgoing trunk group (e.g., used for calls routed from the redirecting switch to the service platform switch) and an incoming trunk group (e.g., used for calls returning from the service platform switch to the redirecting switch). Alternatively, bi-directional trunks can be used.
- Trunk configuration for any of the examples can be done to ensure calls are handled properly and to avoid unnecessary processing (e.g., checking for hairpin loops scenarios in situations where such scenarios are not likely or impossible to occur).
- To implement the illustrated examples, the interface between a redirecting switch and the service platform switch can use call setup signaling capable of transmitting any of a variety of information useable as correlation information (e.g., calling party identity, billing number, or both). For example, ANI can be used. Examples of signaling interfaces that can be used include ANSI-ISUP signaling (e.g., the Calling Party Number, Charge Number, or some combination of the parameters are supported in the IAM), ISDN-PRI signaling (e.g., the Calling Party Number is supported in the Setup Message), ISDN-BRI signaling, R1 Feature Group-D Signaling (e.g., ANI delivery is supported). Other signaling interfaces, including ITU-ISUP (e.g., calling party number is supported) can be used. Further, the call reference parameter for ISDN/ISUP signaling can be used for correlation.
- Use of other signaling parameters specific to a signaling interface (e.g., the “call reference” parameter in ISDN/ISUP signaling) is possible. In some cases, it may be desirable to combine two or more parameters for correlation.
- For any of the illustrated examples, the service platform switch can return the correlation information unmodified in the same signaling parameter as received from the redirecting switch, but other arrangements are possible.
-
FIG. 13 shows amethod 1300 for avoiding a hairpin loop scenario, including optional support for a situation in which a caller can have more than one call active at a time. The method can be used with any of the depicted telecommunications systems. - At 1312, when a call is routed from a redirecting switch to a service platform switch, a parameter (e.g., billing identity or calling party identity) is populated with a unique value. For example, the unique value can be a subscriber's calling identity (e.g., Directory Number (DN), Mobile Directory Number (MDN), Mobile Station ISDN number (MSISDN), Mobile Identification Number (MIN), Mobile Station Identifier (MSI), or a dynamically generated identifier such as Temporary Mobile Station Identifier (TMSI)).
- However, some service platform switch services may permit multiple simultaneous call instances to be associated with a single subscriber's number. In such an arrangement, a pool of dedicated identities (e.g., billing identities) can be used. For example, a billing identity can be selected out of a pool of dummy (e.g., not identifying an actual subscriber) identities and used for a call. The selected identity can be temporarily associated with the actual identity for billing purposes. For call setup signaling, the selected identity can be substituted for the actual identity in hairpin loop call legs.
- An example in which such an arrangement can be useful is in situations involving multi-line capability for the same directory number or call termination services. In the case of call termination services, multiple callers may be redirected to the service platform switch before being redirected away from the subscriber (e.g., routing terminating calls to a prepaid service system before delivery to a voicemail system). The use of dedicated billing identities can also aid in identifying call records associated with the hairpin loop for removal in downstream billing processing.
- At 1314, calls arriving on the incoming hairpin loop trunk group trigger an event to locate the call instance for the corresponding outgoing hairpin loop trunk group matching the configured correlation parameter.
- At 1316, upon finding a match of the correlation tags, hairpin loop processing can take place. In the example, the switch parks the original call leg that triggered the redirection to the service platform switch. Once parked, the switch can release the call leg to the service platform switch.
- At 1318, the switch uses the called number (e.g., destination number) from the incoming call from the service platform switch call that was released. The switch treats the number as a redirection operation for the original call leg. If the calling party identity or billing identity were modified for call processing (e.g., to be one of a dedicated group of billing identities), the switch can restore the calling party identity.
- If the calling party identity or billing identity were modified for call processing (e.g., to be one of a dedicated group of billing identities), the switch can restore the calling party identity (e.g., for signaling when the call is directed to its destination).
- One useful application of the described technologies is upgrading equipment in conventional networks. For example, hairpin avoidance processing (e.g., releasing call legs) can be done transparently to service platform switches. Accordingly, such service platform switches need not be upgraded. Further, the illustrated technologies can be used in systems not having special provisions for avoiding hairpin loops. As a result, conventional switches using ordinary call setup signaling and conventional interfaces can be easily upgraded without the added expense of incorporating supplementary services, new signal protocols, new interfaces, or new parameters.
- The described technologies can be applied for use in any of a variety of landline or mobile telecommunications networks. For example, the technologies can be applied for use in GSM networks. In some cases, additional (e.g., intermediary) switches may be involved in the technologies. Although the examples have been discussed primarily in the context of telecommunications networks, the technologies are equally applicable to any circuit-switched networks. For example, in the case of any directed signal, a hairpin loop scenario can be detected and avoided (e.g., by removing legs).
- In general, although the examples have been discussed primarily in the context of using calling party or billing identifiers to correlate call legs, many other identifiers used by a network to identify users or transactions can be used. Providing an exhaustive list is beyond the scope of this document, but some other examples of suitable identifiers include Electronic Serial Number (ESN), International Mobile Station Identifier (IMSI), and IAM-EI. Other identifiers include, for example, Directory Number (DN), Mobile Directory Number (MDN), Mobile Station ISDN number (MSISDN), Mobile Identification Number (MIN), Mobile Station Identifier (MSI), or a dynamically generated identifier such as Temporary Mobile Station Identifier (TMSI). Any other identifier, such as an Internet domain name or Internet address can also be used. In some cases, a combination of identifiers can be used for correlation (e.g., combination of calling party number and charge number).
- Some of the examples describe using two groups of unidirectional trunks. In a unidirectional arrangement, traffic can pass in both directions, but certain trunks can be designated for call setup signaling from a particular (e.g., incoming) direction. In this way, the number of trunks being checked during correlation can be reduced. For example, when correlating for an incoming call leg, only identifiers for outgoing call legs need be checked. Alternatively, trunks need not be so designated. For example, a trunk might both initiate and receive calls.
- Similarly, some of the examples describe input or output ports. However, an arrangement involving ports not so designated can be used in addition to or instead of having ports designated for input or output.
- Further, in some of the examples, a particular type of call setup signaling (e.g., ISUP) is depicted. However, other types of call setup signaling (e.g., any signaling for initiating and establishing calls, such as that for ISDN-PRI, ISDN-BRI, R1 Feature Group-D, or GSM-based implementations) can be used instead.
- Still further, in some of the examples, an identifier is correlated with another identifier passed via the same parameter. Alternatively, the correlation can be done via different parameters. For example, a called party parameter can be correlated with a charge number parameter. Also, more than one parameter can be combined for correlation. In some cases, correlation can be done even though the values of identifiers being correlated are not identical. For example, in a prepaid scenario, additional information may be prepended to an identifier.
- In view of the many possible embodiments to which the principles of the invention may be applied, it should be recognized that the illustrated embodiments are examples of the invention, and should not be taken as a limitation on the scope of the invention. Rather, the scope of the invention includes what is covered by the following claims. I therefore claim as my invention all that comes within the scope and spirit of these claims.
Claims (22)
1-21. (canceled)
22. A method comprising:
at a switch in a telecommunications network, initiating an outgoing call leg, wherein a first identifier is associated with the outgoing call leg;
at the switch, receiving an incoming call leg, wherein a second identifier is associated with the incoming call leg;
correlating the outgoing call leg and the incoming call leg based at least on the identifiers; and
responsive to correlating the outgoing call leg and the incoming call leg, processing the outgoing call leg and the incoming call leg as a hairpin loop.
23. The method of claim 22 further comprising:
determining the first identifier from call setup signaling associated with the outgoing call leg; and
determining the second identifier from call setup signaling associated with the incoming call leg.
24. The method of claim 22 further comprising:
determining the first identifier from a billing number parameter associated with an Initial Address Message associated with the outgoing call leg; and
determining the second identifier from a billing number parameter associated with an Initial Address Message associated with the incoming call leg.
25. The method of claim 22 wherein processing the call legs as a hairpin loop comprises:
releasing the incoming call leg.
26. The method of claim 22 wherein processing the call legs as a hairpin loop comprises:
parking a call leg; and
applying silence to the parked call leg.
27. The method of claim 26 wherein processing the call legs as a hairpin loop further comprises:
releasing the outgoing call leg.
28-39. (canceled)
40. A method of upgrading a telecommunications switching system to avoid a hairpin loop scenario, the method comprising:
upgrading at least one switch in the switching system to implement correlation to correlate call legs in the hairpin loop scenario and release at least one call leg in a hairpin loop responsive to the correlation;
wherein the correlation is based on call setup signaling supported by the switch, and the switch accommodates a hairpin loop with at least one service platform switch that need not be upgraded to avoid the hairpin loop scenario.
41. The method of claim 22 wherein the outgoing call leg comprises a service request.
42. The method of claim 41 wherein the incoming call leg comprises a call leg directed back to the switch after performing processing for the service request of the outgoing call leg.
43. The method of claim 41 wherein the outgoing call leg comprises a request for directory assistance.
44. The method of claim 41 wherein the outgoing call leg comprises a request for accessing voicemail messages.
45. The method of claim 41 wherein the outgoing call leg comprises a request for voice-activated dialing.
46. The method of claim 41 wherein the outgoing call leg comprises a request for prepaid services.
47. The method of claim 27 wherein processing the call legs as a hairpin loop further comprises:
maintaining connectivity for a call associated with the call legs.
48. One or more computer-readable media comprising computer-executable instructions for performing a method comprising:
at a switch in a telecommunications network, initiating an outgoing call leg, wherein a first identifier is associated with the outgoing call leg;
at the switch, receiving an incoming call leg, wherein a second identifier is associated with the incoming call leg;
correlating the outgoing call leg and the incoming call leg based at least on the identifiers; and
responsive to correlating the outgoing call leg and the incoming call leg, processing the outgoing call leg and the incoming call leg as a hairpin loop.
49. The one or more computer-readable media of claim 48 further comprising computer-executable instructions for performing the following:
determining the first identifier from call setup signaling associated with the outgoing call leg; and
determining the second identifier from call setup signaling associated with the incoming call leg.
50. The one or more computer-readable media of claim 48 further comprising computer-executable instructions for performing the following:
determining the first identifier from a billing number parameter associated with an Initial Address Message associated with the outgoing call leg; and
determining the second identifier from a billing number parameter associated with an Initial Address Message associated with the incoming call leg.
51. The one or more computer-readable media of claim 48 wherein processing the call legs as a hairpin loop comprises:
releasing the incoming call leg.
52. The one or more computer-readable media of claim 48 wherein processing the call legs as a hairpin loop comprises:
parking a call leg; and
applying silence to the parked call leg.
53. The one or more computer-readable media of claim 52 wherein processing the call legs as a hairpin loop further comprises:
releasing the outgoing call leg.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/398,074 US20060245575A1 (en) | 2002-02-27 | 2006-04-04 | Call path reduction via correlation of call legs in a hairpin loop scenario |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/085,491 US7050563B2 (en) | 2002-02-27 | 2002-02-27 | Call path reduction via correlation of call legs in a hairpin loop scenario |
US11/398,074 US20060245575A1 (en) | 2002-02-27 | 2006-04-04 | Call path reduction via correlation of call legs in a hairpin loop scenario |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/085,491 Division US7050563B2 (en) | 2002-02-27 | 2002-02-27 | Call path reduction via correlation of call legs in a hairpin loop scenario |
Publications (1)
Publication Number | Publication Date |
---|---|
US20060245575A1 true US20060245575A1 (en) | 2006-11-02 |
Family
ID=27753643
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/085,491 Expired - Fee Related US7050563B2 (en) | 2002-02-27 | 2002-02-27 | Call path reduction via correlation of call legs in a hairpin loop scenario |
US11/398,074 Abandoned US20060245575A1 (en) | 2002-02-27 | 2006-04-04 | Call path reduction via correlation of call legs in a hairpin loop scenario |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/085,491 Expired - Fee Related US7050563B2 (en) | 2002-02-27 | 2002-02-27 | Call path reduction via correlation of call legs in a hairpin loop scenario |
Country Status (1)
Country | Link |
---|---|
US (2) | US7050563B2 (en) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080139170A1 (en) * | 2003-05-08 | 2008-06-12 | Ari Kahn | Call Management Protocol for Insufficient Credit |
US20100268797A1 (en) * | 2009-04-16 | 2010-10-21 | Exfo Service Assurance, Inc. | Correlating network transactions |
US10187528B2 (en) | 2011-09-21 | 2019-01-22 | Starlogik Ip Llc | Universal ring free |
Families Citing this family (21)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7133516B2 (en) * | 2003-11-24 | 2006-11-07 | Motorola, Inc. | Prevention of call forwarding loops in communication networks |
US7440421B2 (en) * | 2004-09-29 | 2008-10-21 | Avaya Inc. | Detection of looping communication channels |
KR100770843B1 (en) * | 2005-01-18 | 2007-10-26 | 삼성전자주식회사 | Method for improving call sucess ratio when each other user equipment call trial happens at the same time in a mobile communication system |
US8139729B2 (en) | 2005-04-27 | 2012-03-20 | Verizon Business Global Llc | Systems and methods for handling calls associated with an interactive voice response application |
US7542768B2 (en) * | 2006-03-23 | 2009-06-02 | Alcatel-Lucent Usa Inc. | Dynamic ring start delay based on multiple factors |
US20080037533A1 (en) * | 2006-08-11 | 2008-02-14 | Santera Systems, Inc. | Methods, systems, and computer program products for associating independent legs of a call in a telecommunications network |
US9473644B2 (en) * | 2006-08-11 | 2016-10-18 | Genband Us Llc | Methods, systems, and computer program products for hairpin condition elimination in a telecommunications network |
KR100883105B1 (en) * | 2007-03-30 | 2009-02-11 | 삼성전자주식회사 | Method and apparatus for dialing voice recognition in a portable terminal |
US8644298B1 (en) | 2007-09-12 | 2014-02-04 | Genband Us Llc | Adding a service control channel after session establishment |
US8155021B2 (en) * | 2009-01-19 | 2012-04-10 | Avaya Inc. | Feature interaction detection during calls with multiple-leg signaling paths |
US8300558B2 (en) * | 2009-01-19 | 2012-10-30 | Avaya Inc. | Feature interaction detection in multi-party calls and calls with bridged appearances |
US8917844B2 (en) * | 2009-01-19 | 2014-12-23 | Avaya Inc. | Mid-call detection and resolution of feature interactions |
US9049290B2 (en) * | 2009-06-29 | 2015-06-02 | Avaya Inc. | Interaction detection between web-enabled and call-related features |
US9203652B2 (en) * | 2009-12-21 | 2015-12-01 | 8X8, Inc. | Systems, methods, devices and arrangements for cost-effective routing |
US8385521B2 (en) * | 2010-06-21 | 2013-02-26 | Kirusa Inc. | Billing for call complete calls |
US8369508B2 (en) * | 2010-06-21 | 2013-02-05 | Tel-Tech Systems, Inc. | Call routing in telephone switch based on duplicate leg detection |
US10419310B1 (en) | 2015-12-17 | 2019-09-17 | 8×8, Inc. | Monitor device for use with endpoint devices |
US10530934B1 (en) | 2016-05-04 | 2020-01-07 | 8X8, Inc. | Endpoint location determination for call routing decisions |
US10542150B1 (en) | 2016-05-04 | 2020-01-21 | 8X8, Inc. | Server generated timing of location updates for call routing decisions |
US10326888B1 (en) | 2016-05-04 | 2019-06-18 | 8X8, Inc. | Location updates for call routing decisions |
US11076051B1 (en) | 2016-05-04 | 2021-07-27 | 8X8, Inc. | Endpoint location update control for call routing decisions |
Family Cites Families (21)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH0775371B2 (en) * | 1988-07-13 | 1995-08-09 | 富士通株式会社 | Call transfer registration method in electronic switching system |
US5550911A (en) * | 1994-11-29 | 1996-08-27 | Lucent Technologies Inc. | Adjunct call handling for accessing adjunct-based capabilities platform |
US5664010A (en) * | 1995-01-04 | 1997-09-02 | Electronic Data Systems Corporation | System and method for providing an improved telecommunications service node |
GB2298101B (en) * | 1995-02-20 | 1999-04-28 | Sony Uk Ltd | Frequency separation of image data |
US5805691A (en) * | 1996-05-28 | 1998-09-08 | Mci Corporation | System and method for safely and efficiently redirecting a telephone call |
US5790638A (en) * | 1996-06-07 | 1998-08-04 | Telefonaktiebolaget L M Ericsson (Publ) | Signaling in call transfer calling operations to control the initiation of secondary number telephone service features |
US5881145A (en) * | 1996-07-29 | 1999-03-09 | Northern Telecom Limited | Redirection of calls to ported directory numbers in telephone networks |
US5884179A (en) * | 1996-09-16 | 1999-03-16 | Ericsson Inc. | Optimized routing of terminating calls within a mobile telecommunications network |
US6052589A (en) * | 1997-02-19 | 2000-04-18 | Telefonaktiebolaget Lm Ericsson | Method and arrangement relating to telecommunications systems |
US5995610A (en) * | 1997-05-06 | 1999-11-30 | Telefonaktiebolaget Lm Ericsson | Cooperative call processing across public and private intelligent networks |
US6097797A (en) * | 1997-05-19 | 2000-08-01 | Ricoh Company, Ltd. | Network facsimile apparatus capable of E-mail communications |
US6370241B1 (en) * | 1997-12-23 | 2002-04-09 | Quest Communications Int'l., Inc. | Telephony system for calling card calls |
US6144723A (en) * | 1998-03-24 | 2000-11-07 | Nortel Networks Corporation | Method and apparatus for providing voice assisted call management in a telecommunications network |
US6381306B1 (en) * | 1998-06-08 | 2002-04-30 | Inet Technologies, Inc. | System and method for monitoring service quality in a communications network |
US6097798A (en) * | 1998-07-09 | 2000-08-01 | Bell Atlantic Network Services, Inc. | Electronic surveillance in a public switched telephone network |
US6078648A (en) * | 1998-07-09 | 2000-06-20 | Bell Atlantic Network Services, Inc. | Advanced intelligent network (AIN) functionality for electronic surveillance |
US6549613B1 (en) * | 1998-11-05 | 2003-04-15 | Ulysses Holding Llc | Method and apparatus for intercept of wireline communications |
US6393289B1 (en) * | 1998-11-19 | 2002-05-21 | Lucent Technologies Inc. | Apparatus, method and system for wireless telecommunication session control by an adjunct network entity |
US6601031B1 (en) * | 2000-01-13 | 2003-07-29 | Lucent Technologies Inc. | Speech recognition front end controller to voice mail systems |
US7068759B2 (en) * | 2002-02-27 | 2006-06-27 | At&T Wireless Services, Inc. | Electronic surveillance via correlation of call legs |
US6845152B2 (en) * | 2003-03-28 | 2005-01-18 | Telefonaktiebolaget Lm Ericsson (Publ) | System and method to stop call looping |
-
2002
- 2002-02-27 US US10/085,491 patent/US7050563B2/en not_active Expired - Fee Related
-
2006
- 2006-04-04 US US11/398,074 patent/US20060245575A1/en not_active Abandoned
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080139170A1 (en) * | 2003-05-08 | 2008-06-12 | Ari Kahn | Call Management Protocol for Insufficient Credit |
US8675841B2 (en) * | 2003-05-08 | 2014-03-18 | Starscriber Corporation | Call management protocol for insufficient credit |
US20140199960A1 (en) * | 2003-05-08 | 2014-07-17 | Starscriber Corporation | Call management protocol for insufficient credit |
US9094890B2 (en) * | 2003-05-08 | 2015-07-28 | Starscriber Corporation | Call management protocol for insufficient credit |
US20100268797A1 (en) * | 2009-04-16 | 2010-10-21 | Exfo Service Assurance, Inc. | Correlating network transactions |
US8271633B2 (en) * | 2009-04-16 | 2012-09-18 | Exfo Service Assurance Inc. | Correlating network transactions |
US10187528B2 (en) | 2011-09-21 | 2019-01-22 | Starlogik Ip Llc | Universal ring free |
Also Published As
Publication number | Publication date |
---|---|
US20030161460A1 (en) | 2003-08-28 |
US7050563B2 (en) | 2006-05-23 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20060245575A1 (en) | Call path reduction via correlation of call legs in a hairpin loop scenario | |
US8204175B2 (en) | Electronic surveillance via correlation of call legs | |
US7062028B2 (en) | Method and apparatus for routing calls based on the identification of the calling party or calling line | |
US7035385B2 (en) | Method and system for screening calls during voicemail messaging | |
RU2141734C1 (en) | Mobile communication network | |
US7450938B2 (en) | Method for improving communication success rate in simultaneous call trial between subscribers in mobile communication systems | |
US7593379B2 (en) | Method and system to provide service availability to multi-mode terminals in different access networks | |
US5930698A (en) | Method and apparatus for efficient law enforcement agency monitoring of telephone calls | |
US6944445B2 (en) | Homezone call forwarding service method | |
US20070201619A1 (en) | Method and system for call proceeding in an intelligent network system | |
JP2003534725A (en) | Notification of the existence of messages stored on the voicemail server | |
KR20050050542A (en) | A method and apparatus for anonymous call redirection in a wireless network | |
US20050249343A1 (en) | Method for conveniently adding contact information to a network-based address book | |
US6839555B2 (en) | Method and apparatus for supporting voice message services with automatic rebound in a wireless intelligent network | |
US6111943A (en) | Rapid call set-up for multiple leg telecommunications sessions | |
US6792264B1 (en) | Reception forcing method for mobile communication system, mobile communication system and managing center | |
US20070178894A1 (en) | Method and apparatus for rerouting terminations for CALEA targets through a predetermined surveilling MSC | |
EP1156654A2 (en) | Systems and associated methods for call merging without established call interruption | |
JP3376339B2 (en) | Call monitoring system using intelligent network system | |
US6330318B1 (en) | Method of and system for interrupting and parking calls in a switched telecommunications network | |
AU751585B2 (en) | Method and device in telecommunications system | |
JP2002510170A (en) | Caller confirmation | |
JP3715182B2 (en) | Intelligent network-based telephone system compatible with call waiting service | |
JP2002223295A (en) | System for limiting terminating call by number of originating party | |
JPH0451643A (en) | Malicious call incoming control system |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: AT&T MOBILITY II, LLC, GEORGIA Free format text: CHANGE OF NAME;ASSIGNOR:CINGULAR WIRELESS II, LLC;REEL/FRAME:021126/0415 Effective date: 20070420 |
|
AS | Assignment |
Owner name: AT&T MOBILITY II LLC, GEORGIA Free format text: CHANGE OF NAME;ASSIGNOR:AT&T MOBILITY II, LLC;REEL/FRAME:021143/0069 Effective date: 20070830 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |