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

"Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com> Fri, 12 February 1999 20:26 UTC

Return-Path: <owner-confctrl>
Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id MAA17496 for confctrl-outgoing; Fri, 12 Feb 1999 12:26:14 -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 MAA17491 for <confctrl@zephyr.isi.edu>; Fri, 12 Feb 1999 12:26:13 -0800 (PST)
Received: from omzrelay.mcit.com (omzrelay.mcit.com [166.37.204.49]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id MAA25750 for <confctrl@isi.edu>; Fri, 12 Feb 1999 12:26:12 -0800 (PST)
Received: from omzexch006.mcit.com (omzexch006.mcit.com [166.37.194.37]) by omzrelay.mcit.com (8.8.7/) with ESMTP id TAA20660; Fri, 12 Feb 1999 19:24:48 GMT
Received: by omzexch006.mcit.com with Internet Mail Service (5.5.2232.9) id <1N9CDJ7G>; Fri, 12 Feb 1999 20:25:15 -0000
Message-ID: <CA6966C24AC6D111B5A100805FEAB7D8577416@nsrip00208.mcit.com>
From: "Donovan, Steven R. (MCI)" <Steven.R.Donovan@mci.com>
To: "'Pat.Calhoun@Eng.Sun.COM'" <Pat.Calhoun@Eng.Sun.COM>, Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>
Cc: "'iptel@lists.research.bell-labs.com'" <iptel@lists.research.bell-labs.com>, "'confctrl@ISI.EDU'" <confctrl@ISI.EDU>, Douglas Clowes <dclowes@ozemail.com.au>
Subject: RE: draft-ietf-mmusic-sip-session-timer-00.txt
Date: Fri, 12 Feb 1999 20:25:06 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BE56C5.CB3AE254"
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

This is an interesting discussion, however I'm not sure that we are going to
get answers to the questions that Pat is asking.  Only time will tell how
services providers make money off of IP based telephony services.

However, this is not the purpose of proposing the addition of the session
timer to the SIP protocol.  The primary purpose is to give the stateful SIP
Proxy Server a method of determining the validity of the individual sessions
for which it is keeping state.

Are there comments on the mechanisms proposed in the session-timer draft?

Steve

> -----Original Message-----
> From:	Pat.Calhoun@Eng.Sun.COM [SMTP:Pat.Calhoun@Eng.Sun.COM]
> Sent:	Friday, February 12, 1999 9:39 AM
> To:	Jonathan Rosenberg; Pat.Calhoun@Eng.Sun.COM
> Cc:	Donovan, Steven R. (MCI); 'iptel@lists.research.bell-labs.com';
> 'confctrl@ISI.EDU'; Douglas Clowes
> Subject:	Re: draft-ietf-mmusic-sip-session-timer-00.txt
> 
> 
> >Patrice Calhoun wrote:
> >> 
> >> My only concern here is how does the service provider offer a service
> *and*
> >> make at least enough money to recover the capital costs (of course,
> certain
> >> providers may want to cover many additional costs, which is outside the
> scope
> >> of this discussion :).
> >
> >It comes back to the same question thats been brought up here on
> >numerous occassions - what are you billing for? SIP provides the setup
> >services, not the transport services. So, it makes sense for a SIP
> >server to charge for what it actually does - set the call up. It really
> >doesn't make sense, I don't think, to try to bill by the minute for the
> >SIP part of the call, since its really a transaction service. SIP is
> >only one part of the picture, though. There is also transport service -
> >diffserv prioritization, for example. A service provider can happily
> >charge by the minute,bit, packet, or whatever here.
> >
> 
> This is perhaps my mis-understanding. I have been working with the TIA
> recently
> and they have adopted MobileIP/DIAMETER for the next generation cellular
> data networks. When one considers voice over IP using IP cellular phones,
> one
> quickly wonders how the charging will really work. Yes, it is true that
> one
> will charge for network access, but conceivably, one could also charge for
> calls as well. This is especially true if these calls span providers.
> 
> Perhaps I have all of this wrong. I understand that charging for an LDAP
> query cannot amount to much, and perhaps that is all bundled as part of
> the
> access charge. Are there any providers on this list that have an idea on
> how
> they will actually bill for these services?
> 
> PatC
> 
> 
> ---------
> This message came from the IETF IPTEL Working Group Mailing List.