Subject: RE: [SIP] Authentication and billing through proxy/re-direct serv er

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 20 Jun 2001 09:01:52 -0400

Just for grins, what would you expect the charging to look like when the
terminating end is on a different network from the originating end, but they
were both sipphones?  Suppose there were three networks (a transit network
as well as the originating and terminating networks)?  Suppose there was
an enterprise network (no internal charging) connected to a public (IP)
network
that charged by the minute?
 
I don't want to start a debate on billing possibilities.  I do think that
you have to
accept that CDRs may have to be generated at a few places in the network.
I myself am not wild about UAs doing CDR generation.  I think proxy servers 
can do that.  The piece of information the PS doesn't have is the exact
connection
time information.  We may want to be able to get that sent on a BYE.  
 
Suppose you just thought of this stuff as statistics.  There are several
interesting
statistics you may wish to gather on a call (lost packets for example).
Sure,
you could make this a management function, but you are then faced with
storage
and other issues associated with a very large number of endpoints.  If you
could
report statistics on a BYE, the PS could then generate the CDR.
 
This may also help a problem we are currently calling "session management".
There
is some work at the Softswitch Consortium on this.  It deals with the
following
practical problem - your customer service center gets the following call "I
was
just talking to my mother and I couldn't hear her".  Okay, what equipment
was used
on that call, and where did it go wrong?  To make that really work EVERY
device
that participates in some way on the call needs to report information on the
call,
and it has to do so proactively.  This is equivalent to a CDR with more
information
(statistics).  Yes, we could get UAs to generate them, but we could also
just pass
up the info on BYE and let the PS save it, massage it, and send it on it's
way.
 
Brian

-----Original Message-----
From: Jay Batson [mailto:[email-masked]]
Sent: Tuesday, June 19, 2001 5:59 PM
To: Ashhar Farhan; [email-masked]
Subject: Re: [SIP] Authentication and billing through proxy/re-direct server

There is another possibility that "real commercial systems" might use (in
fact, are likely to use...):

- Charge only for PSTN gateway transit.
- Sessions that stay on the IP net (only) are built into a base
bandwidth/connectivity fee.

In this case, CDRs generated by the gateway will provide sufficient
information about PSTN connectivity to create billing info, wouldn't they?
Neither the proxy nor the originating (IP-network-resident) UA need to know
/ do anything....

-jb

At 03:28 AM 6/4/01, Ashhar Farhan wrote:

in a typical next gen telco setup, the billing is centralised and their
Point of presence are basically SIP servers that gateway to PSTN cloud.

the INVITE gets redirected/proxied from the central server and the is resend
to the gateway (a sip server).
here, we have an issue of user authentication. the user has to be
authenticated by the redirect/proxy server. the authentication (as per the
SIP recommendations) should be md5 digest. 
the scheme would be that the redirect/proxy should generate a digest over
the redirected INVITE request using the nonce and password of the intended
server.

billing systems are usually needed to be centralised (esp. in those next gen
telcos where the servers are operated by franchises). this is a commercial
requirement of SIP operations.

the 2543.bis does not explicitly talk of the redirect/proxies authenticating
requests for the gateways.

the second issue:
the call minutes are the accepted billing mechanism for atleast the next
couple of years. to support billing, accurate times of call start and end
are important.
the call times maybe at variance between the client and the server due to a
the RTT nature of messaging itself. In that case, it will be advisable, from
a caller perspective to know when exactly did the call get disconnected (a
second's delay can roll the call over to the next minute) and how long did
the call last - as per server's record. Although MESSAGE can be used for
this, i would rather believe that a more intrinsic method must be available
to support this that can update the caller's own 'call meter'.

- [email-masked]

_____________________________________________________
Chat with your friends as soon as they come online. Get Rediff Bol at
http://bol.rediff.com <http://bol.rediff.com/> 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

-------------
PingMe!
Jay Batson
CEO
Pingtel Corp.
mailto:[email-masked] <mailto:[email-masked]> 
781-938-5306 (office)

---

From: Michael Thomas <[email-masked]>
Date: Wed, 20 Jun 2001 07:33:28 -0700 (PDT)

I agree with Brian that "statistics" is a far
better word to use than "billing" because it
doesn't set off alarms. However, if the statistics
are going to be used in such a way that fraudlent
statistics could result in theft, that must
obviously be defended against. There is no set
answer here on how one can do this. To be free
from fraud, a trusted device *in the media path*
must be capable of determining session start and
end, etc. Not the signaling path; it can be
duped. For calls terminating in a trusted PSTN
gateway, you can obviously generate statistics
there. However, for calls that begin and terminate
on untrusted devices (say, our Brian and my home
SIP phones), you either need some sort of middle
box, or you need to just get over any thought of
it being secure.

The Packetcable/manyfolks drafts use the "middle
box" approach for gating resources at the
untrusted edge by using RSVP/COPS at the access
router to delineate where resources are consumed
on the cable plant in the case of Packetcable. 
It should be noted that if Brian and I don't care
about elevated QoS, there is nothing that the
service provider can do to prevent us from having
a chat. Obviously, similar schemes can be hatched
for other scenarios such as DSL, cellular, etc.

	  Mike

Rosen, Brian writes:
 > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
 > <HTML><HEAD>
 > <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
 > 
 > 
 > <META content="MSHTML 5.50.4522.1800" name=GENERATOR></HEAD>
 > <BODY>
 > <DIV><SPAN class=280574212-20062001><FONT face=Arial color=#0000ff>Just for 
 > grins, what would you expect the charging to look like when 
 > the</FONT></SPAN></DIV>
 > <DIV><SPAN class=280574212-20062001><FONT face=Arial color=#0000ff>terminating 
 > end is on a different network from the originating end, but 
 > they</FONT></SPAN></DIV>
 > <DIV><SPAN class=280574212-20062001><FONT face=Arial color=#0000ff>were both 
 > sipphones?&nbsp; Suppose there were three networks (a transit 
 > network</FONT></SPAN></DIV>
 > <DIV><SPAN class=280574212-20062001><FONT face=Arial color=#0000ff>as well as 
 > the originating and terminating networks)?&nbsp; Suppose there 
 > was</FONT></SPAN></DIV>
 > <DIV><SPAN class=280574212-20062001><FONT face=Arial color=#0000ff>an enterprise 
 > network (no internal charging) connected to a public (IP) 
 > network</FONT></SPAN></DIV>
 > <DIV><SPAN class=280574212-20062001><FONT face=Arial color=#0000ff>that charged 
 > by the minute?</FONT></SPAN></DIV>
 > <DIV><SPAN class=280574212-20062001><FONT face=Arial 
 > color=#0000ff></FONT></SPAN>&nbsp;</DIV>
 > <DIV><SPAN class=280574212-20062001><FONT face=Arial color=#0000ff>I don't want 
 > to start a debate on billing possibilities.&nbsp; I do think that you have 
 > to</FONT></SPAN></DIV>
 > <DIV><SPAN class=280574212-20062001><FONT face=Arial color=#0000ff>accept that 
 > CDRs may have to be generated at a few places in the 
 > network.</FONT></SPAN></DIV>
 > <DIV><SPAN class=280574212-20062001><FONT face=Arial color=#0000ff>I myself am 
 > not wild about UAs doing CDR generation.&nbsp; I think proxy servers 
 > </FONT></SPAN></DIV>
 > <DIV><SPAN class=280574212-20062001><FONT face=Arial color=#0000ff>can do 
 > that.&nbsp; The piece of information the PS doesn't have is the exact 
 > connection</FONT></SPAN></DIV>
 > <DIV><SPAN class=280574212-20062001><FONT face=Arial color=#0000ff>time 
 > information.&nbsp; We may want to be able to get that sent on a BYE.&nbsp; 
 > </FONT></SPAN></DIV>
 > <DIV><SPAN class=280574212-20062001><FONT face=Arial 
 > color=#0000ff></FONT></SPAN>&nbsp;</DIV>
 > <DIV><SPAN class=280574212-20062001><FONT face=Arial color=#0000ff>Suppose you 
 > just thought of this stuff as statistics.&nbsp; There are several 
 > interesting</FONT></SPAN></DIV>
 > <DIV><SPAN class=280574212-20062001><FONT face=Arial color=#0000ff>statistics 
 > you may wish to gather on a call (lost packets for example).&nbsp; 
 > Sure,</FONT></SPAN></DIV>
 > <DIV><SPAN class=280574212-20062001><FONT face=Arial color=#0000ff>you could 
 > make this a management function, but you are then faced with 
 > storage</FONT></SPAN></DIV>
 > <DIV><SPAN class=280574212-20062001><FONT face=Arial color=#0000ff>and other 
 > issues associated with a very large number of endpoints.&nbsp; If you 
 > could</FONT></SPAN></DIV>
 > <DIV><SPAN class=280574212-20062001><FONT face=Arial color=#0000ff>report 
 > statistics on a BYE, the PS could then generate the CDR.</FONT></SPAN></DIV>
 > <DIV><SPAN class=280574212-20062001><FONT face=Arial 
 > color=#0000ff></FONT></SPAN>&nbsp;</DIV>
 > <DIV><SPAN class=280574212-20062001><FONT face=Arial color=#0000ff>This may also 
 > help a problem we are currently calling "session management".&nbsp; 
 > There</FONT></SPAN></DIV>
 > <DIV><SPAN class=280574212-20062001><FONT face=Arial color=#0000ff>is some work 
 > at the Softswitch Consortium on this.&nbsp; It deals with the 
 > following</FONT></SPAN></DIV>
 > <DIV><SPAN class=280574212-20062001><FONT face=Arial color=#0000ff>practical 
 > problem - your customer service center gets the following call "I 
 > was</FONT></SPAN></DIV>
 > <DIV><SPAN class=280574212-20062001><FONT face=Arial color=#0000ff>just talking 
 > to my mother and I couldn't hear her".&nbsp; Okay, what equipment was 
 > used</FONT></SPAN></DIV>
 > <DIV><SPAN class=280574212-20062001><FONT face=Arial color=#0000ff>on that call, 
 > and where did it go wrong?&nbsp; To make that really work EVERY 
 > device</FONT></SPAN></DIV>
 > <DIV><SPAN class=280574212-20062001><FONT face=Arial color=#0000ff>that 
 > participates in some way on the call needs to report information on the 
 > call,</FONT></SPAN></DIV>
 > <DIV><SPAN class=280574212-20062001><FONT face=Arial color=#0000ff>and it has to 
 > do so proactively.&nbsp; This is equivalent to a CDR with more 
 > information</FONT></SPAN></DIV>
 > <DIV><SPAN class=280574212-20062001><FONT face=Arial 
 > color=#0000ff>(statistics).&nbsp; Yes, we could get UAs to generate them, but we 
 > could also just pass</FONT></SPAN></DIV>
 > <DIV><SPAN class=280574212-20062001><FONT face=Arial color=#0000ff>up the info 
 > on BYE and let the PS save it, massage it, and send it on it's 
 > way.</FONT></SPAN></DIV>
 > <DIV><SPAN class=280574212-20062001><FONT face=Arial 
 > color=#0000ff></FONT></SPAN>&nbsp;</DIV>
 > <DIV><SPAN class=280574212-20062001><FONT face=Arial 
 > color=#0000ff>Brian</FONT></SPAN></DIV>
 > <DIV><SPAN class=280574212-20062001><FONT face=Arial 
 > color=#0000ff></FONT></SPAN>&nbsp;</DIV>
 > <DIV><SPAN class=280574212-20062001><FONT face=Arial 
 > color=#0000ff></FONT></SPAN>&nbsp;</DIV>
 > <DIV><SPAN class=280574212-20062001><FONT face=Arial 
 > color=#0000ff></FONT></SPAN>&nbsp;</DIV>
 > <BLOCKQUOTE dir=ltr 
 > style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
 >   <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
 >   size=2>-----Original Message-----<BR><B>From:</B> Jay Batson 
 >   [mailto:[email-masked]]<BR><B>Sent:</B> Tuesday, June 19, 2001 5:59 
 >   PM<BR><B>To:</B> Ashhar Farhan; [email-masked]<BR><B>Subject:</B> Re: 
 >   [SIP] Authentication and billing through proxy/re-direct 
 >   server<BR><BR></FONT></DIV>There is another possibility that "real commercial 
 >   systems" might use (in fact, are likely to use...):<BR><BR>- Charge only for 
 >   PSTN gateway transit.<BR>- Sessions that stay on the IP net (only) are built 
 >   into a base bandwidth/connectivity fee.<BR><BR>In this case, CDRs generated by 
 >   the gateway will provide sufficient information about PSTN connectivity to 
 >   create billing info, wouldn't they?&nbsp; Neither the proxy nor the 
 >   originating (IP-network-resident) UA need to know / do 
 >   anything....<BR><BR>-jb<BR><BR>At 03:28 AM 6/4/01, Ashhar Farhan wrote:<BR>
 >   <BLOCKQUOTE class=cite cite type="cite">in a typical next gen telco setup, 
 >     the billing is centralised and their Point of presence are basically SIP 
 >     servers that gateway to PSTN cloud.<BR><BR>the INVITE gets 
 >     redirected/proxied from the central server and the is resend to the gateway 
 >     (a sip server).<BR>here, we have an issue of user authentication. the user 
 >     has to be authenticated by the redirect/proxy server. the authentication (as 
 >     per the SIP recommendations) should be md5 digest. <BR>the scheme would be 
 >     that the redirect/proxy should generate a digest over the redirected INVITE 
 >     request using the nonce and password of the intended server.<BR><BR>billing 
 >     systems are usually needed to be centralised (esp. in those next gen telcos 
 >     where the servers are operated by franchises). this is a commercial 
 >     requirement of SIP operations.<BR><BR>the 2543.bis does not explicitly talk 
 >     of the redirect/proxies authenticating requests for the gateways.<BR><BR>the 
 >     second issue:<BR>the call minutes are the accepted billing mechanism for 
 >     atleast the next couple of years. to support billing, accurate times of call 
 >     start and end are important.<BR>the call times maybe at variance between the 
 >     client and the server due to a the RTT nature of messaging itself. In that 
 >     case, it will be advisable, from a caller perspective to know when exactly 
 >     did the call get disconnected (a second's delay can roll the call over to 
 >     the next minute) and how long did the call last - as per server's record. 
 >     Although MESSAGE can be used for this, i would rather believe that a more 
 >     intrinsic method must be available to support this that can update the 
 >     caller's own 'call meter'.<BR><BR>- 
 >     [email-masked]<BR><BR><BR><BR>_____________________________________________________<BR>Chat 
 >     with your friends as soon as they come online. Get Rediff Bol at<BR><A 
 >     href="http://bol.rediff.com/" 
 >     eudora="autourl">http://bol.rediff.com</A><BR><BR><BR><BR><BR><BR>_______________________________________________<BR>This 
 >     list is for continuing development of the SIP protocol.<BR>The 
 >     sip-implementor's list is the place to discuss implementation,<BR>and to 
 >     receive advice on understanding existing sip.<BR>To subscribe to it, send 
 >     mail to <BR>[email-masked] with "subscribe" in the 
 >     body.</BLOCKQUOTE><X-SIGSEP>
 >   <P></X-SIGSEP><B>-------------<BR>Ping</B>Me!<BR>Jay Batson<BR>CEO<BR>Pingtel 
 >   Corp.<BR><A href="mailto:[email-masked]" 
 >   eudora="autourl">mailto:[email-masked]</A><BR>781-938-5306 
 >   (office)<BR><BR></P></BLOCKQUOTE></BODY></HTML>

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 21 Jun 2001 01:09:58 +0200

At 04:33 PM 6/20/2001, Michael Thomas wrote:
[...]
> To be free
>duped. 

Michael,

could you give more details on what kind of fraud is
expected to be prevented by what kind of middleboxes?

> However, for calls that begin and terminate

I did not understand this either -- I think that
if you call Brian using your SIP phone and both of 
you guys pay to your ISP, everyone will be happy. 
What do I need a middlebox for?

Jiri

_______________________________________________
Sip mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/sip