Subject: [Sipping] I-D ACTION:draft-ietf-sipping-e164-00.txt

From: [email-masked]
Date: Mon, 03 Dec 2001 08:36:52 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF.

	Title		: Resolution of e.164 numbers in SIP Applications
	Author(s)	: B. Campbell
	Filename	: draft-ietf-sipping-e164-00.txt
	Pages		: 8
	Date		: 30-Nov-01
	
This document describes how SIP may use the DNS to resolve services
associated with E.164 numbers

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-e164-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sipping-e164-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sipping-e164-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Matt Zito <[email-masked]>
Date: Mon, 3 Dec 2001 14:30:46 -0500

See inline.

> -----Original Message-----
> From: Christian Huitema [mailto:[email-masked]]
> Sent: Monday, December 03, 2001 2:08 PM
> To: [email-masked]
> Subject: RE: [Sipping] I-D ACTION:draft-ietf-sipping-e164-00.txt
> 
> 
> The essence of the draft is that if a SIP entity has to forward an
> INVITE to a "tel:+12345678901" URL, it should first try to map the
> telephone number to an URL using the DNS mapping specified in ENUM.
> 
> Well, I think this is a thoroughly bad idea.
> 
> Right now, my UA gives me two choice: invite a contact using 
> a sip URL,
> or call a phone number. If I want to call a partner, I can look at the
> partner business card, and make a conscious decision to 
> either call the
> url "[email-masked]" or call the phone number "+1 234 567 8901".
> Presumably, I choose the phone number for a reason. Why 
> should a network
> element override that choice and redirect the call to the URL instead?
> 

Well, what about legacy phones that simply have numeric pads?  These could
be SIP-enabled, and use ENUM to return sip id's or any other information
available that the UA supports.  Along those same lines, it would be nice if
your UA could look at the available options and make a decision based on
those (either interactively or based on predefined preferences).  But to say
that the network elements shouldn't look up phone numbers breaks a feature
set that many providers as well as end users are interested in applying.

Thanks,
Matt

-- 
Matthew J. Zito
Systems Engineer
Register.com, Inc., 11th Floor, 575 8th Avenue, New York, NY 10018
Ph: 212-798-9205
PGP Key Fingerprint: 4E AC E1 0B BE DD 7D BC D2 06 B2 B0 BF 55 68 99

_______________________________________________
Sipping mailing list  http://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: [email-masked]
Date: Mon, 3 Dec 2001 14:31:13 -0500

>> Christian Huitema wrote:
>>
>> Right now, my UA gives me two choice: invite a contact using a sip URL,
>> partner business card, and make a conscious decision to either call the
>> Presumably, I choose the phone number for a reason. Why should a network

Receiver-side policy - just because I provided you with a phone number does
not mean I relinquish
my ability to redirect that number somewhere else, including a SIP URL.
Routing is always an expression of wishes by the caller, and a execution of
policy by receivers, and
the receiver has the final say on what happens.

its not the element that overrides, its my policy.  Now there are other
ways to do what I just described,
but that's a separate discussion...

cheers,

- gur

---

From: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Mon, 3 Dec 2001 20:00:10 -0500

Basically, it provides another tool (e.g., ENUM) as an OPTION (not
mandatory). Whether it would really be used or how it would be used is a
different thing and, as Gur and others mentioned (and Dean has provided a
head start), we may have a separate discussion on this. In fact, many of us
have been waiting to have a "standard" based tool like this for
creation/execution of services.

Radhika R. Roy

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Monday, December 03, 2001 3:24 PM
To: Christian Huitema; [email-masked]
Subject: Re: [Sipping] I-D ACTION:draft-ietf-sipping-e164-00.txt

Well, maybe there's something not clear here. Or maybe two points -- I
should check the draft and verify that it brings this out.

1) Local policy, such as SIP routing tables or outbound proxy rules, MAY
override the "look it up in DNS" approach normally used for resolving a SIP
URL. This means if you really want to send a call to the PSTN via your own
choice of routes, you can.

2) Ok, you've got this SIP phone in your hand, and you want to call a phone
number off of somebody's business card. You don't actually know whether that
phone number will be routed to a SIP phone or a PSTN phone before it's all
over with. You have two choices: 1: force the call through a gateway to
PSTN, which might send it through the called party's gateway and back onto
the Internet, or 2: Treat the number as a URI and see if DNS knows how to
find a URL for a node willing to claim responsibility for handling the
next-hop routing.

Most phones (or local outbound proxies) configured with gateway routes will
actually default to sending "phone numbers" to a default gateway to PSTN.
Only in the presence of additional information, such as phone-routes, TRIP
info, or DNS, will they do something different. So basically it boils down
as to how your phone and the various network elements are configured, what
least-cost routing policies are being applied, and what dynamic information
about the network is available to the decision-making nodes.

Does this begin to address your concern? How can we make this more clear in
the draft?

--
Dean Willis

----- Original Message -----
From: "Christian Huitema" <[email-masked]>
To: <[email-masked]>
Sent: Monday, December 03, 2001 1:07 PM
Subject: RE: [Sipping] I-D ACTION:draft-ietf-sipping-e164-00.txt

> -- Christian Huitema

---

From: Ben Campbell <[email-masked]>
Date: 06 Dec 2001 16:12:40 -0600

> element override that choice and redirect the call to the URL instead?

The next line mentions the element MAY choose some other method to
resolve the URI. Effectively, local policy wins. I suppose the effect of
all this effectively makes the SHOULD you mention into a MAY; my choice
of words could have been a bit better.But, unless the element in
question just happens to be a PSTN gateway, it has to do resolve the URI
somehow. Maybe it uses DNS; maybe it invokes local policy to route the
request to a known gateway, etc, 

In any case, there is no reason to assume in your example that an enum
resolution of the number "+1 234 567 8901" happens to result in
"[email-masked]". If it _does_ match, it is because Joe (or Joe's
provider) _wants_ it to match. It seems to me that it makes every bit as
much sense for a network element to redirect the number to a URL as it
does for an element to redirect one URL to another URL. As an example,
consider that it might map "tel:+12345678901" to
"sip:[email-masked];user=phone"

Thanks!

Ben.