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

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Fri, 6 Jan 2006 13:17:27 -0500

Can we back up one and ask where is this URI coming from?

My initial reaction to the question below is that the URI of the target
and the URI of the routing hop may be two different things and contained
in two different SIP message elements, e.g. Request-URI v. Route URI.
Is there a mental architectural picture behind this that has not been
described yet?

BTW, the use of sub-domain vice just saying domains below helps address
the confusion of my earlier question that was hinting at the need for
some discriminator for identifying policies when more than one exists
per domain.

Mike

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stastny Richard
> Sent: Friday, January 06, 2006 1:07 PM
> To: Livingood, Jason; Michael Haberler
> Cc: [email-masked]
> Subject: [Speermint] Publishing SIP Peering Policy and user 
> provided URIs
> 
> 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
> 

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