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

"Dean Willis" <Dean.Willis@MCI.COM> Tue, 23 February 1999 17:17 UTC

Return-Path: <owner-confctrl>
Received: (from majordom@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id JAA17956 for confctrl-outgoing; Tue, 23 Feb 1999 09:17:25 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id JAA17951 for <confctrl@zephyr.isi.edu>; Tue, 23 Feb 1999 09:17:24 -0800 (PST)
Received: from ndcrelay.mcit.com (ndcrelay.mcit.com [166.37.172.49]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA14949 for <confctrl@ISI.EDU>; Tue, 23 Feb 1999 09:17:23 -0800 (PST)
Received: from omss5.mcit.com (omss5.mcit.com [166.37.210.27]) by ndcrelay.mcit.com (8.8.7/) with ESMTP id RAA16684 for <confctrl@ISI.EDU>; Tue, 23 Feb 1999 17:16:33 GMT
Received: from dwillispc3 ([166.35.227.103]) by omss5.mcit.com (InterMail v03.02.05 118 120) with SMTP id <19990223171652.CKA10255@[166.35.227.103]> for <confctrl@ISI.EDU>; Tue, 23 Feb 1999 11:16:52 -0600
From: Dean Willis <Dean.Willis@MCI.COM>
To: confctrl@ISI.EDU
Subject: RE: draft-ietf-mmusic-sip-session-timer-00.txt
Date: Tue, 23 Feb 1999 11:16:25 -0600
Message-ID: <000601be5f50$3e253200$67e323a6@dwillispc3.mcit.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-reply-to: <36D2B626.DE1022AB@cs.columbia.edu>
X-Mimeole: Produced By Microsoft MimeOLE V4.72.3155.0
Importance: Normal
Sender: owner-confctrl@zephyr.isi.edu
Precedence: bulk

Henning said:
> Aishling wrote:
> >
> > >
> > > 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
> >
> > Do clients not only issue requests, I didn't realise they
> could accept
> > requests???
>
> 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...


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