Subject: Session timer

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 19 Jul 1999 15:19:16 +0300

Hi,

About the draft about session timer.
I think that it is a good idea. In a pre-paid call, the server could
tear down the connection when the user has run out of money... the
problem is how to do that.

In the draft, the proxy server sends BYE request. This sounds bad to me,
since in a race condition, one of the User Agents, could issue a request
with the same CSeq that the BYE generated by the proxy, and we would
have two messages with the same Cseq number that are completely
different.

It may be solved with Record-Route header... so, if all the traffic goes
through the proxy, it can take care of all the mess that its BYE can
trigger...

Anyway, I do not like proxies sending BYEs...

Comments?

Gonzalo
-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 31 18
FIN-02420 Jorvas          Email :  [email-masked]
Finland

---

From: Henry Sinnreich <[email-masked]>
Date: Tue, 20 Jul 1999 09:44:48 +0200

> Comments?
This is a hard problem and I believe we have to distinguish between SIP
gateway endpoints and SIP clients.
* In the gateway case, there are plenty of PSTN-like hooks for billing,
* In the client, one can use an encrypted and signed cookie as the DCS Group
does, though I believe we need a slighly different architecture has to be
used to accommodate a multi-provider environment. The information in the
cookie and the QoS minutes (if any) can be used for charging. This is a bit
hazy, but we need to develop a multi-provider solution that works equally
well for other, non-telephony services.

Henry

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Gonzalo Camarillo
> Sent: Monday, July 19, 1999 2:19 PM
> To: mmusic
> Cc: Ricky Project
> Subject: Session timer
>
>
> Hi,
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 19 Jul 1999 22:32:33 -0400

> through the proxy, it can take care of all the mess that its BYE can

No. The proxy can never generate a BYE in a system with any security. It
will fail authentication. In any case, the proxy cannot "force" the UA
to end the call if it doesn't want. The purpose of the session timer is
not for services like pre-paid calling cards, but merely as a heartbeat
timer for SIP sessions. When the keepalive is missed for some number of
intervals, the session is assumed dead, and a proxy (and UA) can safely
destroy state for the call. No BYE should be sent by any parties.

-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: Gonzalo Camarillo <[email-masked]>
Date: Tue, 20 Jul 1999 08:23:15 +0300

Hi Jonathan,

[email-masked] wrote:
> will fail authentication.

Another reason to add to the ones I said to try to avoid BYEs sent by a
proxy... ( as I said before it sounds like a bad idea)

> In any case, the proxy cannot "force" the UA
> to end the call if it doesn't want.

That was my feeling also... anyway, if I am in the middle of a
conversation and my pre-paid card is out of money, how can somebody
force me to stop speaking??

If nobody can, everybody is going to buy 0.20$ telephone cards, just
enough to begin the conversation :o)

> The purpose of the session timer is
> timer for SIP sessions.

For this purpose it should work fine...

Regards,

Gonzalo

> When the keepalive is missed for some number of

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 20 Jul 1999 09:47:52 -0400

> force me to stop speaking??

There are plenty of ways. The problem is that SIP is not necessarily the
right way. I view SIP as a transactional service, for establishing
sessions. Network servers provide a transactional service, as a result.
All they can do to enforce policy is block subsequent transactions. This
doesn't help tear down the call. Basically, a server can only refuse to
provide service for a service it actually provides. Thus, if you want to
stop people from talking - do it at the media layer. For example, here
are a few possibilities:

1. The calling card is for RSVP service. It allows a timed QoS session.
The card contains some token placed in RESV messages. The routers use
this token in COPS queries to determine the amount of time left on the
card that the reservation is valid for. When the calling card expires,
the routers revert to best effort service.

2. The calling card is for IP service. Its provided to a DHCP server,
which gives an IP address for a certain amount of time. After that time
has expired, the address is revoked. This is accomplished perhaps by
instructing a firewall to block all packets from that address. This kind
of service would be very useful at terminals in airports. You plug in
your laptop, give your "calling card number" and get an IP address for a
time.

3. The calling card is for gateway service. If a calling card is used
for a call through a gateway, the gateway simply ceases to provide
service when time runs out. This means the call is over.

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 20 Jul 1999 11:03:42 -0400

Jonathan Rosenberg wrote:

> your laptop, give your "calling card number" and get an IP address for a

Indeed, the Chicago airport apparently has such a wireless service
(minus the calling card) for WaveLAN cards. So does  the 300'
neighborhood of my home.

In addition, you'd have to make sure that the ARP server doesn't allow
somebody else to "steal" an IP address from a paying customer. A new
version of shoulder surfing...

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs