Hi John,
yes, we have had this discussion a few times already. On one side there
are people that think that most terminals will implement 3pcc and that
3pcc would resolve everything. On the other side there are people that
think that most terminals will not implement 3pcc (how many terminals
support it nowadays anyway?) and that a simpler mechanism such a header
field would achieve a much wider deployment, even if it requires support
from both the caller and the callee.
Note that 3pcc do not address the cases where the original terminal
(i.e., the controller) leave the session because in 3pcc the session
cannot continue without the controller.
Regarding what is better, a complicated mechanism that can be deployed
without support from the remote user agent or a simpler mechanism that
requires support from all user agents, it depends on the deployment
scenario. In scenarios where there are enough incentives for parties to
implement the mechanism, the latter option may be a good choice. Note
that every time we define a new header field in SIP we are using the
second option.
Cheers,
Gonzalo
Elwell, John wrote:
I still don't buy the media session correlation part of this in section
2.
In 2.1, the statement "Two SIP dialogs will be established: one between
the desk phone and
Bob's UA and one between the soft client and Bob's UA." is of
concern.
There is nothing in the prior description of the use case to say that
there must be two SIP dialogs.
In 2.2, the statement "A SIP dialog between Bob's IP-TV device and
Laura's UA needs to be
established." is of concern.
It does not necessarily follow from the prior description of the use
case that a separate dialog needs to be established.
In 2.3, the statement "A SIP dialog between Bob's PC and Laura's
multimedia phone needs to
be established." is of concern.
It does not necessarily follow from the prior description of the use
case that a separate dialog needs to be established.
In 2.4, the statement "That is, Bob wants Laura to treat both streams
as if both had been established using a single SIP dialog." is of
concern.
There is nothing in the prior description of the use case to state that
it is not a single SIP dialog.
In 2.5, the statement "A SIP dialog between Bob's webcam
phone at this summer cottage and Laura's multimedia phone needs to be
established." is of concern.
This does not necessarily follow from the prior description of the use
case.
In 2.6, the statement "Two SIP dialogs need to be established:
one between Bob's UA and Laura's desk phone and one between Bob's UA
and Laura's multimedia phone." is of concern.
This does not follow from the prior description of the use case.
Consequently I am not convinced that "REQ1 It must be possible to
correlate an already existing dialog or
dialogs with a new dialog or dialogs as relating to the same media
session."
is requirement we need to address.
I agree that handling different media within a session on different
devices on the calling side and/or the called side is an interesting
scenario. However, I believe one of the requirements is as follows:
"REQx: It must be possible for a user participating in a multi-media
session to use different devices for different media, without requiring
any special support at the peer UA, other than the need to support
different remote IP addresses for different media."
Otherwise users want to use different devices in this way would be
dependent on special support at peer multimedia devices.
John
-----Original Message-----
From: i-d-announce-bounces@xxxxxxxx
[mailto:i-d-announce-bounces@xxxxxxxx] On Behalf Of
Internet-Drafts@xxxxxxxx
Sent: 06 March 2009 07:15
To: i-d-announce@xxxxxxxx
Subject: I-D
Action:draft-loreto-sipping-context-id-requirements-02.txt
A New Internet-Draft is available from the on-line
Internet-Drafts directories.
Title : Requirements for Dialog Correlation
in the Session Initiation Protocol (SIP)
Author(s) : G. Camarillo, S. Loreto
Filename :
draft-loreto-sipping-context-id-requirements-02.txt
Pages : 10
Date : 2009-03-05
This document justifies the need and lists the requirements for
correlating SIP (Session Initiation Protocol) dialogs. The
correlated dialogs may or may not be related to the same multimedia
session. Being able to logically correlate multiple SIP dialogs is
useful for applications that, for different reasons, need to
establish several SIP dialogs to provide a given service. The
logical correlation of two SIP dialogs is also useful, for instance,
to correlate an incoming with an outgoing dialog at a B2BUA.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-loreto-sipping-conte
xt-id-requirements-02.txt
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
