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

[[e-mail] (Patrice Calhoun)]

>There is no way to properyly time the session unless the end-point is a
>controlled network element.  A gatekeeper and/or SIP server cant do anything
>unless the media stream gets through it ... of course, a SIP server, and or
>H.323 gatekeeper can talk to routers, which control an IP media stream, and
>affect the media stream.
>
>Even worse, a sip server / gatekeeper that wishes to track the end of a call
>so that it can bill by the second needs to worry about end points that just
>go out and die and never send an end of conversation ... this mechanism is
>not yet specified ...

Yes the cellular network that the same problem, hence the "end" button
on your phone. This would require a periodical update from the SIP Client 
to the SIP Server (a refresh of some sort).

PatC
>
>-=Francois=-
>
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]]
>Sent: Thursday, February 11, 1999 6:22 PM
>To: Donovan, Steven R. (MCI); '[e-mail]';
>'[e-mail]'; '[e-mail]'
>Subject: RE: draft-ietf-mmusic-sip-session-timer-00.txt
>
>
>
>>
>>
>>> -----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
>>> 
>
>
>
>---------
>This message came from the IETF IPTEL Working Group Mailing List.