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

From: "Stastny Richard" <[email-masked]>
Date: Wed, 29 Mar 2006 13:08:08 +0200

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

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 29 Mar 2006 16:01:16 +0200

Bob wrote:

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

Thanks for bringing this up, because I forgot to
mention one very important issue in my elaboration:

SIP is a session initiation protocol (!), end2end

Therefore it is up to the end-user may decide what kind of
application they use to communicate, voice, video, IM, etc.
they also may change the media during communication.

This is negotiated in the message body

So how can the proxy at L5 signalling layers be involved
in L3 charging if he does not (need to) know what kind
of resources will be required at the access and transport
layers, so how they can charge?

This is even recognized in the 3GPP IMS architecture
- see Camarillo/Garcia-Martin - The 3G IMS, in section
4.7 Message body page 63 - for the avoidance of doubt:

"An important property of bodies is that they are transmitted
end to end. This is, proxies do not need to parse the message
body in order to route the message. In fact, the user agents
may choose to encrypt the contents of the message body end to end.
In this case, proxies would not even be able to tell which type
of session is being established between both user
agents."

Although they seem to have completely forgotten this some
sections later when the describe in section 7.4 the 
IMS accounting architecture.

So I wonder ...

Cheers

Richard

> From: Bob Natale [mailto:[email-masked]]
> Sent: Wednesday, March 29, 2006 3:25 PM
> To: Stastny Richard
> Cc: [email-masked]
> Subject: RE: [Speermint] Billing, Accounting, Tariffing and Charging
> 
> 
> 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
> 
> 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
> 
> 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.
> 
> 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.
> 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.
> 
> 
> 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.
> 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
> 
> 
> 
> 
> > 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.
> >
> > > > 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
> > > > 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
> > > > > > and
> > > > > > steady state, and after that data packets can flow between the
> > > > > > two domains.
> > > > > >
> > > > > > DNS entries to publish a SIP proxy's policy for accepting
> > > > > > incoming calls" proposes DNS as a way of exchange polices.
> > > > > >
> > > > > > _information peering_ (for the lack of a better term) is
> > > > > > happening between DNS servers. All important information
> > > > > > related to
> > "peering" is
> > > > > > that BGP indirectly (or directly) knows the capabilities of
> > > > > > the transport layer (thus the name capability negotiation).
> > > > > >
> > > > > > if policies are going to be huge, what draft dds-00 states as
> > > > > > a possibility
> > > > > >

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 29 Mar 2006 16:05:24 +0200

Exactly

Richard

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Wednesday, March 29, 2006 3:58 PM
> To: Bob Natale
> Cc: Stastny Richard; [email-masked]
> Subject: Re: [Speermint] Billing, Accounting, Tariffing and Charging
> 
> 
> 
> Bob Natale wrote:
> >
> > Hi Richard,
> >
> 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
> 
> > Cheers,
> > BobN
> >
> > 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)
> >
> > 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 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.
> >
> >
> > 3. So why is it necessary to charge termination fees to the O-user at
> all for SIGNALLING?
> >
> > 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
> >
> >
> >
> >
> >

---

From: "Bob Natale" <[email-masked]>
Date: Wed, 29 Mar 2006 09:18:45 -0500

Hi Paul,

I'm not interested in charging (in the billing sense) wrt SPEERMINT, and I don't presume to prejudge what SPs will attempt to charge (bill) for in the future.  (I expect to be negatively surprised. :)

However, my point was that:
- Pure signaling apps are likely to become more prevalent and more valuable;
Therefore,
- SPEERMINT may need to cover the *accounting* requirements for such traffic at all relevant points in the SPEERMINT peering architecture (which is yet to be defined by this WG).

Cheers,
BobN
-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Wednesday, March 29, 2006 8:58 AM
To: Bob Natale
Cc: Stastny Richard; [email-masked]
Subject: Re: [Speermint] Billing, Accounting, Tariffing and Charging

Bob Natale wrote:
>  
> 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?":
> 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

> 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.
> 
> 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.
> 
> 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. 
> 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.
> 
> 
> VoIP; RTC and IP separate signalling (L5) from transport (L3) It also separates the SP from the access Now taking into account some facts:
> 
> 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.
> 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
> 
> 
> 
> 
> 
>>be quite artificial and could be questionable going forward...  Just my personal comments.
>>
>>-Medhavi.
>>
>>
>>>>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
>>
>>>>The location of an IXP, the provisioning of this IXP and the Core-T 
>>>>SP are
>>
>>the
>>

---

