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

From: "James McEachern" <[email-masked]>
Date: Wed, 7 Dec 2005 18:51:54 -0500

Richard,
It seems to me there are two basic options here, both of which are roughly equivalent.

1. I-ENUM contains an AoR, (probably in a format like sip:[email-masked];user=phone, rather than something like sip:[email-masked], to protect user privacy).  The SRV records for provB could then point to ingress14.provB.net and ingress21.provB.net.

OR

2. I-ENUM contains "sip:[email-masked];user=phone" AND
"sip:[email-masked];user=phone".

Presumably provB controls the content of its information in both I-ENUM and its SRV records, so it could even be left up to provB to decide which method to use.

The main difference I can see is that option 2 would allow provB to identify different ingress gateways for different customers, which might be useful. However, option 2 would result in different treatment depending on whether the call was originated with an E.164 number or a SIP URI, which seems undesirable.

Does this sound reasonable?

Jim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stastny Richard
Sent: Wednesday, December 07, 2005 7:01 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: [Sip] SIP AoR, tel and ENUM - Second Try

Hi folks,

thanks for the statements sofar, but I am still confused
(maybe even more ;-)

It seems also that my first post was not too well formulated

The basic question was:
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?

I will try to give another example and start from
within the scope of SPEERMINT (I hope this is the
last iteration before the name gets too lomg ;-)

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?

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?

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

In this last case one would not need to query the
SRV records in provB.net

I hope I did not confuse the issue even more

Richard

_______________________________________________
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: "Stastny Richard" <[email-masked]>
Date: Thu, 8 Dec 2005 16:58:08 +0100

Jim wrote:
>Presumably provB controls the content of its information in both I-ENUM and its SRV records, so it could even be left up >to provB to decide which method to use.

This seems to be the consensus we are converging here

There are only two caveats:
1. This is only easy if ProvB controls the NAPTRs directly
(in a multi-Tier approach)
If the data are held in a central DB (say a Peering Provider) and
the provisioning is done via other means, a common approach may 
be required for the whole DB.

2. All ProvAs querying the tree need also have a common understanding
how to interpret the NAPTRs retrieved.

So according to Klaus, the second entry should look:

2. I-ENUM contains "sip:[email-masked]:5060;user=phone" AND
"sip:[email-masked]:5060;user=phone".

Richard

________________________________

Von: James McEachern [mailto:[email-masked]]
Gesendet: Do 08.12.2005 00:51
An: Stastny Richard; [email-masked]; [email-masked]; [email-masked]
Betreff: RE: [Sip] SIP AoR, tel and ENUM - Second Try

Richard,

OR

Jim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stastny Richard
Sent: Wednesday, December 07, 2005 7:01 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: [Sip] SIP AoR, tel and ENUM - Second Try

Hi folks,

The basic question was:

ingress14.provB.net
and
ingress21.provB.net

eg:

Is it:

OR is it

Richard

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Fri, 9 Dec 2005 13:19:03 -0500

Juha,

That was in the yu-np-08 draft now dead, but did not survive to the
present draft np-07.  Even so, it described how to map from tel: into
sip: but not vice versa.

Mike

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Juha Heinanen
> Sent: Friday, December 09, 2005 10:43 AM
> To: Paul Kyzivat (pkyzivat)
> Cc: [email-masked]; [email-masked]; Stastny Richard; 
> [email-masked]; Klaus Darilion
> Subject: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try
> 
> Paul Kyzivat writes:
> 
>  > 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.
> 
> 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
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: "Stastny Richard" <[email-masked]>
Date: Fri, 9 Dec 2005 19:52:35 +0100

The example below is very interesting, but not a very realistic one.
 
As long a calls to the PSTN are charged, this will never work
with re-direct, only with forwarding (as it is now in the PSTN with
all such scenarios). In case of forwarding User B gets charged
 
Richard

Von: Tolga Tarhan [mailto:[email-masked]]
Gesendet: Fr 09.12.2005 19:35
An: Juha Heinanen; Paul Kyzivat
Cc: Sip; [email-masked]; Stastny Richard
Betreff: RE: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try

All,

Just to be clear, let me define my understanding of Juha's scenario:

1) UserA@provA sends an invite to his local proxy (provA) for
UserB@provB.

2) UserB has told his provider that he wants all of his calls redirected
to his PSTN number.  Clearly, userB's intent is that the call be
completed through a media gateway to the PSTN.  For this example, let's
say the number was +17205551212.

3) provB receives the request from provA and now needs to send a
redirect to the PSTN number.  Assume for this example that provA and
provB have no business relationship, and therefore, provB will not
accept a call to the PSTN from provA.

That being said, probably the simplest thing that provB can do is use a
tel: URI in the redirect.  That avoids all ambiguity and logically
requests that provA use a local media gateway to complete the call to
the PSTN.

If the tel: URI is not an option for some reason, then provB should send
the redirect to sip:+17205551212@provA;user=phone.  Notice the use of
provA, which the proxy at provB would have to derive, presumably using
the "From" header.  I don't think this is a good option, because there
may be no reliable way to consistently derive the correct URI.

I have to side with Paul, however, in saying that IF the redirect from
provB actually refers to sip:+17205551212@provB (regardless of the
presence of a user attribute), then the RFC is fairly clear -- the
request that results from the redirect must be sent to provB, which will
almost certainly fail.

--
Tolga Tarhan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Juha Heinanen
Sent: Friday, December 09, 2005 8:59 AM
To: Stastny Richard
Cc: Sip
Subject: Re: [Sip] Re: [Enum] SIP AoR, tel and ENUM - Second Try

Stastny Richard writes:

 > A user enters a phone number, the UA sends it by default
 > to his provider A with
 > sip:[email-masked];user=phone

that is fine if the user is placing the call, but how about when the
user wants to refer the calling party with 302 to his number on pstn
network? 

last time i checked, phones from paul's company use sip uri format,
which according to paul's interpretation must be routed to whatever host
part is listed there, which for sure get blocked by the proxy if the
caller belongs to a different domain.

-- juha