Subject: RE: Proxy Server Inconsistencies

From: John Hearty <[email-masked]>
Date: Thu, 21 Jan 1999 15:20 -0600 (CST)

>There may be the need for a maximum session expires
>duration to prevent a user agent from specifying the year 2100 as the
>expires time of a session.

 If approach #3 was pursued, a minimum value for the session expires
duration would also be needed so applications don't overload SIP servers
sending updated INVITEs once a second, for example.  Users might otherwise
want it low to minimize charges for sessions dropped without a BYE for
some reason.  Without such a minimum, you might loose the benefit of
minimizing messaging option #3 gives us.  This idea would also apply
to timer values in the other options as well.

John Hearty
MCI Worldcom
Global Network Evolution

Date: Thu, 21 Jan 1999 12:12 -0600 (CST)
From: "Donovan, Steven R. (MCI)" <[email-masked]>
To: "'Jonathan Rosenberg'" <[email-masked]>,
    Henning Schulzrinne <[email-masked]>
CC: [email-masked],
    [email-masked],
    [email-masked]
Sender: [email-masked]
Subject: RE: Proxy Server Inconsistencies

It seems like there are three options for a SIP extension draft that would
address the problem of a stateful proxy being able to determine whether or
not sessions are still active.

1) Add a user agent based session keep alive message (I'm still involved in
this session).  The proxy would tear down the session if the keep alive was
not received within a predefined timer.  

2) Add a proxy based session ping message (Are you still involved in this
session).  The proxy would wait for a response to the ping request.  If no
response is received within a predefined time then the proxy would tear down
the session.

3) Adding a session expires parameter to the Invite.  The expires time could
be updated with a subsequent invite for the session.  The proxy would have
the ability to tear down the session when the session time has expired.
This would presumably be achieved by the proxy sending a BYE to both parties
involved in the call.  There may be the need for a maximum session expires
duration to prevent a user agent from specifying the year 2100 as the
expires time of a session.

All three approaches add to the complexity of the user agent and proxy,
however only marginally.

The third approach seems to minimize the amount of messaging required.

Based on those two criteria, the third option seems preferable.  Are there
other options and criteria that should be factored into the analysis?

Steve

> -----Original Message-----
> From: Jonathan Rosenberg [SMTP:[email-masked]]
> Sent: Wednesday, January 20, 1999 2:27 PM
> To:   Henning Schulzrinne
> Cc:   [email-masked]; [email-masked]; [email-masked]
> Subject:  Re: Proxy Server Inconsistancies
> 
> Henning Schulzrinne wrote:
> > 
> 
> > > I understand the point that a SIP keep alive would typically be
> redundant
> > > with media exchange, but I don't believe this is universally true.
> E.g.,
> > > suppose I want to monitor a sleeping infant, and I use a media
> encoding
> > > that doesn't transmit anything during periods of inactivity.  I can
> imagine
> > > other "shared presence" applications, where little media is exchanged,
> the
> > > point is in the potential.  I don't believe a media transport agent
> has any
> > > intrinsic "keep alive" responsibilities; it simply must insure that
> WHEN it
> > > is transmitting data, there is someone to receive it.  What needs to
> be
> > > "kept alive" (or, actually, allowed to time-out) is the "in
> conference"
> > > state.  I don't think we can assume that the desired liveliness of the
> "in
> > > conference" state is proportional to the liveliness of the media
> exchange.
> > >
> > > How about something like a DURATION or TTL parameter on the INVITE?
> So,
> > > the meaning would be something like "I invite you to be in conference
> with
> > > me for the next 4 minutes."  Re-INVITEs would need to be sent
> periodically
> > > to keep the conference going.  I have not got into the spec enough to
> > > understand all of the implications of this, but it seems
> straightforward in
> > > principle.
> > 
> > Note that the session description (at least for SDP) already has
> > duration information. INVITE does have an Expires header. See the
> > following text:
> > 
> > For {\INVITE} requests, it is a request and response-header field.  In a
> > request, the caller can limit the validity of an invitation, for
> > example, if a client wants to limit the time duration of a search or a
> > conference invitation.  A user interface {\MAY} take this as a hint to
> > leave the invitation window on the screen even if the user is not
> > currently at the workstation.  This also limits the duration of a
> > search.  If the request expires before the search completes, the proxy
> > returns a 408 (Request Timeout) status.  In a 302 (Moved Temporarily)
> > response, a server can advise the client of the maximal duration of the
> > redirection.
> 
> The Expires header is close but not the same thing we are talking about,
> though. Expires limits the duration of the invitation, not the session.
> Once the invitation is accepted, the Expires header has no meaning. 
> 
> -Jonathan R.
> -- 
> Jonathan D. Rosenberg                       Lucent Technologies
> Member of Technical Staff                   101 Crawfords Corner Rd.
> High Speed Networks Research                Holmdel, NJ 07733
> FAX: (732) 834-5379                         Rm. 4C-526
> EMAIL: [email-masked]
> URL: http://www.cs.columbia.edu/~jdrosen

---

From: [email-masked] (Adam B. Roach)
Date: Thu, 21 Jan 1999 18:50:33 -0600 (CST)

>From: John Hearty <[email-masked]>
>
>some reason.

It seems that handling billing at the session layer would be
somewhat problematic, anyway. As you point out, even a server-driven
solution requires a keep-alive or PING with a frequency representing 
the smallest billing unit; this might be somewhat onerous.

On the other hand, the media channel (assuming you are contemplating
billing for a voice call) is much better equipped for making billing
determinations (you know within the time it takes to send a few
media packets -- fractions of a second -- that the call is down). 

For other session types, billing for session duration makes less 
sense than e.g. charging for network resources or charging per 
transaction (in a model with potentially multilple transactions in
a session) -- information that won't necessarily be available to 
the session layer.

/a