Subject: Basic problem with caller/callee asymmetry for telephony??

From: "Scott Petrack"<[email-masked]>
Date: Thu, 7 May 1998 15:08:13 +0200

SCOTT PETRACK @
                                 VOCALTEC
                             05/07/98 03:08 PM
               (Embedded image moved to file: PIC02484.PCX)

I believe that there may be a small hole in SIP for certain applications.
The fix is extremely simple, minor, and backward compatible. I am grateful
for a check.  (I am about to download the very latest working draft).

In the establishment of the session (aka call) , the caller uses a client
and the callee a server. Later, the caller can change session parameters by
sending a new SIP request. For example, the caller can send a BYE request
to end the call. But how can the _callee_ change the session parameters?
For example, how can the _callee_ signal the end of the session?

(It is not really enough just to have the callee stop sending RTP and send
an RTCP BYE. I am asking how the callee can request the end of the session.
This is very different. For example, this also contains an implicit request
to the caller to stop sending RTP).

In SIP, the caller does not need to have a SIP server running at all. It
just makes requests. So the callee has no place to send a BYE or any other
SIP request to the caller.

I have a simple backward compatible solution to this problem (if you agree
with me that it exists):

1. Allow an ACK  (request) to include a Location: header which contains the
address of a SIP server which can receive later requests about changing the
session.  (The server specified in this Location: field MUST know about the
ACK-ed session). In fact, it would best and simplest to allow Location:
fields in any request. The semantics of Location are now the same for
client and server -- The Location: field contains the address of a server
"owned" by the sender of the message, which is guaranteed to know about the
session described in the message.

2. As a default fallback, one could say that a callee MAY try to send a
later request to the last Via: line, which in principle contains the
address of the initiating SIP client. SIP clients that wish to allow
invitees to send change requests for the session MUST either include a
Location: header in the request (as above) or have a SIP server listening
on the default port (5060) at the address listed in the Via: header.

Please let me know if the problem does not exist or has a different
solution. I don't want to get into lots of conference control issues right
now, but for tightly controlled conferencing such as two party telephony
(sorry if you don't find this application interesting....) it should at
least be possible for either side to request the session to end, and more
generally, for either side to request a change in the session parameters by
issuing a new request. Luckily, we can do this with the simple addition
above.

Scott

Scott Petrack
VocalTec Communications Ltd.
[email-masked]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 07 May 1998 13:46:57 -0400

> SIP request to the caller.

I think you can solve your problem without any changes. For consistency,
lets denote the direction of the original INVITE request the "forward"
direction; requests which then flow from the callee back to the caller
are in the "reverse" direction. My assumption was that requests in the
reverse direction are sent to the address listed in the From: field of
the original forward request. Now, assume that this address is
[email-masked]. The SIP server sitting at vocaltec.com would route
calls for you to whatever entity has registered itself as being able to
receive calls for this address. This need not be the device which
originates calls; it can be some other server which "owns" this address,
as you suggest. Thus you can easily have a separate device for incoming
and outgoing calls without any additional changes to SIP. You
essentially place your "callback" address in the From field, which need
not be the address of the device initiating the call.

One disadvantage to doing it this way is that this reverse direction
transaction will need to flow through the vocaltec.com SIP server. Had a
Location: field been included in the original forward request, and first
reverse request could go directly to the final server. Of course, as the
response to the reverse request will contain a Location: field,
subsequent reverse requests can do directly. Thus, I see this
disadvantage as relatively minor.

> on the default port (5060) at the address listed in the Via: header.

I think the From field is the place you would look, not the Via (as
these may be hidden anyway).

-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: Igor Slepchin <[email-masked]>
Date: Thu, 07 May 1998 15:34:27 -0400

Jonathan Rosenberg wrote:
> <...>

In fact, draft-ietf-mmusic-sip-05.ps says that the original "forward"
INVITE may contain the Location field so this is not an issue (6.20):

   INVITE and  ACK requests MAY also contain  Location headers
   indicating the location the request is originating from.

        This allows the callee to send a  BYE directly to the
        caller instead of through a series of proxies. The  Via
        header is not sufficient since the desired address may be
        that of a proxy.

---
Igor Slepchin