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

[[e-mail] (Patrice Calhoun)]

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

If this is a simple change, it would provide an enormous amount of control over
the SIP Server that has to maintain session state information.

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