One or more implementations of communication systems described in the Appendix provide telephone services to users at terminals 110, which are serviced though a mobile telephone system that includes a mobile backbone 120, by a voice server 154, such as a premised IP-based PBX system or a network-based IP Centrex system, that is accessed over a data network. For example, users at terminals 110 can user private dialing plans and access enhanced services implemented by the voice server 154. A gateway NCG 182 couples the mobile backbone 120 to the voice server 154 by communicating with the mobile backbone using conventions mobile telephone protocols (e.g., IS-41, GSM), and by communicating with the voice server 154 using Internet Protocol (IP) based signaling, for example, using the Session Initiation Protocol (SIP) from control signaling and the Real Time Protocol (RTP) for audio data.
IP PBX and Centrex vendors would like to make their feature sets available to users with mobile handsets on a mobile telephone network. To provide features while a call is being setup (such as voice mail access or no-answer transfer), calls involving such users are routed through the voice server 154, which may for example be an Enterprise IP PBX of IP Centrex server. The gateway NCG 182 plays a role in this setup by reacting to WIN/CAMEL trigger messages from the cellular network and using those messages to route a subscriber's calls to the voice server. A sequence of interchanges between elements in the communication system for the purpose of call setup is shown in
The approach illustrated in
Referring back to
As described in incorporated applications Ser. No. 11/492,698 and PCT/US2006/028755, one way to signal “mid-call” requests is to encode them in the audio path between the mobile telephone 110 and the gateway NCG 182, for example, as DTMF digits that are interpreted and converted to their corresponding PBX/Centrex signaling (e.g., using the SIP protocol) by the gateway NCG.
Although such in-band DTMF-based signaling can provide access to mid-call features, alternative ways of signaling can provide certain advantages. Three alternatives for signaling mid-call actions to the gateway NCG are described below. In each case a cellular feature that can occur in the middle of a call is used to signal the mid-call request to the NCG. The first uses an added call attempt (in CDMA the additional call attempt implies Three-Way Calling, in GSM this is simply a second call) as a way to deliver mid-call requests using the same WIN/CAMEL triggering mechanism described above. The second is a similar approach, but uses SMS messaging to signal the request to the NCG during a call (it should be noted that if the SMS approach proves viable, it could also supplant the need for WIN/CAMEL triggers). The third alternative uses a GSM feature called USSD (Unstructured Supplemental Service Data), which allows feature requests from a subscriber to be passed transparently to a USSD service platform.
In GSM and CDMA it is possible to place an additional call during an existing call. In CDMA, this is normally done to establish a Three-Way call; in GSM a second call is placed. In this first alternative, the additional call attempt is used to signal “mid-call” requests to the NCG using special dialing sequences such as a *xx sequence . The additional call originations causes the same type WIN/CAMEL trigger to be sent to the NCG as occur during the initial call setup. Therefore, the NCG receives the mid-call triggers for special mid-call requests as well. When the NCG receives a trigger for a mobile telephone for which it is already mediating a call, instead of setting up a call, the NCG applies the appropriate mid-call request to a call in progress, for example, based on the digits dialed at the mobile telephone. An example of this approach is shown in
As an example of this approach, when the mobile user dials the three-way call using a special “star” code, a WIN OriginationRequest message is sent by the mobile network to the NCG. If the NCG recognizes this sequence, then instead of setting up the new call, it will end that call (i.e., the additional call that the mobile network thinks was requested by the user) and applies the requested actions to the initial call (in this case sending a REFER message to the PBX/Centrex for the first call to invoke a call transfer request). (Depending on the user experience, it may be necessary to first route the additional call to the NCG prior to ending it so that the user does not hear or see confusing error messages).
In the above example, the NCG is aware of the specific feature request. In a variant of this approach, for PBX/Centrex call servers that support mid-call DTMF features, the NCG could simply signal the proper “flash” message, which would tell the call server to collect and interpret DTMF digits from the subscriber. This variant is illustrated in
Advantages of this first approach include one or more of not requiring ongoing DTMF monitoring in calls by the gateway NCG, limiting of extra signaling only to when mid-call triggers are needed, and signaling sequences for triggers that can be short enough to remember, so no client changes would be needed. A limitation of certain implementations of this first approach is that they may “use up” a three-way calling on the handset, so it may not be possible to mid-call trigger during an existing CW/TWC call (note however that this is only an issue if the MSC's TWC multiple line calling features are is used. This approach allows the PBX/Centrex three-way calling features to be used).
The second approach is similar to the first approach described above, but uses SMS messaging to signal the mid-call request to the gateway NCG in response to a user input. An application executing on the mobile handset sends an SMS to a special destination number that identifies the NCG. This message is sent (via the mobile subscriber's and NCG's SMSC/MC) to the NCG, which then applies the same mid-call signaling as in the previous examples. An example is shown in
An advantage of this second approach over the first approach is that it is still possible to use the MSC's TWC and CW features. A possible disadvantage of this approach is that it requires a special application in the handset to send the SMS message—when using TWC, it is possible for users to dial the start code themselves, but it would likely be too awkward to send a specially encoded SMS message. Also, to get the SMS messages to the NCG would require a “dummy” SMS account on the NCG, and there is added cost to deliver the SMS message to/from the subscriber (though mid-call features are relatively infrequent). Another possible concern is the delay when sending the SMS message, since it needs to be sent within a second or two to provide an adequate user experience, and SMS message delivery times may exceed that (a possible way to avoid this delay is to configure the NCG as the subscriber's MC/SMSC).
The third approach is similar to the second approach. GSM systems have feature called USSD (Unstructured Supplemental Service Data) that allows feature requests from a subscriber to be passed transparently to a USSD service platform. Since USSD requests can occur during an active call, these can be used to signal mid-call requests. The cellular network can be configured to send particular USSD requests representing mid-call requests to the NCG, and it can then implement the mid-call signaling with the PBX or Centrex. An example is shown in
This approach avoids the delays associated with SMS messaging, and it doesn't require an extra call. A possible disadvantage of this third approach is that it is not available on CDMA systems, which currently have no USSD equivalent.
It is to be understood that the foregoing description is intended to illustrate and not to limit the scope of the invention, which is defined by the scope of the appended claims. Other embodiments are within the scope of the following claims.
This application is related to U.S. application Ser. No. 11/492,698, filed on Jul. 25, 2006, titled “Mobile and Packet-Based Call Control,” and to International Application PCT/US2006/028755 also filed on Jul. 25, 2006. These applications are incorporated herein by reference.