Re: [Enum] ENUM Query

[Wayne Cutler <[e-mail]>]

Hi Brian,
Thanks for your questions. Please see below in line..

Regards,
Wayne

From: Brian Rosen [mailto:[e-mail]]
Sent: 03 March 2020 17:51
To: Wayne Cutler <[e-mail]>
Cc: [e-mail]
Subject: Re: [Enum] ENUM Query

“This email has been received from an external source – please review before actioning, clicking on links, or opening attachments”

One question: are the services that are provided on these two networks distinct?
WC - Yes.  The service-sets offered on the two networks do not intersect.

Do one or both of them supply messaging service?  Calling Service?
WC - Yes.  RCS offers a number of messaging services.  MMTEL offers voice and video calling.  For historic reasons,  SMS (which is technically a messaging service) is part of the service-set associated with MMTEL. So, in the dual-IMS core scenario, one IMS core provides voice/video/SMS and the second IMS Core provides RCS Messaging.

If both, then how is a message/call to the TN routed?
WC - GSMA defines two disjoint sets of services, which we refer to as RCS and MMTEL.  The desire is that the ENUM response provide 2 URIs, one for each service-set, each of which resolve to an entry point to the network providing that service-set.  These URIs can be the same or different (i.e. covering the single/dual IMS core(s) use cases).

I think we would want to have some service differentiation as the discriminator if its one network that supplies each service.
WC - Agreed.  GSMA is responsible for the mapping of service requests to a service-set.  We intend that the ENUM response provide a URI for each service-set.  What seems to be lacking is an ENUM service for the RCS Messaging service-set.

Brian


On Mar 3, 2020, at 6:00 AM, Wayne Cutler <[e-mail]<mailto:[e-mail]>> wrote:

Dear ENUM List,
I have an ENUM Registry query that I’d like to run past you to solicit expert feedback/recommendations on the best way forward.

The scenario that is applicable concerns the deployment of MMTEL (Multi-Media Telephony) & Advanced RCS Messaging by MNOs (Mobile Network Operators). For historic reasons, there are two different ways that MNOs have deployed MMTEL & RCS Messaging services :-
i)                    Both MMTEL & RCS Messaging services are provided by a single IMS Core Network and the UE registers to this single IMS core to receive all of its services. All terminating service requests are required to be routed to the single IMS network. Therefore, the existing ENUM infrastructure is fine for this scenario as the telephone number of a given user resolves to a SIP URI that identifies the target IMS core network.
ii)                   The MMTEL and RCS services are provided by 2 separate IMS Core Networks - one for MMTEL and one for RCS Messaging. In this scenario, the UE registers to both IMS core networks (so-called "dual registration") and gets its full suite of services via a combination of the 2 IMS cores.  The same IMPU (IMS Public User Id) is used for both IMS registrations and the same phone number is used to route terminating service requests for both MMTEL & RCS Messaging related requests. Therefore, in this case, an ENUM request for a given telephone number needs to be able to identify 2 different target IMS cores. The related service request can then be passed onto the correct IMS core based on the its context (i.e. does the request relate to a MMTEL or RCS Messaging service). This is the scenario that doesn't seem to be covered in the existing ENUM Registry.

So, the problem we have is how to resolve a single telephone number to 2 different SIP URIs. Looking at the existing ENUM registry, there seems to be 3 options :-
•       Enhance the current ProtocolBasedClass of SIP as defined in RFC 3764 to add a sub-type - e.g. "SIP/MMTEL" & "SIP/RCS" - with the absence of a sub-type meaning "all services".
•       Re-use (or perhaps re-interpret?) an existing result (e.g. ApplicationBasedClass of IM or unifmsg) to mean RCS Messaging - but this feels like a kludge,
•       Define a new ENUM registry entry to identify RCS Messaging.

I would be grateful of any advice / recommendation that you have and am happy to answer any further questions for clarification.

Best Regards,
Wayne Cutler


.
_______________________________________________
enum mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/enum<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fenum&data=02%7C01%7Cwcutler%40gsma.com%7Ca3a3a076ea7d438c93e908d7bf9b816b%7C72a4ff82fec3469daafbac8276216699%7C0%7C0%7C637188546946136534&sdata=%2FuEdiPIO68Sfj%2F7CSf3O9KnP%2BXpUTvoq27CkTBSspGI%3D&reserved=0>


.