Subject: [Sip] Migration from E.164 to email-style SIP URIs

From: "Elwell, John" <[email-masked]>
Date: Fri, 04 Apr 2008 09:18:39 +0100

On this thread I would like to explore what can be done in terms of
avoiding the issues concerned with RFC 4474 and E.164-based SIP URIs by
migration towards the use of email-style URIs.
E.164-based URIs will still be needed, particularly for interworking
with PSTN but also in those SIP environments where E.164 numbers are
more easily handled (e.g., phones with number-based user interfaces).
But perhaps we can explore more the possibility of using the two forms
in parallel, e.g., E.164-based in PAI (e.g., as TEL URI) and email-style
in From. I know Dan has an interesting straw man on this topic, which I
will allow him to present himself.

John
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 04 Apr 2008 11:50:38 +0300

I wonder whether RFC 4474 isn't doing fine when you assume that E.164 
numbers apear in an email style format.
The assumption there is, however, that devices display the domain part 
as well (which they don't do today) and user's actually configure their 
authorization policies in a way that it includes both the E.164 number 
and a corresponding domain name.

Hence, this is not a standardization problem but a usability issue.

Do I misunderstand your proposal?

Ciao
Hannes

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 04 Apr 2008 10:03:16 +0100

Hannes,

The problem is the changing of domain part as the E.164-based URI
traverses service providers, so that it no longer represents the true
origin of the request. Furthermore it breaks the RFC 4474 signature,
unless re-signed by the service provider.

With an email-style SIP URI (i.e. one in which the user part does not
look like an E.164 number), intermediate service providers cannot change
the domain part (or if they do they break things entirely).

John

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]] 
> Sent: 04 April 2008 09:51
> To: Elwell, John
> Cc: [email-masked]
> Subject: Re: [Sip] Migration from E.164 to email-style SIP URIs
>

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 4 Apr 2008 16:59:45 -0700

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Elwell, John
> Sent: Friday, April 04, 2008 1:19 AM
> To: [email-masked]
> Subject: [Sip] Migration from E.164 to email-style SIP URIs
> 
> in parallel, e.g., E.164-based in PAI (e.g., as TEL URI) and 
> email-style in From. I know Dan has an interesting straw man on 
> this topic, which I will allow him to present himself.

One idea that someone (Jonathan?) posted to SIP, about a week 
before the Philadelphia meeting, was to mix both e.164 and email
style identifiers.  In that email, it was suggested to use a 
separator between the two (a "*", as I recall).  

I have been thinking about using both E.164-style and email-style 
URIs in parallel, for two reasons:

  1.  provide a migration path from E.164-style URIs to email-style
      URIs
  2.  allow stronger identity to be asserted for email-style URIs

Here is a straw-man idea:

On an outgoing request containing an e164-style URI in the From:
(or PAI, as you prefer), the domain additionally places the user's 
email-style URI into a new header (let's call it "email-identity").
It determines the mapping between a user's E.164 URI and email URI
using a flat database (example: +14085551234 -> [email-masked]).

This new header is signed along with everything else we like to 
sign [choose RFC4474, draft-fischer-sip-e2e-sec-media-00.txt, or 
draft-wing-sip-identity-media-02.txt, as you prefer].

If the receiving domain understands email-identity, it validates
the claimed identity, and it presents the email-style URI to the
called party.  Thus, the E.164 in the From: (or in the PAI) is 
essentially ignored.  If the receiving domain does not understand
email-identity, the receiving domain does not enjoy any benefits
of the email-identity header and does not experience any harm from
the email-identity header.

This provides a backwards-compatible way to migrate to email-style
URIs, and gives us strong identity with those email-style URIs.

-d

---

From: [email-masked] (Juha Heinanen)
Date: Sat, 5 Apr 2008 17:48:15 +0300

> using a flat database (example: +14085551234 -> [email-masked]).

my proxy is currently is using P-Preferred-Identity header for that
purpose.  why is a new header needed?

-- juha

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 5 Apr 2008 12:05:28 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan
> Wing
>

Interesting proposal.

> draft-wing-sip-identity-media-02.txt, as you prefer].

You wouldn't be able to use 4474 as is, because it has no way to sign a new header, afaik. (though I'm all for a 4474bis ;)
I know this is only a straw-man and too soon to get into the details, but I can't help myself, so I wonder why you wouldn't just put this email-style URI *inside* the From-URI as an escaped uri or user param.  That way it avoids a new header and gets signed by 4474 as is, and really what you're saying is it is an alias property of the From-URI.

> URIs, and gives us strong identity with those email-style URIs.

And lets the UAS offer its user the ability to add both the e164 and email-forms into its contact address book.  I'm not sure if that's good or bad, but it's a nice feature.

-hadriel

---

From: "Dan Wing" <[email-masked]>
Date: Sat, 5 Apr 2008 10:01:05 -0700

> From: Juha Heinanen [mailto:[email-masked]] 
> Sent: Saturday, April 05, 2008 7:48 AM
> To: Dan Wing
> Cc: [email-masked]; 'Elwell, John'

The header, containing the email-style URI, needs to be signed.

I do not care if it is a new header or not, but I see value in not
overloading a header with an already-defined semantic (such as
P-Preferred-Identity).  But this is a detail.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Sat, 5 Apr 2008 11:02:51 -0700

Hadriel Kaplan wrote: 
> > Behalf Of Dan Wing
> You wouldn't be able to use 4474 as is, because it has no way 
> to sign a new header, afaik.

Right, RFC4474 is not extensible.

> (though I'm all for a 4474bis ;)
> I know this is only a straw-man and too soon to get into the 
> details, but I can't help myself, so I wonder why you 
> wouldn't just put this email-style URI *inside* the From-URI 
> as an escaped uri or user param.  That way it avoids a new 
> header and gets signed by 4474 as is, and really what you're 
> saying is it is an alias property of the From-URI.

That would look something like:

  From: Dan Wing <sip:[email-masked];email-id=[email-masked]>

and the originating domain (cisco.com) would provide strong identity 
over the entire URI, including the E.164 and the email-style portion
([email-masked]).

I wanted to avoid signing the E.164 in the From, because we have not 
yet resolved if we can do that in a meaningful way.

> And lets the UAS offer its user the ability to add both the 
> e164 and email-forms into its contact address book.  I'm not 
> sure if that's good or bad, but it's a nice feature.

Right, but that could also be another attack vector if the
E.164 is unsigned or only trustable hop-by-hop.

-d

---

From: "Elwell, John" <[email-masked]>
Date: Sat, 05 Apr 2008 19:40:07 +0100

Also PPI is not end-to-end - it is intended only to go as far as the
first proxy, where it is moved to PAI or discarded.

John 

> From: Dan Wing [mailto:[email-masked]] 
> Sent: 05 April 2008 18:01
> To: 'Juha Heinanen'
> Cc: [email-masked]; Elwell, John
> Subject: RE: [Sip] Migration from E.164 to email-style SIP URIs
> 
> 
>  
>

---

From: "Elwell, John" <[email-masked]>
Date: Sat, 05 Apr 2008 19:43:58 +0100

I too think the straw man from Dan is an interesting idea. The
alternative that I think Hadriel is suggesting (email style as a
parameter of the E.164-based SIP URI) would probably not survive any
changes of the E.164-based URI by intermediaries -part of the problem
with E.164-based URIs in practice.

John

> Sent: 05 April 2008 19:03
> To: 'Hadriel Kaplan'; [email-masked]
> Cc: Elwell, John

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 05 Apr 2008 23:06:24 -0400

I too think that the idea is interesting - modulo all the loose ends.

	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 6 Apr 2008 11:48:48 -0400

> From: Elwell, John [mailto:[email-masked]]
>

I don't disagree with that, obviously, but 4474 breaks in such a case anyway.  In other words, I thought he was proposing both the e164 and email-style get signed, but maybe I misunderstood.  Regardless, I (maybe naively) hope the changing of From-URI E.164's is a temporary situation, for anyone except those doing end-end relationship-hiding, for whom none of this will apply anyway.

-hadriel

---

From: "Dan Wing" <[email-masked]>
Date: Sun, 6 Apr 2008 09:54:02 -0700

> > changes of the E.164-based URI by intermediaries -part of 
> > the problem with E.164-based URIs in practice.
> 
> I don't disagree with that, obviously, but 4474 breaks in 
> such a case anyway.  In other words, I thought he was 
> proposing both the e164 and email-style get signed, but maybe 
> I misunderstood. 

The success and value of signing an E.164 is not changed by my 
proposal; signing the E.164 and solving the 'which domain can
sign for an E.164' is orthogonal to my proposal.  It is still
a useful problem to solve.  

But, with my proposal if you received a message that had
signed both:

  From: Dan Wing <sip:[email-masked];user=phone>
  email-id: Dan Wing <sip:[email-masked]>

and the display on the receiving system could display either one,
you would probably have it display both.  After all, it is hard to 
know which one will have more meaning or value to the called 
party.  Certainly, the signature generated by the originating
domain (cisco.com) has superior security properties compared 
to the signature generated by an intermediary (att.net).

> Regardless, I (maybe naively) hope the 
> changing of From-URI E.164's is a temporary situation, for 
> anyone except those doing end-end relationship-hiding, for 
> whom none of this will apply anyway.

-d

---

From: "Fischer, Kai" <[email-masked]>
Date: Mon, 7 Apr 2008 10:24:49 +0200

That's an interesting proposal. I didn't get if your intention is to
sign both headers (From header with E.164 and 'email-identity' header)
or only the email-based one.

In case signing both, an identity binding between the E.164 SIP URI and
the email based one is created, which results into the other problems
with RFC 4474 discussed in the two mail threads 'RFC 4474 and PSTN' /
'RFC 4474 and SBC traversal'. 

In case signing only the 'email-identity' header, does this mean that
email-like SIP URIs are only provided in the new header field (because
they are signed) and not in the From header in the long term (after
migration ;-)).

Kai

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 7 Apr 2008 09:29:04 -0700

> From: Fischer, Kai [mailto:[email-masked]] 
> Sent: Monday, April 07, 2008 1:25 AM
> To: Dan Wing; [email-masked]
> Cc: Elwell, John

For the purposes of my straw-man, you can assume (a) we have resolved
all problems with signing E.164s in From, or you can assume (b) we have
not resolved any problem with signing E.164 in From -- either way, my
proposal still provides benefit:  the called party can use the email-
style address to establish end-to-end identity with the calling party,
and can use that to establish an end-to-end SRTP session (using a
mechanism similar to your draft or the Wing/Kaplan draft).

> they are signed) and not in the From header in the long term (after

Once both endpoints know they can use email-style URIs, they could put
the same information into the From and into the Email-Identity headers
-- or sign the From and ignore the email-identity.

-d

---

From: "Fischer, Kai" <[email-masked]>
Date: Tue, 8 Apr 2008 15:32:19 +0200

> mechanism similar to your draft or the Wing/Kaplan draft).
Let's explore your proposal further regarding the problems discussed in
the other two threads (sorry for mixing the email threads now, but it is
close related to the migration proposal):

First problem: Weak PSTN numbers
Proposal
- Don't include the E.164 number in the signature if it was received
from the PSTN (certificate fingerprint is still protected and bound to
the email-style SIP URI of SIP Gateway provided in 'email-identity')
- Include the E.164 number in the signature if not received from the
PSTN
That's independent from the concrete signing mechanism except that RFC
4474 does not cover the new header field

Second problem: SBC traversal
- If both identity information are signed it conflicts with SBCs
modifying SDP information and therefore need to change the domain part
of the SIP URI in the From header as well
- If only the email-identity information is signed (by the Wing/Kaplan
or Fischer draft), intermediary SBCs should not break the signature.
However, the E.164 number has PSTN security level only as assumed above,
but email-style is bound to certificate fingerprint and signed

An straw man extension to your proposal, which mitigates the SBC
traversal problem is to create two signatures. One signing the
email-identity including the certificate fingerprint and which is
protected end-to-end. The other one covering the From header field and
which might re-newed during traversal by intermediaries. The
disadvantage are for sure two signing processes.

Kai

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 8 Apr 2008 14:10:06 -0700

> Sent: Tuesday, April 08, 2008 6:32 AM

Sure, you could do that.

But at this point in time it seems there is little value in
RFC4474 signatures if there are SBCs on the path; if the SBCs
support RFC4474, they will have to re-sign the identity and
will have to re-write the From.  In such a situation, RFC4474
provides protection of SIP requests being modified between 
the Service Provider (running the SBC) and yourself.  You can 
achieve identical protection from the same attack by doing 
SIP-over-(D)TLS with that same SBC, and not bothering with
RFC4474 (or RFC4916) to/from that SBC.

(I would even go so far to say that, in the same case with 
your provider running an SBC, running SIP-over-(D)TLS to that
provider is superior to RFC4474 because SIP-over-(D)TLS 
protects SIP responses; neither RFC4474 or RFC4916 protect 
SIP responses.)

-d

---

From: [email-masked]
Date: Tue, 8 Apr 2008 17:30:51 -0400

From: "Elwell, John" <[email-masked]>

   origin of the request.

Well, yes.  If you change the domain part of a URI as it traverses
service providers, you're going to break things.  If you mean "what
the user +123456789 means in cisco.com's domain", say
<sip:[email-masked]>.  If you mean "what the user +123456789
means in siemens.com's domain", say <sip:[email-masked]>.  And
there's no reason to believe that there is any relationship between
the two -- unless you have authoritative information about *both*
domains.

If you mean "the E.164 number +123456789", say <tel:+123456789>.

I don't see anything that will go wrong if people pay attention to
what URIs are defined to mean.

Now there is a problem with signing tel: URIs, how do you determine
that the signer has the authority to sign a particular tel: URI, but
that's a delegation-of-authority problem that is not inherently
different from other delegation-of-authority problems -- you need a
publicly-known root authority and a tree of delegations.

Dale

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 8 Apr 2008 17:46:18 -0500

Didn't we go through this already?

If it says sip:[email-masked], it's effectively a user
in domain cisco.com with name "+123456789".

If it says sip:[email-masked];user=phone, it's effectively
a phone number derived from a Tel URI that is currently being routed
in cisco.com domain. But don't count on the domain to be authoritative
of the phone number.

> Behalf Of [email-masked]
> Sent: Tuesday, April 08, 2008 14:31
> To: [email-masked]
> Well, yes.  If you change the domain part of a URI as it 
> traverses service providers, you're going to break things.  
> If you mean "what the user +123456789 means in cisco.com's 
> domain", say <sip:[email-masked]>.  If you mean "what 
> the user +123456789 means in siemens.com's domain", say 
> <sip:[email-masked]>.  And there's no reason to 
> believe that there is any relationship between the two -- 
> unless you have authoritative information about *both* domains.
> 
> I don't see anything that will go wrong if people pay 
> attention to what URIs are defined to mean.
> 
> Now there is a problem with signing tel: URIs, how do you 
> determine that the signer has the authority to sign a 
> particular tel: URI, but that's a delegation-of-authority 
> problem that is not inherently different from other 
> delegation-of-authority problems -- you need a publicly-known 
> root authority and a tree of delegations.
> 
> Dale
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 8 Apr 2008 17:01:40 -0700

...
> means in siemens.com's domain", say <sip:[email-masked]>.
> And there's no reason to believe that there is any relationship
> between the two -- unless you have authoritative information about
> *both* domains.

If those URIs included ";user=phone", there is a transitive 
relationship between the SIP URI and the TEL URI.  Without
";user=phone", I agree that no meaning is supposed to be applied 
to the user-part (the part to the left of the "@").

> I don't see anything that will go wrong if people pay attention 
> to what URIs are defined to mean.
>

That is one approach to determining who owns something.

I have a different approach, which I derived from how we determine if 
someone owns an IP address when we receive a TCP SYN that is 
proportedly from that IP address:  challange them to prove that 
packets route the other way.  Afterall, the Internet does not have
a central authority for who owns an IP address (or else we could
secure BGP routing better than we secure it today).

In SIP, you accomplish something similar to the TCP SYN cookie by
sending a SIP request towards the E.164, asking them to sign the 
request and return it to you.  Details are in 
draft-wing-sip-e164-rrc-01.txt and comments are welcome.

-d

---

From: [email-masked]
Date: Tue, 8 Apr 2008 22:31:01 -0400

From: "Dan Wing" <[email-masked]>

True.  In that case, we have SIP URIs which are essentially aliases
for tel URIs.  But in that case, any signing should be of the
fundamental tel URI, which then obviates the problem with an SBC that
translates one alias-URI into another.

It seems like this mechanism is at most as certain as the E.164
mapping that it uses for the "reverse direction".  I gather from the
Enum people there is some trouble with that.

It seems to me that in practice, people don't validate requestors by
checking their apparent IP address, but rather by whether they can
present certificates.  But that is probably an issue that has been
hashed over before...

Dale

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 8 Apr 2008 21:23:05 -0700

> Sent: Tuesday, April 08, 2008 7:31 PM
> To: [email-masked]
> Subject: Re: [Sip] E.164 - who owns it
> 

But the only mechanism we have to sign, RFC4474, does not provide a
way to sign a tel URI.

> Enum people there is some trouble with that.

I don't understand your statement; draft-wing-sip-e164-rrc-01.txt 
does not use ENUM, rather it uses the same routing that the SIP
network (of proxies, B2BUAs, and SBCs) uses.

> present certificates.  But that is probably an issue that has been

draft-wing-sip-e164-rrc-01.txt does not have people perform the
reverse routability check.  The reverse routability check happens
without the users noticing, as part of validating that an E.164
request that just arrived would have a new request (towards that
same E.164) routing in the same direction.

-d

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 08 Apr 2008 22:27:54 -0700

At Tue, 8 Apr 2008 17:01:40 -0700,
> draft-wing-sip-e164-rrc-01.txt and comments are welcome.

While withholding judgement on draft-wing-sip-e164-rrc-01, I don't
think this is that accurate a description of what can be inferred
from the fact that a peer can complete a TCP connection initiated with
a given source IP address.

As you say, in order to allow a TCP connection to be established,
the passive endpoint requires the active endpoint to prove 
(for some value of prove) that it received the passive endpoint's
SYN/ACK by ACKing the passive endpoint's ISN. This arguably serves
at least two security purposes:

- Prevention of DoS: TCP connections consume resources on the
  client. Forcing the client to ACK the ISN prevents blind
  resource consumption attacks on the passive endpoint.
  (This can also be combined with a stateless cookie technique,
  aka SYN cookies) to produce a system where no state is consumed
  on the passive endpoint until the liveness check is passed.

- Endpoint authentication: the ability of the active endpoint
  to ACK the ISN demonstrates that the active endpoint is on-path
  from the passive endpoint to the claimed initiating source
  IP address.

This second guarantee is very weak for three reasons:

(1) Many TCP stacks do not use sufficiently random PRNGs to
    generate the ISN, in which case sequence number prediction
    attacks are a real problem.
(2) Even if the ISN is randomly generated, there are only
    32 bits of ISN, so it's at least theoretically possible
    to guess it in a blind attack (though of course very
    expensive).
(3) Even if we ignore the previous two considerations, 
    all that the ability to ACK the ISN indicates is that
    the attacker is on-path. There are many situations
    in which an attacker is on-path (wireless being a 
    commonly cited case).

It's precisely for these reasons that one cannot use source IP
authentication for TCP connections on the public Internet, that
mechanisms such as .rhosts are deprecated, and that cryptographic
mechanisms such as IPsec were designed.

Incidentally, this third deficiency seems to me to be shared
by draft-wing-sip-e164-rrc. Any attacker who is on path 
between the relying party and the target of the return
routability check (either because they are on-path in
the SIP routing fabric or because they are able to
observe one of the links) will be able to pass the return
routability check.

-Ekr

---

From: "Fischer, Kai" <[email-masked]>
Date: Wed, 9 Apr 2008 13:23:52 +0200

> Sent: Dienstag, 8. April 2008 23:10
> To: Fischer, Kai; [email-masked]
> Cc: Elwell, John

I agree to that. The other way around, the second signature provides
additional benfit (end-to-end property) if RFC 4474 is used in that
scenarios for some reason. But that depends if the outcome of the 'RFC
4474 and SBC traversal' email thread is
- Yes, there is a problem which need to be fixed or
- No problem, RFC 4474 is applicable in these scenarios

Kai

---

From: [email-masked]
Date: Wed, 9 Apr 2008 11:55:21 -0400

OK, so we have several different URIs, sip:1234@domain;user=phone,
which are understood to be equivalent to tel:1234 and also to each
other, and because of that, SBCs feel free to translate each of these
into each other, but the signing mechanism generates signatures which
depend on which of these particular URIs is present.  So you have to
change either your signing mechanism to recognize the equivalence, or
your SBCs to stop exploiting the equivalence.

Sorry, I don't understand.  You said "sending a SIP request towards
the E.164", by which I understand an Enum lookup.  Did you mean
"sending a SIP request towards a SIP URI which purposts to represent
an E.164"?

Once we start thinking about that, it opens the can of worms again, in
that validating sip:1234@xxx;user=phone is a different operation than
validating sip:1234@yyy;user=phone, so we can validate only one of
those two purportedly equivalent SIP URIs.  This seems to lead back to
the position that assuming those two URIs are equivalent for any
purpose is a Bad Idea, and therefore we should change the SBCs
behavior.

   > present certificates.  But that is probably an issue that has been

s/people/applications/

What I mean is that few security mechanisms that I know of depend on
determining that the purported origin of a message is its actual
origin.  In practice, applications use SSL, where identity is
determined by certificates presented.

Dale

---

From: [email-masked] (Juha Heinanen)
Date: Wed, 9 Apr 2008 19:14:43 +0300

[email-masked] writes:

 > other

this is not true.

-- juha

---

From: Michael Thomas <[email-masked]>
Date: Wed, 09 Apr 2008 09:34:22 -0700

>  > which are understood to be equivalent to tel:1234 and also to each

I was wondering about that... it sure doesn't seem to me that they're
the same thing at all because I have control of my sip: name space and
if I manufacture e.164-like addresses that's nobody's business but mine.

       Mike

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Apr 2008 12:45:49 -0400

>  > which are understood to be equivalent to tel:1234 and also to each

To what does "this" refer?

You are correct that these URIs aren't equivalent. But I think Dale is 
right that they are often "understood" to be equivalent, at least to the 
extent that SBCs feel free to translate among them at will, and phones 
feel free to display the number parts without regard for the domain part.

	Paul

---

From: [email-masked] (Juha Heinanen)
Date: Wed, 9 Apr 2008 19:56:01 +0300

> To what does "this" refer?

i don't have access to rfcs, but since the number in sip uri user part
is not a globally unique e.164 number (+...), it has no meaning without
the domain, i.e., tel:1234 means nothing.  there must be some tel uri
rfc, where this is explained.

-- juha

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Apr 2008 13:22:40 -0400

> rfc, where this is explained.

OK, if that is what you are objecting to. Agreed the example isn't a 
valid tel. But it is equally invalid in sip.

I was overlooking that, assuming the point was simply to show some tel: 
and corresponding sip, and wasn't about the precise form of the digits.

	Paul

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 9 Apr 2008 11:22:33 -0700

> Behalf Of Eric Rescorla
> Sent: Tuesday, April 08, 2008 10:28 PM
> To: Dan Wing
> Cc: [email-masked]
> determine

Fortunately SIP does not suffer from a 32-bit number space, so
(1) and (2) are not a limitation with draft-wing-sip-e164-rrc.

> observe one of the links) will be able to pass the return

That is correct.

A signature generated by the originating domain (e.g., RFC4474)
would protect from such an on-path attacker -- unless of course 
the on-path attacker is also generated the original message 
and is also on-path for the return routability check.  

But, then, if the attacker is on-path for the return 
routability check, they already 'own' that E.164.  Ignoring
draft-wing-sip-e164-rrc for a minute, any normal INVITE 
for that E.164 will go to that very same attacker.

-d

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 09 Apr 2008 11:44:10 -0700

At Wed, 9 Apr 2008 11:22:33 -0700,
> for that E.164 will go to that very same attacker.

Again, I'm not (at least not yet) passing judgment on this draft.
Rather, I'm observing that your characterization of the situation
with IP isn't really right. I'll have to read this draft more
carefully to determine whether I think it works.

-Ekr

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 9 Apr 2008 11:53:59 -0700

> your SBCs to stop exploiting the equivalence.

Yes, I agree.

> "sending a SIP request towards a SIP URI which purposts to represent

draft-wing-sip-e164-rrc-01.txt says to turn the SIP URI into a TEL URI,
and then generate a Return Routability Check (RRC) towards that TEL URI:

  "1.  Strip the domain name of the From:  of the incoming INVITE.  This
       results in a TEL URI.  For example,
       "sip:[email-masked];user=phone" is rewritten to
       "tel:+14085551212".

   2.  Rewrite the TEL URI to a SIP URI, following the Verifier's
       default routing rules.  For example, if outgoing calls are sent
       to the service provider example.net, then "tel:+14085551212" is
       rewritten to "sip:[email-masked];user=phone".

   3.  Generate a random nonce.

   4.  Using the SIP URI constructed in step (2), construct a SIP
       SUBSCRIBE message with Request-URI and To headers that use that
       SIP URI, and an "Expires" header of 0.  The SUBSCRIBE contains
       the random nonce in its body as Content-Type application/
       return-routability-nonce.

   5.  Send the SUBSCRIBE message.  This will cause the calling party to
       send a NOTIFY."

> purpose is a Bad Idea, and therefore we should change the SBCs

(I assume the omission of "+" in those two URIs was an accident.)

If I receive two Invites on one day from

  (a)  sip:+1234@yyy;user=phone
and
  (b)  sip:+1234@xxx;user=phone 

I expect that they were both originated by someone who really does 'own' that
number.

If I turn the SIP URL into a TEL URI (tel:+1234), and route it using my
default routing rules, it could be routed somewhere else
(sip:+1234@zzz;user=phone), and then to somewhere else again
(sip:+1234@abcd;user=phone).  But as long as it eventually arrives at the same
place as (a) or (b) originated from -- then I am happy that my own outbound
SIP routing thinks that (a) or (b) really do "own" the E.164 number "+1234" --
because that is what my SIP routing says is true.

> determined by certificates presented.

Doing such would require something, somewhere, to assert who owns a certain
E.164.  I don't know how to do that.  An ENUM system cannot do that, because
of a pile of reasons (ITU politics, service provider business models, LNP, and
so on).  Certificate Authorities, at least as they currently exist, are not
capable of asserting that a company 'owns' a certain E.164 or a range of
E.164s.

draft-wing-sip-e164-rrc is my pragmatic approach to the problem at hand.  It
does not require ENUM, does not require CA's to assert who owns an E.164 -- it
uses SIP itself to test if the message was originated from the same place we
would route an E.164 call to.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 9 Apr 2008 11:56:26 -0700

> carefully to determine whether I think it works.

Well, I only said I was inspired by SYN cookies; not that I was
trying to do Just As Good as SYN cookies.

-d

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 9 Apr 2008 18:54:35 -0500

If if have a web page with sip:[email-masked];user=phone, and I click on
it should result in my default SIP app to make a call to [email-masked].

Example.com may route it to [email-masked] or whatever.

If I have a web page with tel:+12242 and I click on it, my default
TELEPHONE app (which may not may not be SIP) should make a call to
+12242. If my default voice app happens to be SIP, then it will
send the request to my default outbound proxy.

So, Juha is right, those 2 URIs are very different.

> Behalf Of Paul Kyzivat
> Sent: Wednesday, April 09, 2008 09:46
> To: Juha Heinanen
> Cc: [email-masked]
> You are correct that these URIs aren't equivalent. But I 
> think Dale is right that they are often "understood" to be 
> equivalent, at least to the extent that SBCs feel free to 
> translate among them at will, and phones feel free to display 
> the number parts without regard for the domain part.
> 
> 	Paul

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 9 Apr 2008 18:20:23 -0700

What if I am trying to do video -- which cannot be done over the Internet
(unless you are insane and enjoy video delivered over an ISDN line,
naturally).

-d

> Behalf Of Francois Audet
> Sent: Wednesday, April 09, 2008 4:55 PM
> To: Paul Kyzivat; Juha Heinanen
> Cc: [email-masked]

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 9 Apr 2008 19:46:19 -0700

[resending with a correction; I had intended to say 'over the PSTN' (not 'over
the Internet').

What if I am trying to do video -- which cannot be done over the PSTN (unless
you are insane and enjoy video delivered over an ISDN line, naturally).

-d

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 9 Apr 2008 22:04:16 -0500

Well, you can still do video over PSTN with H.320. I still view this as "telephony".

Not sure I understand the question.

----
François AUDET, Nortel Networks
mailto:[email-masked]

-----Original Message-----
From: Dan Wing [mailto:[email-masked]]
Sent: Wed 09-Apr-08 7:46 PM
To: Audet, Francois (SC100:3055)
Cc: [email-masked]; 'Paul Kyzivat'; 'Juha Heinanen'
Subject: RE: [Sip] E.164 - who owns it

-d

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 9 Apr 2008 21:20:19 -0700

> From: Francois Audet [mailto:[email-masked]] 
> Sent: Wednesday, April 09, 2008 8:04 PM
> To: Dan Wing
> Cc: [email-masked]; Paul Kyzivat; Juha Heinanen

Sorry -- please pick something you cannot do over the PSTN.  Instant
Messaging, presence, high-quality video (HDTV), whatever.

> Not sure I understand the question.

Let me reword my previous email into a question:

If you have a non-SIP telephony application that trunks towards the PSTN, and
it is configured to process tel URIs, and it is asked to initiate a call that
exceeds the capabilities of the PSTN (instant messaging, presence,
HDTV-quality video, whatever you prefer) -- would it route the call towards a
"SIP trunk" in order to gain the ability to set up that call, abort the call,
or just ignore it all and trunk towards the PSTN?

An additional question (statement, actually) is:  We can't influence how that
non-SIP telephony application provides for its own identity and authentication
of tel URIs.

(This is getting me to lean more towards my email-identity straw-man.  With
it, we can step out of this festering, smelly pile of trying to get E.164
working well with SIP and move to email-style SIP URIs.  The IETF is capable
of building an end-to-end identity/authentication solution around email-style
SIP URIs; we have one (RFC4474) that works if we prohibit SBCs and B2BUAs from
modifying SDP).

-d

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 10 Apr 2008 08:03:13 +0100

> Sent: 09 April 2008 03:31
> To: [email-masked]
[JRE] But what about other parameters on the right hand side. For
example, is
tel:+123456789
an alias for:
sip:[email-masked];user=phone;gr=abd76gd6  ?

I don't think so.

And is:
sip:[email-masked];user=phone;
an alias for:
sip:[email-masked];user=phone;gr=abd76gd6  ?

I don't think so

And is:
sip:[email-masked];user=phone;gr=abd76gd6
an alias for:
sip:[email-masked];user=phone;gr=abd76gd6  ?
Possibly, assuming by routing the first one to provider.net it
eventually gets changed to the latter and routed accordingly.

You might ask whether these are valid examples. I believe they are,
because the GRUU draft says just add a gr parameter to the AoR, and I
believe the user=phone parameter is part of the AoR in this case.

Of course, you wouldn't have a GRUU in a From header field, so this is
perhaps not relevant to the RFC 4474 discussion (hence the change of
thread name), but it is germane to the issue of how a Request URI can
change as it is routed through intermediaries.

John

---

From: Heinrich Sinnreich <[email-masked]>
Date: Thu, 10 Apr 2008 07:40:22 -0500

> SIP URIs; we have one (RFC4474) that works if we prohibit SBCs and B2BUAs from

I believe this is the conclusion and about sums it up.
Henry

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Apr 2008 10:46:23 -0400

> believe the user=phone parameter is part of the AoR in this case.

IMO it is a little fuzzy whether URI parameters are actually part of an 
AOR. When adding or looking up a URI in a location service, it is first 
canonicalized by removing all URI parameters, including the "user" 
parameter. As a result, both

   sip:[email-masked];user=phone
   sip:[email-masked]

will route to the same place. Its not entirely clear to me whether the 
gruu is to be constructed with the canonicalized URI or the original 
one. But there seems to be nothing to prevent you from registering once 
using user=phone, and another time omitting it, or using user=ip. And 
you would get the same location service entry in both cases.

> change as it is routed through intermediaries.

I think the bottom line is that we can't just toss out the term "alias" 
as something that is well defined. I think that A can be an alias for B 
for one purpose, but not be an alias for B for some other purpose.

In this discussion, I think two From-URIs might sometimes be considered 
aliases of one another if they result in the same callerid display to 
the recipient, or if calls to both reach the same destination.

	Thanks,
	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 10 Apr 2008 11:49:55 -0500

I'm still not sure I get it.

If I present a Tel URI, and somebody uses it to reach me, and it just happens
that we are both using SIP as our default "Telephony" client, then sure, you
absolutely will be able to do whatever you want (IM, HD, etc.). 

The point is that if you choose to advertise a Tel URI INSTEAD of a SIP URI, don't be
surprised if you have people reaching you with PSTN-capabilies only.

Conversely, if you choose to advertize a SIP URI ONLY, then you may be missing out
entirely on people calling from PSTN.

- At least, that's the theory...

> Sent: Wednesday, April 09, 2008 21:20
> > Well, you can still do video over PSTN with H.320. I still 
> view this 
> > as "telephony".
> 
> Sorry -- please pick something you cannot do over the PSTN.  
> Instant Messaging, presence, high-quality video (HDTV), whatever.
> 
> If you have a non-SIP telephony application that trunks 
> towards the PSTN, and it is configured to process tel URIs, 
> and it is asked to initiate a call that exceeds the 
> capabilities of the PSTN (instant messaging, presence, 
> HDTV-quality video, whatever you prefer) -- would it route 
> the call towards a "SIP trunk" in order to gain the ability 
> to set up that call, abort the call, or just ignore it all 
> and trunk towards the PSTN?
> 
> An additional question (statement, actually) is:  We can't 
> influence how that non-SIP telephony application provides for 
> its own identity and authentication of tel URIs.
> 
> (This is getting me to lean more towards my email-identity 
> straw-man.  With it, we can step out of this festering, 
> smelly pile of trying to get E.164 working well with SIP and 
> move to email-style SIP URIs.  The IETF is capable of 
> building an end-to-end identity/authentication solution 
> around email-style SIP URIs; we have one (RFC4474) that works 
> if we prohibit SBCs and B2BUAs from modifying SDP).
> 
> -d
> 
>

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 10 Apr 2008 10:02:57 -0700

> Sent: Thursday, April 10, 2008 9:50 AM
> To: Dan Wing

Sure, folks might contact me over the PSTN if I used a TEL URI, and
I agree that I wouldn't be surprised.  Afterall, the PSTN remains the
lowest-common denominator for interactive communications.

> Conversely, if you choose to advertize a SIP URI ONLY, then 
> you may be missing out entirely on people calling from PSTN.
>

Advertising a SIP URI exclusively would be as silly as advertising
an email URI exclusively.  You always want a way to accept incoming
PSTN calls (because it is the lowest common denominator for 
interactive communications), and a legitimate business would also 
want a physical address and a postal address to receive physical
packages and deliveries.

-d

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 10 Apr 2008 12:11:16 -0500

> Advertising a SIP URI exclusively would be as silly as 
> advertising an email URI exclusively.  You always want a way 
> to accept incoming PSTN calls (because it is the lowest 
> common denominator for interactive communications), and a 
> legitimate business would also want a physical address and a 
> postal address to receive physical packages and deliveries.

Agreed.

Cutting to the chase, I'd put the following on my business card:

tel: +1-408-495-2456
sip:[email-masked]
mailto:[email-masked]

Cheers.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Apr 2008 13:14:28 -0400

Francois,

I agree with your point entirely.

BUT, even if I choose to advertise a sip URI (with user=phone), some of 
the UASs I call may well display only the numeric portion as the 
callerid. Those people in turn may then attempt to call me back using a 
TEL URI, and as a result, may end up going over the PSTN, even if 
originating from a sip device. (I don't know how often a PSTN path will 
be chosen even if a sip path was possible, but probably more often than 
we would wish.)

If the devices are half way smart, even if they only show the number 
they will keep the entire URI in their call log, so that if I attempt a 
callback via the call log it will use the whole URI. But I expect some 
devices will be dumber than that.

I don't know that we can do anything about it, except perhaps publish 
some best practices drafts. But I expect it may be a problem for a long 
time.

	Paul

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 10 Apr 2008 10:18:58 -0700

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Thursday, April 10, 2008 10:14 AM
> To: Francois Audet
> Cc: Dan Wing; [email-masked]
> be chosen even if a sip path was possible, but probably more 
> often than we would wish.)

Until there is a reason to use IP, nobody cares if the call goes
over the PSTN.  Reasons might include, but are not limited to,
encrypted media, strong identity, high-quality video, multimedia 
(whiteboard, screen sharing, etc.), and so on.

> some best practices drafts. But I expect it may be a problem 
> for a long time.

Yep.

-d

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Apr 2008 13:19:44 -0400

> Cutting to the chase, I'd put the following on my business card:

Interestingly, that doesn't indicate that you are reachable via sip 
using the numeric address.

A sip caller given the tel might figure that out, but might not. If you 
had user enum, and the caller used it, then all is well. But if not, and 
if the caller just blasts the tel uri to his SP, it may figure it out, 
and may not.

You are going to ask why the caller would use the tel form in that case. 
One reason would be because the UI of the device only supports numeric 
input.

	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 10 Apr 2008 12:27:10 -0500

> Interestingly, that doesn't indicate that you are reachable 
> via sip using the numeric address.

Yes, I did that on purpose. I don't see a point in doing it.

> A sip caller given the tel might figure that out, but might 
> not. If you had user enum, and the caller used it, then all 
> is well. But if not, and if the caller just blasts the tel 
> uri to his SP, it may figure it out, and may not.
> 
> One reason would be because the UI of the device only 
> supports numeric input.

So, a SIP user (or anybody young enough to prefer IM paradigm to phone
paradigm) will use sip:[email-masked].

The old luddites with a PSTN-looking phone will keep on dialing digits
on their phone. That's where the Tel URI is useful.

The niche market for sip:[email-masked];user=phone is very 
small. Beyond people on this mailing list, I really don't see who would
care. I really believe that practically speaking, sip:[email-masked];user=phone
is meant to be used "on-the wire" as opposed to by users.

sip:[email-masked]                   ~= http://www.att.com
sip:[email-masked];user=phone ~= http://www.att.com/gen/landing-pages?pid=3308

I think we are rat-holing on imaginary issues.

---

From: [email-masked]
Date: Thu, 10 Apr 2008 13:51:37 -0400

Interesting...  Because the verification generated by this algorithm
is not quite what I expected from how it was described, and it is both
narrower and probably more useful than what I expected.  The
verification is that "Within the Verifier's context, the routing rules
that are in effect send tel:+1234 to the given domain."  This actually
doesn't say anything about ownership of E.164 numbers (other than that
E.164 numbers are the space of URIs), but it says a tremendous amount
about how requests are routed from the Verifier's context:  "If I call
the given number, will I reach the given domain?"  That's not useful
for validating an incoming caller based on an asserted E.164 origin
number (unless one's local E.164 routing is known to be trustable),
but it's really useful for knowing if I can call the caller back using
the asserted E.164 number.

Dale

---

From: [email-masked]
Date: Thu, 10 Apr 2008 14:01:03 -0400

I don't think so.

   And is:

   I don't think so

   And is:

Personally, I agree with you that these URIs are all "different".  But
if we consider them to be different, any signing mechanism must
consider them to be different, and any transport mechanism must avoid
changing one of them into another.

Previously in this discussion, people have argued that SBCs are not
behaving incorrectly when they change one of these URIs into another,
and that thus any signing mechanism must tolerate such a substitution.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Apr 2008 14:05:04 -0400

> I think we are rat-holing on imaginary issues.

Perhaps. The above is a bit esoteric. A more realisic issue is what to 
put in From, where at the moment you can't put multiple choices. So I 
have to choose whether to cater to the luddites or the young. (I'm not 
young, but I don't think I'm *quite* a luddite. Just saddled with a lot 
of legacy stuff I don't have the option of changing or am too cheap to 
change. (I *am* cheap.))

At least with P-A-I you can put both a sip and a tel. The alternative 
being explored on this list of including both in normal sip signaling 
would solve that.

	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 10 Apr 2008 13:13:27 -0500

Yeah, I'd say putting sip:[email-masked];user=phone in From
(or anything "on-the-wire") is very appropriate.

I don't think we are disagreeing actually. 

> Sent: Thursday, April 10, 2008 11:05
> Cc: Dan Wing; [email-masked]; Juha Heinanen
> >> A sip caller given the tel might figure that out, but 
> might not. If 
> >> you had user enum, and the caller used it, then all is 
> well. But if 
> >> not, and if the caller just blasts the tel uri to his SP, it may 
> >> figure it out, and may not.
> >>
> >> One reason would be because the UI of the device only supports 
> >> numeric input.
> > 
> > small. Beyond people on this mailing list, I really don't see who 
> > would care. I really believe that practically speaking, 
> > sip:[email-masked];user=phone
> > sip:[email-masked];user=phone ~= 
> > http://www.att.com/gen/landing-pages?pid=3308
> > 
> Perhaps. The above is a bit esoteric. A more realisic issue 
> is what to put in From, where at the moment you can't put 
> multiple choices. So I have to choose whether to cater to the 
> luddites or the young. (I'm not young, but I don't think I'm 
> *quite* a luddite. Just saddled with a lot of legacy stuff I 
> don't have the option of changing or am too cheap to change. 
> (I *am* cheap.))
> 
> At least with P-A-I you can put both a sip and a tel. The 
> alternative being explored on this list of including both in 
> normal sip signaling would solve that.
> 
> 	Paul
>

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Thu, 10 Apr 2008 18:40:58 +0000

Paul,

I don't understand a couple of your points below.  Can you elaborate?

tim 

> Sent: Thursday, April 10, 2008 12:14 PM
> To: Francois Audet
> Cc: [email-masked]; Dan Wing
> originating from a sip device. (I don't know how often a PSTN 
> path will be chosen even if a sip path was possible, but probably more

> often than we would wish.)

Are you saying that use of tel:+4085551212 as opposed to
sip:+4085551212;user=phone makes it more likely that the call will be
routed the PSTN?  If so, why would that be?  

> devices will be dumber than that.

When you say "use the whole URI" do you mean in the R-URI?  I'm not sure
this would be desirable behavior.  If the host part of the R-URI does
not identify a domain for which the network serving the calling party is
authoritative, then as I understand it the network serving the calling
party should simply proxy the INVITE per 3263.  But then how does the
network serving the calling party provide originating services to its
subscriber?

As a practical matter I'll note that in some networks with which I am
familiar, the value to be used in the host part of the R-URI is dictated
by the network.

> for a long 

A "best practice" promoting the behavior described above, seems
problematic.  Maybe if there are networks somehow fundamentally unlike
that described above (e.g., where there is no concept of originating
services), it could be scoped to be applicable to them?  I suppose this
is a general problem with best practices - few are universally "best".

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Apr 2008 15:16:23 -0400

> routed the PSTN?  If so, why would that be?  

IMO if I give you sip:[email-masked], with or without user=phone, 
then a call back to that URI MUST be via sip, and the 3263 rules say 
that it MUST be routed to domain sp.com before making any decision about 
how to reach something associated with the user part.

If I give you tel:+4085551212, then you have total freedom regarding 
what protocol to use to reach me, and the path taken. You may just use 
an arbitrary PSTN phone, or an H.323 phone, or a proprietary voip 
service, or whatever.

> When you say "use the whole URI" do you mean in the R-URI? 

I was thinking of a device that keeps a log of *incoming* calls, so the 
From-URI would be appropriate.

> I'm not sure

If you are originating a call from a dial string, not a URI, then I 
guess you can formulate the R-URI any way you want. But if the calling 
party is supplying a URI (e.g. one it has saved from a prior received 
call) then it should be used as-is.

If you want some server on the originating end to do something for the 
outbound call, then you should put a Route header in the request 
identifying the server.

As a practical matter, suppose you receive a call from 
sip:[email-masked]. If you want to return that call, you 
have little choice but to use that as the R-URI. You can't very well 
send it to sip:[email-masked] and expect the right thing to happen.

So, if you received a call from sip:[email-masked];user=phone, 
then IMO the caller had an expectation that callbacks would be delivered 
there, not to sip:[email-masked]. But in fact that is exactly 
what a lot of systems are doing.

> is a general problem with best practices - few are universally "best".

I think as a community we are far from agreeing on what "best practices" 
are.  Hopefully it will eventually be sorted out. But it seems that 
there is a fair chance that we will never all agree on what best 
practices are in this regard, and will continue to be partitioned into a 
bunch of warring feudal communities, with tax collectors on every road.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Apr 2008 15:18:37 -0400

If I understand what Dan is proposing, the result is that you get a call 
if the callee believes the caller owns the number, regardless of whether 
anyone else in the world does.

	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 10 Apr 2008 21:13:34 +0100

Dan, 

> Sent: 09 April 2008 19:54
> To: [email-masked]; [email-masked]
[JRE] What about the following case? Enterprise.com uses two service
providers, sp1.net for incoming calls and some outgoing calls and
sp2.net for other outgoing calls. It sends an INVITE request via
sp2.net, which signs the E.164-based From URI. The SUBSCRIBE request is
routed via sp1.net to enterprise.com, which will be unable to sign the
NOTIFY request. However, if the outgoing call had gone via sp1.net there
would be no problem. I am not sure whether this behaviour is a good
thing or a bad thing.

Of course, if enterprise.com signs and the signature survives end-to-end
there is no problem and the called user gets a more useful caller ID.

John

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 10 Apr 2008 13:14:53 -0700

> Sent: Thursday, April 10, 2008 12:19 PM
> To: [email-masked]
> Cc: [email-masked]
> if the callee believes the caller owns the number, regardless 
> of whether anyone else in the world does.

Right.

And we know our own SIP routing is set up correctly, right?  
Otherwise it's broken and doesn't work for the intended purpose 
-- namely, sending SIP messages to their intended destination.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 10 Apr 2008 13:22:06 -0700

... 
> would be no problem. I am not sure whether this behaviour is a good

Here is a quick ASCII diagram of what you are describing:

                     sp1.net-<<-
                    /           
                   /             
  Enterprise.com -<
                   \
                    \sp2.net->>-

> Of course, if enterprise.com signs and the signature survives 
> end-to-end there is no problem and the called user gets a more 
> useful caller ID.

Exactly.

If enterprise.com is UNABLE to create a signature, but rather its 
signatures are destroyed and over-written by sp1.net or sp2.net,
then yes, the best that can be done is trust sp1.net and sp2.net
to have Done The Right Thing.  That is not too valuable to me.  
If that is the only value we want or need, we already have RFC4474 
that provides exactly this same characteristic.

draft-wing-sip-e164-rrc is an attempt to provide something 
stronger, so that the message arrives at Enterprise.com and 
they -- not their service provider(s) -- create the signature (as
you said).

-d

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 10 Apr 2008 21:22:07 +0100

Dale, 

> Sent: 10 April 2008 19:01
> To: [email-masked]
> Subject: Re: [Sip] E.164-based SIP URIs and TEL URIs as aliases
> 
> 
[JRE] I don't see how we can tolerate the dropping of the gr parameter,
which would happen in a couple of cases above if the URIs concerned were
treated as aliases.

John

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 10 Apr 2008 21:31:21 +0100

> Sent: 10 April 2008 15:46
> To: Elwell, John
> Cc: [email-masked]; [email-masked]
> will route to the same place. 
[JRE] Really? I always thought the purpose of the user=phone parameter
was to distinguish telephone number URIs from other URIs that happen to
look like phone numbers. With the assertion you make above, the
user=phone parameter would serve no purpose.

> Its not entirely clear to me 
> whether the 
[JRE] That wasn't really the point I was getting at. My concern is that
if user=phone can be part of a GRUU, and if SBCs see this in a
Request-URI and think "oh, it's a telephone number", they might convert
it to a tel URI, or change the domain part in the SIP URI and somehow
contrive to drop the gr parameter. In such cases the GRUU will be
corrupted and will not work.

> the recipient, or if calls to both reach the same destination.
[JRE] That might be so, but in the Request-URI it seems to be much more
of a concern. Can anyone shed any light on what SBCs might do if a
Request URI contains both user=phone and gr=xxxx parameters? Hadriel?

John

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Thu, 10 Apr 2008 22:24:27 +0000

Paul,

> > routed to the PSTN?  If so, why would that be?  
> 
> that it MUST be routed to domain sp.com before making any 
> decision about how to reach something associated with the user part.

OK, I'm fine with that.

> an arbitrary PSTN phone, or an H.323 phone, or a proprietary voip 

I see your point.  In the networks with which I am familiar there is not
such cleverness, though.  They only know SIP and PSTN, and only use PSTN
as a fallback.  So in my limited world, the type of URI (sip vs. tel)
does not impact the liklihood that the call will be transported via SIP.

> I was thinking of a device that keeps a log of *incoming* 
> calls, so the From-URI would be appropriate.

Yes, I understand that.  I was asking if you meant that the device would
put the value it extracted from the From-URI into the Request-URI of the
callback.  As opposed for example to putting it in the To-URI and maybe
constructing a R-URI with the same user part ("dialed digits") but a
different host part (identifying the network serving the calling party).
I guess such a thing would be legal.

> call) then it should be used as-is.

Well as I noted, such a call will fail in some networks with which I am
familiar.  In some cases it may succeed because the network ignores or
its dreaded SBCs overwrite, the host part of the R-URI.  I doubt you'll
find many public networks willing to allow their proxies to be used but
their call servers bypassed.

> outbound call, then you should put a Route header in the request 

I see how that could work, yes.  Except for the issue that many
currently deployed devices do not support Route headers.   

> send it to sip:[email-masked] and expect the right 

Of course.  But I believe the issue here is specific to URIs that have
telephone numbers as the user part.  

I think the issue we're wrestling with is whether the semantics of the
relationship between user and host part of such URIs is the same as that
of "email style" URIs.  I believe that it is not.

In an email style URI (one whose user part is not a telephone number)
the domain in the host part provides service to the user identified in
the user part.  In a URI whose user part is a telephone number, the
domain in the host part may or may not (i.e., cannot be assumed to)
provide service to the user identified in the user part.  By identifying
"foo.com" in the host part of a URI whose user part contains a telephone
number, I am giving the network authoritative for foo.com the right to
examine for purposes of routing, the user part of the URI.  I am not
implying that that network provides service to the user identified by
the URI's user part.  It might, but if it did that would be
coincidental.

> what a lot of systems are doing.

This has nothing to do with where the call is delivered.  If we're
talking about global public telephone numbers, then +12125551234
uniquely identifies an endpoint.  In the absence of erroroneous
configuration both calls will complete to that endpoint.  The only
practical difference is how they get there.  

> bunch of warring feudal communities, with tax collectors on 

Frankly I'm missing why this is such a big deal.  If a network changes
sip:[email-masked];user=phone to sip:[email-masked], but
the session anyway terminates to the device at which +12125551234 is
registered, so what?

Tim

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Apr 2008 19:00:01 -0400

Elwell, John wrote:
[snip]
> user=phone parameter would serve no purpose.

At one point I thought that too - that the user= parameter defined 
alternative namespaces for the user part of the uri, within the same 
domain. But then the relevant portions of 3261 were pointed out to me, 
which contradicted that idea:

3261 Section 10.3:

       5. The registrar extracts the address-of-record from the To header
          field of the request.  If the address-of-record is not valid
          for the domain in the Request-URI, the registrar MUST send a
          404 (Not Found) response and skip the remaining steps.  The URI
          MUST then be converted to a canonical form.  To do that, all
          URI parameters MUST be removed (including the user-param), and
          any escaped characters MUST be converted to their unescaped
          form.  The result serves as an index into the list of bindings.

3261 Section 16.5

    ...  When accessing the
    location service constructed by a registrar, the Request-URI MUST
    first be canonicalized as described in Section 10.3 before being used
    as an index.  The output of these mechanisms is used to construct the
    target set.

The end result is that the user= parameter really has no significance.

Section 19.1.1 says:

          The set of valid telephone-subscriber strings is a subset of
          valid user strings.  The user URI parameter exists to
          distinguish telephone numbers from user names that happen to
          look like telephone numbers.  If the user string contains a
          telephone number formatted as a telephone-subscriber, the user
          parameter value "phone" SHOULD be present.  Even without this
          parameter, recipients of SIP and SIPS URIs MAY interpret the
          pre-@ part as a telephone number if local restrictions on the
          name space for user name allow it.

Based on the above, its not that a given domain can have the same string 
represent a telephone number *and* something else. It can only do one or 
the other for any given string. The parameter is only an informative 
qualifier regarding which it is. But I don't know who it is supposed to 
be informing. The servers running within the domain presumably already 
know this.

Section 16.5 (Re proxies) says:

    If the domain of the Request-URI indicates a domain this element is
    not responsible for, the Request-URI MUST be placed into the target
    set as the only target, and the element MUST proceed to the task of
    Request Forwarding (Section 16.6).

       There are many circumstances in which a proxy might receive a
       request for a domain it is not responsible for.  A firewall proxy
       handling outgoing calls (the way HTTP proxies handle outgoing
       requests) is an example of where this is likely to occur.

Section 16.6 then gives the steps for request forwarding. In this case 
these don't change the R-URI since the target is the same as the old 
R-URI. The only way the parameters or the user portion of the R-URI can 
enter in here is in adding extra headers to the request, notably 
including Route headers. So the fact that this includes what seems to be 
a phone number could result in a Route header whose value depends on 
that phone number. But that just results in visiting added intermediate 
stops, not what the final destination is.

So, the only remaining way for this parameter to influence anything is 
in a UAS.

Section 8.2.2.1 says:

    However, the Request-URI identifies the UAS that is to process the
    request.  If the Request-URI uses a scheme not supported by the UAS,
    it SHOULD reject the request with a 416 (Unsupported URI Scheme)
    response.  If the Request-URI does not identify an address that the
    UAS is willing to accept requests for, it SHOULD reject the request
    with a 404 (Not Found) response.

Apparently the UAS only must be *willing* to process the URI - there is 
no requirement that it *be responsible* for the domain of the R-URI. IMO 
that is a mistake, but it seems to be the normative justification for SBCs.

So, a UAS that is willing may receive a request for any old domain. And 
then I guess it is free to use the user= parameter to decide that the 
user part of the URI is in tel format, and it then may decide to 
generate a *different* request to some other destination that it thinks 
is responsible for the phone number, and link the two requests.

So apparently that is the value of the user parameter.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Apr 2008 19:34:01 -0400

> I guess such a thing would be legal.

Section 8.1.1.1 of 3261 applies here:

    The initial Request-URI of the message SHOULD be set to the value of
    the URI in the To field.  One notable exception is the REGISTER
    method; behavior for setting the Request-URI of REGISTER is given in
    Section 10.  It may also be undesirable for privacy reasons or
    convenience to set these fields to the same value (especially if the
    originating UA expects that the Request-URI will be changed during
    transit).

    In some special circumstances, the presence of a pre-existing route
    set can affect the Request-URI of the message.  A pre-existing route
    set is an ordered set of URIs that identify a chain of servers, to
    which a UAC will send outgoing requests that are outside of a dialog.
    Commonly, they are configured on the UA by a user or service provider
    manually, or through some other non-SIP mechanism.  When a provider
    wishes to configure a UA with an outbound proxy, it is RECOMMENDED
    that this be done by providing it with a pre-existing route set with
    a single URI, that of the outbound proxy.

    When a pre-existing route set is present, the procedures for
    populating the Request-URI and Route header field detailed in Section
    12.2.1.1 MUST be followed (even though there is no dialog), using the
    desired Request-URI as the remote target URI.

The only case in which R-URI won't equal the To-URI is if there is a 
preexisting route set and the first route in that set is a 
strict-router. In that case the To-URI will end up as the last value of 
the Route header.

Loose routing has been defined for five years or so now. It generally 
ought to be supported. So in general the R-URI should equal the To-URI. 
In my example they would both equal what was in the From-URI of the 
incoming call that is now being returned.

> their call servers bypassed.

Their proxies don't have to be bypassed. Those proxies just become part 
of a preexisting route set known to the UAC and populated into the Route 
header.

> currently deployed devices do not support Route headers.   

Its about time they got with the program.

> of "email style" URIs.  I believe that it is not.

It should be the same until you get to the target domain.

But I just posted another message on a closely related point that goes 
into this more. You might want to reply to that.

And I don't see how treating them differently helps you. Won't your SP 
still want to provide originating services when I'm calling 
sip:[email-masked]? How will it do so?

> provide service to the user identified in the user part. 

I think we can/should assume that it is *claiming* responsibility, at 
least to the extent that return calls to this URI should pass through 
it, perhaps after passing through other servers. It may decide to relay 
the call on elsewhere, but initially it is to be assumed to be the 
responsible domain. As I note in my other post, proxies MUST treat it 
that way.

> By identifying

That is really true for any URI. When the request reaches a server 
authoritative for the domain of the URI it is some sense has reached its 
destination - the place the stated in the URI. It is up to that server 
to decide if it really wants to respond, or to forward it on to some 
*other* *more* responsible server.

There is no law that says how a server responsible for a domain is to 
interpret the user part. Even if the URI looks like a phone number and 
there is a user=phone param, it is not *obligated* to deliver the 
request to some place that the *caller* thinks owns that phone number. 
It can make its own decision.

Now this may all still work, swapping domain names while leaving the 
user part alone. But only if it is done amongst a bunch of "consenting 
adult" servers that have a consistent policy about the handling of the 
user part.

> practical difference is how they get there.  

*You* may think that +12125551234 uniquely identifies the endpoint. But 
that doesn't mean that foo.com agrees with you. foo.com minted the URI 
with the expectation that requests would be delivered to it.

You may sent it to your-sp.com *first*, but ultimately you ought to be 
getting it to the foo.com server with sip:[email-masked] as the R-URI.

A key difference in this regard is that if you are obligated to get it 
to sip:[email-masked] then you won't be able to route it via the 
PSTN. That may be exactly what foo.com intended.

> the session anyway terminates to the device at which +12125551234 is

Getting an e2e sip connection can be a big deal. It means I can 
potentially use a variety of media, rather than just voice, and I can 
use various call control primitives that wouldn't otherwise be available.

What you want can easily be achieved if the caller starts out with a tel 
uri in the r-uri field. But then it has the latitude to decide which it 
wants to do.

	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 10 Apr 2008 21:01:33 -0400

> Request URI contains both user=phone and gr=xxxx parameters? Hadriel?

That's unknowable.  There are over a dozen SBC vendors, according to the analysts, possibly as many as 30 depending on your definition, though many of them are only seen in specific markets or regions.  Even if you could ask all of them, they wouldn't be able to answer, because it's basically highly configurable. (and my guess is it is on other SIP devices too)

I know we've had a problem with it in one case where we weren't trying to prevent it from working, but in talking with some people in IETF-Philly I'm still not sure if it was specific to our config in that case, or just a problem gruu would have even with legacy true-3261 networks in general. (my guess is it's specific to SBCs, or really any b2bua, because most b2bua's replace the Contact URI, and gruu is subsequently broken... and there are a LOT more b2bua's than just SBCs)

In general though, Paul wasn't far off on the bogey-man - the whole idea of an SBC is to give total control to the owner of the SBC, imo.  (I just happen to think that's ok)  For example my company's SBC doesn't modify the req-uri unless it's set to, which of course most everyone does the instant they install it.

In my personal opinion this type of stuff can be changed by vendors or their customers through configs, and will be if it provides value, so long as it doesn't conflict with their other goals.  That's why I wrote the draft-kaplan-sip-uris-change draft.  All providers want calls to work, imho.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 10 Apr 2008 22:08:45 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul
> Kyzivat
>

Interesting.  You said "if I give you... then a call *back* to that MUST be via sip".  In what way do you mean "if I give you..."?  Like in the From-URI of an outgoing request?  Or out-of-band (e.g., on a business card)?  Or both?

> call) then it should be used as-is.

So how are we to tell which one it was, if you can formulate a dial string any which way? (I'm confused)

> outbound call, then you should put a Route header in the request

And I wish that would work, but in many cases it won't.  For some of those cases I think it's because of bad equipment, and hopefully not a permanent problem.  But the From-URI you end up getting has a host-part that is of the previous or local domain, instead of the real originating domain, and thus the Req/To-URI you end up generating later will likewise be the local or next-domain.  If we could get wider vendor support for Tel-URIs (and Route headers), this problem will go away eventually... I hope.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Apr 2008 22:45:09 -0400

> Interesting.  You said "if I give you... then a call *back* to that MUST be via sip".  In what way do you mean "if I give you..."?  Like in the From-URI of an outgoing request?  Or out-of-band (e.g…

Sorry - I wasn't clear.

In this case what I had in mind (by referring to a "call back") was that 
  I gave it to you in a From-URI.

That's just one use case. A similar one would be if I gave it to you in 
a vcard and you called me (not *back* in this case) using the URI from that.

> So how are we to tell which one it was, if you can formulate a dial string any which way? (I'm confused)

What I meant was: if you are a device with a URI that receives digits 
and uses them to construct a URI, rather than receiving a URI, then you 
can create the URI any way you want. We don't have a lot of rules about it.

For instance, you could just take the digits, slap "sip:" on the front, 
and "@domain;user=dialstring" on the back, and it would be very 
explicit. But of course almost nobody does that.

Or you could do the above but leave the user=dialstring off, on the 
agreement that it will be understood as a dialstring.

Or you could use some dial plan info local to the UAC to translate the 
dial string into an E.164 number, and then put that into a sip: or tel: URI.

How the UA decides if it is getting a dial string or a URI is up to it, 
and is strongly a function of its UI. In many cases this will be quite 
obvious. (E.g. If all it has is a number pad.) If the device is capable 
of full keyboard input, then it may always expect full URIs, or it may 
take either and distinguish based on the syntax of the text entered.

> And I wish that would work, but in many cases it won't. 

AFAIK we are in the business of determining the valid ways of doing 
things. If implementations choose to do otherwise all we can do is keep 
encouraging.

> For some of those cases I think it's because of bad equipment, and hopefully not a permanent problem.  But the From-URI you end up getting has a host-part that is of the previous or local domain, instead of the real originating domain, and thus the Req/To-URI you end up generating later will likewise be the local or next-domain.  If we could get wider vendor support for Tel-URIs (and Route headers), this problem will go away eventually... I hope.

The problem with trying to make up for the inadequacies of the neighbors 
is - how do you know which ones do it right and which do it wrong?

I guess you SBC guys can keep getting the business to try to solve that 
problem. But it really means a bunch of configuration about the 
idiosyncrasies of all the peers. That only works when there are a 
limited number of them.

	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 10 Apr 2008 23:17:45 -0400

>   I gave it to you in a From-URI.

Ah, ok.  The only issue then is that when a UAC generates a request, it's not really clear how it should know when it wants things back *only* via SIP, or when it doesn't care.  For example, if you make a phone call, why would your UAC use a From-URI of TEL?

It would (typically) be your registered AoR, and sip:me@domain.  And yet I doubt very much that most phones, or their users, really care whether people calling them *back* go through the PSTN or not to reach their SIP phone.  I bet most of them have no idea they're even *using* a SIP phone.

> things. If implementations choose to do otherwise all we can do is keep

Absolutely.  But pragmatism has its place too. (I'm not saying this is one of those times though)

> is - how do you know which ones do it right and which do it wrong?

With some things it's part of the peering agreement (e.g., a "profile"), with some things it's based on device-specific config or vendor-profiles.  But for some things it's a lowest-common-denominator: change it to what works with every device.

> idiosyncrasies of all the peers. That only works when there are a

Yup, and why I'm trying to get things to stop needing to be "fixed".  It's not core to an SBC's value prop, and not a good long-term strategy for such.

-hadriel

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Fri, 11 Apr 2008 04:06:36 +0000

Thanks, Paul.  This has been a useful exchange.

I agree with you that we need to be able to provide originating services
to the calling party without forcing the R-URI to identify a domain for
which the calling party's network is authoritative.  And as you note
this is mandatory to support "email style" R-URIs.  Inclusion of a Route
header seems like a good solution, albeit one dependent on supplier
implementation.  IMS offers another.

On reflection I'm not sure the rule that "if I give you
sip:[email-masked], with or without user=phone, then a call back to
that URI MUST be via sip" is advisable.  What if there's no VoIP peering
agreement between my network and the network authoritative for 'sp.com'?
Which would you prefer, that the call fail or that it be routed via the
PSTN?  Given that there's no practical way to know each caller's
preference, networks will have to implement some "reasonable" policy.
To me it seems reasonable to expect that someone who identifies himself
with a telephone number would not be opposed to receiving calls via the
PSTN, if that's the only way they can be delivered.

I'm not sure what you mean by "foo.com minted the URI with the
expectation that requests would be delivered to it".  I'm not sure what
"minting" means, but hopefully it doesn't involve foo.com generating
calls whose From-URI imbeds a telephone number for which foo.com is not
responsible.  "Responsibility" is a bit vague, but basically I mean that
either the number is assigned to foo.com by the numbering plan
authority, the number is ported to foo.com, or use of the number is
authorized to foo.com by its legitimate owner (e.g., through a wholesale
arrangement).  The issue is that there be a "chain of custody" leading
to the entity providing service to the number.  Implementation of lawful
intercept, for example, relies on this.

tim

> Sent: Thursday, April 10, 2008 6:34 PM
> To: Dwight, Timothy M (Tim)
> Cc: [email-masked]; Francois Audet; Dan Wing
> >>>> some best practices drafts. But I expect it may be a 
> problem for a
> > long 
> >>>> time.

---

From: Dean Willis <[email-masked]>
Date: Fri, 11 Apr 2008 03:06:01 -0500

> does not impact the liklihood that the call will be transported via  

We need an RFC 3262 for resolving Tel: URLs.

I suspect it looks like:

1) Consult your configured routing information. If that fails,
2) Do an ENUM lookup. If that fails,
3) If you have a telephony routing table (like TRIP), consult that. If  
that fails,
4) Use your default telephony route; send it to a gateway.

Or perhaps these are reorderable approaches, and each node needs  
something like an nsswitch.conf file to tell it which routing order to  
use?

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Fri, 11 Apr 2008 03:15:55 -0500

> The end result is that the user= parameter really has no significance.

It MAY have no significance. If the UAS or proxy (not registrar!) node  
has access to telephony routing information (such as TRIP), then its  
policy MAY be to treat a user=phone URI differently by applying a  
different routing policy, e.g. by picking a route from TRIP.

> be informing. The servers running within the domain presumably already

Of course, the UAS or proxy with telephony routing information MAY  
choose to apply such to a numeric looking request even without a  
user=phone.

Knowing when to do telephony routing and when to do more SIP-like  
routing (RFC 3263, etc.) is a real challenge. We missed a bet by not  
making user=phone or tel: mandatory here.

> So, the only remaining way for this parameter to influence anything is

It seems to me that a routing proxy could reroute the request based on  
numeric interpretation, and that it might choose to do numeric  
interpretation based on the user=phone.

Yep.

> So apparently that is the value of the user parameter.

If it were used consistently within an organizational topology, I  
maintain that it could have utility at rerouting proxies.

On the other hand, I think we should have just used tel: for all these  
cases. It's much cleaner.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 Apr 2008 09:26:28 -0400

> It would (typically) be your registered AoR, and sip:me@domain.  And yet I doubt very much that most phones, or their users, really care whether people calling them *back* go through the PSTN or no…

Yes, this is definitely a policy issue. And for many phones it really 
won't matter. In that case I think they would be best to use tel:. 
(Except of course that may introduce interop problems with devices that 
don't support tel. But those will be fixed by SBCs :-)

It starts to matter when the device does more than audio.

> Yup, and why I'm trying to get things to stop needing to be "fixed".  It's not core to an SBC's value prop, and not a good long-term strategy for such.

I'm really glad to hear that. And even though you are a marketing guy, I 
believe you.

	Paul

---

From: [email-masked] (Juha Heinanen)
Date: Fri, 11 Apr 2008 16:39:30 +0300

> don't support tel. But those will be fixed by SBCs :-)

i think it is mandatory for sip phones to support tel.  otherwise it is
impossible to for a sip phone in another domain to 302 caller to a pstn
number.

-- juha

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 Apr 2008 09:45:18 -0400

> implementation.  IMS offers another.

IMS *does* use Route headers for this, at least in-dialog. Its been 
quite awhile since I looked at IMS and I'm starting to forget. As I 
recall they were a bit inconsistent about whether the P-CSCF is listed 
in the Route header, or if the request is just sent there without. If I 
remember correctly the Route header isn't used for the REGISTER, But it 
is used subsequently.

In any case, if you want to just populate your request with the correct 
R-URI and then send it to an outbound proxy without naming that proxy 
anywhere in the message, that is ok too.

> PSTN, if that's the only way they can be delivered.

I wouldn't object to "trying something else", like turning the sip uri 
with user=phone into a tel uri, *if* the call otherwise cannot be 
completed. Its then an error recovery strategy.

> "minting" means,

It just means the foo.com itself created the URI. Which indicates that 
it at least *believes* it can process the user part.

> but hopefully it doesn't involve foo.com generating
> responsible. 

AFAIK foo.com is permitted to populate the user portion of the uri with 
anything it wants that is syntactically valid.

This is certainly true when user=phone is absent. And I think it is true 
if user=phone is present. All that does is make a statement about the 
*syntax* of the field, nothing about the ownership of a telephone number.

> "Responsibility" is a bit vague, but basically I mean that

Well, absent a mechanism for signing E.164 numbers with certs that 
*prove* ownership there is no way to enforce that policy. And it seems 
far from clear that others agree with you that this is the policy that 
ought to exist.

IMO that is a value of distinguishing tel from sip/user=phone. With sip, 
the supplier of the URI determines the routing. With tel, the originator 
of the call determines the routing.

It is the desire to ignore the domain name in the sip URI that leads to 
your need to have this special, unenforceable, policy on responsibility. 
(Well, its enforceable in a legal sense with peering agreements, but 
that builds a closed garden.)

	Paul

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 11 Apr 2008 10:25:17 -0400

Getting back to this, the circumstance that is worried about cannot exist.

Unlike in IP networks, an e.164 cannot be "dual homed".  It is not possible
for sp1.net and sp2.net to allow origination/termination of the same e.164

In the PSTN, a call to an e.164 always is routed to a specific service
provider.  The service provider can route it to one of several termination
domains (at the direction of the enterprise/consumer).

The enterprise can indeed be served by multiple service providers, but the
e.164s would be different.

On the PSTN, "who owns it" is actually fairly poorly defined.  In countries
where number portability is implemented, the subscriber has a right to port
the number, but it's actually "owned" in nearly every sense by the carrier
who currently serves it.  In most non-portability countries, for all intents
and purposes, the carrier owns the number.

For routing purposes, the destination of the route is known by the service
provider.  Other service providers can learn the identity of the carrier
that currently serves the number, but typically not the identity of, or the
route to, the terminating domain.  

The advent of user ENUM could change these relationships and knowledge, but,
so far, user ENUM is not widely implemented.  Infrastructure ENUM attempts
to fix the route issue, by providing anyone the termination domain
information, while retaining the current effective ownership of the numbers
by the carrier.  Private ENUM leaves the relationships as they are.

When an enterprise asserts that it owns a number, it doesn't.  The carrier
effectively owns it.  What the enterprise can do is use the number as a
globally unique string and then create some URIs using that string.  That
isn't the same thing.  We need to keep that in mind.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan
Wing
Sent: Thursday, April 10, 2008 4:22 PM
To: 'Elwell, John'; [email-masked]; [email-masked]
Subject: Re: [Sip] E.164 - who owns it

... 

                     sp1.net-<<-
                    /           
                   /             
  Enterprise.com -<
                   \
                    \sp2.net->>-

Exactly.

-d

---

From: [email-masked] (Juha Heinanen)
Date: Fri, 11 Apr 2008 17:31:00 +0300

Brian Rosen writes:

 > for sp1.net and sp2.net to allow origination/termination of the same
 > e.164.

where is that stated?  isn't it national policy if dual homing of e.164
numbers is allowed or not?

-- juha

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 11 Apr 2008 10:31:34 -0400

> > Yup, and why I'm trying to get things to stop needing to be "fixed".
> It's not core to an SBC's value prop, and not a good long-term strategy
> for such.
>

:)
I resemble that remark.  It doesn't take a rocket-scientist to figure out growth in SIP volume will mean growth in SBCs regardless, and having things work "out of the box" helps growth. (and that includes making SIP used for things other than phone calls)

-hadriel

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Fri, 11 Apr 2008 14:41:23 +0000

Paul, 

> remember correctly the Route header isn't used for the 

I guess I'm forgetting too :-)

Anyway you're right, IMS does use Route headers (except in REGISTER,
which is sent to the P-CSCF learned during "P-CSCF discovery").
Basically the UE gets a route list in the Service-Route header appended
to the 200OK received in response to the REGISTER, and uses that list in
to populate the Route header in subsequent dialog-initiating requests.

> anything it wants that is syntactically valid.

I don't disagree that IETF may permit this.  But appropriate use of
numbering resources is not up to the IETF.  I think it is at least bad
practice to identify a session originator with a URI whose structure
implies that the user part is a telephone number (user part is numeric,
preceded by '+', "user=phone" parameter appended, etc.,), unless the
originating network has some legitimate right to assign that number.  

The only reason I can think of to allow this, would be to facilitate the
sort of mischief (spoofing of caller ID etc.,) that currently plagues
the PSTN, and has been rightly criticized on this list.  

I understand that such a policy is difficult to enforce via protocol
mechanisms.  "appropriate use" policies, often are.  Still documenting
them can be of use, for example because they legitimize the punishment
:-)  And certainly if this discussion vectors into definition of a BCP
we would want to take care that the IETF not endorse or promote
antisocial practices.

tim

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 11 Apr 2008 11:07:18 -0400

In theory, as with any PSTN regulation, it could be.

As a practical matter, the way calls are routed, it isn't I believe.  Are
you aware of a country that allows it?  I'd love to see the routing tables.
You've got a better shot of allowing two carriers to originate a call with
the same e.164.  There is no error checking, or reverse routability checks
in the SS7 network.  However, usually carriers frown on spoofing of called
party number.

In all the work I've seen on numbering, including all the latest ENUM
deployments, dual homed e.164s wouldn't work.  

That doesn't mean we couldn't make them work in ENUM/SIP land, just that the
current state of the PSTN, and the ENUM deployments, doesn't allow the
possibility, AFAIK.

Brian

-----Original Message-----
From: Juha Heinanen [mailto:[email-masked]] 
Sent: Friday, April 11, 2008 10:31 AM
To: Brian Rosen
Cc: 'Dan Wing'; 'Elwell, John'; [email-masked]; [email-masked]
Subject: Re: [Sip] E.164 - who owns it

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Fri, 11 Apr 2008 18:13:36 +0300

Brian Rosen writes:

 > the same e.164.

this latter thing is what i have been demanding the regulator in finland
to allow.  i don't think there are any technical problems in
implementing it.

-- juha

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 11 Apr 2008 11:25:16 -0400

I'm not quite sure how you mean "dual-homed E.164".  In IP, I think of dual-homed as simply being reachable through multiple interfaces (for a dual-homed host), or multiple BGP exit/entry points for a common prefix (for a dual-homed end network).

If you're implying there is only one physical or logical path to reach a given E.164, well, you'd be wrong. :)  From a SIP perspective, I think there are also in fact multiple origination and termination points for the same E.164, because I consider the PSTN/H.323/whatever to be "the end" from a SIP perspective.  In other words if in SIP-land I can send a SIP Invite to one of multiple next-domains, each of which would ingress it into the PSTN, I consider them each distinct SIP termination points.  But I'm not sure you mean it that way?

-hadriel

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Brian Rosen
> Sent: Friday, April 11, 2008 11:07 AM
> To: 'Juha Heinanen'
> Cc: [email-masked]; 'Elwell, John'; 'Dan Wing'

---

From: [email-masked]
Date: Fri, 11 Apr 2008 11:28:34 -0400

From: [email-masked] (Juha Heinanen)

Well, I don't think it's *mandatory* (RFC 3261, section 7.1):

           SIP elements MAY support Request-URIs with schemes other than
           "sip" and "sips", for example the "tel" URI scheme of RFC
           2806 [9].

Dale

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 11 Apr 2008 11:32:22 -0400

Yes, I don't think there is a technical problem.  There is a trust issue,
which really is the discussion we are having.  It actually is possible for
any carrier to determine if the carrier handing it a call is the "owner" of
the TN, even if they don't do it in practice.  You seem to want to break
that.  

Seems like you need to change the actual ownership of the number to the
user, and you need a way to establish a chain of trust, in order for things
like CallerId to work reliably.

Actually, around here, we have the opposite problem.  There are certain
carriers who in fact do allow spoofing of called party number.  It has
caused quite a bit of controversy and I expect regulation soon.

In your proposals to the regulator, are you asking that ownership of a
number clearly be vested in the user, and have you proposed a mechanism for
how such ownership would be verified?  A properly administered user enum
system might do.

Brian

-----Original Message-----
From: Juha Heinanen [mailto:[email-masked]] 
Sent: Friday, April 11, 2008 11:14 AM
To: Brian Rosen
Cc: 'Dan Wing'; 'Elwell, John'; [email-masked]; [email-masked]
Subject: RE: [Sip] E.164 - who owns it

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Fri, 11 Apr 2008 18:32:28 +0300

>            "sip" and "sips", for example the "tel" URI scheme of RFC

i didn't mean mandatory in rfc 3261 sense, but mandatory in practice. or
do you have any other suggestion how i can 302 someone to my pstn
number?

-- juha

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 11 Apr 2008 11:41:22 -0400

Nope.  

I mean you can't have two calls with the same e.164 that are originated from
or terminated to different carriers.

Let's say you have two carriers who serve you.  Doesn't matter how they
serve you or where they pick up or deliver calls.  Only one of them will
(should) accept a call with a particular e.164.  Only one of them can
deliver you a call with a particular e.164.

The one carrier associated with an e.164 can deliver it to any point, or
even multiple points in a subscriber network.  There can be multiple
physical or logical paths, but the call will be originated from or
terminated to one carrier.

If you have two carriers, you have two distinct sets of e.164s that they
handle.

Brian

-----Original Message-----
From: Hadriel Kaplan [mailto:[email-masked]] 
Sent: Friday, April 11, 2008 11:25 AM
To: Brian Rosen; 'Juha Heinanen'
Cc: [email-masked]; 'Elwell, John'; 'Dan Wing'
Subject: RE: [Sip] E.164 - who owns it

I'm not quite sure how you mean "dual-homed E.164".  In IP, I think of
dual-homed as simply being reachable through multiple interfaces (for a
dual-homed host), or multiple BGP exit/entry points for a common prefix (for
a dual-homed end network).

If you're implying there is only one physical or logical path to reach a
given E.164, well, you'd be wrong. :)  From a SIP perspective, I think there
are also in fact multiple origination and termination points for the same
E.164, because I consider the PSTN/H.323/whatever to be "the end" from a SIP
perspective.  In other words if in SIP-land I can send a SIP Invite to one
of multiple next-domains, each of which would ingress it into the PSTN, I
consider them each distinct SIP termination points.  But I'm not sure you
mean it that way?

-hadriel

---

From: [email-masked] (Juha Heinanen)
Date: Fri, 11 Apr 2008 18:41:51 +0300

> the TN, even if they don't do it in practice.  You seem to want to break

not at all.  what i have suggested is that the number database that
already exists in finland that tells which carrier currently "owns" any
single number should support more than one carrier for a number.

-- juha

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 11 Apr 2008 17:15:28 +0100

Francois,

Did you mean "appropriate" or "inappropriate" below?

Up until that message, I liked what Francois and Paul have been saying
concerning using just publishing TEL and email-style SIP URIs.

It seems that E.164-based SIP URIs will still be used as aliases for
email style, essentially because when somebody dials a telephone number,
ENUM look-up on the TEL URI will yield an E.164-based SIP URI, and
onward routing will be on that basis. But that is no reason for
publishing an E.164-based SIP URI on your web site or business card.
Also for many purposes the email-style should be sufficient in From,
although it might cause a problem when delivered to a PSTN gateway or a
device that can only display a telephone number. We can, however, also
deliver a TEL URI in P-Asserted-Identity, which would solve that
problem.

In this way, RFC 4474 (or whatever we end up with to get around the
problem of SBCs altering SDP) will never need to sign an E.164-based
URI. A PSTN gateway would put an email-style SIP URI in From,
identifying the gateway rather than the party on the PSTN, and the RFC
4474 signature will be sufficient for DTLS-SRTP purposes (since
DTLS-SRTP is only as far as the gateway).

John

> Sent: 10 April 2008 19:13
> To: Paul Kyzivat
> > >> You are going to ask why the caller would use the tel 
> form in that 
> > >> case.
> > > The niche market for 
> sip:[email-masked];user=phone is very

---

From: Dean Willis <[email-masked]>
Date: Sat, 12 Apr 2008 04:04:59 -0500

> impossible to for a sip phone in another domain to 302 caller to a  

I too think tel: support is critical.

To refine the above, without tel: it is generally impossible to 302 a  
caller to a PSTN node without also specifying a route for reaching  
that node.

If one were to redirect to sip:number@domain;user=phone, one might  
still reach the correct telephone, but one would be constrained to do  
so by using the resources at the specified domain, which might or  
might not present an authorization problem.

The only way we have to redirect a caller to a PST node that is to be  
reached by the caller's best available means is to use a tel: URI.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Sat, 12 Apr 2008 04:07:02 -0500

> or terminated to different carriers.

911?

--
Dean

---

From: "Francois Audet" <[email-masked]>
Date: Sat, 12 Apr 2008 10:18:30 -0700

Every single endpoint that I've seen does NOT use a Tel URI per se, but
rather, a Tel URI embedded in a sip URI as per RFC 3261/19.1.6.

Insisting on Tel URI seems kind of out of touch with reality.

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 12 Apr 2008 13:44:42 -0400

> Francois Audet

Yeah, same here.  And it seems like a lot of servers do too (pbx/app-servers/feature-servers/etc.), or at least their configs/tables seem to be only setup for sip URI's.

-hadriel

---

From: [email-masked] (Juha Heinanen)
Date: Sat, 12 Apr 2008 21:31:23 +0300

> Insisting on Tel URI seems kind of out of touch with reality.

then PSTN is out of touch with 302.  please tell me, how can i write a
sip uri in my phone that redirects the caller in another domain to my
cell phone?

-- juha

---

From: Dean Willis <[email-masked]>
Date: Sat, 12 Apr 2008 13:46:58 -0500

> Insisting on Tel URI seems kind of out of touch with reality.

So they're functionally limited.

Explain to me what  you would send in a 302 response to redirect the  
UAS to call a certain phone number on it's own dime.

I don't believe we have a way to do this, and I have always believed  
it to be a critical use case for real integration (and no, today's  
"telephony over IP" services are not really integrated, which is why  
Gizmo customers call Vonage customers through multiple PSTN gateways).

Here's a use case:

Let's say Gizmo and Vonage some day figure out how to peer at a SIP  
level.

Assuming we maintain current billing models:

Alice is a Gizmo customer. As such, she pays Gizmo per minute on calls  
going to the PSTN, but calls to IP destinations (which don't use  
Gizmo's bandwidth) are not charged to her. Calls coming from the PSTN  
are also not charged to her.

Bob is a Vonage customer. As such, he pays Vonage per minute on calls  
going to the PSTN, but calls to IP destinations (which don't use  
Vonage's bandwidth) are not charged to him. Calls coming from the PSTN  
are also not charged to him.

Alice calls Bob. Bob wishes to redirect Alice to call the premium  
telephone destination 1-900-HELP-DSK.  This is an expensive service to  
Bob, but perhaps he thinks Alice is willing to pay for it or already  
has a service contract allowing her to call the service for free.

If Bob wanted to pay for this call, he would proxy Alice through a  
Vonage gateway, but provide credentials so that the call is charged  
back to him. Bob does not wish to pay from his account . But in this  
case, let us assume that Bob does NOT want to pay for Alice's call to  
the help desk.

The obvious way to do this is for Bob to send a 300 class response,  
probably a 302. But remember that Bob's system has no knowledge of  
Alice's PSTN routing model, and outside of a domain name, no knowledge  
of Gizmo's service at all.

So what should go into the 302 as a Contact: header field value?

It can't be "sip:[email-masked]"  or even "sip:[email-masked];user=phone 
" because Alice presumably doesn't have permission to use Vonage's  
gateways.

Perhaps Bob's system could guess that Gizmo might understand ""sip:[email-masked] 
" or maybe ""sip:[email-masked];user=phone" and use this to  
reach an appropriate gateway.

But what if Alice gets better rates by using a local phone line on her  
FXO port to reach that phone number?

What if, unknown to Bob, there's an ENUM entry for +19004357375 that  
would have allowed Alice to call that number directly over SIP instead  
of using a gateway at all?

Similar (and perhaps less contrived) use cases can be constructed  
around REFER -- how doe we ask somebody in a different domain to call  
a PSTN destination?

How do you think this should work?

The only way I'm aware of that we have to express the desired semantic  
is to redirect the call to "tel:+19004357375" and let Alice's UA  
figure out how it wants to get there.

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 12 Apr 2008 15:02:52 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Juha
> Heinanen
>
> Francois Audet writes:
>

Well a 302 with a tel may work, or may not.  Alternatively you could use a sip URI in the 302.  For the domain portion of that 302's contact: if you don't know a SIP-PSTN provider which will send it to your cell, then you could try setting it to your provider's domain (if you have one), or the domain which sent the request.  And since a 3xx can have multiple contact URIs, you can try all these at the same time, including Tel, but I suggest making the first one the most likely to succeed, because I've been told some devices can't handle multiple contacts either (ya, it's friggin nuts - don't shoot the messenger).

It's nasty, but it should work in many cases I think. (though honestly most cases I've seen just set it to sip and their provider's domain and it works... but that could easily be because I mostly only see traces from providers)

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 12 Apr 2008 15:05:33 -0400

> of the call determines the routing.

You're implying the supplier or originator of the URI cares, or has a way to let its user determine this.  Afaik, there is no button on phones for "let people call me only through sip" vs. "let people call me however they can".  Most vendors assume people want the latter, I suspect.  But since most or at least many devices use sip: all the time period, and most proxy/etc. vendors want calls to work because their customers do, they will route it whichever way they can to do so.

A second problem is the desired behavior of using the From for later requests.  Since UA's register a sip URI typically, and they use this for the From of their requests, the far-end UAS will get that From.  Since the UAS would then use this URI for its address book to generate new requests later, by your earlier emails this implies that UAS only wants the request to purely stay sip.

That would be ok if the original request stayed sip the entire path to the UAS, and the reverse path sometime later could also stay sip.  There are actually cases where that's not going to be true, but let's assume it is for now.  So imagine if the original request had a sip From but a tel req-uri.  For some reason this request gets routed through the PSTN, back over SIP to the final dest UAS.  If the PSTN-SIP gateway uses a tel From we're ok, but if it uses a sip From then per the desired behavior the UAS would use this sip URL in later requests and not be able to use the PSTN or whatever to get it back.

That, to me, is why this desired behavior is so brittle.  There are just so many times/ways a sip URL in the From or req-uri is used when it ostensibly shouldn't, that operators have little choice but to ignore it to make calls work.  I think this may be fixable eventually, but I'm not quite sure how to do that and keep all the semantics you're looking for, without having calls fail in the transition period - which is a non-starter.

> that builds a closed garden.)

People don't "desire" to ignore the domain name, they "desire" to make calls work.  If all UA's sent using tel URLs when they should per your definition, we probably wouldn't be having this conversation. :)

-hadriel

---

From: [email-masked] (Juha Heinanen)
Date: Sat, 12 Apr 2008 22:12:42 +0300

Hadriel Kaplan writes:

 > Alternatively you could
 > use a sip URI in the 302.  For the domain portion of that 302's
 > contact: if you don't know a SIP-PSTN provider which will send it to
 > your cell, then you could try setting it to your provider's domain
 > (if you have one), or the domain which sent the request.

where can i find a phone that is clever enough to use the domain of the
sender of the request?  and how do you tell your phone to do that?

-- juha

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 12 Apr 2008 15:18:22 -0400

Interesting use case.  You could argue though that the same thing could happen for tel, since a proxy along the way can recurse without Alice's consent.

(this use case though triggers some memory cells in my brain of something like this being used for a scam in the PSTN, where they got the terminating or originating provider to have to pay a 1-900 for calls they couldn't bill to the human callers, so of course the owners/co-conspirators of the 1-900 called themselves this way and profited... or maybe I'm remembering it wrong)

-hadriel

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean
> Willis
> Sent: Saturday, April 12, 2008 2:47 PM
> To: Francois Audet
> Cc: SIP IETF; Paul Kyzivat; Dan WING
> Subject: [Sip] Restatement of redirect (or refer) to a phone number
> problem (was Re: E.164 - who owns it)
>
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 12 Apr 2008 15:20:27 -0400

> Sent: Saturday, April 12, 2008 3:13 PM
>
> Hadriel Kaplan writes:
>
>  > Alternatively you could

:)
Open-source phones I assume.  Or the SER or Asterisk or whatever could probably be programmed to do it for your phone.

-hadriel

---

From: [email-masked] (Juha Heinanen)
Date: Sat, 12 Apr 2008 22:26:25 +0300

Hadriel Kaplan writes:

 > Open-source phones I assume.  Or the SER or Asterisk or whatever
 > could probably be programmed to do it for your phone.

haven't seen any.  sip is now about 10 years old and even such a basic
thing as redirecting a caller to my cell phone is not yet possible.

-- juha

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 12 Apr 2008 15:33:39 -0400

Who said it wasn't possible?  We're just talking about whether it's done the same way universally in practice.

-hadriel

> Sent: Saturday, April 12, 2008 3:26 PM
>
> Hadriel Kaplan writes:
>

---

From: "Francois Audet" <[email-masked]>
Date: Sat, 12 Apr 2008 13:25:15 -0700

Every single implementation that I've see does the following:

Contact: sip:[email-masked];user=phone

Where example.com is the domain of the forwarding user. The SIP proxy will
then route it to a PSTN if appropriate.

---

From: "Francois Audet" <[email-masked]>
Date: Sat, 12 Apr 2008 13:34:36 -0700

I do it on my SIP phone all the time.

I can put ANY SIP URI I want.

If it's a phone number, phone will append the default domain of the phone.

The other phone then INVITE the contact. The enterprise proxy looks at the
phone number and then decides if it owns it (e.g., it could be another phone
number of a phone in the enterprise). If it owns it, it will route the
INVITE to that phone. Never goes to PSTN. If it does not own it, it will
route to the appropriate PSTN gateway (based on least cost routing for
outbound PSTN gateways and such). That's what happens when I forward to my
cell phone.

The point of this story is that when ;user=phone is used, the routing is
based on the phone number. Like it or not, this is what seems to happen. In
other words, it's a functional equivalent to a Tel URI.

There is a reason why people do it like this. Try sending a Tel URI on the
wire and see what happens with most equipment out there.

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 12 Apr 2008 16:42:49 -0400

Yup, and the same thing happens at service providers too.
But I think Juha is referring to how does he redirect such without having a provider/enterprise.

-hadriel

> Sent: Saturday, April 12, 2008 4:35 PM
> To: Juha Heinanen; Hadriel Kaplan
> Cc: Francois Audet; SIP IETF; Paul Kyzivat; Dan WING; Dean Willis

---

From: "Francois Audet" <[email-masked]>
Date: Sat, 12 Apr 2008 20:11:11 -0700

Like p2psip?

You still would use the domain name of the overlay, no?

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 13 Apr 2008 00:03:42 -0400

Its my understanding that 911 is not an E.164 number.  It can't be used 
in a global TEL uri. If you want to use it in a tel uri you must combine 
it with a context, such as tel:911;phone-context=+1

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 13 Apr 2008 00:25:14 -0400

So you are telling me that you SHOULD forward someone to your own domain 
to reach a phone number even when you know that your domain would not be 
willing to route the resulting request from the forwardee. Instead you 
are *counting* on the forwardee to *ignore* the domain and the 3263 
routing rules and instead use its own logic to reach the number???

So in effect you are suggesting that we should revise 3263 regarding sip 
URIs with user=phone, and get the result widely adopted rather than get 
tel widely adopted.

	Paul

---

From: [email-masked] (Juha Heinanen)
Date: Sun, 13 Apr 2008 07:46:08 +0300

Hadriel Kaplan writes:

 > Who said it wasn't possible?  We're just talking about whether it's
 > done the same way universally in practice.

i meant "possible in practice using commercially available sip phones".
i think it would be high time to deprecate use of tel uris in sip,
because (as people indicated) they have not been implemented to the
extend that one could use them in 302s?

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Sun, 13 Apr 2008 07:48:07 +0300

> then route it to a PSTN if appropriate.

i think you have not followed this thread.  it has been pointed out that
the above does no work if caller does not have the right to use pstn
gateway of example.com.

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Sun, 13 Apr 2008 07:51:32 +0300

> wire and see what happens with most equipment out there.

if user of my proxy uses tel uri (+...) in request uri, the proxy
converts it to sip using using where host part is taken from caller's
from uri.  openser even has a function tel2sip for that purpose.

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Sun, 13 Apr 2008 07:53:53 +0300

> URIs with user=phone, and get the result widely adopted rather than get 

these two are indeed the options and this wg MUST do one of them before
writing more rfcs that no-one will implement.

-- juha

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 13 Apr 2008 00:58:55 -0400

No, I very clearly said "don't shoot the messenger", but that that is what I see happening.  Clearly you SHOULD use a tel URI, or the sip URI with the domain of your cell phone (if it has such).  But the reality is people AREN'T doing that very often, afaict.  I am in no way suggesting 3263 rules should not be followed, nor that tel uri's shouldn't be used.

Juha asked how he could write a *sip* URI in a 302 to redirect to a cell phone, and I answered what he could try.

I don't know why this is shocking - are you not seeing that often as well?  [maybe it's just me]  Don't get me wrong - I see 302's aplenty which point to a different domain as well, but in many of those cases the domain they point to is also not authoritative for the E.164 (ie, they're to transit peers).

[Although with regard to 3263, I'm not sure what part of setting the contact uri to your own domain doesn't follow that.  The target of that domain is reached (your proxy/pbx/whatever), and it can't route it locally because it has no such global user, so based on local policy it may determine an alternative path, typically to the PSTN.]

-hadriel

> Sent: Sunday, April 13, 2008 12:25 AM
> To: Hadriel Kaplan
> Cc: Juha Heinanen; Francois Audet; SIP IETF; Dan WING; Dean Willis
> Juha
> > Well a 302 with a tel may work, or may not.  Alternatively you could use
> a sip URI in the 302.  For the domain portion of that 302's contact: if
> you don't know a SIP-PSTN provider which will send it to your cell, then
> you could try setting it to your provider's domain (if you have one), or
> the domain which sent the request.  And since a 3xx can have multiple
> contact URIs, you can try all these at the same time, including Tel, but I
> suggest making the first one the most likely to succeed, because I've been
> told some devices can't handle multiple contacts either (ya, it's friggin
> nuts - don't shoot the messenger).
> >
> > It's nasty, but it should work in many cases I think. (though honestly
> most cases I've seen just set it to sip and their provider's domain and it
> works... but that could easily be because I mostly only see traces from
> providers)
> >
> > -hadriel
> >

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 13 Apr 2008 01:09:05 -0400

> the above does no work if caller does not have the right to use pstn

Sure, but the example.com proxy has rules for whether to allow such or not.  If it *doesn't* want to allow it, or it has no such alternate routes, then life sometimes gets super-ugly. [again don't shoot the messenger]  Some (not all) of those proxies then pass the 302 back upstream, but change the contact URI's domain to the domain they're passing it back up to.  In effect they do what they do for req-uri's of requests they send.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 13 Apr 2008 01:25:46 -0400

> from uri.  openser even has a function tel2sip for that purpose.

Yeah, and many people do that type of thing to get around any lack of tel-uri support.  (though I usually see it being set to the routed to next-domain, not the From domain, fwiw)

But anyway, this leads back to the original problem.  If we want a sip: req-uri to mean "only use sip", then we can't go changing tel to sip, or sip to tel, and we can't go casually using sip in From's.  That would be a big change from current defacto use, afaict.

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Sun, 13 Apr 2008 00:43:11 -0500

> then route it to a PSTN if appropriate.

I think you've missed the use case. You've forwarded the call to a  
gateway in the domain of the called party. Since the calling party  
(most probably) does not have authorization to use that gateway, the  
likely response when they attempt INVITE to that contact is a 404.

SIP, as you describe it, works just fine in a single-provider domain.  
That's telephony over IP, not a model for Internet communications.

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 13 Apr 2008 02:17:46 -0400

> That's telephony over IP, not a model for Internet communications.

But sending it to the PSTN is a model for Internet communications??

Look, for better or worse, we have allowed proxies to recurse on 3xx.  If you set a TEL uri in the contact, the upstream proxy can decide whether to recurse on that or not.  If it chooses not to, it can pass the 3xx upstream, and the *next* proxy upstream can make the same decision, and so on.

Now replace "tel:" with "sip:", and add the domain of the upstream proxy, and a user=phone.  It may be ugly.  It may be wrong.  But it's working.  And it's working across domains.  And it's probably working better than tel would right now, imho.

So where do we go from here?
Option 1) Ignore it.  This may only be a minor population of the sip community; or they may fix it themselves someday; or it may not be a real problem if they keep doing what they're doing.
Option 2) Figure out how to make tel more successful.
Option 3) Figure out how to make sip with user=phone a true alias.
Option 4) ??

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Sun, 13 Apr 2008 14:30:14 -0500

On Apr 13, 2008, at 1:17 AM, Hadriel Kaplan wrote:
> Option 1) Ignore it.  This may only be a minor population of the sip  
> community; or they may fix it themselves someday; or it may not be a  
> real problem if they keep doing what they're doing.

I'm inclined to 2 or 3. As the discussion has noted, user=phone is at  
best a trifle underdocumented. Either 2 or 3 requires additional spec  
work; but at lest the problem is tractable this way.

--
Dean

---

From: "Francois Audet" <[email-masked]>
Date: Sun, 13 Apr 2008 16:55:58 -0700

I'm just saying what I've seen.

I'm not endorsing it by any means. I'm just saying is has a better chance of
working in the real world today than putting a Tel URI on the wire.

On Apr12 2008 21:25 , "Paul Kyzivat" <[email-masked]> wrote:

>> Well a 302 with a tel may work, or may not.  Alternatively you could use a
>> sip URI in the 302.  For the domain portion of that 302's contact: if you
>> don't know a SIP-PSTN provider which will send it to your cell, then you
>> could try setting it to your provider's domain (if you have one), or the
>> domain which sent the request.  And since a 3xx can have multiple contact
>> URIs, you can try all these at the same time, including Tel, but I suggest
>> making the first one the most likely to succeed, because I've been told some
>> devices can't handle multiple contacts either (ya, it's friggin nuts - don't
>> shoot the messenger).
>> 
>> It's nasty, but it should work in many cases I think. (though honestly most
>> cases I've seen just set it to sip and their provider's domain and it

---

From: "Francois Audet" <[email-masked]>
Date: Sun, 13 Apr 2008 17:02:04 -0700

I understand what you are saying.

But I have difficulty imagining a case where the owner of the domain of the
service provider or enterprise (example.com) would not be able to reach a
PSTN gateway.

I guess you are worried about [email-masked] phoning [email-masked] and b.com doesn't have
a gateway but wants to forward to PSTN (and wants the originating to fork
the bill). So it sends tel URI instead. Sure, but again, I doubt it will
work very well.

I guess you could cheat and put a.com in the SIP contact. I think there are
lots of cases where the domain will be ignored anyways.

Again, don't shoot the messenger: it makes sense to me to use Tel URI for
this. I am just saying it may cause interop problems. Maybe that's ok, and
maybe implementations will start implementing tel URI.

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 13 Apr 2008 21:14:40 -0400

ISTM that pieces of the specs, like tel, aren't implemented for a couple 
of reasons:
- they are too hard to implement
- there isn't enough bang for the buck
- its just not understood

Tel clearly isn't *hard* to implement. That rules out the first excuse, 
and for the second implies that there isn't perceived to be much bang at 
all, since the bucks are small. So I expect that either it just isn't 
understood, or else there is perceived to be no benefit at all.

If we can demonstrate that there is value here then it seems like it 
should be possible to get implementors to support it. But maybe I'm 
being naive.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 13 Apr 2008 21:26:20 -0400

If you create a URI that know not to be valid, or don't know to be 
valid, you are asking for trouble. This is certainly the case with b.com 
constructs an a.com uri. And its also true when b.com creates a uri with 
the b.com domain for a phone number not  belonging to b.com, and gives 
it to somebody who has no service relationship with b.com. This might 
work in some cases, but it is no basis for normative behavior.

We need to specify something that can be expected to work.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 13 Apr 2008 22:21:01 -0400

> You're implying the supplier or originator of the URI cares, or has a way to let its user determine this.  Afaik, there is no button on phones for "let people call me only through sip" vs. "let peo…

As I've said elsewhere it doesn't upset me to have pstn routing used as 
a fallback. But the common behavior we've been discussing has never 
stated the sip routing will be preferentially tried.

Regarding whether the phone gives the user a way to specify this 
behavior: it would be an unusual user who would understand how to use 
such an option. But I can see how particular devices, based on their 
design of configuration, would decide this one way or another. 
Audio-only devices might just use tel all the time, since sip routing 
might not give them any benefit.

Multimedia devices, and devices with fancy audio capabilities might 
choose to advertise a sip URI because there is little benefit to them 
otherwise.

> A second problem is the desired behavior of using the From for later requests.  Since UA's register a sip URI typically, and they use this for the From of their requests, the far-end UAS will get t…

This does require some additional clarification. At the moment it is not 
legal to register a tel URI. So you must register the sip equivalent 
instead. There would need to be some clarification about the cases where 
a tel may be used with a sip phone number registration. Or else maybe it 
would be better to make registering a tel URI valid. I don't currently 
have a strong opinion on one vs the other.

> That would be ok if the original request stayed sip the entire path to the UAS,
> and the reverse path sometime later could also stay sip. 
> There are actually cases where that's not going to be true, but let's assume it
> is for now.  So imagine if the original request had a sip From but a tel req-uri.
> For some reason this request gets routed through the PSTN, back over SIP to the
> final dest UAS.  If the PSTN-SIP gateway uses a tel From we're ok, but if it
> uses a sip From then per the desired behavior the UAS would use this sip URL
> in later requests and not be able to use the PSTN or whatever to get it back.

Well, with the semantics we are trying to sort out, it would be entirely 
appropriate for the GW to use a tel uri for To-, From-, and R-URIs. 
Since the incoming call is from the PSTN it has no data to suggest that 
the caller can be reached any other way. I suppose it could use a sip 
URI identifying itself, if it *wants* to take responsibility for any 
return calls, but that is an unlikely scenario.

> That, to me, is why this desired behavior is so brittle.  There are just so
> many times/ways a sip URL in the From or req-uri is used when it ostensibly
> shouldn't, that operators have little choice but to ignore it to make calls work. 
> I think this may be fixable eventually, but I'm not quite sure how to do that
> and keep all the semantics you're looking for, without having calls fail in
> the transition period - which is a non-starter.
> 
> 

I'm proposing what I think is a more sensible and functional arrangement 
if everybody followed it. Obviously everybody doesn't follow it now, we 
need to figure out if there is a feasible migration path. But its not 
like everything that should work does work today (or we wouldn't be 
having this conversation), so there is need to figure stuff out in any case.

(My general philosophy of architecture is to first figure out when I 
want to be, then figure out how to get there, and finally make 
compromises if I can't find a way to get there. If instead you just find 
the easiest thing you can do, you just end up going in circles and 
making a hodge-podge.)

	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Sun, 13 Apr 2008 22:59:35 -0400

> stated the sip routing will be preferentially tried.

Ah.  Well, in my world it's not a black-white thing.  I always like to think sip end-end is preferential, but there are cases due to least-cost-routing or regulatory requirements that the PSTN is used when there was a sip path.  But anyway, if you think it's ok to use PSTN as a fallback for a sip: request, then I'm not sure what the problem is?  I mean that effectively weakens the scheme to be basically what we have now, no?

> return calls, but that is an unlikely scenario.

Totally, but it's not what they're doing. (some are good about this, some ain't)  And Dean is currently proposing a GW uses a sip: From URI, with a user=phone, so it can be signed.  But that is another of the many issue threads. :)

> having this conversation), so there is need to figure stuff out in any

I'm trying to remember how we got on this topic, because things are working fine with-respect-to sip as a default scheme, afaik.  I think it's architecturally ugly, and will cause us grief later, but I can't seem to recall what current "problem" drove this particular topic.(?)

-hadriel

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Mon, 14 Apr 2008 03:11:20 +0000

> Ah.  Well, in my world it's not a black-white thing.  I 
> always like to think sip end-end is preferential, but there 
> are cases due to least-cost-routing or regulatory 
> requirements that the PSTN is used when there was a sip path. 
>  But anyway, if you think it's ok to use PSTN as a fallback 
> for a sip: request, then I'm not sure what the problem is?  I 
> mean that effectively weakens the scheme to be basically what 
> we have now, no?

Seems that way to me.  Any such rule would have to allow for network
policy, and there are lots of legitimate policies e.g., least cost
routing and the necessity of SIP peering agreements, that would result
in its not being followed.  In the end this is a business issue not a
technical one.

tim

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 14 Apr 2008 00:21:01 -0400

> should be possible to get implementors to support it. But maybe I'm

Well, under the "not enough bang for buck" category would be the "it sometimes fails" sub-type.  I find that with many of the things in sip, because lots of equipment is already deployed, if a mechanism introduces a call failure probability it would have to have a really BIG benefit to overcome that.  Using a TEL URI just isn't something that can be ignored, or negotiated.  New devices introduced into an already deployed network have to work seamlessly with the legacy crap, or they don't get in.  So it may well be that lots of devices are now able to handle TEL, and we'll just never know it due to this vicious cycle. :(

-hadriel

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 14 Apr 2008 11:05:12 -0500

I think that 2 is the best.

Maybe a BCP level document explaining the use case you described 
and hope that it will encourage implementations. 

> From: Dean Willis [mailto:[email-masked]] 
> Sent: Sunday, April 13, 2008 12:30
> To: Hadriel Kaplan
> Cc: Audet, Francois (SC100:3055); SIP IETF; Paul Kyzivat; Dan WING
> I'm inclined to 2 or 3. As the discussion has noted, 
> user=phone is at best a trifle underdocumented. Either 2 or 3 
> requires additional spec work; but at lest the problem is 
> tractable this way.
> 
> --
> Dean
> 
>

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 14 Apr 2008 11:06:16 -0500

I agree.

> Sent: Sunday, April 13, 2008 18:15
> To: Dean Willis
> Cc: Hadriel Kaplan; Audet, Francois (SC100:3055); SIP IETF; Dan WING
> ISTM that pieces of the specs, like tel, aren't implemented 
> for a couple of reasons:
> Tel clearly isn't *hard* to implement. That rules out the 
> first excuse, and for the second implies that there isn't 
> perceived to be much bang at all, since the bucks are small. 
> So I expect that either it just isn't understood, or else 
> there is perceived to be no benefit at all.
> 
> If we can demonstrate that there is value here then it seems 
> like it should be possible to get implementors to support it. 
> But maybe I'm being naive.

---

From: Dean Willis <[email-masked]>
Date: Mon, 14 Apr 2008 15:51:01 -0500

> service provider or enterprise (example.com) would not be able to  

The problem is we're talking about TWO service providers, and reaching  
the wrong one's gateway.
> the bill). So it sends tel URI instead. Sure, but again, I doubt it  

It has the potential to work well, whereas what we have now doesn't.

> maybe implementations will start implementing tel URI.

I've no doubt that there will be interop problems. That's what happens  
when you specify something that has previously been unspecified and  
left to whim or caprice.

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 14 Apr 2008 19:24:45 -0400

> The problem is we're talking about TWO service providers, and reaching

I'm not sure I understand the problem.  Service providers decide whether they want to send a call to the PSTN or not for another domain, and that decision is based on their peering relationship and regulatory restrictions.  If the peering relationship is such that b.com will try the PSTN (e.g., because a.com pays b.com to be its provider), then it will, else not.  So it's not reaching the wrong one's gateway.  A.com calls b.com, b.com can forward the call to the pstn if it has that type of relationship with a.com, else it sends the 302 redirect back upstream.  What's the "wrong one's" gateway?

> It has the potential to work well, whereas what we have now doesn't.

Well, it seems to be working.  There's plenty of bilateral peering already happening, and the 302's seem to work across the providers.  It's just that the contact URI in them is not what I would call the "right" one, but it's working.

Really, in the long list of interop issues, this one's pretty low on the totem pole, imho.  People are having trouble getting basic calls to work without the aid of a middle-box.  That's a bit higher on the list to me. :)

> when you specify something that has previously been unspecified and

OK, but failing calls will not give it a high chance of being adopted.  Maybe we can figure out how to get a sip: uri to work as well - there's more than one way to skin a cat, even with a potato peeler. ;)

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Mon, 14 Apr 2008 22:08:57 -0500

On Apr 14, 2008, at 6:24 PM, Hadriel Kaplan wrote:
> I'm not sure I understand the problem.  Service providers decide  
> whether they want to send a call to the PSTN or not for another  
> domain, and that decision is based on their peering relationship and  
> regulatory restrictions.  If the peering relationship is such that  
> b.com will try the PSTN (e.g., because a.com pays b.com to be its  
> provider), then it will, else not.  So it's not reaching the wrong  
> one's gateway.  A.com calls b.com, b.com can forward the call to the  
> pstn if it has that type of relationship with a.com, else it sends  
> the 302 redirect back upstream.  What's the "wrong one's" gateway?
>
>
> Well, it seems to be working.  There's plenty of bilateral peering  
> already happening, and the 302's seem to work across the providers.   
> It's just that the contact URI in them is not what I would call the  
> "right" one, but it's working.

I really can't see how; I can't make it work with my providers

Let's revisit the problem again:

Alice is a customer of provider A.  Bob is a customer of provider B.

Alice calls Bob. Bob wishes to forward her call to Jenny's telephone  
number, +445558675309.

At this point, Bob and provider B don't know what gateway Alice might  
use to reach the PSTN, They also don't know whether reaching Jenny's  
phone number even requires Alice to use a gateway.

What does Bob put into the Contact of a 302 he might send to Alice?

I've heard several alternatives:

1) sip:+445588675309:b.com

2) sip:+445588675309:b.com; user=phone

3) sip:+445588675309:a.com

4) sip:+445588675309:b.com;user=phone

5) tel:+445588675309

So let's step through what these mean and why they each might not  
work. Keep in mind also that there's a very real possibility that  
Alice might nod NEED a gateway to reach Jenny; it's possible that  
Jenny's phone number is already in ENUM and is directly reachable via  
SIP. But this only works if Alice knows to look it up that way.

1) causes Alice to make a call to a user ID in the domain of b.com.  
Assuming that b figures out that this means a telephone destination,  
Alice probably doesn't have an account at b.com to use for placing the  
call. So unless B provides free SIP-to-PSTN calling, or at least  
provides free translation service to ENUM, she's out of luck.

Of course, maybe a.com knows that when it gets a 302 back with a  
contact that looks like it might be a phone number, it should discard  
the host part and do phone number routing on the user part. That works  
until a.com also has user IDs that look like phone numbers. Of course,  
this is a direct violation of RFC 3261, which bans a.com from  
retargeting a request with a b.com host part.

2) is much the same as 1, except that "user=phone" provides another  
hint. B is no more likely to provide gateway services, but at least  
least if A is going to do an illegal foreign retargeting, it has a  
broader hint that phone number routing instead of user routing is  
required.

3) instructs alice to make a call in the domain of a.com. That's fine  
as long as sip:+445588675309:a.com routes to Jenny. Does it? It might  
route to somebody with user ID +445588675309, which is a perfectly  
valid user ID.

It might also be true that Alice doesn't use a.com for her PSTN calls.  
Perhaps instead, she uses c.com. So to use c.com services, or do an  
enum lookup, she has to do an illegal retargeting.

4) is much like 3, with the added hint that a telephone-number  
destination is indicated. This might eliminate the accidental calling  
of user +445588675309, but it does nothing to resolve the question of  
Alice not using a.com services for PSTN gateways. There's also an open  
issue as to whether PSTN routing (such as an ENUM lookup) can be  
applied, vs requiring the call to traverse a gateway.

At the very best, a.com (or Alice's UA) knows to discard the host part  
and do telephone routing on the user part. If Alice's UA does this,  
it's probably a violation of RFC 3261, as the UA itself is not  
responsible for the host-part of the contact. A proxy in a.com could  
do this translation. But what happens if Alice doesn't use a.com for  
routing PSTN calls? For example, I might place SIP calls using  
"softarmor.com", but I make my PSTN calls using "sipphone.com", so a  
302 sent to me for "sip: [email-masked];user=phone" will  
most assuredly fail.  Now, if the a.com proxy knew to translate the  
call, that would be OK, but depending on the relationship between  
Alice and a.com, it might not.

5) doesn't work at all, because Alice's phone doesn't understand tel:  
URLs, since understanding of such was listed as a MAY in RFC 3261. But  
it's the only suggestion from the set that doesn't require violating a  
bunch of existing protocol rules.

> Really, in the long list of interop issues, this one's pretty low on  
> the totem pole, imho.  People are having trouble getting basic calls  
> to work without the aid of a middle-box.  That's a bit higher on the  
> list to me. :)

This is a very basic interdomain calling scenario. I'm really hoping  
we get more and more interdomain calls.

> OK, but failing calls will not give it a high chance of being  
> adopted.  Maybe we can figure out how to get a sip: uri to work as  
> well - there's more than one way to skin a cat, even with a potato  
> peeler. ;)

Failing calls that don't work now isn't much of a handicap.  Changing  
the rules of RFC 3261 to make case 3 or 4 generally valid might also  
work.

Fundamentally, we need a documented solution that works in the general  
case and doesn't conflict with MUST level rules of other RFCs we cite,  
unless it supercedes those RFCs.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Apr 2008 00:19:07 -0400

Dean Willis wrote:
>> pstn if it has that type of relationship with a.com, else it sends the 
>> 302 redirect back upstream.  What's the "wrong one's" gateway?
>>
>>
> So let's step through what these mean and why they each might not work. 
> Keep in mind also that there's a very real possibility that Alice might 
> nod NEED a gateway to reach Jenny; it's possible that Jenny's phone 
> number is already in ENUM and is directly reachable via SIP. But this 
> only works if Alice knows to look it up that way.
> 

As another alternative, Hadriel has mentioned b.com returning a 302 when 
it gets the request with the phone number and its domain in the R-URI. 
But I don't know what uri it will put in the 302.

> Of course, maybe a.com knows that when it gets a 302 back with a contact 
> that looks like it might be a phone number, it should discard the host 
> part and do phone number routing on the user part. That works until 
> a.com also has user IDs that look like phone numbers. Of course, this is 
> a direct violation of RFC 3261, which bans a.com from retargeting a 
> request with a b.com host part.
> 
> broader hint that phone number routing instead of user routing is required.
> 
> 3) instructs alice to make a call in the domain of a.com. That's fine as 
> long as sip:+445588675309:a.com routes to Jenny. Does it? It might route 
> to somebody with user ID +445588675309, which is a perfectly valid user ID.
> 
> Perhaps instead, she uses c.com. So to use c.com services, or do an enum 
> lookup, she has to do an illegal retargeting.
> 
> destination is indicated. This might eliminate the accidental calling of 
> user +445588675309, but it does nothing to resolve the question of Alice 
> not using a.com services for PSTN gateways. There's also an open issue 
> as to whether PSTN routing (such as an ENUM lookup) can be applied, vs 
> requiring the call to traverse a gateway.

It won't prevent calling the user with the name that looks like a 
number, at least not if a.com uses a location service. That is because 
the basic 3261 rules say to ignore the uri params when looking up in the 
location service.

	That's all the comments I have for now.
	Paul

> and do telephone routing on the user part. If Alice's UA does this, it's 
> probably a violation of RFC 3261, as the UA itself is not responsible 
> for the host-part of the contact. A proxy in a.com could do this 
> translation. But what happens if Alice doesn't use a.com for routing 
> PSTN calls? For example, I might place SIP calls using "softarmor.com", 
> but I make my PSTN calls using "sipphone.com", so a 302 sent to me for 
> "sip: [email-masked];user=phone" will most assuredly fail.  
> Now, if the a.com proxy knew to translate the call, that would be OK, 
> but depending on the relationship between Alice and a.com, it might not.
> 
> This is a very basic interdomain calling scenario. I'm really hoping we 
> get more and more interdomain calls.
> 
> 
>>
>>
>>
> the rules of RFC 3261 to make case 3 or 4 generally valid might also work.
>

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 14 Apr 2008 21:22:17 -0700

You are making this more complicated than it is. See below.

> 4) sip:+445588675309:b.com;user=phone

Bob would typically put 2, (assuming you meant
sip:[email-masked];user=phone) despite the fact that 5 would be more
appropriate.

If B.com is not the cheapest crappiest service provider or enterprise
possible, it will then recurse on it's own PSTN gateway and route the call
there.

I guess in theory, it's possible that it would pass the 302 back. If it did
do this, then I would think that it should make the 302 usable by a.com.
Passing a b.com might work (although it would probably have recursed on it
already). If it doesn't have a gateway, then I guess it could change it to a
Tel URI (which might then fail) or even substitute the domain with a.com and
let a.com deal with it (which it may or may not). Fact is, there is no free
lunch.

In any case, I think 2 is the most likely.

Now, if we want a service where you want Alice to be responsible for
figuring out "how to get to the PSNT", then yeah, I think the Tel URI is
better (but it may not work today in practice unfortunately, in which case
Alice's Proxy would have to B2BUA it and much around with the contact, which
would break 4474, yadi yada).

---

From: Dean Willis <[email-masked]>
Date: Mon, 14 Apr 2008 23:59:42 -0500

On Apr 14, 2008, at 11:19 PM, Paul Kyzivat wrote:
> number, at least not if a.com uses a location service. That is  
> because the basic 3261 rules say to ignore the uri params when  
> looking up in the location service.
>

I disagree. Once you've decided to use an RFC 3261 location service,  
what you say is probably correct. But the parameter can be used to  
make an earlier decision to use telephony routing INSTEAD of using an  
RFC 3261 location service.

RFC 3261 says:

> In addition to DNS and location service lookups shown in this  
> example, proxy servers can make flexible "routing decisions" to  
> decide where to send a request

So DNS is clearly a different sort of lookup than "location service".  
ENUM is a DNS lookup, and I see no reason why "user=phone" is not a  
valid flag for saying "don't do location service, do ENUM or TRIP or  
other telephone routing instead".
--
Dean
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Dean Willis <[email-masked]>
Date: Tue, 15 Apr 2008 00:09:27 -0500

>> 4) sip:+445588675309:b.com;user=phone

Yes, I meant "@",

> sip:[email-masked];user=phone) despite the fact that 5 would be  

But this one is fairly certain not to work.

> possible, it will then recurse on it's own PSTN gateway and route  

Try this experiment: Fire up your Gizmo account, and have the  
registered UA return a 302 to a Contact of sip:[email-masked] 
"
.

Now call "sip:[email-masked]" (or whatever your Gizmo ID  
is) from a phone that doesn't have Gizmo credentials and see if they  
let you make a free phone call to the PSTN. Hint: They don't.

> would break 4474, yadi yada).

You make a mistake in assuming that a phone number means that Alice  
has to figure out how to get to the PSTN. She doesn't -- she needs to  
figure out how to get to the target specified by the phone number,  
which might or might not be on the Internet as well as the PSTN.  
further, she needs to figure out the "best" (and that's a local policy  
question) to get there, and answering this question might involve  
choosing between multiple gateways and connecting directly over the  
Internet. It might even require something as complex as starting up a  
VPN in order to get a connection to a corporate gateway.

There is no way that the domain of the target can make this decision  
for her, unless the domain of the target is picking up the cost (the  
PSTN gateway charge) for doing so, in which a proxy-retargeting  
operation is arguably a better approach than a 302 response.

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 15 Apr 2008 01:12:15 -0400

> 4) sip:+445588675309:b.com;user=phone

Right, and there is no single answer to this, because different strokes for different folks.  (not that there shouldn't be only one way, or that the ways should be documented - I'm just being the messenger here)

Typically, Bob as a UAS puts in 1 or 2. (if one can say "typically" for a UAS redirecting to begin with)  Since that's a 302 for the original transaction, it goes upstream through Bob's b.com proxy/reg, since that's how it got to Bob to begin with.  One of those does a recursion, says "hmmm, not one of my users, and I won't send calls for a.com to PSTN, so time to redirect back a.com".  The contact then gets either changed to 3 or 4. (I assume you have a typo in 4)  OR, a.com does it when it gets a 302 back from b.com with 1 or 2 in it.  So ultimately a.com is looking at 3 or 4 in a 302 redirect.  And a.com will get this response before Alice does, because a.com was in the request path to get to b.com, so it's in the 302 response via path.  A.com then recurses on it, to the PSTN if it doesn't have such a user.

> provides free translation service to ENUM, she's out of luck.

1 and 2 never reach Alice in those forms.  3 or 4 might, but even that's debatable (it's debatable if Alice gets the 302 redirect unless both b.com and a.com can't recurse route it).

> retargeting a request with a b.com host part.

A.com gets 3 or 4, with a.com in it.

> route to somebody with user ID +445588675309, which is a perfectly

You're absolutely right that there could be a sip:[email-masked];user=phone, which b.com did not really mean.  But what *exactly* do you think will happen if a.com gets tel:+445588675309 instead??  Most likely answer: a.com will immediately resolve it to sip:[email-masked];user=phone.  I mean there's a reason people are calling it an "alias".  If you'd like, we can make the param "user=^H^H^H^H^H^H^H^H^H^H^H".  :)

> enum lookup, she has to do an illegal retargeting.

Somehow I don't think a.com or b.com care much about that. ;)

> we get more and more interdomain calls.

Oh me too!  But what I meant was there are problems getting the call from Alice to Bob working, never mind Bob redirecting to Charlie. :)

-hadriel

---

From: [email-masked] (Juha Heinanen)
Date: Tue, 15 Apr 2008 08:45:36 +0300

Hadriel Kaplan writes:

 > A.com then recurses on it, to the PSTN if it doesn't have such
 > a user.

automatic recursion of 302 by a proxy to pstn is very dangerous.  of
course alice needs to get a change to decide if she want to continue to
this new destination.

-- juha

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Apr 2008 08:39:09 -0400

I'm not comfortable with this. It may be a technically valid 
interpretation, but I have a gut feeling that it will lead to 
inconsistent service. But I can't identify a specific case at the moment.

	Paul

Dean Willis wrote:
>> the basic 3261 rules say to ignore the uri params when looking up in 
>> the location service.
>>
> 
> what you say is probably correct. But the parameter can be used to make 
> an earlier decision to use telephony routing INSTEAD of using an RFC 
> 3261 location service.
> 
> RFC 3261 says:
> 
>> In addition to DNS and location service lookups shown in this example, 
>> proxy servers can make flexible "routing decisions" to decide where to 
>> send a request
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Apr 2008 09:01:52 -0400

Hadriel Kaplan wrote:
> Typically, Bob as a UAS puts in 1 or 2. (if one can say "typically" for a UAS redirecting to begin with)  Since that's a 302 for the original transaction, it goes upstream through Bob's b.com proxy/reg, since that's how it got to Bob to begin with. 

> One of those does a recursion, says "hmmm, not one of my users, and I won't send calls for a.com to PSTN, so time to redirect back a.com".  The contact then gets either changed to 3 or 4. (I assume you have a typo in 4) 

Dean already discussed the problems with b.com attempting to construct a 
sip-based phone number URI in the domain of a.com. IMO its a really bad 
idea.

> OR, a.com does it when it gets a 302 back from b.com with 1 or 2 in it.  So ultimately a.com is looking at 3 or 4 in a 302 redirect.  And a.com will get this response before Alice does, because a.com was in the request path to get to b.com, so it's in the 302 response via path.  A.com then recurses on it, to the PSTN if it doesn't have such a user.

Conversely, it seems like a bad idea for a.com to be second guessing the 
validity of a sip uri in the domain of b.com. How does it know that it 
*won't* work? And how does it know its not really important that it 
remain as written? After all, it is b.com's URI.

At least for the moment there is nothing that I am aware of in all specs 
that suggests this is any more valid to do than it would be to change 
mailto:[email-masked] to mailto:[email-masked].

> 1 and 2 never reach Alice in those forms.  3 or 4 might, but even that's debatable (it's debatable if Alice gets the 302 redirect unless both b.com and a.com can't recurse route it).

When and if it is appropriate to recurse on 3xx, vs returning it, 
remains an open question. I think we can assume that the policies 
relating to that will change over time. So we ought not assume too much.

> You're absolutely right that there could be a sip:[email-masked];user=phone, which b.com did not really mean.  But what *exactly* do you think will happen if a.com gets tel:+445588675309 instead??…

The difference is that tel: really does unambiguously represent a phone 
number, whose target is well defined for all. Domains a.com and b.com 
are expected to agree on what it designates.

That is not true of sip:[email-masked] and sip:[email-masked]. 
And it is, arguably, not true for those with user=phone either.

> Somehow I don't think a.com or b.com care much about that. ;)

Perhaps they don't, if they don't care about standards.

But *we* care, since we are making the standards. I think we want a 
standard that can be used successfully without violating it. And I think 
we would like to make it possible for Alice to use two providers in that 
way - at least I do.

> Oh me too!  But what I meant was there are problems getting the call from Alice to Bob working, never mind Bob redirecting to Charlie. :)

I hope we fairly quickly get to the point where anybody with sip phone 
can call anybody else with a sip phone, using a sip path e2e.

	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 15 Apr 2008 06:48:22 -0700

> let you make a free phone call to the PSTN. Hint: They don't.

Yeah, sure, they are not there to lose money.

For the type of feature you are looking at, I think a Tel URI makes more
sense. I'm just pointing out with the current state of SIP phones, it
probably won't work.

> operation is arguably a better approach than a 302 response.

Again, let's recommend the Tel URI approach then.

---

From: [email-masked] (Juha Heinanen)
Date: Tue, 15 Apr 2008 17:02:52 +0300

> sense. I'm just pointing out with the current state of SIP phones, it

you are starting a new trend here.  usually this wg has not worried what
people have actually implemented.  instead it has kept on producing
countless rfc that are completely ignored by vendors.

you have to face it that the only way to fix the 302 problem is to make
tel uris mandatory.  if there is a list of fixes to rfc3261 somewhere,
please add it there.

-- juha

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 15 Apr 2008 10:12:26 -0400

I don't disagree with what you or Dean are saying in general (though I think you'll find Tel isn't going to avoid some of the issues Dean raises - they're more issues of response recursion in general).  My only point is that this is what is happening *today*, in many cases.  Dean said "it's not working", and my point was "not true - it is working right now, just not how we want and therefore it may have serious issues in the future".

-hadriel

> Sent: Tuesday, April 15, 2008 9:02 AM
> To: Hadriel Kaplan
> Cc: Dean Willis; Francois Audet; SIP IETF; Dan WING
> > Right, and there is no single answer to this, because different strokes
> for different folks.  (not that there shouldn't be only one way, or that
> the ways should be documented - I'm just being the messenger here)
> >
> > Typically, Bob as a UAS puts in 1 or 2. (if one can say "typically" for
> a UAS redirecting to begin with)  Since that's a 302 for the original
> transaction, it goes upstream through Bob's b.com proxy/reg, since that's
> how it got to Bob to begin with.
>
> > One of those does a recursion, says "hmmm, not one of my users, and I
> won't send calls for a.com to PSTN, so time to redirect back a.com".  The
> contact then gets either changed to 3 or 4. (I assume you have a typo in
> 4)
>
> > OR, a.com does it when it gets a 302 back from b.com with 1 or 2 in it.
> So ultimately a.com is looking at 3 or 4 in a 302 redirect.  And a.com
> will get this response before Alice does, because a.com was in the request
> path to get to b.com, so it's in the 302 response via path.  A.com then
> recurses on it, to the PSTN if it doesn't have such a user.
>
> > 1 and 2 never reach Alice in those forms.  3 or 4 might, but even that's
> debatable (it's debatable if Alice gets the 302 redirect unless both b.com
> and a.com can't recurse route it).
>
> > You're absolutely right that there could be a
> sip:[email-masked];user=phone, which b.com did not really mean.  But
> what *exactly* do you think will happen if a.com gets tel:+445588675309
> instead??  Most likely answer: a.com will immediately resolve it to
> sip:[email-masked];user=phone.  I mean there's a reason people are
> calling it an "alias".  If you'd like, we can make the param
> "user=^H^H^H^H^H^H^H^H^H^H^H".  :)
>
> > Oh me too!  But what I meant was there are problems getting the call
> from Alice to Bob working, never mind Bob redirecting to Charlie. :)
>

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 15 Apr 2008 08:25:03 -0700

> Alice calls Bob. Bob wishes to forward her call to Jenny's telephone

Dean, few question about requirements that I think change the  
solution ...

Assuming the call to Jenny is not free, does Bob want to pay for the  
call to Jenny or does Bob want Alice to pay for it?

Does Bob want to hide from Alice the fact that the call was forwarded.  
Often people forward their business phone to their mobile phone but  
don't want to reveal to callers either their mobile phone number or  
the fact that they are not really at their business phone.

I'm also wondering if this thread would be better dealt with in the  
BLISS WG.

Cullen <with my individual hat on>

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 15 Apr 2008 11:01:03 -0500

Yeah, exactly.

Dean says "not working" but it is working in most scenarios. 
It just doesn't work that well if everybody is trying to offload the 
responsibility of providing the PSTN gateway to others.

I have no problem with us recommending Tel URI usage for this, and 
hoping that implementations will catch-up. 

> Sent: Tuesday, April 15, 2008 07:12
> To: Paul Kyzivat
> Cc: Dean Willis; Audet, Francois (SC100:3055); SIP IETF; Dan WING
> I don't disagree with what you or Dean are saying in general 
> (though I think you'll find Tel isn't going to avoid some of 
> the issues Dean raises - they're more issues of response 
> recursion in general).  My only point is that this is what is 
> happening *today*, in many cases.  Dean said "it's not 
> working", and my point was "not true - it is working right 
> now, just not how we want and therefore it may have serious 
> issues in the future".
> 
> -hadriel
> 
> 
> > >> Alice calls Bob. Bob wishes to forward her call to Jenny's 
> > >> telephone number, +445558675309.
> > >>
> > >> At this point, Bob and provider B don't know what gateway Alice 
> > >> might use to reach the PSTN, They also don't know 
> whether reaching 
> > >> Jenny's phone number even requires Alice to use a gateway.
> > >>
> > for different folks.  (not that there shouldn't be only one way, or 
> > that the ways should be documented - I'm just being the messenger 
> > here)
> > >
> > > Typically, Bob as a UAS puts in 1 or 2. (if one can say 
> "typically" 
> > > for
> > transaction, it goes upstream through Bob's b.com proxy/reg, since 
> > that's how it got to Bob to begin with.
> >
> > > One of those does a recursion, says "hmmm, not one of my 
> users, and 
> > > I
> > won't send calls for a.com to PSTN, so time to redirect 
> back a.com".  
> > The contact then gets either changed to 3 or 4. (I assume 
> you have a 
> > typo in
> > 4)
> >
> > Dean already discussed the problems with b.com attempting 
> to construct 
> > a sip-based phone number URI in the domain of a.com. IMO 
> its a really 
> > bad idea.
> >
> > will get this response before Alice does, because a.com was in the 
> > request path to get to b.com, so it's in the 302 response 
> via path.  
> > A.com then recurses on it, to the PSTN if it doesn't have 
> such a user.
> >
> > Conversely, it seems like a bad idea for a.com to be second 
> guessing 
> > the validity of a sip uri in the domain of b.com. How does it know 
> > that it
> > At least for the moment there is nothing that I am aware of in all 
> > specs that suggests this is any more valid to do than it 
> would be to 
> > change mailto:[email-masked] to mailto:[email-masked].
> >
> > >> Assuming that b figures out that this means a telephone 
> > >> destination, Alice probably doesn't have an account at 
> b.com to use 
> > >> for placing the call. So unless B provides free SIP-to-PSTN 
> > >> calling, or at least provides free translation service 
> to ENUM, she's out of luck.
> > >
> > debatable (it's debatable if Alice gets the 302 redirect 
> unless both 
> > b.com and a.com can't recurse route it).
> >
> > >> contact that looks like it might be a phone number, it should 
> > >> discard the host part and do phone number routing on the 
> user part. 
> > >> That works until a.com also has user IDs that look like phone 
> > >> numbers. Of course, this is a direct violation of RFC 
> 3261, which 
> > >> bans a.com from retargeting a request with a b.com host part.
> > >
> > >> 3) instructs alice to make a call in the domain of a.com. That's 
> > >> fine as long as sip:+445588675309:a.com routes to Jenny. 
> Does it? 
> > >> It might route to somebody with user ID +445588675309, 
> which is a 
> > >> perfectly valid user ID.
> > >
> > sip:[email-masked];user=phone, which b.com did not 
> really mean.  
> > But what *exactly* do you think will happen if a.com gets 
> > tel:+445588675309 instead??  Most likely answer: a.com will 
> > immediately resolve it to 
> sip:[email-masked];user=phone.  I mean 
> > there's a reason people are calling it an "alias".  If 
> you'd like, we 
> > can make the param "user=^H^H^H^H^H^H^H^H^H^H^H".  :)
> >
> > The difference is that tel: really does unambiguously represent a 
> > phone number, whose target is well defined for all. Domains 
> a.com and 
> > b.com are expected to agree on what it designates.
> >
> > standard that can be used successfully without violating it. And I 
> > think we would like to make it possible for Alice to use 
> two providers 
> > in that way - at least I do.
> >
> > >>> Really, in the long list of interop issues, this one's 
> pretty low 
> > >>> on the totem pole, imho.  People are having trouble 
> getting basic 
> > >>> calls to work without the aid of a middle-box.  That's a bit 
> > >>> higher on the list to me. :)
> > >> This is a very basic interdomain calling scenario. I'm really 
> > >> hoping we get more and more interdomain calls.
> > >

---

From: Dean Willis <[email-masked]>
Date: Tue, 15 Apr 2008 11:19:31 -0500

> tel uris mandatory.  if there is a list of fixes to rfc3261 somewhere,

I'm initially attempted to agree.

But do we need tel: URI support in a node that perhaps just does IM?  
That just does presence?

Perhaps we do, if we see tel: routing and locating as becoming  
critical tools for the internet. Personally, I'm not sure this was  
what we had in mind when thinking about the locator/identifier issue.

--
Dean

---

From: [email-masked] (Juha Heinanen)
Date: Tue, 15 Apr 2008 19:25:29 +0300

> But do we need tel: URI support in a node that perhaps just does IM?  

i can imagine a mobile operator that supports im and presence via a
"pstn" gw.

-- juha

---

From: Dean Willis <[email-masked]>
Date: Tue, 15 Apr 2008 11:28:49 -0500

> call to Jenny or does Bob want Alice to pay for it?

In my original stated use case, Bob doesn't want to pay for it  
himself, and neither does Bob's service provider. If Alice wants to  
pay for it, that's OK with Bob. If she can get it free, that's OK with  
him too.
>
> Does Bob want to hide from Alice the fact that the call was  
> forwarded. Often people forward their business phone to their mobile  
> phone but don't want to reveal to callers either their mobile phone  
> number or the fact that they are not really at their business phone.

I did not explicitly state this, but the general model here would be  
for Alice to know that the call is being forwarded and where it is  
being forwarded to. Since she presumably has to pay the bill (or make  
a lowest-cost routing decision), she needs this information.

For the purpose of the call we're talking about, she might as well get  
connected with Bob and then get a REFER from him.

> I'm also wondering if this thread would be better dealt with in the  

Perhaps. but I'm thinking that this thread is digging some very  
fundamental brokenness with how we've specified and implemented SIP,  
deep in the heart of the RFC 3261 series.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Apr 2008 12:33:03 -0400

Dean Willis wrote:
> Perhaps we do, if we see tel: routing and locating as becoming critical 
> tools for the internet. Personally, I'm not sure this was what we had in 
> mind when thinking about the locator/identifier issue.

Don't we want interop between IM and SMS? If so, then you want IM 
devices to support tel URIs.

	Paul

---

From: Dean Willis <[email-masked]>
Date: Tue, 15 Apr 2008 11:33:05 -0500

> responsibility of providing the PSTN gateway to others.

Doesn't work for me with any of the providers to whose services I have  
access. Of course, most of the providers just do replicated telephone  
services over SIP. The user has no idea about the protocol involved,  
and the functions mirror what that user would have received from a  
class 5 switch or PBX.

Fact, most of the provider systems never issue a 302 at all, and this  
is partly why.

> hoping that implementations will catch-up.

Same here.

--
Dean

---

From: [email-masked] (Juha Heinanen)
Date: Tue, 15 Apr 2008 19:38:46 +0300

> > hoping that implementations will catch-up.

"recommending" is not enough.  support for  tel uris must be made
mandatory.  as i said, if there is a somewhere an rfc3261 bug list, this
belongs there.

-- juha

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Apr 2008 12:52:58 -0400

> deep in the heart of the RFC 3261 series.

There is a relationship with Bliss here, but its complicated.

Here we are simply taking "features" as use cases for investigating the 
adequacy of the fundamental mechanisms of SIP. We aren't so concerned 
with the details of those features. So IMO this is a sip problem.

OTOH, if all the features we are using for use cases are totally bogus, 
then maybe we are doing work to no useful purpose.

This is a matter of whether you think work should be driven from the 
bottom up or the top down. IMO there is no single answer to that. Some 
things need to be driven from the bottom up because there will be no 
demand for a feature until it has been demonstrated to be useful. In 
other cases top down is the way to get real world feedback into the system.

	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 15 Apr 2008 12:33:18 -0500

I'm not sure about that.

It's not because it's mandatory that people implement it (TLS, TCP, SIPS, to name a few).
I think we need instead to explain it is necessary, and what doest it mean to various components (i.e., UACs, UASs, and Proxies).

For example:

- UACs MUST support Tel URIs (and use whatever proxy they have 
  available to route requests to Tel URIs). Example, recurse on 302.

- UAs (not sure there are many problems here).

- Proxies. Need to be able to route on Tel URI. If they don't 
  recurse, need to pass 302 with Tel Contact. If they recurse, need
  to act on it.

Also, we need to warn people on improper usages of Tel URI (stupid
UA pet tricks). For example, don't use Tel URIs in Contacts other than 3XX.

In other words, this is not just as simple adding "must support
Tel URI" in RFC 3261.

> Sent: Tuesday, April 15, 2008 09:39
> To: Dean Willis
>  > > I have no problem with us recommending Tel URI usage for 
> this, and  > > hoping that implementations will catch-up.
>  >
>  > Same here.
> 
> "recommending" is not enough.  support for  tel uris must be 
> made mandatory.  as i said, if there is a somewhere an 
> rfc3261 bug list, this belongs there.
> 
> -- juha
>

---

From: Dean Willis <[email-masked]>
Date: Tue, 15 Apr 2008 13:24:29 -0500

On Apr 15, 2008, at 12:33 PM, Francois Audet wrote:
> I think we need instead to explain it is necessary, and what doest  
> it mean to various components (i.e., UACs, UASs, and Proxies).
>
> For example:
>

They don't necessarily have to use a proxy; they might have their own  
telephony routing tables, be able to make ENUM lookups, etc.

AS I've said, we need an RFC 3263 for tel: URIs if we expect people to  

> - UAs (not sure there are many problems here).

UAS might need to be able to return a Tel contact in a 302 if they  
issue 302 at all.

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 15 Apr 2008 14:46:31 -0400

I totally agree.
They need strong beneficial reasons, not mandates. (ie, the carrot, not the stick, or maybe both)

But we also need to figure out how to do this without making calls fail if they start/try actually using Tel.  Otherwise no one will.

-hadriel

> Sent: Tuesday, April 15, 2008 1:33 PM
> To: Juha Heinanen; Dean Willis
> I think we need instead to explain it is necessary, and what doest it mean
> to various components (i.e., UACs, UASs, and Proxies).
>
> For example:
>

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 15 Apr 2008 22:30:21 +0100

Juha,

In fact, it is probably a combination, e.g., mandating on receipt and
recommending on send. One thing that perhaps should be mandatory is
being able to handle tel received in a 302. Sending tel in a 302 should
not be more than a recommendation.

John

> Behalf Of Juha Heinanen
> Sent: 15 April 2008 17:39
> To: Dean Willis
> Cc: SIP IETF; Francois Audet; Paul Kyzivat; Dan WING
> this, and

---

From: [email-masked] (Juha Heinanen)
Date: Wed, 16 Apr 2008 08:06:32 +0300

> not be more than a recommendation.

fine, juha

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 16 Apr 2008 10:34:25 -0500

Hey, here is another idea.

Alice calls Bob.

Bob sends IM to Alice saying "Call me on my cell phone at +14085551212".

---

From: Anders Kristensen <[email-masked]>
Date: Wed, 16 Apr 2008 15:21:14 -0700

> 4) sip:+445588675309:b.com;user=phone

The presence of user=phone and a valid E.164 number in the user part 
seems like a pretty strong hint so I wonder if the following might work 
as a pragmatic, if not exactly elegant, way forward: allow proxies and 
the UAC to treat cases 2 and 4 as if the URI is equivalent to 5 in the 
sense that they can do ENUM query on the E.164 number and they can even 
rewrite the domain part and expect the URI to identify the same entity.

This doesn't prevent a.com from recursing when really Alice's UA would 
have liked to use another provider for gateway services but then neither 
does using a tel: URI.

We'd also want to start pushing support for tel:, of course.

Thanks,
Anders

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 16 Apr 2008 17:24:28 -0500

That's kind of what I was also saying.

PS: what's the difference between 2 and 4? 

> From: Anders Kristensen [mailto:[email-masked]] 
> Sent: Wednesday, April 16, 2008 15:21
> To: Dean Willis
> Cc: Hadriel Kaplan; SIP IETF; Audet, Francois (SC100:3055); 
> Paul Kyzivat; Dan WING
> The presence of user=phone and a valid E.164 number in the 
> user part seems like a pretty strong hint so I wonder if the 
> following might work as a pragmatic, if not exactly elegant, 
> way forward: allow proxies and the UAC to treat cases 2 and 4 
> as if the URI is equivalent to 5 in the sense that they can 
> do ENUM query on the E.164 number and they can even rewrite 
> the domain part and expect the URI to identify the same entity.
> 
> This doesn't prevent a.com from recursing when really Alice's 
> UA would have liked to use another provider for gateway 
> services but then neither does using a tel: URI.
> 
> destination, 
> > 302 sent to me for "sip: 
> [email-masked];user=phone" will 
> pretty low on 
> >>>> Again, don't shoot the messenger: it makes sense to me 
> to use Tel 
> >>>> URI for this. I am just saying it may cause interop 
> problems. Maybe 
> >>>> that's ok, and maybe implementations will start implementing tel 
> >>>> URI.
> >>> I've no doubt that there will be interop problems. That's what 
> >>> happens when you specify something that has previously been 
> >>> unspecified and left to whim or caprice.
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments on the application of sip
> > 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 16 Apr 2008 18:38:57 -0400

> PS: what's the difference between 2 and 4? 

I think 4 is a typo and was presumably intended to be

    4) sip:+445588675309:a.com;user=phone

It is already the case that a.com may treat 3,4 & 5 alike if it wishes.
And b.com may treate 1,2 & 5 alike if it wishes.

The question is whether a.com may treat 1&2 like 5, or if b.com may 
treat 3&4 like 5.

Apparently some are saying that user=phone is license to ignore the 
domain. But that just raises the question of why one would insert a 
domain along with a parameter that says to ignore it. Makes no sense to me.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 16 Apr 2008 19:03:47 -0400

replying to myself - another thought:

> domain along with a parameter that says to ignore it. Makes no sense to me.

This would make *some* sense to me if the semantics were:

1) you MAY route to this domain following 3263 procedures with 
expectation that it will work.

2) if you are unable to do that (say because you don't have a sip path 
at all, or don't have a path to the domain in the URI) then you may 
treat it as a tel URI and route it any way that works for you.

But it seems that in many of the use cases that have been presented in 
this thread it is actually the case that if the recipient routes to the 
domain in the URI the request *won't* work. That makes absolutely no 
sense to me. In that case TEL seems clearly the right way.

Now Hadriel has made a case that it is the SBC's job to fix this up. So 
when the URL exits the domain in which it will work, then the SBC should 
fix it up with the domain it is going into. I guess that could make 
sense if that SBC was acting as an agent of *both* domains. But 
typically it is only acting as an agent of one domain. An SBC acting for 
b.com has no business changing the domain of the URL to a.com, since 
doing so is (or isn't) a policy of a.com.

A way around that is to say that if the URI contains b.com, then an SBC 
acting for b.com, when it knows it won't honor that, can change it to a 
TEL URI when it exits the domain. It then may well go through another 
SBC acting for a.com as it enters the a.com domain. That SBC could 
change the TEL URI to an a.com URI if that will be handled correctly 
within the a.com domain.

	Paul

---

From: "Robins, Ellen" <[email-masked]>
Date: Thu, 17 Apr 2008 09:35:35 +1000

Hi everyone,
On the subject of E.164 discussion is there a universal preffix or list
of registered preffixes to signify VoIP call.
For example, the same E.164 Mobile or PSTN services numbers can be used
for dialling Video or Voice Call over IP.
Scenario: Alice has her Mobile service number but would like to receive
a call instead of Mobile on her PC SIP Soft Client.
Are there a preffix XYZ that would indicates to network that this call
shall be routed via Gateway to IP Client instead of Mobile ?

Thanks and kind regards / Ellen Robins
ViG Technology Manager
Services Enablers
Wireless Engineering & Operations
Telstra Operations
Telstra Corporation Limited
  
Ph 03 8627 8981
Mob 0428 309 250
Fax 03 9620 7864
Mail [email-masked] 

The information contained in this email message may be confidential. If
you are not the intended recipient, any use of, interference with,
disclosure or copying of this material is unauthorised and prohibited.
If you have received this message in error, please notify me by reply
email and then delete the message.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Paul Kyzivat
Sent: Thursday, 17 April 2008 9:04 AM
To: Francois Audet
Cc: SIP IETF; Dan WING; Dean Willis
Subject: Re: [Sip] E.164 - who owns it

	Paul

>>> Cc: Hadriel Kaplan; SIP IETF; Audet, Francois (SC100:3055); Paul 
>>> Kyzivat; Dan WING

>>> seems like a pretty strong hint so I wonder if the following might 
>>> work as a pragmatic, if not exactly elegant, way forward: allow 
>>> proxies and the UAC to treat cases 2 and 4 as if the URI is 
>>> equivalent to 5 in the sense that they can do ENUM query on the 
>>> E.164 number and they can even rewrite the domain part and expect 
>>> the URI to identify the same entity.
>>>
>>> This doesn't prevent a.com from recursing when really Alice's UA 
>>> would have liked to use another provider for gateway services but 
>>> then neither does using a tel: URI.
>>>

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 16 Apr 2008 18:49:20 -0500

I think the idea is that if you provide a phone number, then
there are alternate ways to reach it than using the domain.

Not sure there is much we can do about this. It's a consequence
of having this type of dualing addressing spaces. 

> Sent: Wednesday, April 16, 2008 15:39
> Cc: Anders Kristensen; Dean Willis; Hadriel Kaplan; SIP IETF; Dan WING
> The question is whether a.com may treat 1&2 like 5, or if 
> b.com may treat 3&4 like 5.
> 
> Apparently some are saying that user=phone is license to 
> ignore the domain. But that just raises the question of why 
> one would insert a domain along with a parameter that says to 
> ignore it. Makes no sense to me.
> 
> 	Paul
> 
> user part 
> >> equivalent to 5 in the sense that they can do ENUM query 
> on the E.164 
> >> number and they can even rewrite the domain part and 
> expect the URI 
> >> to identify the same entity.
> >>

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 16 Apr 2008 18:50:48 -0500

This is starting to smell like BCP material actually. 

> Sent: Wednesday, April 16, 2008 16:04
> 1) you MAY route to this domain following 3263 procedures 
> with expectation that it will work.
> 
> 2) if you are unable to do that (say because you don't have a 
> sip path at all, or don't have a path to the domain in the 
> URI) then you may treat it as a tel URI and route it any way 
> that works for you.
> 
> But it seems that in many of the use cases that have been 
> presented in this thread it is actually the case that if the 
> recipient routes to the domain in the URI the request *won't* 
> work. That makes absolutely no sense to me. In that case TEL 
> seems clearly the right way.
> 
> Now Hadriel has made a case that it is the SBC's job to fix 
> this up. So when the URL exits the domain in which it will 
> work, then the SBC should fix it up with the domain it is 
> going into. I guess that could make sense if that SBC was 
> acting as an agent of *both* domains. But typically it is 
> only acting as an agent of one domain. An SBC acting for 
> b.com has no business changing the domain of the URL to 
> a.com, since doing so is (or isn't) a policy of a.com.
> 
> A way around that is to say that if the URI contains b.com, 
> then an SBC acting for b.com, when it knows it won't honor 
> that, can change it to a TEL URI when it exits the domain. It 
> then may well go through another SBC acting for a.com as it 
> enters the a.com domain. That SBC could change the TEL URI to 
> an a.com URI if that will be handled correctly within the 
> a.com domain.
> 
> 	Paul
> 
> > 	Paul
> > 
> >>>> "softarmor.com", but I make my PSTN calls using 
> "sipphone.com", so 
> >>>> a
> >>>> 302 sent to me for "sip:

---

From: Dean Willis <[email-masked]>
Date: Wed, 16 Apr 2008 20:59:27 -0500

> PS: what's the difference between 2 and 4?

the difference is a typo on my part.

Should be:

1) sip:[email-masked]

2) sip:[email-masked]; user=phone

3) sip:[email-masked]

4) sip:[email-masked];user=phone

5) tel:+445588675309

so the difference between 2 and 4 is the domain part of the Contact:  
header field's URI value in the 302.

First case is that the constructed URI is in the terminating domain,  
which works only if the terminating domain is willing to provide PSTN  
service to Alice. This is just a business case problem -- which, IMHO,  
makes it intractable in some cases. Sure, most of the cases we see  
today have Alice and Bob in the same domain, so it works fine  
intradomain.

Second case is that the constructed URI is in the originating domain,  
which works only if a) it guesses the URI construction correctly, and  
b) Alice has access to the PSTN through that domain.  Both A and B can  
be mediated by Alice or the a.com proxy "understanding" what this sort  
of response means and then figuring it how to transform the URI to  
something they can route. If Alice doesn't use a.com for PSTN service  
and the a.com proxy recurses, it is certain to fail -- but that's  
between Alice and a.com.

One might make the argument that a UA or recursing proxy should "know"  
that if it sees a 302 Contact URI with a domain part equal to that of  
the sender's and a "user=phone" modifier, that a redirection to PSTN  
has been requested.

It;s been proposed that we use #5: if tel: is known to be supported,  
and #4 if it isn't. That's actually quite doable by adding a SIP  
extension tag for "tel" to the Supported field of the request.

How about: A node generating a redirect-to-PSTN in the caller's domain  
MUST use a tel: URI if the request contains a "tel" option tag, and  
SHOULD use a "number@sourcedomain;user=phone" construction if the  
request does not contain such a tag.

--
Dean, who cannot type.

---

From: Dean Willis <[email-masked]>
Date: Wed, 16 Apr 2008 21:05:00 -0500

> shall be routed via Gateway to IP Client instead of Mobile ?

No, there is to my knowledge no such prefix.

In fact, such an approach is contraindicated by use cases:

One might envision a dual-mode phone that registers the same number  
concurrently via mobile protocols and SIP.

Callers from the mobile or PSTN world would probably reach it via  
mobile, and callers from the Internet would reach it via SIP. But even  
that isn't cut-and-dried, since a phone-switch or pbx somewhere on the  
route between a mobile caller and the dual-mode phone might do a least- 
cost path determination and decide to gateway the call to SIP for the  
remainder of the path. Even more confusingly, there are scenarios  
where several such translations might occur.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 16 Apr 2008 22:15:19 -0400

Francois,

I agree much of what I wrote below does sound like a candidate for a 
BCP. But I think it is still a bit premature to write one. At the moment 
I think it is just use cases we are playing with to explore the solution 
space.

	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 17 Apr 2008 00:24:36 -0400

> Now Hadriel has made a case that it is the SBC's job to fix this up.

Hmm... I don't seem to recall saying that at all!  Something has to do it, but it by no means has to be an SBC.  It could, for example, be the same proxy that decided it could not resolve it locally and to pass the 302 upstream.

> So

On the contrary, one could argue a.com has no business changing b.com's domain to a.com, but I see nothing wrong with b.com changing the domain to a.com.  Don't get me wrong - the whole thing sucks, but from a "who's business is it" perspective I think it's b.com's.  Otherwise you're essentially arguing that b.com cannot retarget requests to a.com either.  What's "wrong" is for a.com to retarget requests addressed to b.com to itself instead.

> change the TEL URI to an a.com URI if that will be handled correctly

Funny enough I've seen a case where that exactly happens.  It seemed crazy to me though.

-hadriel

---

From: [email-masked] (Juha Heinanen)
Date: Thu, 17 Apr 2008 09:25:26 +0300

Dean Willis writes:

 > mobile, and callers from the Internet would reach it via SIP. 

a civilized mobile operator would, before routing the call anywhere,
make an enum query and act accordingly.

-- juha

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 17 Apr 2008 10:19:27 -0400

> Hmm... I don't seem to recall saying that at all!  Something has to do it, but it by no means has to be an SBC.  It could, for example, be the same proxy that decided it could not resolve it locall…

OK, *something* has to do it.
In *some* cases a proxy could do it. But in many cases only a UA is 
allowed to do it. For instance changing the From URI. If we are arguing 
that some middlebox is supposed to make this problem go away generally, 
then it will have to be a middlebox that is a UA, hence a B2BUA. Ones 
that perform that sort of role are generally called SBCs.

> On the contrary, one could argue a.com has no business changing b.com's domain to a.com, but I see nothing wrong with b.com changing the domain to a.com.  Don't get me wrong - the whole thing sucks…

Maybe I need to state my point better.
Depending on the type of box and the header that is being modified, a 
box acting for b.com may indeed be permitted to replace a b.com URL with 
some other URL, even an a.com URL. (In fact it doesn't matter what the 
domains of the two urls are, it may be able to do it.)

What is a problem is for b.com to *fabricate* an a.com URL to insert.
b.com in in general not privy to the policies governing the construction 
of urls in the a.com domain, and so has no business constructing one.

And that is what is happening if b.com "changes the domain to a.com" in 
the URL.

> Funny enough I've seen a case where that exactly happens.  It seemed crazy to me though.

Its not at all crazy.

What it means is that b.com is converting one of its own URLs, whose 
semantics it understands, into a url with standardized semantics. Then 
a.com is converting a url with standardized semantics into a url in the 
a.com domain, whose semantics *it* understands.

The alternative is to declare any sip URI with user=phone has 
standardized semantics, and that all domains must support that form. Or, 
every box making the conversion must understand the policies of both sides.

It seems that most are now agreeing that tel URIs would be the right way 
to exchange phone numbers, but are concerned with backward compatibility 
to all those devices that purportedly don't support them. The migration 
is eased of we assume that SBCs (which seem to be everywhere anyway) can 
do the fixup for those that don't support it. And over time the fixups 
could be eliminated.

	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 17 Apr 2008 10:33:31 -0400

> > Funny enough I've seen a case where that exactly happens.  It seemed

Sorry, I should have been clearer - it seemed crazy to me because the two SBC's were connected with a direct fiber, and all responses upstream from b.com were going nowhere but a.com.  :)

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 17 Apr 2008 10:56:42 -0400

> Sorry, I should have been clearer - it seemed crazy to me because the two SBC's were connected with a direct fiber, and all responses upstream from b.com were going nowhere but a.com.  :)

If the fiber was a trunk connecting two peers then I don't think it is 
crazy. It seems preferable to hard coding the peer's policy.

	Paul

---

From: Anders Kristensen <[email-masked]>
Date: Thu, 17 Apr 2008 17:27:31 -0700

Dean Willis wrote:
> It;s been proposed that we use #5: if tel: is known to be supported, and 
> #4 if it isn't. That's actually quite doable by adding a SIP extension 
> tag for "tel" to the Supported field of the request.
> 

Proxies can't muck with Supported headers so I'm not sure how this helps 
if it's a proxy in the caller's domain (as opposed to the UAC itself) 
that understands and acts on tel: URIs.

Anders

---

From: Dean Willis <[email-masked]>
Date: Thu, 17 Apr 2008 20:52:02 -0500

On Apr 17, 2008, at 7:27 PM, Anders Kristensen wrote:

>
>
> Dean Willis wrote:
>> It;s been proposed that we use #5: if tel: is known to be  
>> supported, and #4 if it isn't. That's actually quite doable by  
>> adding a SIP extension tag for "tel" to the Supported field of the  
>> request.
>> How about: A node generating a redirect-to-PSTN in the caller's  
>> domain MUST use a tel: URI if the request contains a "tel" option  
>> tag, and SHOULD use a "number@sourcedomain;user=phone" construction  
>> if the request does not contain such a tag.
>
> Proxies can't muck with Supported headers so I'm not sure how this  
> helps if it's a proxy in the caller's domain (as opposed to the UAC  
> itself) that understands and acts on tel: URIs.

So assume the UAC does not support "tel" and the UAS's domain is not  
going to pay to send the call to the PSTN -- the redirecting node ends  
up doing what it would do now, which is assume that tel isn't  
supported, and make its best SIP guess at a SIP rewrite in the UAC's  
domain.

Proxies that recurse on 302 responses should be taken out and burned  
anyhow. It's just a tragically stupid thing to do in most cases. In  
the scenarios we're talking about, which probably involve a transition  
from a "no charge" IP call to a potentially very expensive (like, up  
to $25 a minute for some premium services) PSTN call, the user REALLY  
needs to be able to make a decision.

So the limitation you've noted doesn't bother me at all.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 18 Apr 2008 08:00:27 -0400

> needs to be able to make a decision.

This doesn't bother me. If this happens I'm just going to refuse to pay 
the bill, with the argument that "I never called that number". So this 
is a feature.

IMO if a proxy was already forking, or prepared to fork, then recursing 
on 3xx is not making things any worse.

Also, you are assuming that the recursion is happening in the calling 
domain. It may well be happening in the called domain, which may want to 
hide the 3xx response from the calling domain.

> So the limitation you've noted doesn't bother me at all.

Why should we need Supported:tel before tel can be used? Its already 
supposed to be supported.

	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 18 Apr 2008 10:32:23 -0400

> needs to be able to make a decision.

I think that's a great utopian view, but in the real world that would be impractical.  A great many SIP UA's are ultimately just TDM gateways, providing POTS-type interfaces into the home, or PBX phone lines into the office, etc.  Afaik there is no way for them to indicate this redirection to the human, or have a way to be told yes/no by the human.  Some people handle this type of thing with an app-server b2bua where it plays out a message and takes in DTMF to make the decision, but I think that's uncommon.

I think/hope in the common case, if a call goes from one provider to another, the second provider will not recurse it outside of its domain and will pass it back upstream to the calling provider to decide.  I think that because often the billing model between them seems to dictate that.  I have no doubt some cases will occur to validate your concern, but I think market forces will "correct" them naturally over time.  Providers have plenty of natural motivation not to piss off their customers and regulators.

-hadriel

---

From: [email-masked] (Juha Heinanen)
Date: Fri, 18 Apr 2008 17:41:24 +0300

Hadriel Kaplan writes:

 > I think that's a great utopian view, but in the real world that would
 > be impractical.  A great many SIP UA's are ultimately just TDM
 > gateways, providing POTS-type interfaces into the home, or PBX phone
 > lines into the office, etc.  Afaik there is no way for them to
 > indicate this redirection to the human, or have a way to be told
 > yes/no by the human.  

in that case their proxy should definitely not recurse on 302 and if the
sip ua box has no way to ask confirmation from the user regarding 302,
then 302 processing should be turned off in the box.

-- juha

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 18 Apr 2008 10:58:55 -0500

I think Hadriel is right.

As much as I agree that from a technical perspective, having 302s not 
recursed on by proxies is better, I can't see this generally becoming
the norm in this SIP universe. It's too late for that.

Maybe in SIP Four Dot Oh. 

> Sent: Friday, April 18, 2008 07:32
> To: Dean Willis; Anders Kristensen
> I think that's a great utopian view, but in the real world 
> that would be impractical.  A great many SIP UA's are 
> ultimately just TDM gateways, providing POTS-type interfaces 
> into the home, or PBX phone lines into the office, etc.  
> Afaik there is no way for them to indicate this redirection 
> to the human, or have a way to be told yes/no by the human.  
> Some people handle this type of thing with an app-server 
> b2bua where it plays out a message and takes in DTMF to make 
> the decision, but I think that's uncommon.
> 
> I think/hope in the common case, if a call goes from one 
> provider to another, the second provider will not recurse it 
> outside of its domain and will pass it back upstream to the 
> calling provider to decide.  I think that because often the 
> billing model between them seems to dictate that.  I have no 
> doubt some cases will occur to validate your concern, but I 
> think market forces will "correct" them naturally over time.  
> Providers have plenty of natural motivation not to piss off 
> their customers and regulators.
> 
> -hadriel
>

---

From: Dean Willis <[email-masked]>
Date: Fri, 18 Apr 2008 13:46:13 -0500

On Apr 18, 2008, at 7:00 AM, Paul Kyzivat wrote:

>
>
> Dean Willis wrote:
>
>> Proxies that recurse on 302 responses should be taken out and  
>> burned  anyhow. It's just a tragically stupid thing to do in most  
>> cases. In  the scenarios we're talking about, which probably  
>> involve a transition  from a "no charge" IP call to a potentially  
>> very expensive (like, up  to $25 a minute for some premium  
>> services) PSTN call, the user REALLY  needs to be able to make a  
>> decision.
>
> This doesn't bother me. If this happens I'm just going to refuse to  
> pay the bill, with the argument that "I never called that number".  
> So this is a feature.

I look forward to seeing that argument played on Judge Judy's daytime  
TV show.

>
> IMO if a proxy was already forking, or prepared to fork, then  
> recursing on 3xx is not making things any worse.

That depends on who it was forking to. If the forks are "retargeting",  
then recursing on a 302 is only marginally worse. If however the forks  
are "rerouting", than recursing on a 302 raises all sorts of  
unanticipated respondent problems that not recursing would have avoided.

>
> Also, you are assuming that the recursion is happening in the  
> calling domain. It may well be happening in the called domain, which  
> may want to hide the 3xx response from the calling domain.

That's fair.

> supposed to be supported.

Ok, spec dude: Can you show me a citation that says tel: MUST be  
supported by a SIP UA? Even a SHOULD?

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Fri, 18 Apr 2008 14:00:46 -0500

On Apr 18, 2008, at 9:32 AM, Hadriel Kaplan wrote:

> I think that's a great utopian view, but in the real world that  
> would be impractical.  A great many SIP UA's are ultimately just TDM  
> indicate this redirection to the human, or have a way to be told yes/ 
> no by the human.  Some people handle this type of thing with an app- 
> server b2bua where it plays out a message and takes in DTMF to make  

IMHO, the right thing for a POTS terminal to do on a 302 response is  
probably either indicate an error condition to the user or use a voice  
app to inform the user if no GUI is available.
>
> I think/hope in the common case, if a call goes from one provider to  
> another, the second provider will not recurse it outside of its  
> domain and will pass it back upstream to the calling provider to  
> decide.  I think that because often the billing model between them  
> seems to dictate that.  I have no doubt some cases will occur to  
> validate your concern, but I think market forces will "correct" them  
> naturally over time.  Providers have plenty of natural motivation  
> not to piss off their customers and regulators.

In some sectors, providers have financial incentives to do just the  
opposite. Lots of US carriers made money charging victims that had  
been tricked into calling those expensive Carribbean premium lines.

See:

	http://www.scambusters.org/ScamBusters8.html

While this has gotten better recently (which could be your market  
forces at work), I have been in many discussions around 3GPP and OMA  
where people expressed concerns that 302 handling could engender a new  
wave of such problems.

That's partly why I think that anything doing a retargeting needs to  
inform the calling party about the retargeting operation. I'm still  
liking a new provisional response as a way to do this, especially with  
Identity in responses. This would allow the call to be dropped quickly  
(and before sending media) if the connected identity is unanticipated.

--
Dean

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Sat, 19 Apr 2008 03:27:01 +0200

All this argument seems to be predicated on an assumption for a charging
model that is not defined anywhere by IETF. Many models exist for
charging in diversion, and calling customer pays all is only one of
them.

302s recursed by intermediate proxies may be perfectly reasonably in
certain charging environments. 

I would further add that in the UK at least, there is a some assumption
that the customer knows what he is going to pay at the time he "dials"
the number (within fairly wide bounds). That means that if the network
equipment (rather than the user's equipment) sends the request off into
0900 land without further input from the user or his equipment, then
that customer will have a fairly good case for complaint and refund.
This somewhat forces the network operator to make sure that any such
cost implications of diversion are reasonable.

Regards

Keith

> Behalf Of Dean Willis
> Sent: Friday, April 18, 2008 7:46 PM
> To: Paul Kyzivat
> Cc: SIP IETF; Francois Audet; Dan WING
> >> the scenarios we're talking about, which probably involve a 
> >> transition  from a "no charge" IP call to a potentially very 
> >> expensive (like, up  to $25 a minute for some premium
> I look forward to seeing that argument played on Judge Judy's 
> daytime TV show.
> 
> >

---

From: Dean Willis <[email-masked]>
Date: Fri, 18 Apr 2008 20:33:20 -0500

> certain charging environments.

Not if they're retargeting. I'd also say that proxy operations that  
retarget are also generally unreasonable, given that (so far) we have  
no way to inform the caller of the retargeting.

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 18 Apr 2008 21:51:17 -0400

> no way to inform the caller of the retargeting.

Sure we do: RFC 4916. :)

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 18 Apr 2008 22:34:44 -0400

>         http://www.scambusters.org/ScamBusters8.html

Well, it sounds to me like that scam was of a different type: the user explicitly calling a number which was billed higher than the user expected.  They reached the number they dialed.  That's a billing problem, not a routing problem. (and btw, "US" carriers didn't make money off that, afaict - Caribbean ones maybe, but for the US carriers I bet it cost more money in customer service issues than it made)

> where people expressed concerns that 302 handling could engender a new

No doubt they can, and probably will.  It's handled by policies, and such policies can be mis-configured and/or abused.  Such is also the case on user endpoints, of course.

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Sat, 19 Apr 2008 01:03:45 -0500

>> no way to inform the caller of the retargeting.

Close, but that only informs the caller AFTER the retargeting has  
completed. It's kind of like introducing yourself to the nice lady at  
the bar after you've already started making babies together.

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 20 Apr 2008 16:33:07 -0400

> no way to inform the caller of the retargeting.

What is your objection? Is it
- that the caller may be billed for something he wasn't expecting?
- that the caller may not want to talk to the new target?

The former is a billing issue, which may or may not be related to this 
discussion, as Keith has pointed out.

The latter can be dealt with via called party identity. In any case it 
is quite within the normal range of expectation to day that you may end 
up talking to someone other than who you thought you were calling.

	Paul

---

From: Dean Willis <[email-masked]>
Date: Sun, 20 Apr 2008 22:46:50 -0500

On Apr 20, 2008, at 3:33 PM, Paul Kyzivat wrote:

>> Not if they're retargeting. I'd also say that proxy operations  
>> that  retarget are also generally unreasonable, given that (so far)  
>> we have  no way to inform the caller of the retargeting.
>

Both, although my bigger concern is the general unanticipated  
respondent problem.

> The former is a billing issue, which may or may not be related to  
> this discussion, as Keith has pointed out.
>
> The latter can be dealt with via called party identity.

Which, with current specs, only kicks in AFTER the INVITE transaction  
has completed.

> In any case it is quite within the normal range of expectation to  
> day that you may end up talking to someone other than who you  
> thought you were calling.

That's probably true, but  it's not a good thing. Why do we keep  
trying to reinvent the failings of the pSTN?

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 21 Apr 2008 00:29:46 -0400

Dean Willis wrote:
>>> retarget are also generally unreasonable, given that (so far) we 
>>> have  no way to inform the caller of the retargeting.
>>
> Both, although my bigger concern is the general unanticipated respondent 
> problem.
> 
>> In any case it is quite within the normal range of expectation to day 
>> that you may end up talking to someone other than who you thought you 
>> were calling.
> 
> That's probably true, but  it's not a good thing. Why do we keep trying 
> to reinvent the failings of the pSTN?

I am perfectly willing to admit that I might not be imagining how things 
might work.

Perhaps this depends very heavily on exactly what is retargeting and 
what is not. If I call the Dr and get the answering service is that 
retargeting? If I call the boss and get the secretary is that 
retargeting? I I call you on your land line and get forwarded to your 
mobile line is that retargeting?  If I call a help line and get 
forwarded to a call center worker is that retargeting?

In most of these cases, even if my UA has a UI to ask me if I want to 
continue I will most likely just consider than annoying and reconfigure 
it to automatically accept all of these retargetings.

I can see the value of being able to specify that I want to speak to a 
certain person and no other, but I think I wojuld only want to use it on 
rare occasions.

BTW, when it does matter to me I would prefer to restrict who actually 
answers the phone, rather than just which phone rings. But I don't see 
much likelihood of that any time soon.

I would be *thrilled* to just have called party identity on a regular basis.

	Paul

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 21 Apr 2008 07:55:15 +0300

> forwarded to a call center worker is that retargeting?

i don't see any problem if callee has configured his proxy or phone to
perform those actions, but i see a big problem if callee returns 302 to
the caller and caller's phone or proxy acts on it without informing the
caller.

-- juha

---

From: Dean Willis <[email-masked]>
Date: Mon, 21 Apr 2008 01:00:21 -0500

On Apr 20, 2008, at 11:29 PM, Paul Kyzivat wrote:

>>>> that  retarget are also generally unreasonable, given that (so  
>>>> far) we have  no way to inform the caller of the retargeting.
>>>
>> Which, with current specs, only kicks in AFTER the INVITE  
>> transaction has completed.
> I am perfectly willing to admit that I might not be imagining how  
> things might work.
>
> retargeting? I I call you on your land line and get forwarded to  
> your mobile line is that retargeting?  If I call a help line and get  

Can they respond with the Dr's credentials? Would their identity  
service put an RFC 4474 in a return UPDATE that matches the To in the  
original request? If so, then it's OK -- the caller is surprised by  
the response. If not, then we have a retargeting. When retargeting  
occurs without infomring the caller, we invariantly have an  
unanticipated respondent scenario.

>
> In most of these cases, even if my UA has a UI to ask me if I want  
> to continue I will most likely just consider than annoying and  
> reconfigure it to automatically accept all of these retargetings.

even the ones that are spoofed "responses"  from an MITM?

Here's the scenario: Alice sends an INVITE to Bob. Charlie sees it,  
and fakes a 200 OK response to Alice before Bob can respond.

Unlikely? Not in a P2PSIP world.

If Bob forwards his phone to Charlie, Alice needs to see something  
signed by Bob or somebody authoritative for Bob that says the call is  
being redirected to Charlie before accepting a response from Charlie.

> I can see the value of being able to specify that I want to speak to  
> a certain person and no other, but I think I wojuld only want to use  
> it on rare occasions.

I bet you'll want to use it on every call. You just don't know it yet.

> BTW, when it does matter to me I would prefer to restrict who  
> actually answers the phone, rather than just which phone rings. But  
> I don't see much likelihood of that any time soon.

You have no choice about who answers. What you have a choice about is  
which answer you will accept as valid.

---

From: Dean Willis <[email-masked]>
Date: Mon, 21 Apr 2008 01:01:15 -0500

> the caller and caller's phone or proxy acts on it without informing  

How does the caller know that the callee has configured his proxy to  
perform those actions and that the response isn't coming from somebody  
else?

--
Dean

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 21 Apr 2008 09:12:06 +0300

> perform those actions and that the response isn't coming from somebody  

dean,

i didn't understand your question.  you mean 200 ok response?  it is
coming from somebody else, for example, if callee has configured to
forward requests to him to his voice mail.

-- juha

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 21 Apr 2008 08:40:40 -0400

> the caller and caller's phone or proxy acts on it without informing the

If the caller is picky about who he ends up talking to then I don't see 
what difference it makes whether the retargeting is processed by a proxy 
or the UAC. And if the caller is concerned about picking up the charge 
for a call to an unanticipated address then it is just an issue of 
whether it is going to get the bill, not who does the retargeting.

I know we traditionally avoid billing issues, but there are a whole 
class of architectural issues such as this that we can't address without 
considering charging.

IMO a fundamental flaw in charging systems is assuming that the caller 
can infer the charging algorithm that will be used for a call based on 
the *form* of the address. By that I mean:
- whether caller or callee pays
- per minute rate, etc.
This of course gets all screwed up if payment responsibility or rate for 
a call changes as a result of retargeting. But its somewhat of a problem 
even without retargeting. The kinds of problems I am aware of are:
- caller isn't always aware of the mapping from address
   to charging algorithm, so may be charged more than anticipated
- relying on form makes dialing rules difficult (do I start with "1"
   or not? It sometimes depends on which UA dialing is initiated.)
- there is a shortage of desirable "free phone" numbers, because of
   the limited forms for them. Adding new freephone prefixes aggrevates
   the prior propblem of callers knowing the algorithm.
- to date there is no precedent for "freephone" addresses conforming
   to "email" syntax.
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 21 Apr 2008 08:54:29 -0400

Dean Willis wrote:
> Can they respond with the Dr's credentials?  Would their identity service
> put an RFC 4474 in a return UPDATE that matches the To in the original 
> request? If so, then it's OK -- the caller is surprised by the response. 
> If not, then we have a retargeting. When retargeting occurs without 
> infomring the caller, we invariantly have an unanticipated respondent 
> scenario.

Well, today if the Dr has sip service with credentials but subscribes to 
a PSTN answering service then I presume not. In some other cases 
possibly yes.

Even in cases like this one, where it would seem in the abstract that 
the new target *ought* to have credentials there will clearly be a 
migration issue.

>> continue I will most likely just consider than annoying and 

Well I would be pleased to have the true spoofs singled out and 
highlighted, if it was possible to reliably separate them from the cases 
that were clearly intended by the callee. But I don't see that being 
possible any time soon.

> Here's the scenario: Alice sends an INVITE to Bob. Charlie sees it, and 
> fakes a 200 OK response to Alice before Bob can respond.
> 

Thats clearlhy a  bad case. If it can be distinguished from the others 
then great.

However its not entirely clear to me that this is conceptually different 
from Bob being offline and having asked Charlie to answer calls for him.

> being redirected to Charlie before accepting a response from Charlie.

I agree this would be a good thing. It doesn't have to be the 3xx response.

>> certain person and no other, but I think I wojuld only want to use it 
>> on rare occasions.
> 

There are just too many cases when I don't know who will be expected to 
answer the call. You seem to be assuming that all phones are personal 
phones.

> which answer you will accept as valid.

I want the one with the real Dean Willis talking, regardless of what AOR 
was used to reach it. (Assuming there *is* a real Dean Willis.)

	Paul

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 21 Apr 2008 11:05:09 -0700

> transaction has completed.

One way to avoid that would be to create a new I-D, 'connected party
precondition'.  But preconditions have not enjoyed much success because, as I
understand it, preconditions cannot be incrementally deployed.

-d

---

From: Dean Willis <[email-masked]>
Date: Mon, 21 Apr 2008 13:11:31 -0500

> forward requests to him to his voice mail.

Ideally we'd be talking about the 200 OK, but our identity assertion  
mechanism (FC 4474) currently doesn't work in the 200 OK, so we're  
really talking an RFC 4916 message in the other direction.

If you call me and I've forwarded those calls to voice mail, how do  
you know that I've authorized this forwarding and that it wasn't done  
by a MITM attacker? With our existing protocol set, you don't.

One possible workaround would be to handle the "forwarding" operation  
by having my bot accept your INVITE with a 200 OK, do an RFC 4916  
exchange, then do a REFER telling you to call my voice mail. Now you  
know "for sure" that I want you to talk to this other identity "my  
voicemail".

It would be much cleaner to allow RFC 4474 in a response, so that I  
could simply respond to your INVITE with a 302 pointing you at my  
voice mail. My signature (or that of my service provider, who we've  
agreed to trust) would assert that the retargeting to the voice mail  
platform is valid.

Where a 302 isn't ideal and it would be better to "proxy retarget" the  
request, we need a new mechanism -- we need a way for the proxy to  
send you something that explains that the request is being retargeted  
and who you should be looking to connect with. I've seen it proposed  
that we could use a new provisional (or reliable provisional) response  
to do this. And if RFC 4474 could be extended to cover this response,  
then this partiular problem would be solved.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Mon, 21 Apr 2008 13:22:32 -0500

On Apr 21, 2008, at 7:54 AM, Paul Kyzivat wrote:
> Thats clearlhy a  bad case. If it can be distinguished from the  
> others then great.

It is distinguished by the facts  1) that the respondent Charlie  
cannot present credentials for the called party Bob, and 2) Alice  
received no authentic instruction from Bob about the retargeting.

SIP today works because our proxies are generally trustworthy and we  
have TLS to make sure we're talking to the proxy we think we're  
talking to. P2PSIP proxies cannot be trusted to that extent, and  
therefore we don't get the same benefit from TLS.

>
> However its not entirely clear to me that this is conceptually  
> different from Bob being offline and having asked Charlie to answer  
> calls for him.
>

It is not different in today's protocol spec. That's the problem -- it  
should be.

>> signed by Bob or somebody authoritative for Bob that says the call  
>> is being redirected to Charlie before accepting a response from  
>> Charlie.
>

Correct. There have been other proposals, such as a reliable  
provisional informing Alice that an authorized proxy has retargeted  
the call to Charlie. This isn't hard -- it takes only a new response  
code and minor mods to RFC 4474. Or it could be done with no new  
extensions using an accept/refer/disconnect model.

>
>>> I can see the value of being able to specify that I want to speak  
>>> to a certain person and no other, but I think I wojuld only want  
>>> to use it on rare occasions.
> There are just too many cases when I don't know who will be expected  
> to answer the call. You seem to be assuming that all phones are  
> personal phones.

For every phone I call, there is somebody I expect would be  
authoritative for that call.

For example, if I call a Lufthansa call center to book a ticket, I  
expect that the party I reach will be able to authentically claim to  
represent Lufthansa.

>>> actually answers the phone, rather than just which phone rings.  
>>> But I don't see much likelihood of that any time soon.
>> You have no choice about who answers. What you have a choice about  
>> is which answer you will accept as valid.
>
> I want the one with the real Dean Willis talking, regardless of what  
> AOR was used to reach it. (Assuming there *is* a real Dean Willis.)

I may not be available. Would you rather reach the person I've  
authorized to handle my calls in my absence, or some random stranger?  
I suppose that's a personal choice ;-).

--
Dean

---

From: [email-masked] (Juha Heinanen)
Date: Tue, 22 Apr 2008 08:29:58 +0300

> extensions using an accept/refer/disconnect model.

and how about if charlie decides to forward the call to bill, who bob
doesn't trust?

-- juha

---

From: Dean Willis <[email-masked]>
Date: Tue, 22 Apr 2008 11:42:35 -0500

> and how about if charlie decides to forward the call to bill, who bob

At least Alice will know she's talking to Bill because Bob forwarded  
the call to Charlie who forwarded it to Bill. If Bill isn't happy  
about this, he and Charlie can step outside the pub later and have two  
words about it. At least this way we know what happened, and we know  
it far more authoritatively than History-Info would have told us.