Subject: RE: draft-ietf-mmusic-sip-session-timer-00.txt

From: [email-masked] (Patrice Calhoun)
Date: Fri, 12 Feb 1999 08:43:02 -0800

>Hi Douglas, how is it in the summer in Australia ?
>
>> If they are your gateways, that you connect to the PSTN, and provide an
>egress service, then you should be in control, and you can control charging
>for the service.
>
>Yes, its pretty easy to track PSTN resource usage, because the media stream
>towards the PSTN must go through them ...
>
>> If it's your gateway (you bought it) and you need it to obey your
>controller (SIP server or gatekeeper) and it doesn't, then send it back and
>get one that will. If it's your gateway (you bought it) and you don't want
>
>I'm not against this scenario, its proven for militarized zones (i.e.
>Intranets in entreprises controlled by MIS). Where I worrry is in DMZs,
>where an ISP forces me to use its gatekeeper.  That's where I'm saying that
>the end point has to become a trusted network element, in the control of the
>ISP, in order to bill by the second/bit.  The control of the session becomes
>in practice when the routers of the ISP refuse to send bits on the network
>on the behalf of non-trusted (to behave according to the ISP's policy) SIP
>end point (I guess that's another form of admission control ...).  This is
>the way that the MSO's are gearing up their VoIP network presently
>(PacketCable).  I.e., if you want to bill by the minute/second/bit, you
>either need to route the media stream through the SIP server and/or make the
>SIP server control the admission of the bits to the IP layer ... that is,
>there needs to be some form of policy decision flowing between a SIP server
>and routers that forwards the media stream bits from SIP endpoints ...
>
>>>Even worse, a sip server / gatekeeper that wishes to track the end of a
>call
>>>so that it can bill by the second needs to worry about end points that
>just
>>>go out and die and never send an end of conversation ... this mechanism is
>>>not yet specified ...
>And if it wishes to bill by the byte, it needs endpoints that will report
>resource usage. It needs endpoints that will report periodically, or store
>records in non-volatile storage to report when they come up.
>Work is in progress, in both ITU SG-16, and ETSI EP-TIPHON.
>
>So I can have the following, when a SIP server never gets a BYE, it doesn't
>need to ping the end point to see if its still alive, it can simply wait
>until the end-point re-REGISTERs, and then flag the call as terminated, and
>then, query the end point to tell it how many seconds were spent on line
>before the end-point died ... has anybody thought of extending the REGISTER
>message to include the duration of the previous call?  I think that this is
>a pretty cool idea ;-)  Of course, if the end-point never re-registers, the
>timer will still be running ... indefinitely.  We have a new policy on IP
>networks, any call of length greater than 1 million minutes is free ...
>
>BTW, I asked the question today to a supplier of H.323 stacks, as to what
>generally did the commercial gatekeepers do in practice to track the end of
>calls.  The person told me that the gatekeepers generally wait for the next
>registration (i.e. their assumption is that the H.323 terminal will
>re-register within hours), to flag the call as terminated.  They also rely
>on either one of the two legs of the call to send a termination message, so
>the case where the two legs are cut off never happens very frequently.  As
>to what is the mechanism that a gatekeeper is supposed to use to "ping" the
>terminal, that's not in the standard in their opinion.  Personally, I begin
>to like the idea of the end-point presenting the duration of the last call
>in the registration message ...

Having built PPP routers in the past, I would never trust the PPP client to
report usage, and generate accounting information from it. Actually, the only
boxes that I ever would really trust are the ones that I have control over,
which in this case seems to be the SIP Servers.

PatC
>-=Francois=-
>[email-masked]