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

From: Cullen Jennings <[email-masked]>
Date: Sun, 22 Apr 2007 16:15:06 -0700

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.

It seems like the SIP URI for the device should be a GRUU.

It seems like you need to say what SLP services template-type for  
this to work.

I wonder how the MNC mode works with security such as say DTLS-SRTP  
given it is acting as a man in the middle.

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.

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.

I can't  really see how the SH mode will work without a require /  
supported 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
> [email-masked] mailing lists by 2007-05-10. Exceptionally,
> comments may be sent to [email-masked] 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf-announce

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

---

From: Ron Shacham <[email-masked]>
Date: Fri, 27 Apr 2007 13:07:55 -0400 (EDT)

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 <[email-masked]>
> Date: April 22, 2007 7:15:06 PM EDT
> To: [email-masked]
> Subject: Re: Last Call: draft-shacham-sipping-session-mobility
> (Session Initiation Protocol (SIP) Session Mobility) to
> Informational RFC
>
>
> 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

We could define this more fully.  How specifically should it be defined for
an Informational RFC?

> given it is acting as a man in the middle.

This is discussed in Section 9.2

> 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.

> 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 /

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.

> PS - I gave this a very quick skim so I apologize if I
> misunderstood thing.
>
>
>> final comments on this action.  Please send substantive comments
>> to the