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

["Pete Cordell" <peteietf at codalogic.com>]

----- Original Message ----- 
From: "Hadriel Kaplan" <HKaplan at acmepacket.com>
To: <Dale.Worley at comcast.net>; <enum at ietf.org>
Sent: Wednesday, April 09, 2008 4:23 AM
Subject: Re: [Enum] Overlap dialing user experience (Re:I-D Action: 
Newdraft - draft-bellis-enum-send-n-00)


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

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.

HTH,

Pete.
--
=============================================
Pete Cordell
Codalogic
=============================================

>> -----Original Message-----
>> From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of
>> Dale.Worley at comcast.net
>> Sent: Tuesday, April 08, 2008 6:24 PM
>> To: enum at ietf.org
>> Subject: Re: [Enum] Overlap dialing user experience (Re: I-D Action:
>> Newdraft - draft-bellis-enum-send-n-00)
>>
>>    From: "Pete Cordell" <peteietf at codalogic.com>
>>
>>    Another option may be to reject the INVITE with some kind of message 
>> (I
>>    guess 4xx, but could it be some kind of moved 3xx type thing?) that
>> says
>>    insufficient digits and don't try to contact me again until you have n
>> more
>>    digits.
>>
>> RFC 3261, section 21.4.22: 484 Address Incomplete
>>
>>    The server received a request with a Request-URI that was incomplete.
>>    Additional information SHOULD be provided in the reason phrase.
>>
>>       This status code allows overlapped dialing.  With overlapped
>>       dialing, the client does not know the length of the dialing
>>       string.  It sends strings of increasing lengths, prompting the
>>       user for more input, until it no longer receives a 484 (Address
>>       Incomplete) status response.
>>
>> If we want to send partial-dial-string queries into the network, as
>> in Otmar's example, we might as well use INVITE and 484 responses as
>> they are already defined.  The refinement would be to be able to
>> provide information as to the minimum number of additional digits
>> needed in the 484 response.
>>
>> Dale
>> _______________________________________________
>> enum mailing list
>> enum at ietf.org
>> https://www.ietf.org/mailman/listinfo/enum
> _______________________________________________
> enum mailing list
> enum at ietf.org
> https://www.ietf.org/mailman/listinfo/enum
> 


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