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

From: Richard Shockey <[email-masked]>
Date: Sun, 01 Jan 2006 16:42:54 -0500

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.
> 
> Are there any issues with overloading the DNS?

None that I can think of ..if the DNS can survive RFID and the ONS it
can survive anything.

Actually VoIP will be much less a burden on the DNS than SMTP lookups
are now. There is vastly more email sent than VoIP calls I would imagine.

> 
> Maybe it would be useful to define XML based policy profiles and have them
> registered at IANA?

I'm wondering if the structure of some of the work in geopriv is
applicable here especially some if the ideas in eXtensible Access
Control Markup Language (XACML)

http://www.tschofenig.com/drafts/draft-tschofenig-geopriv-authz-policies-00.txt

http://www.ietf.org/internet-drafts/draft-ietf-geopriv-policy-07.txt

> 
> Thanks, Henry
> 
> 
> 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Michael Haberler
> Sent: Thursday, December 29, 2005 9:33 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: [voipeer] I-D: Publishing SIP Peering Policy
> 
> [we've worked out a method to publish SIP peering policy through the 
> DNS. It falls into SPEERMINT territory but I think it's relevant for 
> ENUM as well.
> here's the gist in a nutshell - flames on. -mah]
> 
> --
> 
> There will be many, potentially incompatible SIP peering schemes, and
> looking
> at a SIP URI does not help in deciding wether it is reachable (or 
> "peerable"). Such
> information could be managed in local tables at the egress point. 
> However, such static
> setup information is unwieldy to manage and similar in nature to a 
> hosts.txt table, or
> static routes, and associated disadvantages.
> 
> To aid runtime discovery of "peerable" destinations, and facilitate 
> management of
> peering arrangements (including auto-discovery of new peering 
> partners which subscribe
> to the same set of policies), we propose to name the scheme(s) used 
> by a provider and
> publish them in the DNS, by specialized NAPTR RRs. This enables the 
> egress point to
> decide - in advance and without pre-configuration of peers - wether 
> the ingress
> point will accept a SIP INVITE, and which technique should be employed.
> Our proposal also allows smooth migration between peering methods and 
> helps reduce
> the complexity of arrangements by introducing federations, of which a 
> bilateral
> arrangement is just a special case.
> 
> Our proposal focuses on the URI level, and assumes that E.164 numbers 
> are already
> mapped to a URI, for instance by some form of ENUM.
> 
> This draft addresses the problem of managing the peering fabric from 
> an end-to-end
> perspective, which is a core task of the SPEERMINT charter.
> 
> Michael Haberler
> Otmar Lendl
> 
> 
> On 2005/12/28 16:12, [email-masked] wrote:
>  > A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
>  >
>  >
>  > 	Title		: Publishing SIP Peering Policy
>  > 	Author(s)	: O. Lendl
>  > 	Filename	: draft-lendl-sip-peering-policy-00.txt
>  > 	Pages		: 16
>  > 	Date		: 2005-12-28
>  > 	
>  > This documents proposes the use of DNS entries to publish a SIP
>  >    proxy's policy for accepting incoming calls.  Such published policies
>  >    can be used to selectively establish peering relationships between
>  >    VoIP service providers.
>  >
>  > A URL for this Internet-Draft is:
>  > http://www.ietf.org/internet-drafts/draft-lendl-sip-peering-policy-00.txt
>  >
>  > [...]
> 
> ____________________________________________________________________________
> _
> List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/
> User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html
> 
> 
> _____________________________________________________________________________
> List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/
> User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html
> 

-- 

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

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

---

From: Michael Haberler <[email-masked]>
Date: Thu, 05 Jan 2006 22:56:02 +0100

At 22:20 05.01.2006, Khan, Sohel Q [CTO] wrote:

>
>We also need to address: how does a mobile user enjoy the outcome of his
>home admin-domain policy when the he is visiting a foreign admin-domain
>that implements a different policy.

Sohel,

we're just having very modest goals here - addressing the basic 
problem of interworking between ITAD's represented by SIP domains 
without assuming the whole world runs open URIs, with acceptable 
management load and in finite time (this year, that is).

The GSM association is a quite good example for a federation, which 
sets rules for traffic between their members. Why dont you guys just 
go for that and be done?

I understand that IMS roaming is a bit of a home-grown challenge but 
I would be very hesitant to take on fixing it on the plate in this 
working group.

We need to sort this out though wether that's in scope - what is the 
WG opinion here?

-Michael

>Sent: Thursday, January 05, 2006 11:46 AM
>To: Richard Shockey; David Meyer
>Cc: Henry Sinnreich; [email-masked]; [email-masked];
>[email-masked]; [email-masked]
>Subject: Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy
>
>
>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.
> >_______________________________________________________________________
> >______ List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/

---

From: "Dolly, Martin C" <[email-masked]>
Date: Thu, 5 Jan 2006 18:29:44 -0600

Hello,
 
I was curious, being there is so much marketing advertising (via links) on these e-mail lists, whether I can put a plug in for my brothers printing businsess, or is that the line where this e-amil list draws the line between technical versus "other" on this list?
 
Cheers,
 
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Duane
Sent: Thursday, January 05, 2006 7:20 PM
To: Stastny Richard
Cc: Michael Haberler; Richard Shockey; David Meyer; [email-masked]; Henry Sinnreich; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy

Stastny Richard wrote:

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

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."
_____________________________________________________________________________
List Archive: http://darkwing.uoregon.edu/~llynch/voipeer/
User Tools: http://darkwing.uoregon.edu/~llynch/voipeer.html

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 6 Jan 2006 12:31:20 -0500

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

---

From: "James McEachern" <[email-masked]>
Date: Sun, 8 Jan 2006 23:28:19 -0500

I'm not sure I follow this completely, but it seems to suggest that an enterprise customer would not be able to get high quality when making a call (inter-domain) to someone who subscribed to "general flat-rate consumer voip" - even if the enterprise user was making the call, and willing to pay for it. This seems counter-intuitive to me.

Jim 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Livingood, Jason
Sent: Friday, January 06, 2006 12:31 PM

[email-masked]

[email-masked]

[email-masked]

Jason

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 9 Jan 2006 17:17:04 -0500

The items listed were for example purposes.  I just wanted to illustrate
that a provider may wish to vary VoIP peering policies by sub-domain
rather than having just one policy at the domain level.  I just listed
quick examples for each sub-domain, segmented by some illustrative
customer types (SMB, enterprise, consumer, etc.).  And w/r/t my
enterprise example, I actually meant to indicate that they had very high
QoS expectations and policies, but no matter...  ;-)

Jason

> From: James McEachern [mailto:[email-masked]] 
> Sent: Sunday, January 08, 2006 11:28 PM
> To: Livingood, Jason; Stastny Richard; Michael Haberler; 
> Richard Shockey; David Meyer
> Cc: [email-masked]; Henry Sinnreich; [email-masked]; [email-masked]
> Subject: RE: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy
> 
> I'm not sure I follow this completely, but it seems to 
> suggest that an enterprise customer would not be able to get 
> high quality when making a call (inter-domain) to someone who 
> subscribed to "general flat-rate consumer voip" - even if the 
> enterprise user was making the call, and willing to pay for 
> it. This seems counter-intuitive to me.
> 
> Jim 
> 
> 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]
> 	- small-medium sized business voip, may involve IP-PBXs 
> as endpoints, whatever
> 
> 	- free im & voip application service with best-efforts 
> QoS (meaning no QoS)
>

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 11 Jan 2006 19:46:09 +0100

Again
 
Can anybody please explain to me what the term "visited" originating or terminating
network means on L5
 
Both end-users are registered at their respective home networks
(aka SIP servers). I always thought the SIP model is a trapezoid and 
not a hexagon
 
QoS happens at or below L3 and should be negotiated by
the end-user with his acces provider.
 
Richard

________________________________

Von: Tom-PT Taylor [mailto:[email-masked]]
Gesendet: Mi 11.01.2006 19:01
An: Michael Hammer (mhammer)
Cc: Otmar Lendl; Henry Sinnreich; [email-masked]; [email-masked]; Stastny Richard; [email-masked]
Betreff: Re: [Speermint] RE: [Enum] RE: [voipeer] I-D: Publishing SIP Peering Policy

The MSF is defining a scenario they hope to demonstrate, where media
paths cross different domains from signalling. The signalling may be of
the form visited originating network - home originating network - home
terminating network - visited terminating network.  This typical
scenario is an obvious example of L5 transit. Then the media path is
optimized to run directly between the visited networks, possibly by way
of a different transit network offering QoS based on diffserv markings
at the egress points of the visited networks.

L5 and L3 are linked in the originating and terminating visited
networks, but not in between.

Michael Hammer (mhammer) wrote:
> There MUST be some association of IP layer protocol elements to L5
> traffic needs, such as low delay, packet loss etc.  If the L5 need is
> real-time transmission, and that translates to a DSCP marking, then the
> IP network needs to meet that need one way or another or very simply the
> real-time service breaks.  The alternative is that the peering always
> must include both L5 and L3 and you get a half-step instead of full-step
> in evolution from PSTN to IP.
>
> Put another way, is it really necessary to have L5 transit networks?  If
> you insist that L3 always be paired with L5 for real-time, that is what
> you get.
>
> Mike
>
>
>
>>[mailto:[email-masked]] On Behalf Of Otmar Lendl
>>Sent: Monday, January 09, 2006 6:06 PM
>>To: Henry Sinnreich
>>Cc: 'Michael Haberler'; 'Richard Shockey'; 'David Meyer';
>>[email-masked]; [email-masked]; [email-masked];
>>'Stastny Richard'
>>On 2006/01/09 19:01, Henry Sinnreich <[email-masked]> wrote:
>>
>>>Otmar,
>>>
>>>You say:
>>>
>>>
>>>>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.
>>
>>>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.
>>
>>In an ideal world, yes.
>>
>>
>>>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?
>>>
>>
>>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
>>--
>>< Otmar Lendl ([email-masked]) | nic.at Systems Engineer >
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint
>
>