[Sip] draft-kaplan-sip-info-use-cases-00 - more use cases?

"Elwell, John" <john.elwell@siemens.com> Wed, 09 January 2008 09:58 UTC

Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCXhT-0006AX-Vb; Wed, 09 Jan 2008 04:58:19 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1JCXhR-0006AR-Qu for sip-confirm+ok@megatron.ietf.org; Wed, 09 Jan 2008 04:58:17 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCXhR-0006AJ-HG for sip@ietf.org; Wed, 09 Jan 2008 04:58:17 -0500
Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCXhP-0003Y4-Oo for sip@ietf.org; Wed, 09 Jan 2008 04:58:17 -0500
Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0JUD0028JFP2X0@siemenscomms.co.uk> for sip@ietf.org; Wed, 09 Jan 2008 09:58:14 +0000 (GMT)
Date: Wed, 09 Jan 2008 09:58:14 +0000
From: "Elwell, John" <john.elwell@siemens.com>
To: Hadriel Kaplan <HKaplan@acmepacket.com>, IETF SIP List <sip@ietf.org>
Message-id: <0D5F89FAC29E2C41B98A6A762007F5D05494DD@GBNTHT12009MSX.gb002.siemens.net>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: quoted-printable
Thread-Topic: draft-kaplan-sip-info-use-cases-00 - more use cases?
thread-index: AchSpiZDCF97hFP6TcKuyYas45XMSw==
Content-class: urn:content-classes:message
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Cc:
Subject: [Sip] draft-kaplan-sip-info-use-cases-00 - more use cases?
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

Hadriel,

Some possible further use cases:

1. Along the same lines as 6.2/6.3/6.4 (vcard, user-icon, vcalendar), we
could also consider pictures, movie clips, audio clips, etc.. Of course,
we don't want to encourage sending anything too big along the signalling
path, so we would need to consider where to draw the line.

2. We already have the conference event package for obtaining conference
membership details. In many situations the conference focus is also the
source of such notifications, so the subscribe-initiated dialog
parallels the INVITE-initiate dialog, which is rather wasteful. It would
be great to subscribe as part of the INVITE transaction and receive
notifications along the INVITE-initiated dialog.

3. Concerning mobility, I like the suggestion in 6.8 (geo-location
information). Also, there may sometimes be intermediaries on the
signalling path (B2BUAs) that are involved in mobility in some way, and
these might be interested in movement-related notifications (e.g., a
dual mode device moving in or out of WLAN range).

4. The use of offer-answer to achieve hold-retrieve fails to give an
explicit indication of what is happening. An explicit indication of
things like hold, retrieve, microphone mute, speaker mute, camera
on/off, recorder on/off, etc. might be quite helpful. Of course, there
will normally be an offer-answer exchange at the same time, so inclusion
of the notification in a re-INVITE or UPDATE request might be more
useful than using INFO.

5. Concerning 6.7 (soft-key labels), a problem here is that the
notifying UA might not have knowledge of soft key availability at the
receiving UA. In certain closed environments (e.g., involving a UA and
its local voicemail server) it may work, but I am not sure it would work
well in general. Having said that, where it does work, perhaps other
parameters at the device can be controlled in this way, e.g., microphone
and speaker volume (especially if this control is based on say a web
interface, so the user is really controlling his/her own settings from
the web page rather than directly on the device).

6. When a B2BUA performs 3PCC there is plenty of scope for the UAs to
lose track of what is happening. For example, when a B2BUA holds,
retrieves, transfers calls, joins calls, pre-empts calls, etc., there is
currently no explicit information - only perhaps a re-INVITE request.
Thus it can be difficult to know how to interpret things like identity.
Say a UA receives a re-INVITE request with a new PAI, it might deduce
that something like call transfer has occurred. However, if it receives
a re-INVITE request without a PAI, does it mean the previous PAI is
still valid, or does it mean, following transfer, there is no longer any
identity available? Of course, INFO might not always be the most
appropriate method to use for such notification if an offer-answer
exchange is needed at the same time.

7. There might be some usages to do with interworking with TDM, e.g.,
advice of charge during a call, user-to-user information during a call.

John


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip