VoIP and ENUM

In my last post I mentioned the problem of "Public User Identifiers" that are not or only partially public. This is the general problem of the NGNs to use IETF protocols and also part of the Internet Infrastructure on one side, but basically do not want to be connected really.

So what we have is:
- SIP Proxy not allowing you to connect
- SIP proxy filtering addresses
- Domain names reserved but not resolving (e.g. ims.3gppnetwork.org)
- "Public" IP addresses not reachable from the Internet and finally
- "Public" User Identifiers" valid only within certain networks:

I strongly recommend to read the publicly available GSMA document IR.65 IMS Roaming and Interworking Guidelines, especially section 8, to understand the problem they have first and then continue reading the text I posted this week on the TISPAN WG4 mailing list (and received no answer yet). Other GSMA PRDs may be downloaded from here.

------snip-----

Dear all,

Coming back from Stockholm, I re-read the public GSM-A document IR.65 "IMS Roaming & Interworking Guidelines" and here especially Section 8 "Addressing and Routing"

So I would like to get some questions answered from GSMA and also how TISPAN is dealing with these issues?

In Section 8.1 "User addressing" is clearly stated:

In addition to private used identity, every IMS user has one or more public user identities. The public user identity is used in e.g. user-to-user communication. For example, it might be included on a business card."

If I can include a PUI sip:richard.stastny@sonera.fi on my business card, I expect it to stand there alone and not with a footnote stating:
*) to be used only in A1/Vodafone/mobile IMS/TISPAN NGN/etc.
I expect it to be usable in PUBLIC like an e-mail address.

Q1, This implies that access from the Internet TO IMS is needed, how is this achieved?

Q2. How is the public DNS accessed from within an IMS network?

This two questions should be added to the issues in WG4TD18.

Public user identities can be used to identify the user's information within the HSS. Format of public user identity is either SIP URI (RFC 3261 & RFC 2396) or the "tel:"-URI format (RFC 2806), for example sip:clint.eastwood@acme.org or tel: +358405344455."

From the example given and other text one may come to the conclusion that IMS networks may host two types of Public User Identities:

A non-portable PUI in the form sip:user@sonera.fi
A portable PUI in the form sip:clint.eastwood@acme.org

The latter option is very interesting because it requires a hosting of a user provided domain name with the operator. This could be achieved by providing SRV records in the users domain pointing to a X-CSCF? On the public Internet.

There is only a BIG problem here, not only for acme.org type PUI, but even for sonera.fi type PUI as stated later in Section 8.4 "Interworking Specific Issues":

IMS interworking needs additional support regarding used domains, since recipient belonging to another operator is addressed with user-friendly public user identity such as mickey.mouse@sonera.fi instead of mickey.mouse@mnc123.mcc456.3gppnetwork.org. Originating operator needs to be able to route INVITE SIP request towards >recipient's I-CSCF based on only this sonera.fi domain.

Therefore there has to some method mapping sonera.fi domain and the corresponding
I-CSCF IP address. Logically this method would be DNS, but this is a bit problematic.

A BIT problematic? Is it? Now it comes:

Public DNS likely cannot be used in this, since I-CSCF IP addresses should not be available in public Internet. GRX DNS can neither be used, since GRX DNS should not be used to resolve public domains such as sonera.fi.

Again a Catch 22 ;-)

So if this even does not work for sonera.fi, how can one expect this to work for acme.org? You cannot use public DNS, and you cannot use GRX either.

The proposed ways out of this problem are problematic even for sonera.fi, they are impossible for acme.org:

There are some ways to solve this DNS usage issue; all of these require the originating operator maintaining some kind of system by itself to support IMS interworking.

Back to de-centralized management of all domain names?

This kind of distributed functionality is needed, since GRX DNS itself should not handle .com type of domain names.

Logically, because this would just shift the problem of maintaining a separate complete DNS system

Main issue is to route all IMS inter-operator related queries to stay within the operator community (i.e. use only inter-operator DNS hierarchy), thus Internet DNS should be queried only in the case of traffic destined to external networks.

Ok, that means a split horizon in GRX for all sonera.fi's, and nice to hear that THERE IS a way to query the Internet DNS. The question is only how this is done, because above this is excluded.

Three ways to solve this issue:
* Use operator's internal DNS (or other database) to store statically configured information mapping domain to I-CSCF IP address (not recommended due to amount of manual labour needed in configuring this static information)

Good that this is not recommended.

* Better solution would be to use a dynamic query, where each operator would deploy a "private operator DNS server", that replies with correct I-CSCF IP address when another "private operator DNS server" queries it. Addresses of these operator DNS servers itself would be stored in e.g. IR.21 database.
Implementing this does not necessarily require additional equipment, for example the existing operator DNS server that is needed anyway due to e.g. GPRS roaming, can be reused for this purpose. Benefit of using this is reducing the number of static mappings to just one thus reducing management efforts and also handling of domain names becomes easier

I do not understand this, can anybody please explain. I only have the impression that this does not solve the acme.com problem either


* Third possible solution uses domain name rewriting by adding "mncXXX.mccYYY.gprs" to the domains that need to be resolved (e.g. operator.com => operator.com.mnc123.mcc456.gprs), therefore making these public domains resolvable for the GRX DNS. Rewriting can be done by the CSCF using internal rewrite lists mapping used public domain name and the corresponding MNC & MCC. But a better solution is to utilize NAPTR (Naming Authority Pointer Resource Record of DNS, RFC 3401-4) domain rewrite rules in the local operator DNS,
If DNS solution is used, then CSCF sends a query for DNS concerning the public domain to be resolved. DNS reply contains the rewritten domain name, fetched from the domain specific NAPTR field. Supporting this kind of functionality means that each operator would maintain a list of its IMS partners in its local DNS
Note: The operator should register the domain used in public user identity in order to prevent any problems. Also, it might be beneficial if operators could agree on the used domain model for IMS public user addressing, e.g. ims.operator.com. However, various different domains can be handled, as long as everybody is aware of which domain belongs to which operator. For example, these domains could be listed in IR.21 database.

I also do not understand this proposal in detail, but it also works only for known operator names such as sonera.fi and not for acme.com

Since operator.com type of domains can exist also in public Internet, care is needed with domain queries in order to avoid mixing these two separate issues. For example it might be possible for IMS user to connect also to fixed line SIP clients, therefore this fixed line recipient (such as elvis.presley@graceland.com) needs to be discovered by utilizing normal public internet DNS queries. One solution could be to first check every outgoing domain with internal mapping mechanism and if no I-CSCF is found, then query this domain from public internet DNS and route it there.

Now this is an interesting one, because here at least outbound calls to other "operator domains" such as "sip:elvis.presley@graceland.com" are mentioned, so

1. Again you need to access the public Internet DNS and
2. you also need to interconnect with the public Internet outbound.

This raises the minor question how to "call back" into the IMS?
And this loops back to my first question raised:
This implies that access from the Internet TO IMS is needed, how is this achieved?