Subject: [Speermint] Publishing SIP Peering Policy and user provided URIs

From: "Stastny Richard" <[email-masked]>
Date: Fri, 6 Jan 2006 19:07:07 +0100

We should not forget the equivalent of "number portability", which
is user provided URIs within the context of the peering policy. 
Especially companies will like to keep their domain for SIP
URIs like for e-mail, even if the SIP service is provided by a
service provider e.g. IP centrex.
 
What is the proposed way to implement this?
 
e.g a company wants to keep sip:[email-masked]
hosted by a service provider sip:[email-masked]
 
Richard

________________________________

Von: Livingood, Jason [mailto:[email-masked]]
Gesendet: Fr 06.01.2006 18:31
An: Stastny Richard; Michael Haberler; Richard Shockey; David Meyer
Cc: [email-masked]; Henry Sinnreich; [email-masked]; [email-masked]
Betreff: RE: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy

> >Another general question is the following: Is the peering policy a
> >function of the recipient's domain, or one of the full URI? In other
> >words, is peering done one the domain level (and thus equal to all
> >users ain that domain) or do we need to support policies
> which differ
> >amongst users?
>
> This is a very interesting point I am considering since some time.
>
> Basically the final decision which calls one wants to accept
> is an end-users decision. If I as an end-user decide to
> accept a call from anybody, this is my decision. The policy
> in the lendl I-D is only for the whole domain, a policy on a
> single URI level is possible here only by giving always the
> weakest policy, which would be the "." and therefore useless.

(BTW, have not read this I-D in full yet.)

In a given domain you could have several service types, differentiated
perhaps by using sub-domains.  Each of these may have differing QoS
expectations, costs, and associated peering policies.  Seems like it is
whatever is to the right of the @ in the URI.  In the same way that you
associate certain resource records for a domain and different ones for
each sub-domain -- control of which can be delegated out, say to an
enterprise, then you could presumably do the same here.  (I'd leave
examination of the user portion of the URI, to the left of the @ sign,
to the application that answers the callflow rather than burdening the
DNS with such complexity, as with email where you find MX records in the
DNS and the SMTP server looks at the user name and determines proper
treatment once a message is received.)  For example even within a domain
you may want a few sub-domains and these may well have very different
associated policies, and security and QoS expectations:

[email-masked]
        - general flat-rate consumer voip service

[email-masked]
        - small-medium sized business voip, may involve IP-PBXs as
endpoints, whatever

[email-masked]
        - enterprise customers with higher QoS expectations

[email-masked]
        - free im & voip application service with best-efforts QoS
(meaning no QoS)

I like the discussion so far...

Jason

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

---

From: Otmar Lendl <[email-masked]>
Date: Mon, 9 Jan 2006 17:19:04 +0100

> hosted by a service provider sip:[email-masked]

This is a very valid question. 

There certainly will be a SRV entry in the customer's domain which
points to the sip-proxy of the provider. (Just as in the email
case the MX records have to point to the provider's mail-servers.)

As the draft stands now, the SIP peering NAPTRs inside the 
customer's domain need to mirror those of the provider's domain.
This is indeed inconvenient as any change in the peering policy
triggers an update in all customer domains.

We see three possible ways to solve this:

a) The DDDS way:

Instead of 

company.com. IN NAPTR 20 50 "p" "D2P+SIP" "!.*!urn:ietf:sip:domainkeys!" .

the NAPTR in the customer's domain use non-terminal NAPTRs to
refer the querying sip-server to the entries of the provider.
e.g. something like this:

company.com.  IN NAPTR 20 50 "n" "D2P+SIP" "" provider.net.
provider.net. IN NAPTR 20 50 "p" "D2P+SIP" "!.*!urn:ietf:sip:domainkeys!" .

b) Go the route the SPF (for email, the marid WG) took:

Define some "include" mechanism which tells the querier to recurse to
some other domain and merge the entries found there with the one found
in this domain.

c) Don't take the domain of the SIP uri, but the one of the SIP
proxy as determined by a RFC 3263 - NAPTRs or SRV lookups.

----

I think a) is a the best choice.

Comments?

/ol
-- 
< Otmar Lendl ([email-masked]) | nic.at Systems Engineer >