Subject: Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy

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

>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.

On the other hand, with ENUM a policy for a single E.164 number 
would be possible.

Any ideas how to extend this to URIs?

Richard

________________________________

Von: [email-masked] im Auftrag von Michael Haberler
Gesendet: Do 05.01.2006 18:45
An: Richard Shockey; David Meyer
Cc: [email-masked]; Henry Sinnreich; [email-masked]; [email-masked]; [email-masked]
Betreff: Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy

At 18:42 04.01.2006, Richard Shockey wrote:

>David Meyer wrote:
>>On Thu, Dec 29, 2005 at 04:32:49PM -0600, Henry Sinnreich wrote:
>>
>>>This is seems to be an excellent approach and I suggest we discuss it on the
>>>list and close at the 65 IETF meeting in March.
>
>
>This is a general question for the list in general.
>
>Presuming you could query a network for its VoIP peering policy.
>
>What data on terms and conditions of peering would one need to encapsulate?

here's what we could think of  - terms and conditions basically come
from the following four realms:

* Technical
   - What SIP transport is required?
   - SIP extensions? URI conventions? Privacy? Caller-ID?
   - Anti SPIT measures.
   - QoS

* Contractual
   - Do I need to sign a contract (with whomever) beforehand?

* Regulatory
   - Is a certain legal status required? E.g. only registered
     Communication Service Providers may initiate calls.
   - E.g. sender must conform to local CALEA or other rules.

* Financial
   - No settlement?
   - If yes, how.

Note that we are NOT proposing to auto-detect, auto-match this full
gamut of policy elements - we need to finish this in time;
auto-matching legal & regulatory aspects is out of scope for us.

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?

Michael Haberler
Otmar Lendl

>--
>
>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>Richard Shockey, Director - Member of Technical Staff
>NeuStar Inc.
>46000 Center Oak Plaza  -   Sterling, VA  20166
>sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
>ENUM +87810-13313-31331
>PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
>Fax: +1 815.333.1237
><mailto:richard(at)shockey.us> or
><mailto:richard.shockey(at)neustar.biz>
><http://www.neustar.biz> ; <http://www.enum.org>
><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>_____________________________________________________________________________
>List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/
>User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html

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

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

---

From: Duane <[email-masked]>
Date: Thu, 05 Jan 2006 19:20:09 -0500

> Any ideas how to extend this to URIs?

most things in NAPTR are similar to:

x.x.x.x.x.x.x.x.x.x.x.e164.org. 600 IN  NAPTR   100 10 "u" "E2U+HTTP" 
"!.*!HTTP://www.example.com!" .
x.x.x.x.x.x.x.x.x.x.x.e164.org. 600 IN  NAPTR   100 10 "u" "E2U+MAILTO" 
"!.*!MAILTO:[email-masked]!" .
x.x.x.x.x.x.x.x.x.x.x.e164.org. 600 IN  NAPTR   100 10 "u" "E2U+ADDRESS" 
"!.*!ADDRESS:/CN=Fred Smith/STREET=123 Xyz St/L=Bedrock/ST=RA/C=Gondwana 
Land/PC=123456789!" .
x.x.x.x.x.x.x.x.x.x.x.e164.org. 600 IN  NAPTR   100 10 "u" "E2U+SIP" 
"!^\\+13609681666$!sip:[email-masked]!" .

Wouldn't be hard to do something like this, but incorporate the end 
users connection preferences similar to the document posted earlier.

-- 

Best regards,
  Duane

http://www.cacert.org - Free Security Certificates
http://www.nodedb.com - Think globally, network locally
http://www.sydneywireless.com - Telecommunications Freedom
http://happysnapper.com.au - Sell your photos over the net!
http://e164.org - Using Enum.164 to interconnect asterisk servers

"In the long run the pessimist may be proved right,
     but the optimist has a better time on the trip."

---

From: Otmar Lendl <[email-masked]>
Date: Mon, 9 Jan 2006 18:36:43 +0100

[I will stop crossposting to the voipeer and enum@ietf lists, 
IMHO this belongs to the speermint list.]

> only by giving always the weakest policy, which would be the "." and therefore

Right now in the PSTN, we have peering policies on a carrier-level and
individual per-subscriber policies as well. E.g. consider the various
call-blocking feature US-based carriers have deployed over the last
years to combat telemarketers and anonymous calls.

As far as I know, such individual blocks are internal to a carrier and not
announced to others.

The same can be implemented in a SIP setting: The domain policies tell
you that the destination network will talk to you over IP, but then
there still is the option to block the call inside the destination
network for any reason. The only new part here is that we might need
an additional SIP error code indicating "I blocked this call, you might
try some other route" (in contrast to "This user is not available at all")

Such user-specific blocks could be implements purely on the user's
SIP device.

As Jason wrote, if you really want to run separate policies for a set of
users for inter-provider routing, then you can use different domains.

> On the other hand, with ENUM a policy for a single E.164 number 

Yes, but one design criteria was independence from E.164 numbers. 
The scheme needs to work in a pure SIP world as well.

> Any ideas how to extend this to URIs?

Do we really need to? In the email world this isn't done, too.

All current protocols regarding proxy and transport selection for SIP
are only based on the domain. I don't want to diverge from that model.

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

---

From: "Henry Sinnreich" <[email-masked]>
Date: Mon, 9 Jan 2006 12:19:37 -0600

Otmar,

>are only based on the domain. I don't want to diverge from that model.

What business has the broadband provider to mess with the user preferences?
Users and enterprises pay for a certain bandwidth and hopefully will have
the choice to pay extra for Diff Serv and that's the end of it.

If one domain has DiffServ and the other does not, it's up to the users to
continue the call or switch over to some other networks, such as mobile or
PSTN. And also to tell the other party to please subscribe to better
broadband :-)

What do you think?

Thanks, Henry

-----Original Message-----
From: Otmar Lendl [mailto:[email-masked]] 
Sent: Monday, January 09, 2006 11:37 AM
To: Stastny Richard
Cc: Michael Haberler; Richard Shockey; David Meyer; [email-masked]; Henry
Sinnreich; [email-masked]; [email-masked]
Subject: Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy

/ol

---

From: Otmar Lendl <[email-masked]>
Date: Tue, 10 Jan 2006 00:05:40 +0100

> the choice to pay extra for Diff Serv and that's the end of it.

In an ideal world, yes.

> PSTN. And also to tell the other party to please subscribe to better

My problem with this idea is that "domain" in the sense of SIP-servers
is an application layer notion.

DiffServ is a layer 3 issue. My layer 3 network does not neccessarily
know which applications I run over them.

If my ISP also acts as my SIP provider, then yes: one can link these
two layers into one integrated QoS solution. AFAIK this is one of the
aims of the IMS. One of the local Austrian ISPs uses this for his
VoIP service: they use separate VLANs/QoS planes for their VoIP offering.

My private playground is quite different: I use an Asterisk installation
on a box (the same one I write this mail on) colocated at ISP A
whereas my SIP-phone at home is connected via ISP B. The gateway to
the PSTN is operated by a commercial provider who uses ISP C.
If you add my ENUM nameservers, you get one more ISP into the picture.
To top it off, I could add a SIP line to my office phone which
would bring our office connectivity into the game were we basically
run own multihomed network.

I really don't know how to get seamless QoS in such a setting.

(As you mentioned before: layer3 networks can't just trust each
other's DiffServ settings.)

/ol