From: "Bob Natale" <[email-masked]>
Date: Wed, 29 Mar 2006 11:05:00 -0500

Hi Tim,
 
> I don't think the WG needs to delve deeply into where, when, why or
how much operators charge each other.

Agreed (enthusiastically :).

> But we do need to make some sort of assumption, if for example we're
to facilitate their interconnection
> through definition of supporting structures (e.g., protocols, MIBs).

Agree with your intent, I believe.  SPEERMINT is chartered (wrt
Requirements at least) to come with a BCP.  So we will have to deal with
"policies and operations" relating to accounting (and other applicable
topics).  If by "definition of...e.g., protocols, MIBs" you mean
"identification" of them, yes, that's a possibility.

> so some form of usage accounting is needed at the points where they
interconnect.

For sure.

Cheers,
BobN

-----Original Message-----
From: Tim Dwight [mailto:[email-masked]] 
Sent: Wednesday, March 29, 2006 10:49 AM
To: Bob Natale
Cc: [email-masked]
Subject: RE: [Speermint] Billing, Accounting, Tariffing and Charging

Bob,

> certain presence and notification apps...?)

It's not impossible that the signaling channel provide services
independent of (or possibly in addition to) establishment of media
streams.  Anybody remember fast-select in X.25?  If signaling were free
you can bet people would invent ways to use it.  Or, would you rather
the network filter the SDP to prevent piggybacking of user data?  :-)

I don't think the WG needs to delve deeply into where, when, why or how
much operators charge each other.  But we do need to make some sort of
assumption, if for example we're to facilitate their interconnection
through definition of supporting structures (e.g., protocols, MIBs).  I
thought that was Richard's point.

> In the PSTN there was originally an accounting regime based on
cascading.

Maybe somewhere it worked like that.  In the US the transit provider
(inter-exchange provider) bills the O-user directly.  Which makes it
necessary to collect usage data on a call by call basis, in the long
distance network.  

The Internet of course adopts a more scalable model in which
interconnected ISPs charge each other based on traffic volume (rather
than trying to account for individual flows).  But the point is they do
charge each other, or at least they sometimes do, so some form of usage
accounting is needed at the points where they interconnect.

Cheers,

tim

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 29 Mar 2006 18:53:54 +0200

Hi Tim,

>I'll join the confused majority.  
 
Welcome ;-)
 
>In my (probably simplistic) view, based on
>experience with other technologies, "L5 peering" ought to involve 3 types of
>activities happening over 3 distinct timescales:
>
>1) some sort of business agreement between entities responsible for a set of
>L5 domains.  Historically such agreements have usually been bilateral,
>though other models are possible.  In general the agreement establishes the
>terms and conditions under which traffic will be exchanged.
 
IMHO you are making an assumption here or drawing a conclusion that "L5 peering"
is fully analogue to L3 peering or interconnection on the PSTN:

the hint is in the term "traffic will be exchanged". In both of the above
mentioned cases really "traffic" is exchanged. 

In our case on L5 only SIP messages are exchanged. If really (media) traffic is exchanged
how much and via which path depends on various other issues such as:
do the end users really set up a media session, how are they connected to
the Internet, or are they connected at all.
 
Example: I am in a hotel in New York and register to a provider in Germany
(I have no idea where the servers are located, could be in Poland), I set
up a session to a friend registered to a SP in Australia, sip:[email-masked]
having his (one of) his servers
located in Japan, to find out that my friend is located in the same hotel in New York,
We both pay 10 bucks to the hotel for a day of unlimted Internet access.
 
How his thid "traffic exchanged" and who needs bilateral peering agreements
and who gets paid what?

>I struggle to imagine this process happening dynamically, e.g., via some
>sort of automated lookup of and agreement to, another operator's terms and
>conditions. 
 
>I do think there is work the WG can do in support of these
>agreements, though.  For example definition of standard MIBs that can be
>used for accounting purposes.  I think as we understand better what
>information needs to be exchanged in this "pre-realtime" phase, other
>opportunities may emerge.
 
In the above case; who is an operator requiring predefined bilateral
peering agreements that I may call my friend in the hotel and get some
additional money to the 20 bucks we already paid?

Or may I call my friend only if per chance both of us hit the checkpot
that our "providers" have a bilateral agreement or are in the same federation?

>2) Step (1), iterated as necessary, establishes a sort of static
>interconnect matrix.  To make traffic flow across that matrix we may need
>some dynamic exchange of "L5 routing" information.  
 
I do not need an dynamic exchange of "L5 routing information"
the L5 routing information is given by sip:[email-masked]
there is no matrix, there is only ONE destination provider
prov.au, no choice.
 
>As has been previously
>noted, this is the role of BGP at L3.  BGP is necessarily dynamic because
>the information it communicates (reachability) is constantly in flux.  There
>is no analogue to BGP in the PSTN - the criteria governing path selection at
>that level of abstraction (the sequence of networks to be traversed) are
>assumed to be relatively static. [I am omitting discussion of tariff
>arbitrage, which is an unfortunate but real result of convoluted "policy"
>that has created a hopefully-shortlived cottage industry]

>How will the path to be taken by a given SIP packet, be selected?  
 
Are you talking here SIP or RTP packets?
 
A SIP invite is sent from my UA to my proxy, the proxy is looking
up prov.au for SRV records, eventually selecting the server in Japan;
resolving the IP address and sending the SIP packet there, etc
 
>How decoupled from the path taken by the media stream, can this practically be?

The media stream may not even leave the hotel

>For example the signaling might "hop through" some sort of peering point
>that offers no media relay services - that seems reasonable - but to have
>the signaling and media traverse completely disjoint sets of L3 networks
>whilst magically receiving end-to-end QoS treatment, does not.  

Aha, so to improve QoS within the hotel, we are using managed networks
from New York to Poland to Japan, back to New York. this helps?

If the LAN is the hotel is congested, you are doomed in either case
 
>What then is
>the nature of the association of signaling-path and bearer-path, and how is
>it assured (assuming that the signaling path is determined at L5 and the
>bearer path at L3)?  
 
This is rebuilding the PSTN. Is this the scope of speermint?
 
>What if any L5 dynamic information needs to be
>exchanged to facilitate this?  

Please leave this to 3GPP and ETSI TISPAN.
Do not spoil their phun and S4 Syndrome

>By what means (protocol?) is it exchanged?

Again look at TISPAN RACS and NACS

>These seem like in-scope questions applicable to the
>realtime-but-not-call-by-call timeframe, to me.

>3) The last timescale of interest is call-by-call.  What (if anything) needs
>to happen in this time scale to facilitate (or as a result of) L5 peering?

QoS can only be done at call time - this is called Trunk Busy by bell-heads
 
cheers
 
Richard

>I *hope* the answer is "nothing", but am willing to be convinced otherwise.

Cheers,

Tim

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

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.

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.

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.

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

Cheers

Richard

personal comments.
> > > > > Sent: ? 28 ??? 2006 23:34
> > > > > To: [email-masked]

---

From: "Reinaldo Penno" <[email-masked]>
Date: Wed, 29 Mar 2006 13:28:55 -0500

> Sent: Wednesday, March 29, 2006 9:59 AM
> To: 'Stastny Richard'; [email-masked]; 'Medhavi Bhatia';
> Reinaldo Penno; 'David Schwartz'; [email-masked]
> Richard,
> > >In my (probably simplistic) view, based on experience with other
> > >technologies, "L5 peering" ought to involve 3 types of activities
> > >happening over 3 distinct timescales:
> > >
> > >1) some sort of business agreement between entities responsible for
a
> set
> > >though other models are possible.  In general the agreement
establishes
> > >the terms and conditions under which traffic will be exchanged.
> >
> > IMHO you are making an assumption here or drawing a conclusion that
"L5
> peering"
> > In our case on L5 only SIP messages are exchanged.
> 
> Understood.

[[Reinaldo]] 

Okay, I understand there is an issue of problem scoping here....but in
the real world, is there of _any_ use that your phone ring but you
cannot talk or hear anything? 

I mean, is the WG focused only on "enabling" SIP messages to be
exchanged between two domains? Isn't that based on some commercial
agreement that as a consequence will enable the two operators to
manually configure the necessary devices? 

Yes, the devices in the network "know" how to send and process DNS
queries/replies, but lots of manual configuration will be needed before
that. Or is our goal to enable plug-and-play VoIP peering? Because that
seems a whole different game.

As for media, I'm not saying we should try to solve media path issues,
but what is the WG stance on this? "Hey, your phone just rang, be glad
for that. That's where our work ends". Aren't there consequences based
on the fact that media and signaling take different paths?

I guess I'm still struggling with the problem the WG is trying to solve.

Thanks,

Reinaldo

> 
> 
> > If really (media) traffic is exchanged how much and via which path
> depends
> on various other issues such as:
> > do the end users really set up a media session, how are they
connected
> (I have no idea where the servers are
> > located, could be in Poland), I set up a session to a friend
registered
> to
> a SP in Australia, sip:[email-masked]
> > having his (one of) his servers located in Japan, to find out that
my
> friend is located in the same hotel in New York,
> > How his thid "traffic exchanged" and who needs bilateral peering
> agreements and who gets paid what?
> 
> It depends.  If your providers are nice enough to run open relays then
> there
> is no need for peering agreements and (probably) no money changes
hands
> between operators.  No doubt this is a viable model.  Is it the only
model
> we intend to support?  Doesn't seem very interesting frankly, but
maybe
> the
> interesting work has to happen elsewhere?
> 
> 
> > >I struggle to imagine this process happening dynamically, e.g., via
> > >some sort of automated lookup of and agreement to, another
operator's
> > >terms and conditions.
agreements,
> > >though.  For example definition of standard MIBs that can be used
for
> > >accounting purposes.  I think as we understand better what
information
> > >needs to be exchanged in this "pre-realtime" phase, other
opportunities
> > >may emerge.
> peering agreements that I may call my friend in the > hotel and get
some
> that our "providers" have a
> > bilateral agreement or are in the same federation?
> 
> In the scenario you describe I assume there are no "operators" per se.
> Again, that is a valid scenario.  If it's the only scenario the WG
intends
> to consider, fine.  Peering if fairly trivial in that context IMHO.
> 
> 
> > >interconnect matrix.  To make traffic flow across that matrix we
may
> > >need some dynamic exchange of "L5 routing" information.
> >
> > the L5 routing information is given by sip:[email-masked] there is no
> matrix, there is only ONE destination provider
> > prov.au, no choice.
> 
> The question is, how do you deliver a signaling packet to the operator
> authoritative for "prov.au".  Maybe that operator runs his SIP proxies
as
> open relays, in which case you can deliver the packets directly.  Your
> example assumes that to be the case.  I agree it might be the case.  I
> think
> our work would be more valuable if we did not assume it were always
the
> case.
> 
> 
> > >As has been previously
> > >noted, this is the role of BGP at L3.  BGP is necessarily dynamic
> > >because the information it communicates (reachability) is
constantly in
> > >flux.  There is no analogue to BGP in the PSTN - the criteria
governing
> > >path selection at that level of abstraction (the sequence of
networks
> > >to be traversed) are assumed to be relatively static. [I am
omitting
> > >discussion of tariff arbitrage, which is an unfortunate but real
result
> of convoluted "policy"
> SIP packet.
> > A SIP invite is sent from my UA to my proxy, the proxy is looking up
> prov.au for SRV records, eventually
> > selecting the server in Japan; resolving the IP address and sending
the
> SIP packet there, etc
> 
> Of course.  If every operator accepts signaling packets from every
> operator,
> things are simple.
> 
> 
> > >
> Agreed, and in this example that seems like a desirable outcome.
There
> are
> other examples where maybe it wouldn't be so desirable.
> 
> 
> > >For example the signaling might "hop through" some sort of peering
> > >point that offers no media relay services - that seems reasonable -
but
> > >to have the signaling and media traverse completely disjoint sets
of L3
> > >networks whilst magically receiving end-to-end QoS treatment, does
not.
> Probably doesn't help in this case.  But again this is only one
example.
> The interesting question is, can we have it both ways?  Can we have
the
> managed network solution when it adds value, and not when it doesn't?
> 
> 
> Of course.
> > >the nature of the association of signaling-path and bearer-path,
and
> > >how is it assured (assuming that the signaling path is determined
at L5
> > >and the bearer path at L3)?
> >
> I don't know what the phrase "rebuilding the PSTN" means.
> 
> 
> Cheers,
> 
> tim

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 29 Mar 2006 21:47:19 +0200

>I guess I'm still struggling with the problem the WG is trying to solve.

I think we all do

I have to admit that my example with the New York Hotel was
of course provokative and also stating the obvoius, or as Otmar
pointed out: it is all there in the RFCs and what speermint may
add is some BCPs and minimum reqiurements

Why I did this?

Because I know about the other extreme model:
It is the GSMA model for peering of mobile operators
within 3GPP: GSMA is the club of mobile operators

They plan that every operator is running SIP in a private 
10.x.x.x network. A user may either be connected directly
to this network or may VPN into it.

All mobile operators interconnect to a commonly operated
extranet (not (yet) connected to the Internet) which is callex IPX
and an evolution of the existing GPX network currently used for GPRS
Roaming. The ENUM database and also other DNS domains are
provided within the IPX ( basically a managed Internet2).

BTW, the DNS root of this network is run by Neustar.

This works fine for all operators connected to this network, but
the question remains, how does the GSMA operators interwork
with say the cable operators or the fixed operators?

Two options exist:
1. cable operators and fixed operators create their
own clubs, and agree to peer with GSMA via a super IPX

2. All others are joining the GSMA club (GSMA is working
on a proposal.

Minor problem: the others still do not even have a club to negotiate
e.g. TISPAN (the fixed operators) has still no clue which way to go
The cable operators are currently doing something in between using
private peering fabrics e.g. Xconnect (e.g. in NL)

And VoIP providers on the Internet are left behind

There is also another problem: an end-device connected
such a network (either direct or via VPN) must have two
separate IP stacks, if it also still wants to be connected to
the Internet. Same is valid for an enterprise connected
to a IMS VOIP provider. There is one stack for communications
via IMS and another one for communications within the
company and to the public Internet. The two may not be connected
bcause then the security of the walled garden s compromised. This
implies that you may e.g. not lauch a voip call via Outlook from the corporate
exchange server easily, only via complicated indirect portals on
the Internet.

What I want to state here is: for doing so, they do not need speermint
either, they have already defined this and implementing it

So one question remains: is there something in between the
open Internet model and the closed IPX model?

The finaly decision between these models will of course be
done by the customer. The customer will have the option
on his device which stack to use.

This may be some ground for speermint

cheers

Richard

________________________________

Von: Reinaldo Penno [mailto:[email-masked]]
Gesendet: Mi 29.03.2006 20:28
An: [email-masked]; Stastny Richard; Medhavi Bhatia; David Schwartz; [email-masked]
Betreff: RE: [Speermint] Billing, Accounting, Tariffing and Charging

a
establishes
"L5

[[Reinaldo]]

Thanks,

Reinaldo

connected
registered
my
hands
model
maybe
operator's
agreements,
for
information
opportunities
some
intends
may
as
the
constantly in
governing
networks
omitting
result
the
There
but
of L3
not.
example.
the
and
at L5

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 30 Mar 2006 12:05:17 +0200

Hi Keith,
 
some questions for clarification
 
>What SPEERMINT needs to deal with is how each operator accounts to another operator for the traffic that one delivers to the >other. In 3GPP that is dealt with primarily by the exchange of IOI parameters over SIP. At the SIP level the account is not >exchanged between operators, merely an indicator of the operator that the traffic has been passed to.

1. So you are proposing SPEERMINT should deal with accounting issues?
2. What kind of traffic? L3 or L5?
3. What if no L3 traffic is deleivered at all?
4.or are you proposing that SPEERMINT is dealing only with networks behind SBC?
5. IOI?
 
regards
Richard

Von: Drage, Keith (Keith) [mailto:[email-masked]]
Gesendet: Do 30.03.2006 11:32
An: Stastny Richard; 'Paul Kyzivat'; 'Bob Natale'
Cc: [email-masked]'
Betreff: RE: [Speermint] Billing, Accounting, Tariffing and Charging

I am sure we could get into all sorts of philosophical discussions on this, but let's just postulate one question:

How much of the items you spend money on in a year are actually based on the cost of providing the service, and how much is based on what the market will bear?

And I don't see it being any different for most ISPs either.

But anyway surely those issues are irrelevant for SPEERMINT.

What SPEERMINT needs to deal with is how each operator accounts to another operator for the traffic that one delivers to the other. In 3GPP that is dealt with primarily by the exchange of IOI parameters over SIP. At the SIP level the account is not exchanged between operators, merely an indicator of the operator that the traffic has been passed to.

regards

Keith

> Sent: 29 March 2006 15:05
> To: Paul Kyzivat; Bob Natale
> Cc: [email-masked]
> complicated over
> > >>>I believe a call to a public number is (or should)
> always going to
> > >>>be
> > >>
> > >>routable. I guess my
> > >>
> > >>>My reply to David's email was more to the idea that you
> can install
> > >>>a
> > >>
> > >>proxy server
> > >>

---

From: "Khan, Sohel Q [CTO]" <[email-masked]>
Date: Fri, 31 Mar 2006 12:27:39 -0600

How the providers should bill each other should be out of scope of SPEERMINT.
However, SPEERMINT needs to define parameters by which account information may be exchanged between two providers.
The accounting information may be packet level or session level or both.

-----Original Message-----
From: Drage, Keith (Keith) [mailto:[email-masked]] 
Sent: Thursday, March 30, 2006 3:33 AM
To: 'Stastny Richard'; 'Paul Kyzivat'; 'Bob Natale'
Cc: [email-masked]'
Subject: RE: [Speermint] Billing, Accounting, Tariffing and Charging

regards

Keith