[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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?
-hadriel
> -----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