________________________________

Von: Stastny Richard
Gesendet: Di 30.05.2006 15:41
An: Otmar Lendl; Pfautz, Penn L, GBLAM
Betreff: Re: [Speermint] LNP today and routing by domain tomorrow


Penn,
 
I fully agree with Otmar. I just want to add that particularly
every enterprise wants to have their domain name as SIP URI
 
So this problem must be addressed
 
Richard

________________________________

Von: Otmar Lendl [mailto:lendl@nic.at]
Gesendet: Di 30.05.2006 15:29
An: Pfautz, Penn L, GBLAM
Cc: Stastny Richard
Betreff: Re: [Speermint] LNP today and routing by domain tomorrow




Penn,

if ATT were to market their VoIP service in Austria and I became
a customer, I could add

_sip._udp.lendl.priv.at. IN SRV 10 10 5060 vienna.sip.att.net.

to my private domain and thus publish the fact that all
callers should contact ATT's SIP proxy in Vienna if they
have calls for <sip:otmar@lendl.priv.at>.

Any Speermint peering protocol could operate on "vienna.sip.att.net"
just as easily as on "lendl.priv.at".

This is quite the same as

lendl.priv.at. IN MX 10 smtp-in.att.net.

(The NAPTRs in RFC3263 just provide one more level of abstraction)

/ol

