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

From: John Hearty <[email-masked]>
Date: Thu, 11 Feb 1999 15:55 -0600 (CST)

This draft was written in part to address a concern that stateful
SIP proxy servers could have sessions marked active when in fact they
have been terminated, and invalid state data could remain indefinately
in the server.  It is true that BYE messages could be ignored, but
that would have to be coordinated by all parties wishing to remain
in the session, and then they are just using the IP access pipe they
are already paying for.  You could even go one step further in that
line of thinking and have the originator send a Cancel instead of an
ACK once it got the session info back from the terminator in a 200 OK,
thereby never starting the session, but coordination from both ends
would again be required.  So other than setting up the session (which
could be a billable event), coordination of the session from that point
on would be up to the involved clients, no different than what is now
available.

John Hearty
MCI Worldcom
Global Network Evolution

Date: Thu, 11 Feb 1999 13:02 -0600 (CST)
From: [email-masked] (Patrice Calhoun)
To: "Donovan, Steven R. (MCI)" <[email-masked]>,
    "[email-masked]'" <[email-masked]>,
    "[email-masked]'" <[email-masked]>
Sender: [email-masked]
Reply-to: [email-masked]
Delivered-to: [email-masked]
Delivered-to: [email-masked]
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).

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.

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:  [email-masked]'; [email-masked]'
>> 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.

---------
This message came from the IETF IPTEL Working Group Mailing List.