Re: Fwd: Last Call: draft-shacham-sipping-session-mobility (Session Initiation Protocol (SIP) Session Mobility) to Informational RFC

[Ron Shacham <[e-mail]>]

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 <[e-mail]>
> Date: April 22, 2007 7:15:06 PM EDT
> To: [e-mail]
> 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
>> [e-mail] mailing lists by 2007-05-10. Exceptionally,
>> comments may be sent to [e-mail] 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
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/ietf-announce
>
> _______________________________________________
> Ietf mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ietf



_______________________________________________
Ietf mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf