Subject: Re: [Speermint] Re-making or Un-making the PSTN

From: Sukanta ganguly <[email-masked]>
Date: Fri, 13 Apr 2007 19:01:15 -0700 (PDT)

Adam,
   I am not sure I follow your complication. The fact that there are two federation of Bob's uri (according to your example) should provide Alice a way to find Bob's uri. Are you concerned about Alice's discovery of Bob's uri? The border element will do that. In that manner it is no different than a classical IP route discovery with a router. If no deterministic way of finding out the uri ownership can be concluded then the next hop makes this attempt. That is the most logical way of doing unless their is uniform and well understood global master. This happens to be how PSTN does it and hence no difference.

SG

----- Original Message ----
From: "Uzelac, Adam" <[email-masked]>
To: [email-masked]
Sent: Friday, April 13, 2007 1:18:44 PM
Subject: [Speermint] Re-making or Un-making the PSTN

As I sit here working on the VoIP use-case draft, I can't help but
thinking if we aren't just re-making the PSTN, instead of un-making it.
The crux of this issue lies with the routing.  At some of the basic
constructs of next-hop routing decisions that border elements need to
do, these use-cases are starting to smell more and more like PSTN-based
routing look-ups.  A simple determination of who owns the SIP-URI of the
intended recipient can not be determined definitively, so it's just
punted off to the next chain in the link.  The ultimate end-point
determination needs to occur before the next-hop decision can be made.
If we then consider B2BUAs in the mix, it's more likely than not that
the original calling and called parties are changed.  I realize some of
this changes due to local policy, but that still doesn't get to the root
of the problem.

For instance, say there were 2 federations where Bob registered his
SIP-URI, so that according to members of both federation, to reach bob
sessions should be targeted to [email-masked].  Now if Alice is part of
a an external domain to those federations, and with both feds
"advertising" reachablity to Bob, how does Alice determine next-hop?
Basically, who owns Bob's uri?  

If we were to bring ENUM into the discussion, it even get's worse more
wrought with concern due to starting with regulated e164.  I just
sharing out some thoughts.

-AU

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

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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

---

From: "Uzelac, Adam" <[email-masked]>
Date: Mon, 16 Apr 2007 11:47:50 -0400

The point that I am trying to make is that the SIP Peering models being
drawn up here rely too much on the SP representing Bob.  Bob should be
able to represent himself and how the world can reach him without the
help of a service provider.  There are numerous and well documented
reasons that Bill might want a SP to represent him, for services like
authentication, anti-SPIT, etc - but Bill should have another option.
Speermint is gaining more and more of a PSTN coloring in it's attempt to
create universal connectivity by NOT using the PSTN.  There's some irony
in that.

-AU 

> -----Original Message-----
> From: Sukanta ganguly [mailto:[email-masked]] 
> Sent: Friday, April 13, 2007 10:01 PM
> To: Uzelac, Adam; [email-masked]
> Subject: Re: [Speermint] Re-making or Un-making the PSTN
> 
> Adam,
>    I am not sure I follow your complication. The fact that 
> there are two federation of Bob's uri (according to your 
> example) should provide Alice a way to find Bob's uri. Are 
> you concerned about Alice's discovery of Bob's uri? The 
> border element will do that. In that manner it is no 
> different than a classical IP route discovery with a router. 
> If no deterministic way of finding out the uri ownership can 
> be concluded then the next hop makes this attempt. That is 
> the most logical way of doing unless their is uniform and 
> well understood global master. This happens to be how PSTN 
> does it and hence no difference.
> 
> 
> SG
> 
> As I sit here working on the VoIP use-case draft, I can't 
> help but thinking if we aren't just re-making the PSTN, 
> instead of un-making it.
> The crux of this issue lies with the routing.  At some of the 
> basic constructs of next-hop routing decisions that border 
> elements need to do, these use-cases are starting to smell 
> more and more like PSTN-based routing look-ups.  A simple 
> determination of who owns the SIP-URI of the intended 
> recipient can not be determined definitively, so it's just 
> punted off to the next chain in the link.  The ultimate 
> end-point determination needs to occur before the next-hop 
> decision can be made.
> If we then consider B2BUAs in the mix, it's more likely than 
> not that the original calling and called parties are changed. 
>  I realize some of this changes due to local policy, but that 
> still doesn't get to the root of the problem.
> 
> For instance, say there were 2 federations where Bob 
> registered his SIP-URI, so that according to members of both 
> federation, to reach bob sessions should be targeted to 
> [email-masked].  Now if Alice is part of a an external 
> domain to those federations, and with both feds "advertising" 
> reachablity to Bob, how does Alice determine next-hop?
> If we were to bring ENUM into the discussion, it even get's 
> worse more wrought with concern due to starting with 
> regulated e164.  I just sharing out some thoughts.
> 
> -AU
> 
> Tired of spam?  Yahoo! Mail has the best spam protection 
> around http://mail.yahoo.com 
>

---

From: "PFAUTZ, PENN L, ATTCORP" <[email-masked]>
Date: Mon, 16 Apr 2007 15:02:49 -0400

I thought, however, that the point of Speermint *was* to deal with
peering between service providers.
Pure user-to-user calls either aren't an issue or are dealt with in the
P2P SIP discussions. Do folks disagree? 
 Quoting from the charter:
"The most focused deliverables of SPEERMINT are best current practices
regarding exchange of real-time sessions among VoIP and other
real-time application service providers and, in particular, how
such calls are routed."

Did I fall off the wagon somewhere?

Penn Pfautz
AT&T Global Access Management
+1-732-420-4962

-----Original Message-----
From: Uzelac, Adam [mailto:[email-masked]] 
Sent: Monday, April 16, 2007 11:48 AM
To: Sukanta ganguly; [email-masked]
Subject: RE: [Speermint] Re-making or Un-making the PSTN

-AU

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Mon, 16 Apr 2007 15:38:16 -0400

I guess, there could be an argument that the PSTN was born out of not
technical stuff, but how SPs wanted to connect to each other. That will
re-surface again and again (e.g IMS and here as well). Not sure how you can
prevent this.

Even in the P2P SIP scenario (later as Penn points out), if one P2P user
wants to talk to another P2P user who happens to be on a different P2P
network, I am not sure peering problems will be over (you could assume
everything interoperates, but if provider A provides a P2P network and
provider B provides another P2P network then they may only talk through some
sort of peering since provider B's infrastructure nodes or endpoints may
refuse to directly accept calls from provider A's endpoints because they may
think that they are insecure). I am just thinking on the fly here...

---

From: "Stastny Richard" <[email-masked]>
Date: Mon, 16 Apr 2007 21:45:55 +0200

>Bob should be
>help of a service provider. 

Hmm, eh, USER ENUM?
 
But this is not used (wanted) by providers and users

And, as Penn says, the scope of SPEERMINT is provider peering

End-users, if they want to, may use User ENUM and RFC3263 anyway
 
Richard

________________________________

Von: Uzelac, Adam [mailto:[email-masked]]
Gesendet: Mo 16.04.2007 17:47
An: Sukanta ganguly; [email-masked]
Betreff: RE: [Speermint] Re-making or Un-making the PSTN

-AU

---

From: "Uzelac, Adam" <[email-masked]>
Date: Mon, 16 Apr 2007 16:04:06 -0400

Consider me charter refreshed. Just needed to get grounded here on some
thoughts.  Back to re-making or un-making the PSTN - whichever is more
appropriate.  ;)

Adam 

> From: Stastny Richard [mailto:[email-masked]] 
> Sent: Monday, April 16, 2007 3:46 PM
> To: Uzelac, Adam; Sukanta ganguly; [email-masked]
> The point that I am trying to make is that the SIP Peering 
> models being drawn up here rely too much on the SP 
> representing Bob.  Bob should be able to represent himself 
> and how the world can reach him without the help of a service 
> provider.  There are numerous and well documented reasons 
> that Bill might want a SP to represent him, for services like 
> Speermint is gaining more and more of a PSTN coloring in it's 
> attempt to create universal connectivity by NOT using the 
> PSTN.  There's some irony in that.
> 
> -AU
> 
> there are 
> > two federation of Bob's uri (according to your
> > example) should provide Alice a way to find Bob's uri. Are you 
> > concerned about Alice's discovery of Bob's uri? The border element 
> > will do that. In that manner it is no different than a classical IP 
> > route discovery with a router.
> > If no deterministic way of finding out the uri ownership can be 
> > concluded then the next hop makes this attempt. That is the most 
> > logical way of doing unless their is uniform and well understood 
> > global master. This happens to be how PSTN does it and hence no 
> > difference.
> >
> >
> > SG
> >
> > do, these use-cases are starting to smell more and more like 
> > PSTN-based routing look-ups.  A simple determination of who 
> owns the 
> > SIP-URI of the intended recipient can not be determined 
> definitively, 
> > so it's just punted off to the next chain in the link.  The 
> ultimate 
> > end-point determination needs to occur before the next-hop decision 
> > can be made.
> > the original calling and called parties are changed.
> >  I realize some of this changes due to local policy, but that still 
> > doesn't get to the root of the problem.
> >
> > sessions should be targeted to [email-masked].  Now if 
> Alice is part 
> > of a an external domain to those federations, and with both feds 
> > "advertising"
> worse more

