SIP in higher education

[John Todd <>]

There are actually two components of your first question about PSTN 
failover for ISN destinations:

 1) If the ISN ENUMish(1) DNS lookup failed, would the call be routed 
some other way?

 2) If the ISN ENUMish DNS lookup returned a set of URIs, some of 
which were "sip:", and some of which were "tel:" methods, could the 
system fail over to the PSTN?


The answer to #1 is "No", since by nature ISN dialing strings are not 
e.164, which is the only method by which the PSTN accepts inbound 
calls.  But that is the same as asking if SIP URIs can be dialed on 
the PSTN, and the answer there is also "No" unless some PSTN-style 
number can be looked up and used as a dialing substitute.  Thus, ISNs 
are no better or worse than SIP URIs if the lookup mechanism fails.

The answer to #2 is "Yes, but it depends on local and remote policy." 
If an ISN lookup succeeds and returns a "tel:" URI, then of course 
the local administrator may choose to fail over to the PSTN if the 
SIP path doesn't work for whatever reason.  It may be the case that 
the remote network does not want to receive telephone calls, and 
therefore they do not list a "tel:" URI in their DNS tables for that 
ISN - both sides of this equation depend on agreeing policies, so 
this is not dictated by the numbering scheme itself.

I think your question was really leaning towards #2, but I think it's 
worth noting that question #1 is also worth considering in the global 
scheme of things.  However, DNS service can be as robust as PSTN 
connectivity if properly administered in a redundant network 
environment, so I would suggest that this is not an impediment to 
deployment of ISNs.  (In fact, ISNs are slightly better than SIP URIs 
since there is the use of an ENUMish lookup which may result in a 
"tel:" response in the worst case, thus making the destination 
reachable via PSTN, unlike SIP URIs.)


Your second question is "Also, would these numbers, (ITAD * number) 
work for use use in the
current ENUM as a sip destination?".  The answer here is "Yes" but 
that's because there is no required overlap between ISN and ENUM. 
The two systems describe a totally different method of reaching 
endpoints, but they both share the common digits on the 12 digit 
keypad.  Thus, they can co-exist without any difficulty.  The 
confusion on my note portion below perhaps is that it is _possible_ 
for a local administrator to use e.164 numbering as a subscriber 
identifier.  This is at the discretion of the local administrator.


(1) ENUMish = "ENUM-like" but I got tired of typing "ENUM-like", so I 
adopted the diminutive "-ish" as a suffix.  Seems to work for me, 
since the term "ENUM" is very specifically using the "e164.arpa" 
suffix, which is not the case here or for any of the multiplying 
legions of ENUMish root zones.

JT


At 9:38 AM -0600 8/5/05, Bauer, Steven J. wrote:
> Would there be an automated method to fall back to the normal pstn
> provided the VoIP connection didn't work for some reason? 
>
> Also, would these numbers, (ITAD * number) work for use use in the
> current ENUM as a sip destination? 
>
> Steve
>
>
> -----Original Message-----
> From: John Todd 
> [mailto:]
> Sent: Thursday, August 04, 2005 8:18 PM
> To: Ed Guy; 
>
> Subject: Re: [sip.edu] ITAD-based numbering, an alternative proposal
>
> 7) I am unconvinced that e.164 numbers should be forbidden as part of
> the identifier, regardless of if the "*" or run-length value is used
> as an ITAD delimitation method.  It may be good practice to actually
> go out of one's way to _include_ the e.164 numbers as an alias
> identifier for a domain.
>    Let's say I have Penny's business card with -only- her e.164 number
> on it (16095551212), and I know that Penny is a professor at Banzai
> University (BU).  Because I often communicate with other staff at BU,
> I happen to know that the ITAD for the BU is 1984.  Or perhaps I
> looked up BU's ITAD in the on-line ITAD directory.  If the
> administrator at BU has been clever and followed the hypothetical
> best practices document, then for every e.164 number that BU is
> allocated from various PSTN providers is _also_ mapped in an internal
> system on BU's SIP proxies.  So, I could guess and dial
> 16095551212*1984 and it would map to a device which would reach
> Penny.  Recall that these directory listings do NOT pollute the true
> ENUM root nor should they cause any confusion, because they are
> essentially local requests within the entity.  Of course, every
> entity needs to maintain that list however they see fit - there can
> be as many or as diverse a set of aliases as would be deemed
> appropriate for that enterprise.  Perhaps 
> 5551212@1984
>  maps to Penny,
> as does 
> 1212@1984.
>   Other numbers which are not part of previous
> e.164 mappings may also map to Penny - this is totally up to the
> local administrator, and it may make sense for some entities to
> install full e.164 mappings in their tables to make "guess-able"
> transitions possible even if only the e.164 number and organization
> is known by a caller.  Some sites might use it, some might not, but
> why limit the obvious mappings?
>
> JT