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

[[e-mail] (Patrice Calhoun)]

>
>
>> -----Original Message-----
>> From:	[e-mail] [SMTP:[e-mail]]
>> Sent:	Thursday, February 11, 1999 1:02 PM
>> To:	Donovan, Steven R. (MCI); '[e-mail]';
>> '[e-mail]'
>> Subject:	RE: draft-ietf-mmusic-sip-session-timer-00.txt
>> 
>> Pardon the perhaps very naive question, but I suppose I am not as versant
>> in 
>> SIP as I would like to be.
>> 
>> My understanding is that a SIP Client issues an Invite message to a SIP
>> Server,
>> which in turn forwards the request to a target SIP Client (or some GW or
>> some
>> sort). Once the ACK has returned to the originating client, I was under
>> the
>> impression that both SIP Clients send RTP packets directly to each other,
>> bypassing the SIP Server (this is where I am unclear).
>> 
>	This depends on the implementation of the SIP Server.  There are
>valid reasons to have the SIP Server proxy the IP packets.  But in general,
>you are correct.  There will be SIP Servers that do not have a view of the
>RTP flow.
>
>> So if this is true, how will a SIP Server (stateful, or stateless) enforce
>> any
>> session timeouts? A malicious SIP Client can simply keep the session
>> active
>> for as long as it wishes, ignoring any messages from the SIP Server that
>> may
>> tell it to disconnect.
>> 
>> This, as far as I can see, could cause some serious problems if one wishes
>> to
>> deploy a service and still maintain some control over the sessions.
>> 
>> Again, perhaps I am way off here. Any clarifications would certainly be 
>> appreciated.
>> 
>	You are correct and I personally would not rely on reporting from
>the SIP Server to do reliable billing.  However, if a stateful SIP Proxy
>server is built, for whatever reason, the current SIP specification does not
>have a mechanism for the SIP server to know which of the sessions for which
>it has state are valid.  This draft gives the SIP Server a mechanism to
>remove those sessions that it feels are no longer valid.
>
>	The amount of control that a SIP server exerts over sessions is a
>separate issue.  As John Hearty accurately points out in a separate email,
>the user of the SIP device can choose to bypass the SIP server entirely.
>The challenge for service providers will be to implement services that make
>user's want to access the service provider's SIP server.

This is not actually true. It is quite simple for service providers to install
a set of filters in their systems that require that all RTP traffic be directed
to one of their local SIP Servers.

Note that I am not advocating such an idea. I like free service, but one must
realize that free services are rarely every deployed by the services 
providers :(

PatC
>
>> PatC
>> 
>> >This time with the draft attached.  Sorry for the extra mail.
>> >
>> >Steve
>> >
>> > <<draft-ietf-mmusic-sip-session-timer-00.txt>> 
>> >
>> >> -----Original Message-----
>> >> From:	Donovan, Steven R. (MCI) 
>> >> Sent:	Thursday, February 11, 1999 10:17 AM
>> >> To:	'[e-mail]'; '[e-mail]'
>> >> Subject:	draft-ietf-mmusic-sip-session-timer-00.txt
>> >> 
>> >> This message is notification of the following Internet Draft which has
>> >> been submitted to the IETF for posting.
>> >> 
>> >> <draft-ietf-mmusic-sip-session-timer-00.txt> 
>> >> 
>> >> Abstract: 
>> >> 
>> >> This document proposes an extension to the SIP specification.  This
>> >> extension adds a new message header that is used to specify the 
>> >> duration of a requested session.
>> >> 
>> >> The session timer can be used to limit the total duration of a session
>> >> if, for instance, one of the participants in the session wants to
>> >> limit the cost of the session.  It can also be used by stateful SIP
>> >> Proxy Servers to track the status of sessions for which session state
>> >> exists on the servers. Currently a stateful SIP Proxy Server that is 
>> >> not handling the media stream(s) for the session has no mechanism to 
>> >> definitively determine the state of all sessions for which it has
>> state.
>> >> While the SIP Specification does provide the BYE method for terminating
>> >> the session, there is no mechanism for a SIP Proxy Server to detect the
>> >> end of a session when the BYE message is not sent or is lost due to 
>> >> network problems.
>> >> 
>> >> The internet draft is attached.
>> >> 
>> >> Steve Donovan
>> >> MCIWorldcom
>>