Subject: RE: [Enum] Carrier ENUM, SIP URIs and DNS

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Mon, 27 Jun 2005 10:04:35 -0400

Adrian,

May I tweak this slightly.

Reachability from a telephony feature standpoint depends on whether the
proxy, SBC or whatever is permitted to allow the call through.  The
issue here is that an ENUM query on an E.164 number from any PSTN
gateway MUST resolve to a URI and subsequently to an IP address to which
a request can be routed.  What the receiving server does with that
request is not ENUM's problem, but a service feature.

If the above request routing can not take place, then the E.164 number
should not have been assigned in the first place, as it is simply
wasting a numbering resource.  That is the bottom line.

Mike

> -----Original Message-----
> From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On 
> Behalf Of Adrian Georgescu
> Sent: Sunday, June 26, 2005 3:52 PM
> To: James McEachern
> Cc: enum at ietf.org
> Subject: Re: [Enum] Carrier ENUM, SIP URIs and DNS
> 
> 
> On Jun 26, 2005, at 3:37 PM, James McEachern wrote:
> 
> 
> > Richard Stastny wrote:
> >
> >
> >
> >> Still, the basic question for any type of ENUM is: Can you reach a
> >> sip: URI one gets from an mobile operator e.g. 
> sip:frank at vodafone.de 
> >> from any enterprise owned SIP server, from sipgate.de or from 
> >> fwd.pulver.com
> >>
> >>
> >
> > The ability, or inability, to reach a URI such as 
> > sip:frank at vodafone.de from any enterprise owned SIP server would 
> > appear to have nothing to do with converting E.164 numbers to URIs. 
> > The problem would be the same if you started with the URI, 
> or even if 
> > there was no E.164 number associated with the URI at all, would it 
> > not? So isn't it really a SIP issue rather than an ENUM issue?
> >
> > What am I missing?
> >
> 
> What you are missing is that if the target SIP URI is not 
> reachable in the first place, you (as a carrier) would not 
> need to use the e164.arpa tree to publish mappings of an 
> E.164 number to that SIP URI either.
> 
> Adrian
> 
> 
> 
> _______________________________________________
> enum mailing list
> enum at ietf.org
> https://www1.ietf.org/mailman/listinfo/enum
> 

_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: lconroy <[email-masked]>
Date: Mon, 27 Jun 2005 12:44:57 -0400

Hi Mike, Adrian, folks,
 whilst we're doing slight tweaks...
Numbers do go out of service. Thus even if a numbering resource was 
originally assigned for a legitimate use, service to this number may 
have "gone away". There is still a responsibility on some node to deal 
with the situation.

In the case you describe, the inbound PSTN Gateway is responsible for a 
sane termination, from the perspective of the PSTN-based call 
origination point.

If IT can't get through then it still has to provide the tri-tone and 
the appropriate ISUP clearback with some reason code.
It might fail to place the call because of:
-  ENUM failure, or
-  DNS failure, or
-  the SBC isn't talking at all to this IP address, or
-  the SBC rejects the call because this is not from an anointed 
SBC/known server, or
-  the SIP URI is wrong or not found or the destination UA is not 
registered or out of coverage or ...

In all these cases, it's the PSTN Gateway that has to pick up the 
pieces.

If the receiving server/SBC does anything other than giving a failure 
code, then the PSTN gateway just relays state information "back" 
through the call path, but for all those other cases, it has the joy of 
working out what reason code to send back if there's an ENUM failure, 
or ...

Should be fun to design these gateways - testing them for 
interoperability will be even more fun.
I await the specs with interest.

all the best,
  Lawrence
On 27 Jun 2005, at 15:04, Michael Hammer (mhammer) wrote:
Adrian,
May I tweak this slightly.
Reachability from a telephony feature standpoint depends on whether the
proxy, SBC or whatever is permitted to allow the call through.  The
issue here is that an ENUM query on an E.164 number from any PSTN
gateway MUST resolve to a URI and subsequently to an IP address to 
which
a request can be routed.  What the receiving server does with that
request is not ENUM's problem, but a service feature.

-----Original Message-----

Richard Stastny wrote:

---------------------------------------
lawrence conroy    |tel:+44-1794-833666
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum