Subject: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try

From: "Stastny Richard" <[email-masked]>
Date: Fri, 9 Dec 2005 12:41:11 +0100

>Thus, IMO the paramter is more interesting for the outgoing provider. If
>the proxy of provA receives a request from its customer for
>   sip:[email-masked]
>this would adress the lokal user +4312345. A request for
>   sip:[email-masked];user=phone
>would address the E.164 phone number +4312345

Yesss, exactly ;-)

And since you rarely have local users start with +,
sip:[email-masked] is more usual

and
sip:[email-masked]
should not happen, causeing always confusion

Richard

________________________________

Von: Klaus Darilion [mailto:[email-masked]]
Gesendet: Fr 09.12.2005 12:31
An: Stastny Richard
Cc: [email-masked]; [email-masked]; [email-masked]
Betreff: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try

Stastny Richard wrote:
> Klaus wrote:
>
>>If I would design the network for provB, I would use version 2 (without
>>user=phone as the user are not limited to phones).
>
> You mean:
>
>>sip:[email-masked];user=phone
>
> 
> IMHO this does not imply that the user uses a phone,
> it implies that the user-part is a Tel URI !

Yes. This makes more sense. (I've never knowed what the user=phone
parameter is really for).

Thus, IMO the paramter is more interesting for the outgoing provider. If
the proxy of provA receives a request from its customer for
   sip:[email-masked]
this would adress the lokal user +4312345. A request for
   sip:[email-masked];user=phone
would address the E.164 phone number +4312345

Thanks for clarification,
Klaus

> 
> Richard
>
>
>
> ________________________________
>
> Von: Klaus Darilion [mailto:[email-masked]]
> Gesendet: Mi 07.12.2005 13:39
> An: Stastny Richard
> Cc: [email-masked]; [email-masked]; [email-masked]
> Betreff: Re: [Enum] SIP AoR, tel and ENUM - Second Try
>
>
>
> Hi Richard!
>
> comments inline
>
> Stastny Richard wrote:
>
>>Should Infrastructure ENUM contain a routing information
>>to the next hop only (the ingress border element of Provider B
>>(or administrative domain B)
>>or simply a mapping from an E.164 number to an AoR?
>
>
> IMHO it should be a mapping to an AoR as in user ENUM.
>
>
>>I will try to give another example and start from
>
> ...
>
>>I subscribe with provider B and get a default public
>>user identity (AoR) from this provider:
>>e.g. sip:[email-masked]
>>
>>This "foo" can be anything the provider chooses it to be:
>>e.g. an alphanumeric string such as ywzabcd,
>>a numeric string such as 16241 (my FWD number)
>>or 019793321 or 4319793321
>>
>>Any other provider A having a peering agreement
>>with Provider B must be able to route a SIP call
>>given this SIP AoR to provider B, either to the
>>SIP proxy hosting this account or at least to
>>the ingress proxy(s) in provider B network.
>>
>>On way to do so is to use SRV records within
>>the zone of provB.net pointing to e.g
>>
>>ingress14.provB.net
>>and
>>ingress21.provB.net
>>
>>Question: is this correct?
>
>
> IMO yes. Thus, A sends "INVITE sip:[email-masked]" to ingress14.provB.net
>
>
>>Note: after the ingress proxy provider B
>>may use another mapping mechanism to find
>>the real hosting server e.g. srv21.provB.net
>>
>>Now I as a user are not happy with this default
>>public user identity, I want to have some aliases
>>
>>eg:
>>1)sip:[email-masked] and
>>2) +43 1 9793321
>>
>>In case 1) I assume that provider B needs
>>to provide me with redirect server(s), and I
>>need to enter in stastny.com SRV records
>>to point to these redirect servers
>>e.g. redirect.provB.net
>>
>>sip:richard.stastny.com is redirected to
>>sip:[email-masked]
>>
>>Question: is this correct?
>
>
> This is a working scenario. But a redirect server is not mandatory. It
> may also be a proxy which forwards the request "INVITE
> sip:richard.stastny.com" to "INVITE sip:[email-masked]".
>
> It is also possbile that SRV for stastny.com points directly to
> ingress12.provB.net and ingress12 knows about all hosted SIP domains and
> knows how to forward the request to the end user.
>
> But this is a design decision of the provB and IMO should be out of
> scope of SPEERMINT. provB may use redirect server, provC may accept all
> hosted SIP domains directly on their ingress points, .....
>
> I personally prefer relaying instead of redirect. E.g. redirect raises
> questions like: How should intercept the redirect response and forward
> to the new URI? The UA client or the SIP proxy of provA or the egress proxy?
>
> The important thing is that the originator (provA) should not have to
> take care how provB implemented the hosting of SIP domains.
>
>
>>In case 2) we need Infrastructure ENUM
>>[Side note; in my user ENUM I would either enter
>>sip:[email-masked] or sip:[email-masked]
>>this is my choice]
>>
>>Now the question is: what goes into Infrastructure
>>ENUM for say +4319793321?
>>
>>Is it:
>>Sip:[email-masked] (if plain sip:[email-masked] works
>>this must also work)
>>OR
>>sip:[email-masked];user=phone (correct?)
>>OR
>>sip:[email-masked] (wrong?)
>>OR
>>sip:[email-masked] (valid only if 4319793321 = foo)
>>
>>OR is it
>>sip:[email-masked];user=phone (and the above variants)
>>AND
>>sip:[email-masked];user=phone
>
>
> IMO all of these are valid. It's up to the choice of provB. provB can
> put anything into ENUM as long as provB is able to map from the URI in
> I-ENUM to the end user.
>
> If I would design the network for provB, I would use version 2 (without
> user=phone as the user are not limited to phones).
>
>
>>In this last case one would not need to query the
>>SRV records in provB.net
>
>
> Also in the last case (if beeing conform with RFC3263), the egress proxy
> has to perform NAPTR and SRV lookups. If you want to avoid them, just
> put the IP address or the port into the host part, e.g.
>
> sip:[email-masked]:5060;user=phone
>
> regards
> klaus
>
>
>
> _______________________________________________
> Sip mailing list  https://www1.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
>
>

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Klaus Darilion <[email-masked]>
Date: Fri, 09 Dec 2005 15:34:47 +0100

Hi Paul!

Thanks for clarification. I always had problem to understand the proper 
meaning of this parameter. Is this somewhere described in detail? I also 
rememeber a discussion to remove this parameter completly.

regards
klaus

Paul Kyzivat wrote:
> It seems that many people intend to use a namespace for usernames where 
> there is no overlap of names and numbers: there is no possibility for a 
> *name* +4312345 that has a different meaning than the E.164 number 
> +4312345. In that case the presence or absence of the ";user=phone" is 
> irrelevant as far as its meaning within the owning domain. In that case 
> the ";user=phone" is more a matter of informing the world that this is 
> intended to be a phone number.
> 
> Also, as it happens, while
>     sip:[email-masked]
> are not equal by uri comparison rules, they are equal according to the 
> rules that 3261 applies to the targets of registration. So, you can't 
> really have them mean different things.
> 
>     Paul
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 09 Dec 2005 09:08:23 -0500

Paul

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 9 Dec 2005 16:59:49 +0200

> really have them mean different things.

if UA is to send a request to sip:[email-masked], it MUST send it to
provA.com.  in case of sip:[email-masked];user=phone, it can (and
usually MUST) send it wherever it is sending requests to e.164 numbers,
i.e., where it would send tel:+4312345, because the UA may not have any
deal to use provA.com as its outbound proxy.

  -- juha

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 09 Dec 2005 10:28:42 -0500

> deal to use provA.com as its outbound proxy.

I disagree with you Juha. AFAIK the routing of *either* form MUST be 
routed solely based on the provA.com domain. Unless you are responsible 
for the domain in question you are not to interpret the user part in any 
way. There is no dispensation to violate this when the user=phone 
parameter is present.

	Paul

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 9 Dec 2005 17:43:11 +0200

> way. There is no dispensation to violate this when the user=phone 

i'm pretty sure that i have read in some rfc that
sip:+<digits>@<domain>;user=phone is EQUIVALENT with tel:+<number>,
i.e., they are two textual representations of the same thing, but can't
check it now, because i'm travelling in train.

i have seen some SIP UAs to use sip:+<digits>@<domain>;user=phone format
in 302, when the user has made call redirect to a PSTN number.  if this
302 is received by someone in another domain, it cannot reach pstn via
the proxy of the other domain.  so it must interpret
sip:+<digits>@<domain>;user=phone as a tel uri and use its own proxy.

-- juha

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 09 Dec 2005 12:55:14 -0500

> sip:+<digits>@<domain>;user=phone is EQUIVALENT with tel:+<number>,

I forget where that is. 3261 isn't the full story - it got clarified 
somewhere.

The point is that if the user=phone parameter is present, then the user 
part MUST conform to the tel syntax. But that is really a constraint on 
the owner of the domain, because others shouldn't be interpretting the 
user part, even to determine its validity.

> sip:+<digits>@<domain>;user=phone as a tel uri and use its own proxy.

This is a good argument for not doing this.

Putting this form in the 302 is exactly the right thing to do if you 
want to *force* the recipient to go to the specified domain. And there 
could be reasons why you might want to do that. E.g. you want to use 
media only available via SIP, or you want to use SIPS for security.

If you don't want to force the caller to do that, and want to allow the 
option for the caller to reach you indirectly via the PSTN, then you 
ought to use a tel uri. Then the user that gets it has lots of options.

	Paul

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 9 Dec 2005 20:02:56 +0200

> ought to use a tel uri. Then the user that gets it has lots of

yes, that is what i have figured out too.  the problem is that there is
lots of sip phones on the market that don't support tel uris although
this application clearly requires the use of them.  

the root of the problem lies with rfc3261 that doesn't mandate that sip
ua support tel uris (it is MAY) although this application clearly shows
that tel uri support is mandatory in any sip ua.

-- juha

---

From: "Dale R. Worley" <[email-masked]>
Date: Fri, 09 Dec 2005 12:54:29 -0500

> check it now, because i'm travelling in train.

A lot of RFCs hint at such a thing.  The closest I've seen is section 3
of RFC 3824.  But the general drift is not that they are *equivalent*,
but that the tel: URI can be mapped into the sip: URI; there seems to be
no hint that the mapping can be reversed.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Dec 2005 09:18:39 -0500

> rememeber a discussion to remove this parameter completly.

I'm not sure there is a good description anywhere. It has been debated 
many times. What I wrote is my best understanding given all the 
discussion that has gone on in the past.

	Paul

>> It seems that many people intend to use a namespace for usernames 
>> where there is no overlap of names and numbers: there is no 
>> possibility for a *name* +4312345 that has a different meaning than 
>> the E.164 number +4312345. In that case the presence or absence of the 
>> ";user=phone" is irrelevant as far as its meaning within the owning 
>> domain. In that case the ";user=phone" is more a matter of informing 
>> the world that this is intended to be a phone number.
>>