Subject: RE: [Speermint] Re: [Enum] How to correctly set up the request URI?

From: "Creighton, Tom" <[email-masked]>
Date: Fri, 2 Jun 2006 16:58:19 -0400

That is correct.  The SIP URI that clearly identifies you, as you
described, would only be used within your provider's network.

> -----Original Message-----
> From: James McEachern [mailto:[email-masked]]
> Sent: Friday, June 02, 2006 16:52
> To: Creighton, Tom; Lee, Yiu; Stastny Richard; [email-masked];
> [email-masked]
> Subject: RE: [Speermint] Re: [Enum] How to correctly set up the
request
> URI?
> 
> Ok, I think I see now.  Presumably I can have a SIP URI that clearly
> identifies me, but this is not the AOR that would be populated in
> Infrastructure ENUM.  That AOR would either be based on my E.164
number,
> or on some other random string created by the carrier.  Have I got it
> right?
> 
> James
> 
> -----Original Message-----
> From: Creighton, Tom [mailto:[email-masked]]
> Sent: Friday, June 02, 2006 3:49 PM
> To: McEachern, James [CAR:5N00:EXCH]; Lee, Yiu; Stastny Richard;
> [email-masked]; [email-masked]
> Subject: RE: [Speermint] Re: [Enum] How to correctly set up the
request
> URI?
> 
> I think we have two separate issues:
> 
> 1. An issue of misunderstanding of the term AoR.  Section 6 of RFC3261
> defines an Address-of-Record as:
> 
> "Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI
>          that points to a domain with a location service that can map
>          the URI to another URI where the user might be available.
>          Typically, the location service is populated through
>          registrations.  An AOR is frequently thought of as the
"public
>          address" of the user."
> 
> Based on that definition and the examples provided by Richard, a
user's
> privacy would not be compromised because it doesn't directly reach or
> identify the customer.
> 
> 2. There is confusion around what is or is not acceptable in the host
> portion of a SIP URI.  As long as RFC3263 is followed, it shouldn't
> matter what is placed in the host portion of the SIP URI as long as it
> doesn't compromise a user's privacy.  So in the examples Richard
> provided earlier, either are acceptable and would resolve in an
> identical manner.
> 
> Tom
> 
> > -----Original Message-----
> > From: James McEachern [mailto:[email-masked]]
> > Sent: Friday, June 02, 2006 15:12
> > To: Lee, Yiu; Stastny Richard; Creighton, Tom; [email-masked];
> > [email-masked]
> > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the
> request
> > URI?
> >
> > In the past it has been suggested that if Infrastructure ENUM is
> openly
> > accessible, then for data privacy reasons it would not be acceptable
> to
> > list the user AOR.  Do we still believe this is the case, or do we
now
> > think providing the user AOR would be acceptable?
> >
> > James
> >
> > -----Original Message-----
> > From: Lee, Yiu [mailto:[email-masked]]
> > Sent: Thursday, June 01, 2006 2:22 PM
> > To: Stastny Richard; Creighton, Tom; [email-masked]
> > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the
> request
> > URI?
> >
> > Actually, I think it is sufficient for the Enum to return the user
AOR
> > because the routing decision should happen in the provB.net network.
> >
> > -----Original Message-----
> > From: Stastny Richard [mailto:[email-masked]]
> > Sent: Thursday, June 01, 2006 2:18 PM
> > To: Lee, Yiu; Creighton, Tom; [email-masked]
> > Subject: Re: [Speermint] Re: [Enum] How to correctly set up the
> request
> > URI?
> >
> > Ok, so I am back to my original question:
> >
> > if I implement both types of public user identities:
> > E.164 numbers and SIP AoRs, why doing the mapping to different
hosting
> > proxies in two places (in this case ENUM and the HSS), if I can do
it
> > only in one place?
> >
> > -sta
> >
> >
> >
> > ________________________________
> >
> > Von: Lee, Yiu [mailto:[email-masked]]
> > Gesendet: Do 01.06.2006 20:10
> > An: Stastny Richard; Creighton, Tom; [email-masked]
> > Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the
> request
> > URI?
> >
> >
> >
> > Yes. IMS is using Option 2. Option 1 is also possible if the
operator
> > decides to use just a redirect proxy.
> >
> > -----Original Message-----
> > From: Stastny Richard [mailto:[email-masked]]
> > Sent: Thursday, June 01, 2006 2:07 PM
> > To: Creighton, Tom; Lee, Yiu; [email-masked]
> > Cc: [email-masked]
> > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the
> request
> > URI?
> >
> > so basically the IMS I-CSCF -  HSS - S-CSCF way?
> >
> > Richard
> >
> > ________________________________
> >
> > Von: Creighton, Tom [mailto:[email-masked]]
> > Gesendet: Do 01.06.2006 19:45
> > An: Lee, Yiu; Stastny Richard; [email-masked]
> > Cc: [email-masked]
> > Betreff: RE: [Speermint] Re: [Enum] How to correctly set up the
> request
> > URI?
> >
> >
> >
> > Agreed, in this case the proxy associated with provB.net would be an
> > intermediate device that would have to perform some sort of internal
> > lookup in order to route the request to the next hop.
> >
> > > -----Original Message-----
> > > From: Lee, Yiu
> > > Sent: Thursday, June 01, 2006 13:34
> > > To: Stastny Richard; Creighton, Tom; [email-masked]
> > > Cc: [email-masked]
> > > Subject: RE: [Speermint] Re: [Enum] How to correctly set up the
> > request
> > > URI?
> > >
> > > In this case, I guess when the originating proxy resolves the
domain
> > part
> > > of the AOR (sip:[email-masked]), it will return the IP
> address
> > of
> > > the root domain "provB.net" which may be a redirect proxy. So
> > "provB.net"
> > > has two choices:
> > >
> > > (1) It accesses its local routing table and sends a 305 to the
> > originating
> > > proxy with "sbc4711.provB.net" in the contact header.
> > >
> > > (2) It replaces the domain part in the r-uri to more specific like
> > > "proxy.austria.provB.net" and forward the message to the next-hop.
> > >
> > > Either case, the assumption is provB.net will have a way to find
out
> > where
> > > the home proxy of user +4319793321.
> > >
> > > This is only my guess.
> > >
> > > -----Original Message-----
> > > From: Stastny Richard [mailto:[email-masked]]
> > > Sent: Thursday, June 01, 2006 1:13 PM
> > > To: Creighton, Tom; [email-masked]
> > > Cc: [email-masked]
> > > Subject: [Speermint] Re: [Enum] How to correctly set up the
request
> > URI?
> > >
> > > I see,
> > >
> > > but how do you solve this problem if the users can also be reached
> by
> > AoRs
> > > direct?
> > >
> > > -sta
> > >
> > > ________________________________
> > >
> > > Von: Creighton, Tom [mailto:[email-masked]]
> > > Gesendet: Do 01.06.2006 17:57
> > > An: Stastny Richard; [email-masked]
> > > Cc: [email-masked]
> > > Betreff: RE: [Enum] How to correctly set up the request URI?
> > >
> > >
> > >
> > > Maybe the service provider has some sort of segregated network
> > (physically
> > > or logically) and wants/needs to associate each its subscribers
with
> a
> >
> > > particular network segment.  If the provider went with the flat
> model
> > of
> > > provB.net, each of its proxies would have to accept requests
> destined
> > to
> > > all of its customers and would then have to route the request to
the
> > > appropriate region or division of its network.
> > > If the provider went with the hierarchical approach of
> > sbc4711.provB.net,
> > > all of the requests would already be routed to the appropriate
> ingress
> >
> > > point.  This could very well save a service provider a lot of
money
> in
> >
> > > route proxy equipment although might cost more on the provisioning
> > side.
> > >
> > > That is my guess.
> > >
> > > > -----Original Message-----
> > > > From: Stastny Richard [mailto:[email-masked]]
> > > > Sent: Thursday, June 01, 2006 11:30
> > > > To: Creighton, Tom; [email-masked]
> > > > Cc: [email-masked]
> > > > Subject: RE: [Enum] How to correctly set up the request URI?
> > > >
> > > > Thank you, Tom
> > > >
> > > > just a minor additional question:
> > > >
> > > > > In either case, after the provider A proxy performs an ENUM
> query
> > > and
> > > > > rewrites the request URI, it should behave as a UAC and follow
> the
> >
> > > > > procedures outlined in Section 4 of RFC3263 to determine the
IP
> > > > address,
> > > > > port, and transport protocol for the provider B UAS.
> > > >
> > > > If I have to do this according to RFC3263 anyway, why put the
> > > > sbc4711.provB.net into ENUM in the first place?
> > > >
> > > > -sta
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Creighton, Tom [mailto:[email-masked]]
> > > > > Sent: Thursday, June 01, 2006 4:36 PM
> > > > > To: Stastny Richard; [email-masked]
> > > > > Cc: [email-masked]
> > > > > Subject: RE: [Enum] How to correctly set up the request URI?
> > > > >
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Stastny Richard [mailto:[email-masked]]
> > > > > > Sent: Thursday, June 01, 2006 09:06
> > > > > > To: [email-masked]
> > > > > > Cc: [email-masked]
> > > > > > Subject: [Enum] How to correctly set up the request URI?
> > > > > >
> > > > > > Folks,
> > > > > >
> > > > > > Question for clarification:
> > > > > >
> > > > > > In the discussions here on how to populate sip URI in
> > > Infrastructure
> > > > > > ENUM to derive the Call Routing data for SPEERMINT  two
lines
> of
> >
> > > > > > thought exist:
> > > > > >
> > > > > > The Enumservice SIP in Infrastructure ENUM should contain 1.
> the
> >
> > > > > > address-of-record of the user: e.g.
> > > sip:[email-masked]
> > > > > > 2. the ingress point into the provider network:
> > > > > > e.g. sip:[email-masked]
> > > > > >
> > > > > > The originating UAC has in this case set the To: field to
> > > > > > tel:+4319793321 and the Request-URI to e.g.
> > > > > > sip:+4319793321provA.net;user=phone. This caused the ENUM
> query
> > at
> > > > > > the proxy of provider A
> > > > > >
> > > > > > The question is how the proxy of provider A is now setting
up
> > the
> > > > > > request URI in cases mentioned above?
> > > > > >
> > > > > > Does the UAS from provider B accept calls to
> sbc7411.provB.net,
> > or
> > > > > > must the request URI set to the proper AoR as described in
> > > > > > 8.2.2.1 of RFC 3261? If yes, only option 1 is possible in
> ENUM.
> > > > >
> > > > > [Tom Creighton wrote:]
> > > > > From section 8.2.2.1 of RFC3261:    "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."
> > > > >
> > > > > As long as the UAS from provider B is "willing" to accept the
> > > request,
> > > > > either should work.  Since provider B is populating
> Infrastructure
> > > > ENUM,
> > > > > one would hope that they would coordinate this data with the
> > > > > configuration of their proxies.
> > > > >
> > > > > Besides, how do you actually know that sbc4441.provB.net is
> > actually
> > > a
> > > > > hostname and isn't a subdomain?
> > > > >
> > > > > In either case, after the provider A proxy performs an ENUM
> query
> > > and
> > > > > rewrites the request URI, it should behave as a UAC and follow
> the
> >
> > > > > procedures outlined in Section 4 of RFC3263 to determine the
IP
> > > > address,
> > > > > port, and transport protocol for the provider B UAS.
> > > > >
> > > > > >
> > > > > > I would also like to draw the attention to section 3 of
> > > > > > RFC3761 (SIP Enumservice) explaining the usage of AoR in
ENUM.
> > > > > >
> > > > > > Regards
> > > > > >
> > > > > > -sta
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > enum mailing list
> > > > > > [email-masked]
> > > > > > https://www1.ietf.org/mailman/listinfo/enum
> > >
> > >
> > >
> > > _______________________________________________
> > > Speermint mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/speermint
> >
> > _______________________________________________
> > Speermint mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/speermint
> >
> >
> >
> >
> >
> > _______________________________________________
> > Speermint mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/speermint
> 
> _______________________________________________
> enum mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/enum
> 
> _______________________________________________
> enum mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/enum

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

---

From: Tim Dwight <[email-masked]>
Date: Sat, 03 Jun 2006 08:11:24 -0500

What good does this globally-visible public-user-ID to private-user-ID
visible only within the serving network scheme do, if the means of
translating globally-visible public user ID to private user ID is publicly
accessible (public DNS)?  Or, are we assuming that it's not publicly
accessible, e.g., that the serving network has a split DNS and these "final
translations" are only visible within that network?

tim

> Sent: Friday, June 02, 2006 3:58 PM
> To: James McEachern; Lee, Yiu; Stastny Richard; 
> Subject: RE: [Speermint] Re: [Enum] How to correctly set up 
> the request URI?
> 
> That is correct.  The SIP URI that clearly identifies you, as 
> you described, would only be used within your provider's network.
>