On 2006/05/30 14:05, "Pfautz, Penn L, GBLAM" <ppfautz@att.com> wrote:
> Maybe, but the point is that it's point in this case to a service
> provider owned element instead of a domain name owner (user) element.
>
> -----Original Message-----
> From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]
> Sent: Tuesday, May 30, 2006 8:57 AM
> To: Pfautz, Penn L, GBLAM; Otmar Lendl
> Subject: Re: [Speermint] LNP today and routing by domain tomorrow
>
> >some VoIP equivalent of a MX record.
> 
> SRV?
> 
> Richard
>
> ________________________________
>
> Von: Pfautz, Penn L, GBLAM [mailto:ppfautz@att.com]
> Gesendet: Di 30.05.2006 14:47
> An: Otmar Lendl
> Cc: Reinaldo Penno; Stastny Richard
> Betreff: RE: [Speermint] LNP today and routing by domain tomorrow
>
>
>
> Otmar:
> Where I fall off the train is (2). This assumes that everyone gets and
> uses SIP URIs that are not service provider-dependent and service
> providers want to peer using these.
> I really don't think this is going to happen but if it did the obvious
> solution is some sort of parallel to I-ENUM that maps  customer domain
> names to serving carrier. You might even have a some other DNS
> infrastructure that maps user domain name to carrier, some VoIP
> equivalent of a MX record. This is the right way to do domain name
> portability.
> These would avoid the need to bounce around large number of domain
> names, just as ENUM avoid the need to exchange lots of E.164 info as in
> TRIP. In either case, I think this is out of scope for Speermint, just
> as ENUM is, and should be done elsewhere.
>
> Penn
>
> -----Original Message-----
> From: Otmar Lendl [mailto:lendl@nic.at]
> Sent: Tuesday, May 30, 2006 5:06 AM
> To: Pfautz, Penn L, GBLAM
> Cc: Reinaldo Penno; Stastny Richard
> Subject: Re: [Speermint] LNP today and routing by domain tomorrow
>
> On 2006/05/29 23:05, "Pfautz, Penn L, GBLAM" <ppfautz@att.com> wrote:
> >
> > 2. In terms of exchanging domain info. I'm not sure I follow the
> > scenario. I don't expect so many  domains to be relevant if peering is
> > service provider to service provider.
>
> Well, that depends.
>
> Usually you have
>
> Public Name  ---mapping protocol---> Routing address
> Routing address  ---routing protocol---> Nexthop decisions.
>
> In the case of the US PSTN, the public name is the E.164 number
> and the NPAC is the mapping to the routing address (whatever that
> is, I guess carrierID/SwitchID/LineID or something like that).
>
> Based on that, the call is routed within the network.
>
> The routing address is never seen by the customer. He can't dial it
> and he won't print it on business cards.
>
> ---
>
> Email is similar:
> Public name is the email address, mapping is done by the DNS.
> Routing address is the IP address of the mail-server, and
> via BGP a provider knows how to contact that mail-server.
>
> You could reach me if you send mail to lendl@[193.154.150.108], but
> that is guaranteed to change once I move my box to a different ISP.
>
> ---
>
> So what do we have in terms of I-ENUM/Speermint? I see two different
> scenarios:
>
> 1) The user only uses E.164 addresses. He never knows or dials SIP URIs.
>
>    In that case we have:
>
>    Public Name = E.164 number
>    Mapping protocol = I-ENUM
>    Routing address = SIP URI with the provider domain (maybe even
> including
>          a specific SIP proxy within his network)
>    Routing protocol = either plain RFC3263 or whatever speermint comes
> up with
>
>    In this case you can deploy a routing protocol based on domains.
>    Number portability is only done at the I-ENUM step.
>
>    If a customer switches provider, he'll get a new SIP URI. He won't
>    notice as he didn't knew his old one either.
>
> 2) The user knows his SIP URI, will print it on business cards and might
>    dial SIP URIs.
>
>    It is no longer acceptable that the user has to change his URI when
>    he chooses to switch providers, or if the provider moves him to a
>    different SIP proxy within his network.
>
>    Assuming we don't want to go into onward-routing (brrr!) or
>    routing protocols involving the username-part of the SIP URI (yuck!),
>    we have no choice but to allow the customer to use his own domain
>    for his SIP URI.
>
>    Now we have two possible dial-strings:
>
>    a) Public Name = E.164 number
>    AND
>    b) Public Name = SIP URI with the customer's domain
>
>    For a) we could use the same options as in 1).
>  
>    Or: ENUM can map case a) to case b).
>
>    For b) we can do
>
>    Public Name = SIP URI with the customer's domain
>    Mapping protocol = DNS according to RFC3263
>    Routing address = IP address of SIP proxy
>    Routing protocol = BGP
>
>    (This is the end-to-end SIP view)
>
>    Or:
>
>    Public Name = SIP URI with the customer's domain
>    Mapping protocol = DNS according to draft-lendl-domain-policy-ddds-00
>    Routing address = Federation ID + SIP domain
>    Routing protocol = Federation-specific (for which speermint can
>                            provide an example)
>
> -------
>
> As I read the Speermint charter, we need to provide a solution for 2) as
> well.
>
>
> >                                       If everybody really doesn't use
> > E.164 but chooses to reinvent the wheel again by having their own
> > domain, then we'll need DNS RRs that specify a VoIP service provider
> > similar to what infrastructure ENUM will do for E.164.
> > Am I missing something?
>
> I consider "using customer-owned domains for public user IDs" not a
> new idea. It's been successfully used in email, web and in most other
> Internet communication protocols. Have a look at the IMS specs in terms
> of Private User Identity vs. Public User Identity.
>
> That concept has proven to be very useful.
>
> Well, RFC3263 already contains a (actually, three) mapping steps.
> Eg. let's reword an example from 3263 a bit:
>
>
>    As an example, consider a client that wishes to resolve
>    sip:user@customer.us.  The client performs a NAPTR query for that
>    domain, and the following NAPTR records are returned:
>
>    ;          order pref flags service      regexp  replacement
>       IN NAPTR 50   50  "s"  "SIPS+D2T"     ""  _sips._tcp.example.com.
>       IN NAPTR 90   50  "s"  "SIP+D2T"      ""  _sip._tcp.example.com
>       IN NAPTR 100  50  "s"  "SIP+D2U"      ""  _sip._udp.example.com.
>
>    This indicates that the server supports TLS over TCP, TCP, and UDP,
>    in that order of preference.  Since the client supports TCP and UDP,
>    TCP will be used, targeted to a host determined by an SRV lookup of
>    _sip._tcp.example.com.  That lookup would return:
>
>    ;;          Priority Weight Port   Target
>        IN SRV  0        1      5060   server1.bigtelco.net
>        IN SRV  0        2      5060   server2.bigtelco.net
>
>
> So there are already DNS RRs which can provide this mapping from
> a customer domain to the carrier's domain. This can be done
> at the NAPTR step, the SRV step or even at the A record step.
>
> All that draft-lendl-domain-policy-ddds-00 does is offer some more
> options during the NAPTR step. The DNS query is exactly the same:
> "please give me all NAPTR records for this destination domain".
>
> ===================
>
> Summary: We really need to decide whether we consider the SIP URIs
> with which deal within Speermint as private, network-internal
> addresses, or whether they are customer-visible and thus public
> identifiers.
>
> A number of design choices depend on that decision.
>
> /ol
> --
> < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer >
>

--
< Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer >



_______________________________________________
Speermint mailing list
Speermint@ietf.org
https://www1.ietf.org/mailman/listinfo/speermint