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

From: Francois Menard Distribution List Management Account <[email-masked]>
Date: Fri, 12 Feb 1999 07:56:19 -0500

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

-=Francois=-
[email-masked]

---------
This message came from the IETF IPTEL Working Group Mailing List.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 12 Feb 1999 09:23:59 -0500

> and routers that forwards the media stream bits from SIP endpoints ...

Well, bits are bits. Why would you want to control "admission" of bits
for this application, and not for others? If the model is that best
effort traffic is not billed by the bit, then you cannot bill for IP
telephony transport when best effort is used. Now, if you have diffserv,
then it seems quite reasonable to have the diffserv treatments get
"turned off" (i.e., packets go back to best effort treatment) when the
session terminates. In that case, billing would probably best be done
for transport in the COPS server, bandwidth broker, or whatever diffserv
element normally provides this function.

> before the end-point died 

Registration is separate from in-progress calls. A client periodically
re-registers independently from whether its in a call or not. A client
may have been in many calls between two registers. Would you include
durations for all of these? Why would the user agent report them anyway,
being it is just going to get billed (again, keeping the DMZ model in
mind). I don't see the benefit of tying these mechanisms together.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen

---------

---

From: Douglas Clowes <[email-masked]>
Date: Sat, 13 Feb 1999 22:38:27 +1100

At 07:56 1999-02-12 -0500, Francois Menard Distribution List Management
>Hi Douglas, how is it in the summer in Australia ?

It's warm and wet. Warmer that Sherbrooke, but I'll be in sunny California
in a couple of days.

>and routers that forwards the media stream bits from SIP endpoints ...

What's an MSO?

The ISP, in this case is trying to be like the LEC. It's more difficult for
them to do so in a deregulated market, with enforced competition. Is that
an oxymoron?

>networks, any call of length greater than 1 million minutes is free ...

Well, perhaps less than that.

>in the registration message ...

IRR is being used in H.323 to determine if the endpoint is still alive, but
the preference seems to be heading toward gatekeeper routed calls. Here,
you have a TCP connection through the gatekeeper for session control, but
media still goes direct.

>[email-masked]

Douglas

---------