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

["Donovan, Steven R. (MCI)" <[e-mail]>]

	

> -----Original Message-----
> From:	[e-mail] [SMTP:[e-mail]]
> Sent:	Friday, February 12, 1999 2:46 PM
> To:	Donovan, Steven R. (MCI); Jonathan Rosenberg;
> '[e-mail]'
> Cc:	Douglas Clowes; '[e-mail]';
> '[e-mail]'
> Subject:	RE: draft-ietf-mmusic-sip-session-timer-00.txt
> 
> 
> >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?
> 
> Yes, and I appologize for side-tracking the whole thread. Is there anyway
> that we could have shorter INVITEs (perhaps the SIP Server can determine
> the length of a session), and have the SIP Client re-register with the 
> server periodically, such as:
> 
>    SIP Client --------- INVITE ------------> SIP Server
>                (some stuff happens here)
>    SIP Client < ------- ACK (3 mins) ------- SIP Server
>    (2 mins 45 seconds pass, enough to allow for retransmissions)
>    SIP Client ---------- FOOBAR -----------> SIP Server
>    (where FOOBAR is some message that refreshes the session)
> 
> This would allow the SIP Server to have soft-state and time out any
> sessions
> that have not been re-registered (or foobar'ed in the above example).
> 
	The SIP Session Timer draft allows the server to time out sessions
that have not been extended.  The FOOBAR process is a re-INVITE with a new
session-expires header.  The only difference is that the initial INVITE has
the clients requesting duration, where your proposal has the model of the
SIP server specifying the initial duration.

	The question of the softness or hardness of the state is up the SIP
server implementation.

	I suppose one optimization to the current draft is to give the SIP
Server the ability to specify an acceptable session time in the situations
where the client either doesn't specify a duration or when the client
specifies an unacceptable (too long) duration.

> PatC
> >
> >Steve
> >
> >> -----Original Message-----
> >> From:	[e-mail] [SMTP:[e-mail]]
> >> Sent:	Friday, February 12, 1999 9:39 AM
> >> To:	Jonathan Rosenberg; [e-mail]
> >> Cc:	Donovan, Steven R. (MCI);
> '[e-mail]';
> >> '[e-mail]'; 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.
>