---

From: "Henry Sinnreich" <[email-masked]>
Date: Mon, 16 Apr 2007 15:15:14 -0700

Penn Pfautz wrote?

>P2P SIP discussions. Do folks disagree?

As pointed out by Medhavi Bhatia, peering issues exist as well when
users are in different P2P networks.

We can only hope that peering between overlays would avoid some of the
issues discussed here, such as policies, QoS, public/private ENUM, etc.,
in short all the constraints inherited from the PSTN mindset and just
focus on security, spam, etc. In short: Internet-minded peering.

The work reported here on IM peering is a good start IMHO since it shows
the huge traffic issues just for IM. The reported IM systems can also do
voice and video :-)

Internet-minded peering will require some work however and the present
exercise may be a useful experience (what to avoid), if we learn from
it.

Thanks, Henry

-----Original Message-----
From: PFAUTZ, PENN L, ATTCORP [mailto:[email-masked]] 
Sent: Monday, April 16, 2007 12:03 PM
To: Uzelac, Adam; Sukanta ganguly; [email-masked]
Subject: RE: [Speermint] Re-making or Un-making the PSTN

Penn Pfautz

-----Original Message-----
From: Uzelac, Adam [mailto:[email-masked]] 
Sent: Monday, April 16, 2007 11:48 AM
To: Sukanta ganguly; [email-masked]
Subject: RE: [Speermint] Re-making or Un-making the PSTN

-AU

---

From: "Stastny Richard" <[email-masked]>
Date: Tue, 17 Apr 2007 10:32:56 +0200

Hi Henry,

I do not see any difference in P2PSIP peering and SIP Client-Server
Peering

Both is peering of administrative domains

One can assume that P2PSIP peering may use direct media stream between 
clients, but this may also be the case in client-server peering.
 
> focus on security, spam, etc. In short: Internet-minded peering.

Nice you call ENUM inherited from the PSTN mindset ;-)

Serious, there is no difference in P2PSIP peering and CS-Peering
You can do it Internet-minded or PSTN-minded

> exercise may be a useful experience (what to avoid), if we learn from

Correct: Internet-minded (e-mail?) has some problems, most of them can
be resolved with proper identities

Richard

---

From: "Uzelac, Adam" <[email-masked]>
Date: Tue, 17 Apr 2007 09:40:44 -0400

I completely agree with Richard.  I have been following the P2PSIP
working group for some time now, and I see no difference between peering
between 2 overlays, and peering between to SIP VSP.  In terms of
charters, the only difference is the voice-centric focus of Speermint.
I think that it's going to be very interesting to observe the path of
the P2PSIP working group on this front.  Without peering between overlay
capabilities, yet another method to build an "Island" will be created. I
acknowledge this would be a "better" self-governing/free-market type of
island, versus the monopolistic PSTN type - but an "island" nonetheless.

Adam

> Sent: Tuesday, April 17, 2007 4:33 AM
> To: Henry Sinnreich; PFAUTZ, PENN L, ATTCORP; Uzelac, Adam; 
> Sukanta ganguly; [email-masked]
> Subject: P2PSIP Peering (was: Re-making or Un-making the PSTN)
> 
> Hi Henry,
> 
> I do not see any difference in P2PSIP peering and SIP 
> Client-Server Peering
> 
> One can assume that P2PSIP peering may use direct media 
> stream between clients, but this may also be the case in 
> client-server peering.
>  
> Serious, there is no difference in P2PSIP peering and 
> CS-Peering You can do it Internet-minded or PSTN-minded
> 
> > 
> > the huge traffic issues just for IM. The reported IM 
> systems can also
> do
> > voice and video :-)
> > 
> Correct: Internet-minded (e-mail?) has some problems, most of 
> them can be resolved with proper identities
> 
> Richard
> 
> > 
> > Thanks, Henry
> > 
> > real-time application service providers and, in particular, 
> how such 
> > calls are routed."
> > 
> > Speermint is gaining more and more of a PSTN coloring in 
> it's attempt
> to
> > >    I am not sure I follow your complication. The fact 
> that there are 
> help but 
> > > thinking if we aren't just re-making the PSTN, instead of 
> un-making 
> > > it.
> > > constructs of next-hop routing decisions that border 
> elements need 
> > > to do, these use-cases are starting to smell more and more like 
> > > PSTN-based routing look-ups.  A simple determination of 
> who owns the 
> > > definitively, so it's just punted off to the next chain 
> in the link.  
> > > The ultimate end-point determination needs to occur before the 
> > > next-hop decision can be made.
> > > If we then consider B2BUAs in the mix, it's more likely than not 
> > > that the original calling and called parties are changed.
> registered his 
> > > SIP-URI, so that according to members of both federation, 
> to reach 
> > > bob sessions should be targeted to [email-masked].  Now 
> if Alice is 
> > > part of a an external domain to those federations, and with both 
> > > feds "advertising"
> > > If we were to bring ENUM into the discussion, it even get's worse 
> > > more wrought with concern due to starting with regulated e164.  I 
> > > just sharing out some thoughts.
> > >
> > > -AU
> > >

---

From: "Livingood, Jason" <[email-masked]>
Date: Sat, 21 Apr 2007 13:41:03 -0400

At some point isn't Bob a SP representing Bob?  

Jason 

> elements need to 
> to reach bob

---

From: "Stastny Richard" <[email-masked]>
Date: Sat, 21 Apr 2007 20:03:21 +0200

> At some point isn't Bob a SP representing Bob? 
 
Yes
 
The basic question here is what Bob has to do to be
accepted by other SP.
 
Ok, he can start to make bilateral agreements with all other
billions of Bob's, be this may not be a useful option.

Again, 
what are the minimum requirements for an adminstrative domain
to be accepted in a federation?

Richard

Von: Livingood, Jason [mailto:[email-masked]]
Gesendet: Sa 21.04.2007 19:41
An: Uzelac, Adam; Sukanta ganguly; [email-masked]
Betreff: RE: [Speermint] Re-making or Un-making the PSTN

Jason

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 23 Apr 2007 13:27:46 -0400

> to be accepted in a federation?

Why isn't that the private business of a given federation and,
therefore, totally out of scope for the WG?

Jason

---

From: "James McEachern" <[email-masked]>
Date: Mon, 23 Apr 2007 19:20:24 -0400

Thank you Jason.  I've been wondering the same thing myself, while
reading this endless "meaning of life" digression.

Jim 

-----Original Message-----
From: Livingood, Jason [mailto:[email-masked]] 
Sent: Monday, April 23, 2007 1:28 PM
To: Stastny Richard; Uzelac, Adam; Sukanta ganguly; [email-masked]
Subject: RE: [Speermint] Re-making or Un-making the PSTN

Jason

---

From: "Stastny Richard" <[email-masked]>
Date: Tue, 24 Apr 2007 12:38:53 +0200

Jason,
> therefore, totally out of scope for the WG?

Bi-lateral is out-of-scope
Federation is out-of-scope
And the open Internet is dealt with in RFC3263?

So what are we doing in Speermint?

Richard

> Sent: Monday, April 23, 2007 7:28 PM

---

From: Andrew Newton <[email-masked]>
Date: Tue, 24 Apr 2007 07:08:06 -0400

> Federation is out-of-scope

If you mean these are out-of-scope based on Jason's comments about  
the minimum requirements being the private business of a federation,  
then perhaps you misunderstood the remark.  SPEERMINT can still work  
on a set of BCPs for these relationships, from which private peering  
relationships can pick and choose.  For instance, if SPEERMINT  
produces BCPs on ENUM and TLS, a private federation could decide to  
use the ENUM BCP but not the TLS BCP (because perhaps they have blue- 
wire security instead).

Of course, if that's not what was meant by any of this, then I'm at a  
loss too.

> And the open Internet is dealt with in RFC3263?

For viable open peering, more is probably needed than 3263.  And  
here, I think SPEERMINT can say that open peering MUST have x, y, and  
z.  For instance, open peering MUST use TLS.

> So what are we doing in Speermint?

That's how I understand it.  If I've got it wrong, hopefully I'll be  
corrected.

-andy

---

From: "Stastny Richard" <[email-masked]>
Date: Tue, 24 Apr 2007 13:14:24 +0200

Andy,

> z.  For instance, open peering MUST use TLS.

