Interworking with Media Fallback

FIELD OF THE INVENTION

The present invention relates to a method, system, gateway device and computer program product for enabling interworking between a first network domain which does not support downgrading of media compositions, and a second network domain which supports downgrading of media compositions.

BACKGROUND OF THE INVENTION

In order to achieve access independence and to maintain a smooth interoperation with wired terminals across the Internet, an IP multimedia subsystem (IMS) core network, specified e.g. in the 3GPP (Third Generation Partnership Project) specification TS 23.228, has been developed to be conformant to IETF (Internet Engineering Task Force) "Internet Standards". The IMS enables network operators of mobile or cellular networks to offer their subscribers multimedia services based on and built upon Internet applications, services and protocols. The intention is to develop such services by mobile network operators and other third party suppliers including those in the Internet space using the mechanisms provided by the Internet and the IMS. The IMS thus enables conversion of, and access to, voice, video, messaging, data and web-based technologies for wireless users, and combines the growth of the Internet with the growth in mobile communications.

In this connection, it is also studied how interworking between 3GPP IMS and legacy circuit-switched (CS) core network domains of regular telephone users, such as users of second or third generation mobile networks, fixed public-switched telephone networks (PSTN) or fixed integrated services digital networks (ISDN), can be achieved. "Interworking" means that systems or components, possibly from different origins, work together to perform some task. Thus, interworking depends on standards to define the interfaces between the components. The term implies that there is some difference between the components which, in the absence of common standards, would make it unlikely that they could be used together. For example, software from different companies, running on different hardware and operating systems can interwork via standard network protocols.

A cellular network, i.e. a Public Land Mobile Network (PLMN) can be regarded as an extension of networks with CS domains and packet switched (PS) domains

within a common numbering plan and a common routing plan. The PLMN infrastructure is logically divided into a core network (CN) and an access network (AN) infrastructure, while the CN infrastructure is logically divided into a CS domain, a PS domain and an IMS. The CS and PS domains differ by the way they support user traffic. These two domains are overlapping, i.e. they contain some common entities. A PLMN can implement only one domain or both domains. In particular, the CS domain refers to the set of all CN entities offering CS type of connections for user traffic as well as all the entities supporting the related signaling. A CS type of connection is a connection for which dedicated network resources are allocated at the connection establishment and released at the connection release. The PS domain refers to the set of all CN entities offering PS type of connections for user traffic as well as all the entities supporting the related signaling. A PS type of connection transports the user information using autonomous concatenation of bits called packets, wherein each packet can be routed independently from the previ- ous one. The IMS domain comprises all CN elements for provision of IP multimedia services comprising audio, video, text, chat, etc. and a combination of them delivered over the PS domain.

The Session Initiation Protocol (SIP) is an application-layer control protocol which can be used in IP based networks, such as the IMS, for creating, modifying and terminating sessions with one or more participants. These sessions include Internet multimedia conferences, Internet telephone calls and multimedia distribution. Members in a SIP session can communicate via multicast or via a mesh of unicast relations, or a combination of these. In the full end-to-end use of SIP no specific requirements for interworking between non-SIP users, not having a SIP capable terminal equipment, have been considered.

On the other hand, CS networks may use a signaling protocol called Common Channel Signaling System #7 (more commonly called "SS7" or "C7"). In SS7 networks, ISUP (Integrated Services Digital Network (ISDN) User Part) signaling messages are used to set-up, manage and release calls between central office switches. ISUP messages also carry caller ID information, such as the calling party's telephone number and name. ISUP is used for both ISDN and non-ISDN calls between central office switches.

In 3GPP Rel-6 specification TR 23.903, re-dialing scenarios are defined to be performed by a terminal device (or user equipment (UE) in 3GPP terminology) when the called party does not support the requested video call, or when the call needs

to swap between speech and video or vice versa. The UEs terminate the ongoing call and one of the UEs initiates a new call (i.e., redialing).

Additionally, 3GPP Rel-6 has produced a specification TS 29.163 for speech/audio interworking between IMS and CS networks.

However, when an IMS terminal tries to make a multimedia or video call to a CS terminal that is behind an ISUP leg, the IMS/CS interworking point (e.g., media gateway control function (MGCF)) will turn the request to a video-only request to the ISUP leg, because the ISUP network does not support downgrading of media compositions, i.e., there is no fallback mechanism in ISUP. The video call set-up will then always fail when the called terminal does not support video calls or when the called user does not want to receive a video call or when the terminating network does not support a video call.

More generally, when a terminal in a domain (second domain) supporting downgrading of the media composition (i.e. removing one or more of the requested or used media components) tries to make a multimedia call to another terminal in another domain (first domain) that does not support downgrading of the media composition, the domain interworking point will have to use a fixed media composition towards the second domain. The call set-up will then always fail when the called terminal does not support the requested fixed media composition or when the called user does not want to receive a call with the requested fixed media composition or when the terminating network does not support the requested fixed media composition.

SUMMARY

It is therefore an object of the present invention to provide a method and system for enabling flexible interworking between a domain supporting downgrading of the media composition (i.e. removing one or more of the requested or used media components), e.g. an IP based domain, and a domain not supporting downgrading of the media composition, e.g. a legacy ISUP circuit-switched domain.

This object is achieved by a method comprising:

• starting to establish a call or session with a first media composition in a first leg of a first network domain which does not support downgrading of media compositions, by transmitting a first call set-up request for said first media composition to said first network domain in response to the receipt of a set- up message for said first media composition at a gateway control function from a second network domain which supports downgrading of media compositions;

• releasing said call or session and setting up a call or session for a down- graded second media composition in said first network domain by said gateway function, in response to a rejection of said first call set-up request, by transmitting a second call set-up request from said gateway function to said first network domain via said first leg; and

• updating a call or session in a second leg of said second network domain by said gateway function to match said downgraded media composition being established in said first leg.

Additionally, the above object is achieved by a gateway device comprising:

• a call control unit for establishing a first call with a first media composition in a first leg of a first network domain, which does not support downgrading of media compositions, said call control unit comprising at least one call set-up unit configured to transmit a first call set-up request for said first media composition to said first network domain via said first leg in response to the receipt of a set-up message for said first media composition; and

• a session control unit for establishing a session with said first media composition in a second leg of a second network domain which supports down- grading of media compositions, in response to the receipt of said set-up message;

• wherein said at least one call set-up unit is configured to transmit a second call set-up request for a downgraded second media composition to said first network domain via said first leg in response to the receipt of a rejection message which indicates rejection of said first call set-up request; and

• wherein said session control unit is configured to update said session with said first media composition in said second network domain to match the call with said downgraded second media composition being established in said first leg.

Furthermore, the above object is achieved by a computer program product comprising code means for producing the above method steps when run on a computer device.

Accordingly, usability and flexibility can be added in call and/or session establish- ment from network domains (second network domains such as IP based networks or other packet switched networks) supporting media downgrading to network domains (first network domains such as CS networks or other legacy networks) not supporting media downgrading. Thus, a fallback to a downgraded media composition (e.g., speech) can be provided even if the first network domain is inherently a non-fallback network. Moreover, standard devices for the second network domain can be used, while no extra decision logic is required at these terminals (or from the user) for making a new set-up trial in case of a failure.

According to the proposed approach, when the called party rejects the first call setup, the gateway control function or device sets up a new call on the terminating leg and may thus maintain the originating leg. Then the gateway control function or device modifies the originating leg and connects it with the new call on the terminating leg. From the user's point of view the whole procedure appears as a (service) fallback.

It is to be pointed out that the first and second media compositions could be any single medium or any media combination and is by no means intended to be restricted to the compositions described in the exemplary embodiments. The same applies to the first and second network domains. In particular, the result of the proposed fallback procedure may be not only audio/speech but any single media or media combination.

Additionally, it is to be noted that the term "call leg" is used to designate a logical connection between two gateways or switches or between a gateway or a switch and a terminal device. As a simple example, when a number is dialed, one active call leg is set up. When the other party picks up, and the two lines are connected together, two call legs are in action.

The first leg may be connected to the second leg in the second network domain, to form a single connection.

The second leg may be established in response to the receipt of the set-up mes- sage at the gateway control function, and maintained after the rejection of the first call set-up request.

Additionally, an update message may be transmitted via the second leg to update the media to the downgraded second media composition. In a first example, the update message may be a SIP UPDATE message. In an alternative second ex- ample, the update message may be a SIP 200 OK response.

As a specific example, the set-up message may be a SIP message or any other IP based message which triggers set-up of a session. The first and second call setup requests may be initial address messages.

Further, the rejection of the first call set-up request may be signaled by a release message.

In a particular implementation example, the second network domain is an IP multimedia subsystem and the first network domain is a circuit switched network. In this specific case, the method may comprise establishing a multimedia or video call in an Integrated Services Digital Network User Part (ISUP) leg of a circuit- switched network in response to a multimedia or video session establishment with a Session Initiation Protocol (SIP) INVITE message at a media gateway control function, by transmitting an ISUP initial address message (IAM) for the multimedia or video call to the circuit-switched network via the ISUP leg; releasing the multimedia or video call and establishing a speech-only call in the ISUP leg of the cir- cuit-switched network, in response to the receipt of an ISUP Release (REL) message, by transmitting an ISUP IAM for a speech-only call to the circuit-switched network via the ISUP leg.

Additionally, the gateway device may comprise an interworking unit (e.g., media gateway (MGW)) for connecting the first leg to the second leg established in the second network domain, to form a single connection.

Furthermore, the gateway device, which may be a media gateway control function, may comprise a session control unit for establishing the second leg in response to the receipt of the set-up message, and for maintaining the second leg after the rejection of the first call set-up request. The session control unit may be configured to transmit the update message via the second leg to update the media to the downgraded media composition.

Further advantageous modifications or developments are defined in the dependent claims.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will now be described on the basis of an embodiment with reference to the accompanying drawings in which:

Fig. 1 shows a schematic diagram of a network configuration in which the present invention can be implemented;

Fig. 2 shows a schematic diagram of an IMS to CS network logical interworking architecture according to the embodiment;

Fig. 3 shows a schematic block diagram of a gateway device according to the embodiment;

Fig. 4 shows a schematic block diagram of a computer-based implementation of the embodiment;

Fig. 5 shows a schematic flow diagram of a control method according to the embodiment;

Fig. 6 shows a signaling diagram indicating an interworking signaling according to the embodiment, when SIP preconditions are used; and

Fig. 7 shows a signaling diagram indicating an interworking signaling according to the embodiment, when SIP preconditions are not used.

DESCRIPTION OF THE EMBODIMENT

The embodiment will now be described based in an exemplary architecture in which an IP based network is connected to a CS network via a gateway device with an interworking functionality. However, the present invention can be applied to any other network combination.

Fig.1 shows a schematic block diagram of the exemplary network architecture according to the embodiment, wherein an IP based network 10, e.g., a SIP based IMS network, is connected to a CS network 10, e.g., an ISUP-based network, via a gateway device, e.g., a media gateway control function (MGCF) 20, which controls a media gateway (MGW) 40. The gateway device 20 is arranged to control the parts of a call state which pertain to connection control for media channels in the media gateway 40. It may communicate with call session control functions (CSCFs), e.g., as defined in the 3GPP specification TS 23.228.

The gateway functionality may be achieved at the gateway device 20 by perform- ing protocol conversion between CS-based and the IP based call control protocols, e.g., between ISUP and SIP call control protocols.

The media gateway 40 is arranged to terminate bearer channels from the CS network 30, and media streams from a IP based network 10. The media gateway 40 may support media conversion, bearer control and payload processing. It interacts with the gateway device 20 for resource control, owns and handles resources such as echo cancellers etc., and may comprise corresponding codec functions.

Interworking between the IP based network 10 and the CS network 30 may be achieved by using the INVITE method, e.g. in a SIP based functionality for setting- up a session. In particular, capability is added for subscribers located in the CS network 10 to be invited in a conference or call initiated by using the respective SIP functionality. To achieve this, a SIP user sends an INVITE message towards the gateway device 20, where the request URI may be a telephony URI (TEL URI), such as "+442345567@operator.com". When the gateway device 20 receives the INVITE message, it may first send an ISUP initial address message (IAM) to the CS network 30 to thereby establish a first call leg L1 towards the terminal device of the subscriber located in the CS domain, i.e. the CS network 10. Then, the gateway device 20 establishes a second call leg L2 towards the SIP user whose termi-

nal device or UE is connected to the IP based network 10. The SIP user can also be e.g. a conference device.

After having established both call legs L1 and L2 the gateway device 20 connects these call legs to one session, wherein the user plane connections UPC are con- nected via the media gateway 40. In the above specific example, the gateway device 20 maps the received SIP INVITE message to the ISUP IAM to be forwarded to the CS network 30.

In the SIP based example, a call leg is identified by the combination of call-ID, originator (From header) and final recipient (To header). SIP Uniform Resource Locators (URLs) may be used within SIP messages to indicate the originator, current destination (Request-URI) and final recipient of a SIP request, and to specify redirection addresses.

As an alternative, the Bearer Independent Call Control (BICC) protocol may be used instead of ISUP when the invited party is located outside the IMS but IP bearer can still be utilized in the gateway device 20 towards the invited party.

Fig. 2 details shows a schematic block diagram of a more specific architecture of a reference model required to support interworking between 3GPP IMS and CS networks according to the embodiment.

The call control protocol which may be applied across an Mg reference point between a CSCF 70 and the gateway device (e.g., MGCF) 20, may be based on the 3GPP profile of SIP as defined in accordance with the 3GPP specification TS 24.229. Additionally, an Mn reference point describes the interfaces between the gateway device 20 and the media gateway (e.g., MGW) 40, and may have proper- ties as detailed in the 3GPP specification TS 29.332.

The call control protocol which may be applied across an Mj reference point between a breakout gateway (e.g., breakout gateway control function (BGCF)) 60 and the gateway device 20 may be based on the 3GPP profile of SIP as defined in accordance with the 3GPP specification TS 24.229.

Furthermore, an Mb reference point provides a connection between the media gateway 40 and various network entities 80, such as a user equipment (UE) (e.g., via a General Packet Radio Services (GPRS) Tunnel Protocol (GTP) Tunnel to a

GPRS Gateway support node (GGSN)), a multimedia resource function processor (MRFP), or an application server, e.g., in accordance with the 3GPP specification TS 23.002, which is IPv6 based.

A signaling gateway function (SGW) 50 is configured to perform call related signaling conversion to or from BICC/ISUP based message transfer part (MTP) transport networks to BICC/ISUP based stream control transmission protocol (SCTP/IP) transport networks, and forwards the converted signaling to or from the gateway device 20. The functionality within the SGW 50 may be in accordance with the 3GPP specification TS 23.002.

The gateway device 20 is configured to control the media gateway 40 and provides a control plane interface to perform SIP to BICC or SIP to ISUP call related signaling interworking. This functionality may be in accordance with the 3GPP specification TS 23.002.

The media gateway 40 provides a user plane interface between the IP based domain and the CS domain. This functionality may be in accordance with 3GPP specification TS 23.002.

According to the embodiment, when an IMS UE establishes a multimedia/video session via the CSCF 70 and the gateway device 20 towards a CS UE behind a CS leg (e.g., ISUP leg) in the CS network 30, the interworking point, i.e. the gateway device 20, sends a corresponding video call setup towards the called party in the CS network 30.

If the CS network 30 or the called party rejects the video call setup, possibly with a cause code indicating the reason for the rejection, the gateway device 20 maintains the multimedia/video session being established in the IP based network, sends a new setup with a speech-only request to the called party, and continues the leg establishment with speech only.

Fig. 3 shows a schematic block diagram indicating those functionalities of the gateway device 20, which are relevant for understanding the embodiment.

A session control functionality or unit 201 is configured to transmit, receive, process and generate session control signaling required to establish and maintain the IP based leg towards the IP based network (e.g., IMS network). Additionally, a call

control functionality or unit 204 is configured to transmit, receive, process and generate call control signaling for the CS leg towards the CS network 30. When both legs have been established, they are connected via an interworking function 205 (which may be for example the MGW 40 of Figs. 1 and 2) to obtain a single connection.

When the session control unit 201 receives a multimedia or session set-up message, e.g., a SIP INVITE message, it triggers or activates a multimedia (MM) call set-up functionality or unit 203, which may be provided in the call control unit 204, to initiate a call set-up procedure at the call control unit 204 for establishing a video or multimedia call. In response to the receipt of a subsequent set-up release message at the call control unit 204, the MM call set-up unit 203 triggers or activates a fallback (FB) to a speech call set-up functionality or unit 202 which may also be provided in the call control unit 204 and which accordingly initiates a call set-up procedure at the call control unit 204 for the speech call.

It is however noted that the speech call set-up and MM call set-up units 202, 203 may be arranged as a single integrated unit which provides control signaling for the CS legs, or may even be provided outside the call control unit 204.

Additionally, it is noted that the functionalities described in connection with Fig. 3 may be implemented as discrete hardware or signal processing units, or alternatively as software routines or programs controlling a processor or computer device to perform the processing steps of the above functionalities.

Fig. 4 shows a schematic block diagram of a software-based implementation of the embodiment. Here, the gateway device 20 comprises a processing unit 210, which may be any processor or computer device with a control unit which performs control based on a software routines of a control program stored in a memory 212 provided in or at the gateway device 20. Program code instructions are fetched from the memory 212 and are loaded to the control unit of the processing unit 210 in order to perform the processing steps of the above functionalities described in connection with Fig. 3. These processing steps may be performed on the basis of input data Dl and may generate output data DO, wherein the input and output data Dl, DO may related to the control signaling required at the gateway device 20.

Fig. 5 shows a schematic flow diagram indicating the interworking method achieved by the control processing at the gateway device 20 according to the em-

bodiment. The processing of Fig. 5 starts in response to the receipt of a multimedia or video session set-up message from the IP based network.

The call control unit 204 is controlled by the MM call set-up unit 203 to send in step S101 a multimedia or video call set-up request via the CS leg to establish a multimedia or video call. Then, in step S102, it is checked by the call control unit 204 or by the MM call set-up unit 203 whether a set-up release message or indication is received from the CS network 30. If so, the CS multimedia or video call is released and a speech call set-up request is send in step S103 to establish a speech call, based on a control of the speech call set-up unit 202 which has been triggered by the MM call set-up unit 203 (or alternatively by the call control unit 204).

In step S104 the IP based leg is updated to match the speech call in the CS leg, i.e. the video media stream / media component is dropped from the IP based leg.

The procedure continues with step S105, where the CS leg and the IP based leg are connected via the interworking function 205 of the gateway device 20 (e.g., the MGW 40) to obtain a single connection between the calling IP based terminal de- vice (or UE) and the called CS terminal device (or UE). If it is determined in step S102 that no set-up release has been signaled by the CS network 30, the procedure also continues with the step S105.

Fig. 6 shows a more detailed signaling diagram of a first implementation example of the embodiment, which is based on a specific implementation example related to an interworking between a SIP based IMS network and an ISUP-based CS network. In this first example, SIP preconditions are used.

In step 1 , a multimedia session is established from the IMS network with a SIP INVITE message indicating possible multimedia protocols (H.263, H.261 ) and codecs (MP4V-ES, AMR) and that preconditions are not met. In response to this SIP INVITE message, the gateway device 20 transmits in step 2 an ISUP IAM message via the CS leg. Thereby, the desired video call establishment from the gateway device 20 towards the CS party is initiated with the ISUP IAM message. In steps 3 and 4, a SIP 100 Trying message and a subsequent SIP 183 acknowledgement indicating selected video codec (H.263) and audio codec (AMR) are returned to the SIP party. Then, in step 5, an ISUP REL message with a cause code is received from the CS network 30. In response thereto, the CS video call is

released and a decision is made at the gateway device 20 to initiate a speech call instead (step 6).

Meanwhile, the IMS party has issued a SIP PRACK message (step 7) which is acknowledged by the gateway device 20 with a SIP 200 OK response (step 8) to maintain the IMS leg.

Then, in step 9, an ISUP IAM message for the speech call setup is sent via the CS leg. Thereby, a fallback to speech is automatically initiated at the gateway device 20 by setting up a speech-only call towards the CS party without any signaling or other activity at the IMS party. Additionally, a SIP UPDATE message is transmitted in step 10 by the session control unit 201 of the gateway device 20 towards the IMS party in order to update the media of the IMS leg to audio-only. The media update is acknowledged by the IMS party in step 11 with a SIP 200 OK (UPDATE) message, which is again acknowledged by the gateway device 20 in step 12 with a SIP ACK. In step 13, the IMS party sends a SIP UPDATE message to indicate that preconditions are now met and the interworking function 205 at the gateway device issues in step 14 a corresponding ISUP COT message towards the CS party. The CS network sends in step 16 an ISUP ACM message and the inter- working function 205 at the gateway device 20 transmits in step 17 a SIP 180

