Cullen,
Thanks for your comments. Please find my responses below.
We plan to submit an updated draft reflecting some of these
issues.
Regards,
Ron
Begin forwarded message:
From: Cullen Jennings <fluffy(_at_)cisco(_dot_)com>
Date: April 22, 2007 7:15:06 PM EDT
To: ietf(_at_)ietf(_dot_)org
Subject: Re: Last Call: draft-shacham-sipping-session-mobility
(Session Initiation Protocol (SIP) Session Mobility) to
Informational RFC
As far as I can tell, there are three people that have posted an
email abut this document in and some of theses got back to early
2005. I don't think this document has received adequate review from
the SIP community.
It seems like the SH mode is preferable to the MMC mode in general
because it allows the call to transfer to a device that does not
have the limitations of the MN - and often that is why it was
transfered in the first place. For example. if the MN did not
understand video but the user wanted to transfer the call to a
video phone.
I'm not sure I understand. MNC mode can also be used to transfer to devices
with capabilities that the MN doesn't support natively. The only difference
is whether the session control is retained by the MN.
It seems like the SIP URI for the device should be a GRUU.
We agree on this and we'll update accordingly.
It seems like you need to say what SLP services template-type for
this to work.
We could define this more fully. How specifically should it be defined for
an Informational RFC?
I wonder how the MNC mode works with security such as say DTLS-SRTP
given it is acting as a man in the middle.
This is discussed in Section 9.2
When transferring to multiple devices, I think that devices today
don't actually support this (as the document points out in first
para of section 5.3.3) - I think that an option tag is needed to
indicate support for this.
Are you referring to the SH mode that transfers the session to multiple
devices? I don't see why this should require a special new option tag.
The SLP entry associated with the composite device's URI (the URI
representing the "virtual" peering of multiple devices) will indicate
all media supported by the device. The initial REFER request sent to the
device treats the local device as a black box in terms of whether it will
support all media natively or invite another device to handle some of it.
The MN doesn't need to know this through an option tag.
I'm not sure that the OPTION message is required to return all the
codec a device can support - for one thing that often dynamically
changes depending on what else is going on in video devices.
This query should be done immediately before the session transfer.
In fact, it is preferable for the response to include only currently
available capabilities. We should discuss this in more detail.
I can't really see how the SH mode will work without a require /
supported tag.
The single device SH mode shouldn't require any new option tags.
The device must support "replaces", for example. I mentioned before why I
don't think the multi-device case requires a new tag.
Cullen < with my individual hat on>
PS - I gave this a very quick skim so I apologize if I
misunderstood thing.
On Apr 12, 2007, at 8:14 AM, The IESG wrote:
The IESG has received a request from an individual submitter to
consider
the following document:
- 'Session Initiation Protocol (SIP) Session Mobility '
<draft-shacham-sipping-session-mobility-03.txt> as an
Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments
to the
ietf(_at_)ietf(_dot_)org mailing lists by 2007-05-10. Exceptionally,
comments may be sent to iesg(_at_)ietf(_dot_)org instead. In either case,
please
retain the beginning of the Subject line to allow automated sorting.
The file can be obtained via
http://www.ietf.org/internet-drafts/draft-shacham-sipping-session-
mobility-03.txt
IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?
command=view_id&dTag=12922&rfc_flag=0
_______________________________________________
IETF-Announce mailing list
IETF-Announce(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf-announce
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf