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

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

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

---

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

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

---

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

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

---

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 21:00:13 +0100

> I'm sure other examples come to mind.

May I help you: 3GPP and TISPAN IMS ;-)

I always thought the IETF is specifying the Internet

Richard

________________________________

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

I have no problem explaining this term. One example might be if I were
trying to make a call from within my corporate network (the visited
originating network), through my service provider (the home originating
network), etc. To get out of my corporate network my client locates a
SIP proxy in that network, which then forwards the call to the peering
point of my service provider (which has a relationship with my corporate
network that allows this to happen).

I'm sure other examples come to mind.

Stastny Richard wrote:
> 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
>>
>>
>>
>>
>>>From: [email-masked]
>>>[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 >