Skip to Content.
Sympa Menu

sip.edu - RE: [sip.edu] ITAD-based numbering, an alternative proposal

Subject: SIP in higher education

List archive

RE: [sip.edu] ITAD-based numbering, an alternative proposal


Chronological Thread 
  • From: "Bauer, Steven J." <>
  • To: <>, "Ed Guy" <>
  • Subject: RE: [sip.edu] ITAD-based numbering, an alternative proposal
  • Date: Fri, 5 Aug 2005 09:38:15 -0600

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



Archive powered by MHonArc 2.6.16.

Top of Page