Ringing message to the IMS party to indicate alerting at the called CS party. Then, in response to the receipt of an ISUP ANM message from the CS party in step 18, the interworking function 205 of the gateway device 20 issues in step 19 a SIP OK (INVITE) message towards the IMS party which responds in step 20 with a finaliz- ing SIP ACK acknowledgement, so that both legs are connected and the call is in an active state.

Fig. 7 shows a corresponding signaling diagram of a second implementation example of the embodiment, which is also based on the above specific implementa- tion example related to the interworking between a SIP based IMS network and an ISUP-based CS network. Contrary to the first example, this second example covers a case where SIP preconditions are not used.

In step 1 , a multimedia session is established from the IMS network with a SIP INVITE message indicating possible video codecs (H.263, MP4V-ES) and an audio codec (AMR). In response to this SIP INVITE message, the gateway device 20 transmits in step 2 an ISUP IAM message via the CS leg. Thereby, the desired video call establishment from the gateway device 20 towards the CS party is initi-

ated with the ISUP IAM message. As SIP preconditions are not used here, only a SIP 100 Trying message is returned in step 3 to the SIP party. Then, in step 4, an ISUP REL message with a cause code is received from the CS network 30. In response thereto, the CS video call is released and a decision is made at the gate- way device 20 to initiate a speech call instead (step 5).

Then, in step 6, an ISUP IAM message for the speech call setup is sent via the CS leg. Thereby, a fallback to speech is automatically initiated at the gateway device 20 by setting up a speech-only call towards the CS party without any signaling or other activity at the IMS party. In step 7, the gateway device 20 sends an ISUP COT message towards the CS party. The CS network sends in step 8 an ISUP ACM message and the gateway device 20 transmits in step 9 a SIP 180 Ringing message to the IMS party to indicate alerting at the called CS party. Then, in response to the receipt of an ISUP ANM message from the CS party in step 10, the gateway device 20 issues in step 11 a SIP OK (INVITE) message with indication of only an AMR speech codec (speech only) towards the IMS party which responds in step 12 with a finalizing SIP ACK acknowledgement, so that both legs are connected and the call is in an active state.

Thus, as no preconditions are used here, the update of the IP session can be performed simply by the 200 OK response to the SIP INVITE. The SIP UPDATE message and some other messages (indicated as dotted arrows in Fig. 6) of the first example are not required, so that signalling load can be reduced.

To summarize, a method, network system, gateway device, and computer program product have been described, for enabling interworking between a first network domain which does not support downgrading of media compositions, and a second network domain which supports downgrading of media compositions. Establishment of a call with a first media composition is started in a first leg of the first network domain, by transmitting a first call set-up request for the first media composition from a gateway control function to the first network domain in response to the receipt of a set-up message at the gateway control function from a second network domain. The call with the first media composition is released and a call with a downgraded second media composition is set up by the gateway con- trol function in the first network domain, in response to a rejection of the first call set-up request, by transmitting a second call set-up request for the downgraded second media composition from the gateway control function to the first network domain via the first leg. A session with the first media composition is updated in

the second network domain to match the call with the downgraded second media composition being established in the first leg. Thereby, a fallback to the downgraded second media composition is supported even if the first network domain is inherently a non-fallback network, while standard terminals for the second network domain can still be used and no user interference in the second network domain is required .

It is to be noted that the present invention is not restricted to the embodiments described above, but can be implemented in other gateway devices or functionalities where interworking between a fallback capable network (i.e. a network that sup- ports downgrading of the media composition of a session by removing one or more media components, for example removing the video component from the original composition of audio and video), e.g. an IP based network, and a network not supporting fallback, e.g. a legacy ISUP, network is provided. Any set-up message from a fallback capable network may trigger the proposed procedure with initial first call set-up for the requested first media composition and subsequent autonomous fallback to the second call set-up for a downgraded second media composition. Thus, the medium to which fallback is initiated does not necessarily have to be speech/audio. It can be any medium or media composition. The described mechanism can be applied also for example to a fallback from multimedia (with audio, video, data, etc.) to audio and video or to any single medium or any other media composition requested in the original session establishment request. Hence, the proposed solution can be implemented in any interworking procedure involving a fallback capable domain, like an IP based domain, and a non-fallback capable domain, like a legacy CS network domain.