Subject: RE: [Speermint] Billing, Accounting, Tariffing and Charging

From: "Bob Natale" <[email-masked]>
Date: Wed, 29 Mar 2006 08:25:19 -0500

Hi Richard,

1. Your point about the possible relevance for SPEERMINT's scope of accounting requirements, and not billing requirements, is well-taken and will be reflected clearly in the next rev of the Requirements BCP draft.

2. Wrt your comment:  "3. So why is it necessary to charge termination fees to the O-user at all for SIGNALLING?":
Might it not be true that some applications of value to the user might involve signaling only, and not media per se?  (I am thinking of certain presence and notification apps...?)

Cheers,
BobN

-----Original Message-----
From: Stastny Richard [mailto:[email-masked]] 
Sent: Wednesday, March 29, 2006 6:08 AM
To: Medhavi Bhatia; Reinaldo Penno; David Schwartz; [email-masked]
Subject: [Speermint] Billing, Accounting, Tariffing and Charging

> > These are not rhetoric questions; I really do not know the answer.

Welcome to the club, you are not alone ;-)

> > VoIP is exactly the opposite. VoIP (signaling and media) are delay
> sensitive, need
> > prioritization and will be billed.
> >
> 
> Good point. What we need is to separate the problem of peering into at 
> least two parts: terminating the call and the traffic itself (data part).
> The email model applies only to the termination part.

Hmmm, I think it is even more complicated.

Terminology:

Billing is between end-users and a SP (out of scope in spearmint) Accounting is between SP (in scope of spearmint?) Tariffing is the calculation of a charge for using a certain resource for a certain amount of time.

I consider it also paradox that we are discussing accounting and charging, particularly termination charges (fees) 1. in a time even in the PSTN issues are moving to bill-and-keep 2. on an inappropriate layer (L5)

A substantial part of the problems with VoIP peering derives not from trust, QoS, SPIT, etc. problems, but simply how to keep up the existing regime of termination fees.

Especially mobile operators make a living on this.

Where is this problem coming from on the PSTN?
(Lets for a moment forget problems caused by reverse
charging)

In the PSTN there was originally an accounting regime based on cascading. The O-SP bills the O-user for the call (based on distance), and keeping part of it and paying out part to the next (transit) SP. 
This goes on until the destination
(T-SP) is reached, which also gets a share.

The implicit assumptions here are: the originator has the benefit of the call and also call set-up is in one direction and call signalling and the mediastream is traversing all networks in question.

This principle is only broken with call forwarding and also with mobile roaming. In the US also the mobile T-user pays air-time, not so in Europe, hence the problems with mobile NP

Note: in my remark to my previous post on terminating network monopoly (SMP), one may consider the termination fee also as a compensation for the remedy that a terminating network MUST accept any call.

This regime was quite simple, but was more and more complicated over time by burdening it with additional issues such as subsidies, etc. as it is currently in the US.

What does this imply now for VoIP peering or interconnect

VoIP; RTC and IP separate signalling (L5) from transport (L3) It also separates the SP from the access Now taking into account some facts:

1. Although SIP signalling (call set-up) is directed from O to T, the mediastream is both ways and symmetric (so much for Whitacre, he may eventually blame Google Video, but not VoIP providers)

2. The cost for the mediastream is moving more and more to the ends (access), even in the PSTN (see the latest OFCOM report on distance gradients), and the access is already paid in some way or the other by the end-users.

3. So why is it necessary to charge termination fees to the O-user at all for SIGNALLING?

There is one issue where termination fees may apply (although this is going away also - e.g.
Voipbuster): if you connect to the PSTN.

But this is out of scope in Speermint and in addition solutions exist here since years.

My recommendation is that as long as speermint is dealing with L5 peering only, accounting i.e. termination fees should not be dealt with.

Cheers

Richard

> -----Original Message-----
> From: Medhavi Bhatia [mailto:[email-masked]]
> Sent: Wednesday, March 29, 2006 4:28 AM
> To: Reinaldo Penno; David Schwartz; [email-masked]
> Subject: RE: [Speermint] Comments on 
> reqs-and-terminology-01andpolicy-dds-
> 00(Peerign concepts and others..)
> 
> Hi Reinaldo,
> 
> > -----Original Message-----
> > From: Reinaldo Penno [mailto:[email-masked]]
> > Sent: Tuesday, March 28, 2006 8:31 PM
> > To: Medhavi Bhatia; David Schwartz; [email-masked]
> > Subject: RE: [Speermint] Comments on reqs-and-terminology-01 
> > andpolicy-
> dds-00(Peerign
> > concepts and others..)
> >
> > Hello,
> >
> > I tend to agree that the email model sounds attractive except the 
> > delay
> and business
> > requirements of email and VoIP are quire different.
> >
> > Email is not delay sensitive, does not require any type of
> prioritization and is not charged
> > (or at least it wasn't).
> >
> > VoIP is exactly the opposite. VoIP (signaling and media) are delay
> sensitive, need
> > prioritization and will be billed.
> >
> 
> Good point. What we need is to separate the problem of peering into at 
> least two parts: terminating the call and the traffic itself (data part).
> The email model applies only to the termination part.
> 
> > I believe a call to a public number is (or should) always going to 
> > be
> routable. I guess my
> > main question is: is the general belief that VoIP providers will 
> > just
> configure their proxy
> > servers to talk to each other in an email type model? No business
> agreements similar to
> > PSTN/Wireless, no charging, no extra billing for "roaming", etc?
> >
> 
> I agree those are issues. It would be good if we can work out 
> something which is generic (compared to IMS/PSTN specific). Maybe they 
> are out of scope since we are dealing with protocol and architecture 
> issues in the WG. The only aspect billing and roaming affect is that 
> if all technical requirements (e.g the ones this WG specifies) are 
> satisfied, the peer could still reject traffic (w/o consulting the 
> destination user, in Richard's terms) if the commercial relationship 
> does not exist. I think this is what hampers connectivity today. All 
> these commercial relationships exist because SPs want to be layer 5 
> aware (they cannot seem to find a way to evolve their business models 
> otherwise... :), where only the origination SP (Core-O) and Core-T 
> need to have a commercial relationship. The roaming aspect again may 
> be quite artificial and could be questionable going forward...  Just my personal comments.
> 
> -Medhavi.
> 
> > My reply to David's email was more to the idea that you can install 
> > a
> proxy server
> > somewhere, point the "MX" to the next upstream "proxy server" and be
> done with it? As
> > VoIP takes off wouldn't some basic regulatory issues, numbering 
> > schemes
> and others
> > prevent such behavior?
> >
> > These are not rhetoric questions; I really do not know the answer.
> >
> > Regards,
> >
> > Reinaldo
> >
> > > -----Original Message-----
> > > From: Medhavi Bhatia [mailto:[email-masked]]
> > > Sent: Tuesday, March 28, 2006 5:13 PM
> > > To: Reinaldo Penno; David Schwartz; [email-masked]
> > > Subject: RE: [Speermint] Comments on reqs-and-terminology-01
> andpolicy-
> > > dds-00(Peerign concepts and others..)
> > >
> > > >
> > > > It begs the question why the two entities exchanging SIP 
> > > > signaling
> do
> > > not exchange policy
> > > > information themselves through some SIP extension/new 
> > > > protocol/<some
> > > name> and the
> > > > role played by DNS. I'm not advocating this model but it seems a
> > > pertinent question.
> > >
> > > I think peering in L3 must be basic, given how fundamental L3 is 
> > > to
> the
> > > internet. For SIP, TRIP provides functionality similar to BGP 
> > > (only
> for
> > > phone numbers though, I think).
> > >
> > > In my opinion, SIP peering ought to follow the email model. Once
> location
> > > is done and basic requirements are satisfied at the SIP layer 
> > > (like identity etc), the call should be routable. As Richard said 
> > > in the
> earlier
> > > email, the destination SP may still reject or challenge the call 
> > > if it lacks either the basic requirements we agree to in the WG or 
> > > some
> extra
> > > requirements specific to the termination SP (Core-T in my ID). The 
> > > challenge is that in some cases there are going to be IXPs
> (Interconnects)
> > > which sit in the middle due to commercial or regulatory reasons. 
> > > The location of an IXP, the provisioning of this IXP and the 
> > > Core-T SP are
> the
> > > architectural problems which this WG needs to solve as well.
> > >
> > > -Medhavi.
> > >
> > > >
> > > > Regards,
> > > >
> > > > Reinaldo
> > > >
> > > > > -----Original Message-----
> > > > > From: David Schwartz [mailto:[email-masked]]
> > > > > Sent: Tuesday, March 28, 2006 3:18 PM
> > > > > To: Reinaldo Penno; [email-masked]
> > > > > Subject: RE: [Speermint] Comments on reqs-and-terminology-01 
> > > > > and
> > > policy-
> > > > > dds-00(Peerign concepts and others..)
> > > > >
> > > > > Hi Reinaldo
> > > > >
> > > > > I am not sure the goal of SPEERMINT is to recreate L3 peering 
> > > > > at
> L5.
> > > The
> > > > > problem being solved is different in that L3 peering is always
> with a
> > > > > fixed number of neighbors. These are stored as you mention in
> static
> > > > > routing tables at each node and do not change from call to call.
> In
> > > > > contrast, L5 peering is not necessarily static (unless you are
> talking
> > > > > about a federation model). The destination is chosen only when 
> > > > > the
> > > call is
> > > > > made and may be to a peer that a given service provider/domain 
> > > > > administrator/node has never spoken to before.
> > > > >
> > > > > Assuming DNS is used to find the peering node, the query is 
> > > > > made
> on a
> > > call
> > > > > by call basis. Now clearly, this DNS info can be cached at the
> > > originating
> > > > > node but the cache still has a very different nature than that 
> > > > > of
> an
> > > L3
> > > > > routing table.
> > > > >
> > > > > Policy is an entirely different issue (as is the case in L3) 
> > > > > and
> it is
> > > > > important to separate it out from the routing issue. The draft 
> > > > > you
> > > mention
> > > > > about pushing policy via DNS is dealing with one out of many
> possible
> > > > > topologies - namely that of ad hoc federations. There was very
> little
> > > > > discussion about policy at IETF 65 as the foundations of L5
> routing
> > > need
> > > > > to be cemented before the higher level policy issues can be
> addressed.
> > > > >
> > > > > Cheers,
> > > > >
> > > > > David
> > > > >
> > > > > -----Original Message-----
> > > > > From: Reinaldo Penno [mailto:[email-masked]]
> > > > > Sent: ג 28 מרץ 2006 23:34
> > > > > To: [email-masked]
> > > > > Subject: [Speermint] Comments on reqs-and-terminology-01 and
> policy-
> > > dds-
> > > > > 00(Peerign concepts and others..)
> > > > >
> > > > > Hello,
> > > > >
> > > > > I've been reading "reqs and terminology" and I would like to 
> > > > > step
> back
> > > > > and ask some questions about some of the definitions.
> > > > >
> > > > >
> > > > > Peering:
> > > > > ========
> > > > >
> > > > > In layer 3 peering two routers exchange their routing tables,
> reach a
> > > > > steady state, and after that data packets can flow between the 
> > > > > two domains.
> > > > >
> > > > > Layer 5 peering means, "interconnection of two service 
> > > > > providers
> for
> > > the
> > > > > purposes of SIP signaling".
> > > > >
> > > > > Making the inevitable comparison with layer 3 peering, there 
> > > > > are
> some
> > > > > fundamental differences that I'm trying to reconcile.
> > > > >
> > > > > 1) In a traditional (a.k.a. layer 3) peering, both routers
> exchange
> > > all
> > > > > necessary routing information and enter a steady state. At 
> > > > > this
> point,
> > > > > no other routes are exchanged and routers concentrate on
> forwarding
> > > > > packets.
> > > > >
> > > > > I know the WG is in the beginning, but it is not clear to me 
> > > > > what
> > > pieces
> > > > > are needed for an equivalent functionality. For example:
> > > > >
> > > > > 1) Are the entities exchanging SIP signaling for the purpose 
> > > > > of
> > > peering
> > > > > doing so on a _per call_ basis?  Is there going to be some
> mechanism
> > > to
> > > > > exchange such information in bulk such as in a routing protocol?
> Maybe
> > > > > based on domain names or something similar?
> > > > >
> > > > > 2) The draft states that " A
> > > > >    domain's ingress point can be thought of as the location
> pointed to
> > > > >    by the SRV record that resulted from the resolution of the 
> > > > > CRD
> > > (i.e.,
> > > > >    a SIP URI)."
> > > > >
> > > > > So, it seems to me that although the "layer 5 peering" is
> happening
> > > > > between the two entities exchanging SIP signaling, the peering
> point
> > > > > discovery is a result of a SRV query. But the draft also 
> > > > > states
> that "
> > > > > SPEERMINT Working Group is focused on the use of such CRD."
> > > > >
> > > > > Draft peering-policy states that " This documents proposes the 
> > > > > use
> of
> > > > > DNS entries to publish a SIP proxy's policy for accepting 
> > > > > incoming calls" proposes DNS as a way of exchange polices.
> > > > >
> > > > > This begs the question of what are the two "peering" entities
> really
> > > > > doing besides exchange traditional SIP signaling? It seems the
> real
> > > > > _information peering_ (for the lack of a better term) is 
> > > > > happening between DNS servers. All important information 
> > > > > related to
> "peering" is
> > > > > coming from a DNS server which might as well be on your own 
> > > > > domain
> (if
> > > > > your exchange DNS information).
> > > > >
> > > > > In summary, it seems to me the whole architecture is quite a
> departure
> > > > > from layer 3 peering where the entities peering are the 
> > > > > holders of
> the
> > > > > necessary information to allow data packets to flow. Here the
> entities
> > > > > peering publish their peering information to third party 
> > > > > server
> which
> > > > > does the actual "peering" (exchange inter-domain information).
> > > > >
> > > > >
> > > > > Anyway, the idea of the mail is to try to clarify things. 
> > > > > There is
> > > much
> > > > > emphasis on SIP but it seems DNS plays a more central role. Or
> maybe
> > > > > some SIP extension will be made to exchange peering policies?
> > > > >
> > > > >
> > > > > Policies and Independence of lower layers:
> > > > > ==========================================
> > > > >
> > > > > It seems sections 5.5 and 5.6 are _somewhat_ conflicting. 
> > > > > Today
> BGP
> > > > > exchange QoS and VPN information, performs discovery, etc. 
> > > > > This
> > > implies
> > > > > that BGP indirectly (or directly) knows the capabilities of 
> > > > > the transport layer (thus the name capability negotiation).
> > > > >
> > > > > So, although the mechanism to exchange the actual policies 
> > > > > needs
> to be
> > > > > independent of the lower layers, there needs to be a way to 
> > > > > input
> > > lower
> > > > > layer information into the devices exchanging the policies. 
> > > > > Just
> like
> > > > > BGP has filters and priorities based on a myriad of options. 
> > > > > So,
> maybe
> > > > > the wording should change a little.
> > > > >
> > > > > As far as 5.6 goes, it seems to me the policies can be quite
> complex.
> > > > > The experience of BGP tells us that in the end policies can be
> huge.
> > > So,
> > > > > if policies are going to be huge, what draft dds-00 states as 
> > > > > a possibility
> > > > >
> > > > > " If the simple boolean logic and the limited space in the DNS
> answers
> > > > >    are insufficient for an application then a type of policy 
> > > > > rule
> URIs
> > > > >    can be defined which links to policy statements written in 
> > > > > a
> fully
> > > > >    featured policy description language like SAML [14] or 
> > > > > XACML
> [15]."
> > > > >
> > > > > will actually going to be the rule. So, this begs the question 
> > > > > of
> DNS
> > > is
> > > > > a good choice to publish peering policies.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Reinaldo
> > > > >
> > > > > _______________________________________________
> > > > > Speermint mailing list
> > > > > [email-masked]
> > > > > https://www1.ietf.org/mailman/listinfo/speermint
> > > >
> > > > _______________________________________________
> > > > Speermint mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/speermint
> > > >
> > > > --
> > > > No virus found in this incoming message.
> > > > Checked by AVG Free Edition.
> > > > Version: 7.1.385 / Virus Database: 268.3.1/292 - Release Date:
> 3/24/2006
> > > >
> >
> > --
> > No virus found in this incoming message.
> > Checked by AVG Free Edition.
> > Version: 7.1.385 / Virus Database: 268.3.1/292 - Release Date: 
> > 3/24/2006
> >
> 
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint

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

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 29 Mar 2006 08:57:56 -0500

> Might it not be true that some applications of value to the user might involve signaling only, and not media per se?  (I am thinking of certain presence and notification apps...?)

What does that change?

IMO it makes sense to charge for services actually rendered, and not for 
services the SP isn't involved in but wishes they could get some revenue 
from.

The terminating proxy does render some identifiable services that could 
potentially be charged for:
- supplying the AOR
- processing (routing) requests to the AOR

These are of value precisely because they eliminate the need for the end 
user to keep a UA online at all times, and because it permits the end 
user to dynamically associate UAs with the AOR, by providing a 
potentially recognized and trusted domain.

This doesn't seem like stuff that justifies per-use charging, and the 
amount of charging that can be extracted for these basic services is 
probably limited, but its something.

If an SP wants to charge more, then they will have to provide more 
services - ones that users are interested in paying for.

	Paul