Re: [Enum] ENUM Query

[Bernie Hoeneisen <[e-mail]>]

Hi Wayne

To better assess the scope, I also have some questions:

1) What URI Schemes are currently specified to be used in the NAPTR RRs of 
the ENUM response (for each of the services RCS and MMTEL)?

2) How likely do you think is it that further URI Schemes will be added 
in future (for each of the services RCS and MMTEL)?

3) How do you think that further services (in addition to RCS and MMTEL) 
will be added in future?

4) What is your prediction on SMS to be moved to RCS in future?

All the Best,
  Bernie Hoeneisen, IESG Appointed Designated Expert for ENUM

--

http://ucom.ch/
Modern Telephony Solutions and Tech Consulting for Internet Technology


On Wed, 4 Mar 2020, Wayne Cutler wrote:

> 
> 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]> 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]
> https://www.ietf.org/mailman/listinfo/enum
> 
>  
> 
> .
> 
> 
>