This is exactly what I understand with minimum requirements

---

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 24 Apr 2007 09:42:20 -0400

I think you are misunderstanding what I am saying.  Bi-lateral,
federated, and open are all IN SCOPE.

What is NOT in scope, IMHO, is what the "minimum requirements for an
administrative domain to be accepted in a federation" should be.

Why is this out of scope?  It is a business issue - not a technology
standards issue.  For example, XYZ Enterprise Federation Inc. may only
admit enterprises.  And ABC Education Federation Inc. may only admit
universities.  And RS Global Peering Exchange Inc. may only admit
service providers of 1M customers or greater.  And JL Tiny Net
Federation Inc. may only admit small businesses and individual user
domains.  How these federations choose to select/allow domains to
participate is the private business of those federations.

Jason

> Sent: Tuesday, April 24, 2007 6:39 AM
> To: Livingood, Jason; Uzelac, Adam; Sukanta ganguly; 
> [email-masked]
> > > what are the minimum requirements for an adminstrative 
> domain to be 
> > > accepted in a federation?
> > >
> > > Richard
> > 
> > > what are the minimum requirements for an adminstrative 
> domain to be 
> > > accepted in a federation?
> > >
> > > Richard
> >

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Tue, 24 Apr 2007 09:59:50 -0400

Geez, you guys need to get some fresh air and sunshine.

Whether the relationship between peers is bilateral or multilateral is
not that relevant.  What is important is being able to discover whether
a potential peer has a relationship or not with you.  The nature of the
relationship can be defined fully elsewhere, what is needed is the
toolset which allows the peers to do discovery and to connect in a
secure manner or not, as they see fit.  

Some of these issues, such as billing and charging, are secondary.  They
may or may not, and do so in different ways.  The question is whether
there is a means of identifying what those various aspects are.  Try
layering this.  The underlying layer enables the exchange of policy
documents, irrespective of what is in the policy documents.  Later,
someone can hash out the policies.

Mike

> From: Andrew Newton [mailto:[email-masked]] 
> Sent: Tuesday, April 24, 2007 7:08 AM
> To: Stastny Richard
> Cc: Uzelac, Adam; Livingood,Jason; [email-masked]
> If you mean these are out-of-scope based on Jason's comments 
> about the minimum requirements being the private business of 
> a federation, then perhaps you misunderstood the remark.  
> SPEERMINT can still work on a set of BCPs for these 
> relationships, from which private peering relationships can 
> pick and choose.  For instance, if SPEERMINT produces BCPs on 
> ENUM and TLS, a private federation could decide to use the 
> ENUM BCP but not the TLS BCP (because perhaps they have blue- 
> wire security instead).
> 
> Of course, if that's not what was meant by any of this, then 
> I'm at a loss too.
> 
> For viable open peering, more is probably needed than 3263.  
> And here, I think SPEERMINT can say that open peering MUST 
> have x, y, and z.  For instance, open peering MUST use TLS.
> 
> That's how I understand it.  If I've got it wrong, hopefully 
> I'll be corrected.
> 
> -andy
>

---

From: "Stastny Richard" <[email-masked]>
Date: Tue, 24 Apr 2007 16:07:44 +0200

Jason

Maybe we are meaning the same anyway

I do not have any idea why you think I mean with
minimum requirements how many customers a SP may have

I am talking about technical requirements or what you may call it.

The IETF is defining protocols, some of them must be used and some may
be used (SIP is full of options)

Speermint does not develop protocols, but BCPs

If we say that it is recommended that SP use TLS for interconnection
I called this a minimum requirement. Maybe you call this something else

My idea is that we select a group of "protocols" and "options"
and recommend their usage.

Richard

> Sent: Tuesday, April 24, 2007 3:42 PM

---

From: "Stastny Richard" <[email-masked]>
Date: Tue, 24 Apr 2007 16:17:37 +0200

> Geez, you guys need to get some fresh air and sunshine.

Maybe you are right, or maybe we had too much sun ;-)

> secure manner or not, as they see fit.

I agree, maybe I should call my minimum requirements a toolset where
the SP and federation may choose from. This is more general.

---

From: Andrew Newton <[email-masked]>
Date: Tue, 24 Apr 2007 10:20:39 -0400

> Geez, you guys need to get some fresh air and sunshine.

I can't argue with that.  :)

> secure manner or not, as they see fit.

The use of the terms "bilateral" and "multilateral" are probably not  
sufficient to describe the relationships.  By using those terms, I  
was speaking of pre-arranged peering relationships that are almost  
always centered around a contract being signed.  In those cases, you  
can bet your bottom dollar that we know who the next-hop peer is.

Discovery seems to be something that is more akin to the open model.   
Certainly, if we sign a contract to peer with another entity, we  
don't want to "discover" the policies of that agreement after the  
fact and via a daemon process.

> someone can hash out the policies.

Personally, I'm a little skeptical of policy discovery, and I think  
it is only applicable to open peering at best.  But if there are  
people who believe it is workable, then I see no harm in attempting  
to do it.  I do disagree with "someone can hash out the policies"  
later.  I think we are best served by understanding what those  
policies are now.

-andy

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Tue, 24 Apr 2007 14:15:30 -0400

> Sent: Tuesday, April 24, 2007 10:21 AM
> To: Michael Hammer (mhammer)
> Cc: Stastny Richard; Uzelac, Adam; Livingood,Jason; [email-masked]
> > not that relevant.  What is important is being able to discover 
> > whether a potential peer has a relationship or not with you.  The 
> > nature of the relationship can be defined fully elsewhere, what is 
> > needed is the toolset which allows the peers to do discovery and to 
> > connect in a secure manner or not, as they see fit.
> 
> The use of the terms "bilateral" and "multilateral" are 
> probably not sufficient to describe the relationships.  By 
> using those terms, I was speaking of pre-arranged peering 
> relationships that are almost always centered around a 
> contract being signed.  In those cases, you can bet your 
> bottom dollar that we know who the next-hop peer is.

If the contract is between an association and a thousand peers that come
and go (in business out of business), then at any given time you may not
have complete knowledge of the set of peers with current contracts.  You
don't really care.  You just want to know at setup time that they are
valid, perhaps as proven by a current certificate and not on CRL.

> Certainly, if we sign a contract to peer with another entity, 
> we don't want to "discover" the policies of that agreement 
> after the fact and via a daemon process.

The contract and policies would be known in advance.  But, you may be
involved in several disjoint multilateral groups.  So, you need to
discover which group, and thus which policies and contract are in
effect.  It could also be that the same two peers belong to the same two
multilateral groups and a choice is possible.

> > Some of these issues, such as billing and charging, are 
> secondary.   
> > They
> Personally, I'm a little skeptical of policy discovery, and I 
> think it is only applicable to open peering at best.  But if 
> there are people who believe it is workable, then I see no 
> harm in attempting to do it.  I do disagree with "someone can 
> hash out the policies"  
> later.  I think we are best served by understanding what 
> those policies are now.

I am not totally sure what "open" means, but I assume it has some ad-hoc
nature that would require a man in the loop to make decisions, or
perhaps the variable types are defined, but specific values not known
until the policy advertisement tells you exactly what the per-minute
charge would be to connect, for example.

Mike

---

From: Andrew Newton <[email-masked]>
Date: Tue, 24 Apr 2007 14:44:30 -0400

> valid, perhaps as proven by a current certificate and not on CRL.

That depends upon the multilateral relationship.  I believe all the  
commercial ones require the use of their proxies or a common IP  
fabric, so something like TLS isn't necessary.

If you are talking more about clubs, then yes.  But I'm unaware of  
how big a problem it is for the Nantucket Women's League VSP  
Coalition to talk to the Fairbanks Youth Scouting VoIP Association.  :)

> multilateral groups and a choice is possible.

Umm... yeah.  I don't think any sane VSP would enter into a  
dynamically changing contractual agreement as you've described.  That  
seems a little far fetched to me.

As for choices between two peers, we do that today.  It is a matter  
of local policy.

> charge would be to connect, for example.

If it means a man-in-the-loop, then we might as well drop the idea.   
And per-minute charging means you signed a contract somewhere, which  
means it isn't open peering.

-andy

---

From: Otmar Lendl <[email-masked]>
Date: Tue, 24 Apr 2007 22:03:36 +0200

> seems a little far fetched to me.

My guess is that this depends a lot on the type of VSP:
A commercial VoIP operator whose main business is dealing with
termination fees vs. charges to customers may have completely different
peering policies than a commercial enterprise VoIP installation which
has no incentive to charge business partners for incoming calls.

The former will be judicious with whom it wants to peer and under which
terms. The latter will be rather open to incoming calls as long as it
has assurances that abuse will be minimal and that the peering is of
mutual benefit.

/ol
-- 
/ Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 933 \
| nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H |
\ http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg /