Subject: [Enum] Comments on draft-lind-enum-callflows-03.txt

From: Alan Johnston <[email-masked]>
Date: Fri, 15 Mar 2002 22:52:39 -0600

All,

I have a number of comments on this draft.

At a very high level, I feel that this document misses the key aspects
of IP and PSTN interworking enabled by ENUM, namely:

- the main benefit of ENUM is that it allows IP devices to avoid
interworking with the PSTN.

- both IP and PSTN networks currently have routing capabilities today
that work without ENUM even in interworking scenarios - ENUM is a
routing optimization, not a requirement for successful interoperation
between the two networks.

It is important to realize that ENUM is primarily for the Internet and
Internet devices.  If the PSTN can make some use of it in optimizing
routing, that's good, but not the main goal.

Secondly, if service specific call flows are needed (and I am far from
convinced that they are), I think they should be done in the relevant
working group rather than ENUM where they will get expert review.

Finally, the document claims to point out necessary changes to other
protocols such as SIP.  If this were true (which it isn't), the document
should be submitted to SIPPING.  However, the changes discussed relate
to TEL URL parameters instead.

Detailed comments are further down this email.

Thanks,
Alan Johnston
WorldCom
sip:[email-masked]

- - - - - - 
Detailed comments:

Section 4 - I don't think mailto:+1-973-236-6787 a valid mailto URI
based on RFC2378 - it should be clearly labeled as a potential
extension.

Section 5.1 - This call flow breaks at Step 2 as there is no reason
given for the PSTN to route the call to a Gateway, and no adequate
explanation for the selection of this gateway.  The PSTN will route the
call based on dialed digits, unless the PSTN queries ENUM (which is not
shown in any of these flows, but is an interesting idea).

The real call flow here is that the call routes over the PSTN and does
reach a Gateway, but the PSTN does not know that it is a Gateway - it
just looks like a Class 5 switch. 

In Figure 1, all the boxes are functional elements except the one
labeled "IP-based Network".  Since none of the other networks involved
in this flow are labeled this way, it should be removed, or reworked as
a network "cloud".

Step 5 indicates that an A record is used to locate a SIP server when it
is much more likely a SRV record will be used.  Ditto for Step 5 in
Section 6.

Section 5.2 - The options discussed here are just awful.  Separate E.164
numbers for IP devices kind of defeats the purpose of ENUM.  Hairpinning
every PSTN call through a Gateway on the off chance the call terminates
in the IP world also is not good.  The one obvious solution to this
problem is not even mentioned - the only way the PSTN can know if the
call should be routed to a gateway is to query ENUM to see if a URI is
returned.  If no, URI, route in PSTN, if URI (SIP or similar) route to
Gateway.

Section 5.3 - Step 3 of returning a tel URL identical to the E.164
number used to make the lookup is bad as others have pointed out.  If
there is no IP endpoint, there should be no URIs returned by the ENUM
query.

In Section 8 under Conclusions and Future work.  The first open issue,
identifying when a PSTN call should route to IP - this is done using
ENUM.  The open issue is how and where the PSTN should query ENUM.

The second open issue states that extensions to SIP are needed to
support LNP - this has not been shown by this document.  As stated
earlier, any changes to SIP must go through SIPPING.

Any LNP information can be carried as URI parameters, best in tel URLS
which have nothing to do with the SIP protocol, which is incorrectly
stated in the third open issue.

Comments on the Call Flows:

The SIP signaling is incorrect throughout, with the response codes (18x,
200, etc.) missing.  Also, ACKs are also missing.

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum