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

[Tim Dwight <timothy.dwight at verizon.com>]

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

> -----Original Message-----
> From: Creighton, Tom [mailto:Tom_Creighton at cable.comcast.com] 
> Sent: Friday, June 02, 2006 3:58 PM
> To: James McEachern; Lee, Yiu; Stastny Richard; 
> speermint at ietf.org; enum at ietf.org
> 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.
> 
> > -----Original Message-----
> > From: James McEachern [mailto:jmce at nortel.com]
> > Sent: Friday, June 02, 2006 16:52
> > To: Creighton, Tom; Lee, Yiu; Stastny Richard; speermint at ietf.org; 
> > enum at ietf.org
> > 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:Tom_Creighton at cable.comcast.com]
> > Sent: Friday, June 02, 2006 3:49 PM
> > To: McEachern, James [CAR:5N00:EXCH]; Lee, Yiu; Stastny Richard; 
> > speermint at ietf.org; enum at ietf.org
> > 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:jmce at nortel.com]
> > > Sent: Friday, June 02, 2006 15:12
> > > To: Lee, Yiu; Stastny Richard; Creighton, Tom; 
> speermint at ietf.org; 
> > > enum at ietf.org
> > > 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:Yiu_Lee at Cable.Comcast.com]
> > > Sent: Thursday, June 01, 2006 2:22 PM
> > > To: Stastny Richard; Creighton, Tom; speermint at ietf.org
> > > 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:Richard.Stastny at oefeg.at]
> > > Sent: Thursday, June 01, 2006 2:18 PM
> > > To: Lee, Yiu; Creighton, Tom; speermint at ietf.org
> > > 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:Yiu_Lee at Cable.Comcast.com]
> > > Gesendet: Do 01.06.2006 20:10
> > > An: Stastny Richard; Creighton, Tom; speermint at ietf.org
> > > 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:Richard.Stastny at oefeg.at]
> > > Sent: Thursday, June 01, 2006 2:07 PM
> > > To: Creighton, Tom; Lee, Yiu; speermint at ietf.org
> > > Cc: enum at ietf.org
> > > 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:Tom_Creighton at cable.comcast.com]
> > > Gesendet: Do 01.06.2006 19:45
> > > An: Lee, Yiu; Stastny Richard; speermint at ietf.org
> > > Cc: enum at ietf.org
> > > 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; speermint at ietf.org
> > > > Cc: enum at ietf.org
> > > > 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:+4319793321 at provB.net), 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:Richard.Stastny at oefeg.at]
> > > > Sent: Thursday, June 01, 2006 1:13 PM
> > > > To: Creighton, Tom; speermint at ietf.org
> > > > Cc: enum at ietf.org
> > > > 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:Tom_Creighton at cable.comcast.com]
> > > > Gesendet: Do 01.06.2006 17:57
> > > > An: Stastny Richard; speermint at ietf.org
> > > > Cc: enum at ietf.org
> > > > 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:Richard.Stastny at oefeg.at]
> > > > > Sent: Thursday, June 01, 2006 11:30
> > > > > To: Creighton, Tom; speermint at ietf.org
> > > > > Cc: enum at ietf.org
> > > > > 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:Tom_Creighton at cable.comcast.com]
> > > > > > Sent: Thursday, June 01, 2006 4:36 PM
> > > > > > To: Stastny Richard; speermint at ietf.org
> > > > > > Cc: enum at ietf.org
> > > > > > Subject: RE: [Enum] How to correctly set up the request URI?
> > > > > >
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Stastny Richard [mailto:Richard.Stastny at oefeg.at]
> > > > > > > Sent: Thursday, June 01, 2006 09:06
> > > > > > > To: speermint at ietf.org
> > > > > > > Cc: enum at ietf.org
> > > > > > > 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:+4319793321 at provB.net
> > > > > > > 2. the ingress point into the provider network:
> > > > > > > e.g. sip:+4319793321 at sbc4711.provB.net
> > > > > > >
> > > > > > > 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
> > > > > > > enum at ietf.org
> > > > > > > https://www1.ietf.org/mailman/listinfo/enum
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Speermint mailing list
> > > > Speermint at ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/speermint
> > >
> > > _______________________________________________
> > > Speermint mailing list
> > > Speermint at ietf.org
> > > https://www1.ietf.org/mailman/listinfo/speermint
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Speermint mailing list
> > > Speermint at ietf.org
> > > https://www1.ietf.org/mailman/listinfo/speermint
> > 
> > _______________________________________________
> > enum mailing list
> > enum at ietf.org
> > https://www1.ietf.org/mailman/listinfo/enum
> > 
> > _______________________________________________
> > enum mailing list
> > enum at ietf.org
> > https://www1.ietf.org/mailman/listinfo/enum
> 
> _______________________________________________
> Speermint mailing list
> Speermint at ietf.org
> https://www1.ietf.org/mailman/listinfo/speermint
> 


_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum