Re: Overlap dialing user experience (Re:I-D Action: Newdraft - draft-bellis-enum-send-n-00)
"Pete Cordell" <[email protected]>
| Newsgroups | gmane.ietf.enum |
|---|---|
| Message-ID | <003801c89a1b$20d67820$3b00a8c0@Codalogic> |
----- Original Message ----- From: "Hadriel Kaplan" <[email protected]> To: <[email protected]>; <[email protected]> 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: [email protected] [mailto:[email protected]] On Behalf Of >> [email protected] >> Sent: Tuesday, April 08, 2008 6:24 PM >> To: [email protected] >> Subject: Re: [Enum] Overlap dialing user experience (Re: I-D Action: >> Newdraft - draft-bellis-enum-send-n-00) >> >> From: "Pete Cordell" <[email protected]> >> >> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/enum > _______________________________________________ > enum mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/enum >