Re: [Enum] Overlap dialing user experience (Re:I-D Action: Newdraft - draft-bellis-enum-send-n-00)

[Hadriel Kaplan <HKaplan at acmepacket.com>]

> -----Original Message-----
> From: Pete Cordell [mailto:peteietf at codalogic.com]
>
> ----- Original Message -----
> From: "Hadriel Kaplan" <HKaplan at acmepacket.com>
>
> > Even if we should send a 484 back, how do we know to send that vs. a
> > 480/604/whatever based on
> > ENUM DNS not-found/unused responses, or even just alternate route it to
> > the PSTN?
>
> My thinking was that the UA would do an ENUM query for a number, and get
> back some sort of successful, go here response.  The UA would then send an
> INVITE and maybe get a 484 then.

That's certainly one way to go.  I think it's pretty ugly, because it means sending SIP Invites all over the place when they didn't need to, and it means having SIP proxies available for every partial number, but it's one way to go.  I mean certainly nothing precludes that model for people/hotels that want it, even if we do decide some other way of handling this issue in general.


> So in the case of this German hotel, the ENUM query would be based on the
> E.164 data that the number provider has, and would resolve to the hotel
> SIP
> proxy.  The initial INVITE would be sent and the hotel's SIP proxy would
> then be able to say, "484: well actually we need a few more numbers".
> I must confess that I'm not following all the issues about the impact of
> wildcards and relative vs. fixed length n's in the send-n proposal, but I
> could see something like send-n in ENUM and 484 in SIP complementing each
> other rather than competing.

Oh no I didn't mean they were competing - I meant the issue at hand is, imo, how the UAC or proxy doing the ENUM query can know to send back a 484 vs. another failure response (with/without whatever additional data it needs).

-hadriel
_______________________________________________
enum mailing list
enum at ietf.org
https://www.ietf.org/mailman/listinfo/enum