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

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Mon, 27 Jun 2005 13:08:09 -0400

Lawrence,

Of course, error cases as well as service rejection cases must be
handled.

SIP-ISUP/BICC PTST Gateway interworking:

IETF: RFC-3398
ITU-T:  Q.1912.5
ATIS:  T1.679

Mike 

> -----Original Message-----
> From: lconroy [mailto:lconroy at insensate.co.uk] 
> Sent: Monday, June 27, 2005 12:45 PM
> To: Michael Hammer (mhammer)
> Cc: 'enum at ietf.org' ENUM; Adrian Georgescu
> Subject: Re: [Enum] Carrier ENUM, SIP URIs and DNS
> 
> 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.
> >
> > 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
> >
> >
> ---------------------------------------
> lawrence conroy    |tel:+44-1794-833666
> 

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

---

From: lconroy <[email-masked]>
Date: Tue, 28 Jun 2005 06:33:30 -0400

Hi again Mike, folks,
Oh, that it were that simple.
AFAICT, these referenced documents do not deal with ENUM failures or 
DNS failures.

RFC3398 section 8.2.6.1 has the SIP to ISDN cause mapping, bit this 
rather requires
that you get to a SIP system in the first place.

What reason code does the inbound gateway return if the allegedly 
authoritative
DNS server is lame, or the zone has too many entries, but the server 
doesn't support
TCP or EDNS0, or ...?

More importantly, does your gateway send back the same reason codes as 
mine?

all the best,
  Lawrence
On 27 Jun 2005, at 18:05, Michael Hammer (mhammer) wrote:
Lawrence,
Of course, error cases as well as service rejection cases must be
handled.
SIP-ISUP/BICC PTST Gateway interworking:
IETF: RFC-3398
ITU-T:  Q.1912.5
ATIS:  T1.679
Mike
-----Original Message-----
From: lconroy [mailto:lconroy at insensate.co.uk]
Sent: Monday, June 27, 2005 12:45 PM
To: Michael Hammer (mhammer)
Cc: 'enum at ietf.org' ENUM; Adrian Georgescu
Subject: Re: [Enum] Carrier ENUM, SIP URIs and DNS
Hi Mike, Adrian, folks,

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

Richard Stastny wrote: