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

From: [email-masked] (Patrice Calhoun)
Date: Thu, 11 Feb 1999 11:02:08 -0800

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 11 Feb 1999 16:49:26 -0500

> bypassing the SIP Server (this is where I am unclear).

Slight correction - ACK goes from caller to callee.

But, in general, you are right. RTP bypasses the SIP servers.

> deploy a service and still maintain some control over the sessions.

This is an excellent, excellent point, and is something I have been
considering since the whole timeout/DTMF/INFO issues came up. The
question you ask gets back to a more basic problem. Since, unlike
traditional telephony, voice does not flow through the servers
(gatekeepers or SIP servers or MXCP call agents) in Internet telephony,
any sort of "control" a server would like to execute is based on an
assumption that the user agents (the ones sending/receiving the media)
would obey the servers. Consider the example of call transfer. Lets say
we'd like to signal the service using DTMF, so a proxy subscribes to the
DTMF from the client. The client presses the appropriate buttons on the
phone, and the proxy decides to transfer. But, the media doesn't flow
through the proxy, so it has no way of actually transferring the call.
Rather, it will need to go back and tell the user agent to perform the
transfer, since only the user agent can affect where the media goes to.
In that case, why would the UA ask the network for the service in the
first place?  It can simply be invoked directly by the client. In a
network where voice transport is end to end, services based on changing
characteristics of that transport (coding, destination, etc), must also
be end to end. 

Now, if the action the proxy asks to user to take is something the user
wants to do anyway, maybe thats OK. But, if its something less
cooperative, like forcing a hangup, or transferring to an operator,
there is simply no incentive for the user to accept this. 

-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: Douglas Clowes <[email-masked]>
Date: Fri, 12 Feb 1999 11:01:25 +1100

>> deploy a service and still maintain some control over the sessions.

One wonders about the nature of the service you think to deploy. Where you
want to maintain session control without control of at least one enpoint.

>question you ask gets back to a more basic problem.

>Since, unlike
>would obey the servers.

Indeed, in traditional telephony (at least the SS7 kind), voice does not
flow through the control points. Control is maintained by having voice
nodes that obey control nodes.

In H.323 gatekeepers, the gatekeeper may route the control channels between
the endpoints, and issue termination commands in each direction, on those
channels. A gatekeeper may route the media through itself (although this is
unlikely), or another entity. What you wouldchoose to do would depend on
your trust of the level of control you exert on the endpoints, and the
consequences of any lack of control.

If you don't trust either endpoint, but must control the media session, or
conceal the endpoints from each other, you may have to route the media
through a Meter Box (tm), that you can trust. There are gateways that
transcode media (G.711 to G.723.1 for example) and a similar mechanism,
without transcoding, could be deployed.

> Consider the example of call transfer. Lets say
>---------
>This message came from the IETF IPTEL Working Group Mailing List.
>

Douglas

---

From: Aishling <[email-masked]>
Date: Tue, 23 Feb 1999 12:50:18 +0000 (GMT)

> which in turn forwards the request to a target SIP Client (or some GW or some

Do clients not only issue requests, I didn't realise they could accept
requests???

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 23 Feb 1999 09:07:34 -0500

> Do clients not only issue requests, I didn't realise they could accept

Because it sounds strange to some to talk about clients accepting
requests, the SIP spec uses the terms UAC and UAS (user agent client and
server). However, this is obviously more awkward than just saying
"client". Just do the mental substitution...

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

---

From: "Dean Willis" <[email-masked]>
Date: Tue, 23 Feb 1999 11:16:25 -0600

> "client". Just do the mental substitution...

Even more confusing to me is that UAC and UAS seem to be "roles" in a
particular call sequence based on who sent the INVITE and who received
it . . . maybe there is some meat to the megaco edgepoint argument.

In local discussions, it seems to me that "client" has come to mean an
end-or-edgepont (i.e., a phone appliance, PC soft phone, or gateway) and
"server" has come to mean an intermediary or midpoint device, such as a
redirect or proxy server, or a firewall proxy, or an application device
such as an IVR unit . . . . This is rather different from the spec, and
is most confusing.

>From page 8 and 9 of draft 12:

"Client: An application program that sends SIP requests. Clients may or
may not interact directly with a
human user. User agents and proxies contain clients (and servers)."

"Server: A server is an application program that accepts requests in
order to service requests and sends back
responses to those requests. Servers are either proxy, redirect or user
agent servers or registrars."

"User agent client (UAC), calling user agent: A user agent client is a
client application that initiates the
SIP request."

"User agent server (UAS), called user agent: A user agent server is a
server application that contacts the
user when a SIP request is received and that returns a response on
behalf of the user. The response
accepts, rejects or redirects the request."

So, in order to answer a call, a "client" (as commonly used) receives
and OKs an INVITE, therefore acting as a "user agent server" from a SIP
perspective.

It seems to me we need a phrase to refer to a SIP end-or-edgepoint that
does not conflict with the "client" and "server" role definitions.
Suggestions? I considered "user agent", but to many people that implies
something like a user location server capable of making intelligent call
routing decisions.

--
Dean

---

From: Mark Handley <[email-masked]>
Date: Tue, 23 Feb 1999 09:44:22 -0800

>something like a user location server capable of making intelligent call

"SIP User Agent" is the term we intended for a SIP endpoint node.  If
it's a gateway into or from a non-SIP cloud, it's still a "SIP User
Agent" if it originates or terminates SIP calls. 

In the gateway context we do have to be careful to specify "SIP User
Agent" and not just "User Agent" though, because whatever it's
gatewaying into might have it's own concept of what user agent means.

Cheers,
	Mark

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 23 Feb 1999 14:01:56 -0500

Dean Willis wrote:

> something like a user location server capable of making intelligent call

"User agent" is borrowed from HTTP, where it says

user agent
     The client which initiates a request. These are often browsers,
     editors, spiders (web-traversing robots), or other end user tools.

(HTTP doesn't have the problem of user agents being the recipient of
requests.)

"SIP End system" or "SIP CPE?" :-)

---

From: Scott Petrack <[email-masked]>
Date: Thu, 25 Feb 1999 00:00:06 -0500

I found Mark's language is extremely clear --  if other people want to
confuse themselves and others with imprecise language, that is their right,
but it does not help anyone's understanding.

SIP is a client/server protocol. That means that there are clients and
servers and that the two functions are distinct. A client send a request
which invite a server to join a session. The server responds to these requests.

This seems strange at first sight to many telephone people, because they
imagine that it is the same machine which acts as client (i.e. originates
calls) and server (i.e. answers calls). Of course, nothing prevents a
single machine from acting as both client and server, but this is an
implementation. Within SIP, the Contact: header is used to indicate within
a client request the URL of an "associated" SIP server.

Anyone who calls a SIP user agent server a "client" just because it somehow
reminds one of a telephone is making a simple technical mistake which is
likely to lead to misunderstanding, I believe.

Scott