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

----- Original Message From: "Hadriel Kaplan" <>

>> -----Original Message-----
>> From: Pete Cordell [mailto:[email protected]]
>>
>> ----- Original Message -----
>> From: "Hadriel Kaplan" <[email protected]>
>>
>> > 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.

I was envisioning ENUM would get you to the hotel.  The UAC would then send 
an INVITE to the hotel, and its proxy would return 484, I need 4 more digits 
(or maybe the minumum digit length is 20 or whatever it works out to be). 
Then the UAC sends a new invite with the extra collected digits.

Admittedly the x more digits thing is not in place, but it doesn't seem too 
difficult to come up with a header that could do that.

To me that sounds a lot better than administering some mega database, or 
sending an initial INVITE to the hotel and then sending extra DTMF (would 
that be INFO / RTP or whatever etc.?)

>> 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).

Maybe I'm missing something, but the UAC keeps banging away at ENUM until it 
gets a 'go here' reply.  It then does a SIP INVITE and works from there 
(unless it gets a tel: re-direct, in which case it's back to ENUM I guess, 
but hopefully that won't happen!)

On reflection, maybe the thing I'm missing is I don't think ENUM has the 
ability to return a URI that a UAC, after receiving a 484, would be able to 
figure out how to add, say, 4 more digits to.

>
> -hadriel
> _______________________________________________
> enum mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/enum
>