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

["Pfautz, Penn L, GBLAM" <ppfautz at att.com>]

Yes. Again, there might be exceptions, for example a business might want
a URI with their name to be used and some SPs might agree to that, but
generally the point of infrastructure ENUM is to be invisible to the
user 

-----Original Message-----
From: James McEachern [mailto:jmce at nortel.com] 
Sent: Friday, June 02, 2006 4:52 PM
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

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