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

Douglas Clowes <dclowes@ozemail.com.au> Sat, 13 February 1999 11:39 UTC

Return-Path: <owner-confctrl>
Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id DAA16778 for confctrl-outgoing; Sat, 13 Feb 1999 03:39:21 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id DAA16769 for <confctrl@zephyr.isi.edu>; Sat, 13 Feb 1999 03:39:18 -0800 (PST)
Received: from server3.syd.mail.ozemail.net (server3.syd.mail.ozemail.net [203.108.7.41]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id DAA19548 for <confctrl@ISI.EDU>; Sat, 13 Feb 1999 03:39:16 -0800 (PST)
Received: from dcloweslap (slsyd62p04.ozemail.com.au [203.108.19.196]) by server3.syd.mail.ozemail.net (8.9.0/8.6.12.IPASS) with SMTP id WAA05929; Sat, 13 Feb 1999 22:38:31 +1100 (EST)
Message-Id: <3.0.3.32.19990213223827.0076ae50@pop.ozemail.com.au>
X-Sender: dclowes@pop.ozemail.com.au
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Sat, 13 Feb 1999 22:38:27 +1100
To: Francois Menard Distribution List Management Account <fm-listproc@mediatrix.com>, Francois Menard Distribution List Management Account <fm-listproc@mediatrix.com>, "'Pat.Calhoun@Eng.Sun.COM'" <Pat.Calhoun@Eng.Sun.COM>, "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>, "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>, "'iptel@lists.research.bell-labs.com'" <iptel@lists.research.bell-labs.com>
From: Douglas Clowes <dclowes@ozemail.com.au>
Subject: RE: draft-ietf-mmusic-sip-session-timer-00.txt
In-Reply-To: <F16674FCE856D211AC0D00E02910AE0A07B518@INTERNAL>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

At 07:56 1999-02-12 -0500, Francois Menard Distribution List Management
Account wrote:
>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.

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

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?

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

Well, perhaps less than that.

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

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.

>-=Francois=-
>fmenard@mediatrix.com
>

Douglas