Session Initiation Protocol (SIP) Session Mobility
draft-shacham-sipping-session-mobility-05

[Ballot discuss]
This is an overall good document, a very much needed function
and I support its publication. However, there are a few issues
below that call for changes and/or better characterization of
the limitations of the proposal.

> Stationary IP
> multimedia endpoints, including hardware IP phones, videoconferencing
> units, embedded devices and software phones allow more convenience of
> use, but are not mobile.  Moving active multimedia sessions between
> these devices allows mobile and stationary devices to be used
> concurrently or interchangeably in mid-session, combining their
> advantages into a single "virtual device." Since the Session
> Initiation Protocol (SIP) [1] has been chosen by the Third Generation
> Partnership Project (3GPP) as its standard for session establishment
> in the Internet Multimedia Subsystem (IMS) [17] and it is being
> deployed in hardware and software IP multimedia clients, it is
> helpful to specify an architecture to provide this ubiquitous service
> using SIP.

Is this proposal a part of the 3GPP architecture? I was not
aware of it and its also not on the dependency list. If not,
please reword the above to avoid misunderstanding that this
is a part of the 3GPP architecture.

> While having a global infrastructure for discovering devices or other
> services in any location would be desirable, nothing of this sort is
> currently deployed or standardized.  However, this document assumes
> that such an infrastructure is unnecessary for discovering devices
> that are in close proximity, such as the same room.  It is possible
> for such devices to be discovered through direct communication over a
> short-range wireless protocol such as Bluetooth SDP.  Two other
> categories of service discovery protocols may be used, assuming that
> devices that are physically close to each other are also within the
> same network and/or part of the same DNS domain.  Multicast-based
> protocols, such as SLP [18] (in its serverless mode) or Bonjour
> (mDNS-SD [34]) may be used as long as the mobile node is within the
> same subnet as the local devices.  When devices are part of the same
> DNS domain, server-mode SLP or non-multicast DNS Service Discovery
> (DNS-SD) [33] are possible solutions.  Such protocols can discover
> devices within a larger geographical area, and have the advantage
> over the first category in that they allow for the discovery of
> devices at different location granularities, such as at the room or
> building level, and in locations other than the current one.  In
> order to discovery devices in a specific location, location
> attributes, such as room number, must be used in the search e.g., as
> service attributes in SLP or a domain name in DNS-SD).  The mobile
> device must ascertain its location in order to perform this search.

I like the scoping of the document, i.e., you should not be the
one to solve the service location and discovery parts. However,
in fairness to readers, it you should also explain the fact that
many of the above techniques have difficulties in practical
application. For instance, wireless networks are often run
with point-to-point links where the different devices are not
in the same subnet. And more often than not, different networks
(e.g., Wireless LAN, 3G, Wimax) are deployed by completely
separate organizations, which makes having a common DNS or
server setups hard.

Please add some text about this.

> The following is an excerpt from that document:
>
>  ... However, there is no cryptographic means that can
>  prevent the controller from interfering with the initial exchanges
>  of keying materials.  As a result, it is trivially possibly for
>  the controller to insert itself as an intermediary on the media
>  exchange, if it should so desire.
>
> We note here that given the model presented in this document, where
> the controller is operated by the same person that uses the local
> device, there is even more reason to believe that the controller will
> be well-behaved and will not interfere with the transfer of key
> exchanges.

The quoted text seems incorrect. If an authenticated
end-to-end key exchange (such as MIKEY within SIP/SDP)
or DTLS is run between the parties, no inappropriate
third parties can be inserted, and the end points are
always aware of the identity of the other end point that
they are sending SRTP to.

> 9.1. Authorization for Using Local Devices

The document contains a number of flows where two SIP end
devices talk to each other. I do not understand how this
is secured. Mere claims of having a particular identity
appear insufficient for this.

The trait-based authorization scheme may be better; I did
not read that reference. However, the document only
recommends it for public devices.

> 9. Security Considerations

The document has a number of flows where one device instructs
another one to start a RTP flow to a third one. How does
one ensure that this does not lead to a flooding attack,
if the first device fraudulently claims the third one desires
to have the stream?

[Ballot discuss]
> Stationary IP
> multimedia endpoints, including hardware IP phones, videoconferencing
> units, embedded devices and software phones allow more convenience of
> use, but are not mobile.  Moving active multimedia sessions between
> these devices allows mobile and stationary devices to be used
> concurrently or interchangeably in mid-session, combining their
> advantages into a single "virtual device." Since the Session
> Initiation Protocol (SIP) [1] has been chosen by the Third Generation
> Partnership Project (3GPP) as its standard for session establishment
> in the Internet Multimedia Subsystem (IMS) [17] and it is being
> deployed in hardware and software IP multimedia clients, it is
> helpful to specify an architecture to provide this ubiquitous service
> using SIP.

Is this proposal a part of the 3GPP architecture? I was not
aware of it and its also not on the dependency list. If not,
please reword the above to avoid misunderstanding that this
is a part of the 3GPP architecture.

> While having a global infrastructure for discovering devices or other
> services in any location would be desirable, nothing of this sort is
> currently deployed or standardized.  However, this document assumes
> that such an infrastructure is unnecessary for discovering devices
> that are in close proximity, such as the same room.  It is possible
> for such devices to be discovered through direct communication over a
> short-range wireless protocol such as Bluetooth SDP.  Two other
> categories of service discovery protocols may be used, assuming that
> devices that are physically close to each other are also within the
> same network and/or part of the same DNS domain.  Multicast-based
> protocols, such as SLP [18] (in its serverless mode) or Bonjour
> (mDNS-SD [34]) may be used as long as the mobile node is within the
> same subnet as the local devices.  When devices are part of the same
> DNS domain, server-mode SLP or non-multicast DNS Service Discovery
> (DNS-SD) [33] are possible solutions.  Such protocols can discover
> devices within a larger geographical area, and have the advantage
> over the first category in that they allow for the discovery of
> devices at different location granularities, such as at the room or
> building level, and in locations other than the current one.  In
> order to discovery devices in a specific location, location
> attributes, such as room number, must be used in the search e.g., as
> service attributes in SLP or a domain name in DNS-SD).  The mobile
> device must ascertain its location in order to perform this search.

I like the scoping of the document, i.e., you should not be the
one to solve the service location and discovery parts. However,
in fairness to readers, it you should also explain the fact that
many of the above techniques have difficulties in practical
application. For instance, wireless networks are often run
with point-to-point links where the different devices are not
in the same subnet. And more often than not, different networks
(e.g., Wireless LAN, 3G, Wimax) are deployed by completely
separate organizations, which makes having a common DNS or
server setups hard.

Please add some text about this.

[Ballot discuss]
I interpreted this document differently from other ADs (based on other stated ballot positions).

I thought the whole point was that the tools for Session Mobility are already present in SIP, SLP,
and other related protocols.  In fact, there may be a variety of choices.  I thought this document
was identifying the mechanisms and modes that should be preferred when implementing SIP
Session Mobility.  I notice other ADs interpreting this as a roadmap for future work, or
establishing new conformance requirements.

The language needs to be sharpened before this should go forward.

[Ballot comment]
As Sam noted, the liberal use of "must" and "should" is confusing. The word "must" seems to
describe critical functional requirements.  The word "should" seems to identify important
functional requirements in some cases, but in other cases it mens preferred options where
multiple mechanisms are expected to be available.

For example, section 6.1 opens with
  "Before executing a session transfer, the device must check the
  capabilities of the CN and the new device."
I interpert this as a critical functional requirement - if the device blindly transfers a session
codec differences may cause a failure - that is not enforced by the protocols themselves.
That is, SIP and SLP will not enforce this requirement (although they can be used to implement
this requirement.)

The last sentence in the first paragraph of 6.1 uses "should" to identify preferred mechanisms:

  Since the OPTIONS method is standard, it should be used
  to query the CN, while SLP should be used to get the media
  capabilities of local devices, since it is already being used for
  them.

I interpereted this sentence to say "OPTIONS" is mandatory to implement for SIP, and the CN
supports SIP (or it wouldn't be SIP session mobility!),  so this mechanism is the appropriate
one for interrogating the CN.  SLP is already in use for local device discovery and supports
device capability discovery, so it is the preferred solution for these devices.

However, section 6.2 seems to identify a functional requirement:

  "Other differences in device capabilities, such as display resolution
  and bandwidth limitations, should also be reconciled during transfer."

I generally recommend limiting the use of must and should in non-2119 contexts.  This isn't
a hard rule, but it usually increases teh document clarity.

[Ballot comment]
As Sam noted, the liberal use of "must" and "should" is confusing. The word "must" seems to
describe critical functional requirements.  The word "should" seems to identify important
functional requirements in some cases, but in other cases it mens preferred options where
multiple mechanisms are expected to be available.

For example, section 6.1 opens with
  "Before executing a session transfer, the device must check the
  capabilities of the CN and the new device."
I interpert this as a critical functional requirement - if the device blindly transfers a session
codec differences may cause a failure - that is not enforced by the protocols themselves.
That is, SIP and SLP will not enforce this requirement (although they can be used to implement
this requirement.)

The last sentence in the first paragraph of 6.1 uses "should" to identify preferred mechanisms:

  Since the OPTIONS method is standard, it should be used
  to query the CN, while SLP should be used to get the media
  capabilities of local devices, since it is already being used for
  them.

I interpereted this sentence to say "OPTIONS" is mandatory to implement for SIP, and the CN supports SIP (or it wouldn't be SIP session mobility!),  so this mechanism is the appropriate
one for interrogating the CN.  SLP is already in use for local device discovery and supports
device capability discovery, so it is the preferred solution for these devices.

However, section 6.2 seems to identify a functional requirement:

  "Other differences in device capabilities, such as display resolution
  and bandwidth limitations, should also be reconciled during transfer."

I generally recommend limiting the use of must and should in non-2119 contexts.  This isn't
a hard rule, but it usually increases teh document clarity.

[Ballot comment]
As Sam noted, the liberal use of "must" and "should" is confusing. The word "must" seems to
describe critical functional requirements.  The word "should" seems to identify important
functional requirements in some cases, but in other cases it mens preferred options where
multiple mechanisms are expected to be available.

For example, section 6.1 opens with
  "Before executing a session transfer, the device must check the
  capabilities of the CN and the new device."
I interpert this as a critical functional requirement - if the device blindly transfers a session
codec differences may cause a failure - that is not enforced by the protocols themselves.  That
is, SIP and SLP will not enforce this requirement (although they can be used to implement
this requirement.)

The last sentence in the first paragraph of 6.1 uses "should" to identify preferred mechanisms:
  Since the OPTIONS method is standard, it should be used
  to query the CN, while SLP should be used to get the media
  capabilities of local devices, since it is already being used for
  them.

I interpereted this sentence to say "OPTIONS" is mandatory to implement for SIP, and the CN supports SIP (or it wouldn't be SIP session mobility!),  so this mechanism is the appropriate
one for interrogating the CN.  SLP is already in use for local device discovery and supports
device capability discovery, so it is the preferred solution for these devices.

However, section 6.2 seems to identify a functional requirement:

  "Other differences in device capabilities, such as display resolution
  and bandwidth limitations, should also be reconciled during transfer."

I generally recommend limiting the use of must and should in non-2119 contexts.  This isn't
a hard rule, but it usually increases teh document clarity.

[Ballot discuss]
This is a DISCUSS discuss...

I interpreted this document differently from other ADs (based on other stated ballot positions).

I thought the whole point was that the tools for Session Mobility are already present in SIP, SLP,
and other related protocols.  In fact, there may be a variety of choices.  I thought this document
was identifying the mechanisms and modes that should be preferred when implementing SIP
Session Mobility.  I notice other ADs interpreting this as a roadmap for future work, or
establishing new conformance requirements.

The language needs to be sharpened before this should go forward.

[Ballot comment]
As Sam noted, the liberal use of "must" and "should" is confusing. The word "must" seems to
describe critical functional requirements.  The word "should" seems to identify important
functional requirements in some cases, but in other cases it mens preferred options where
multiple mechanisms are expected to be available.

For example, section 6.1 opens with
  "Before executing a session transfer, the device must check the
  capabilities of the CN and the new device."
I interpert this as an important functional requirement - if the device blindly transfers a session
codec differences may cause a failure - that is not enforced by the protocols themselves.  That
is, SIP and SLP will not enforce this requirement (although they can be used to implement
this requirement.)

The last sentence in the first paragraph of 6.1 uses "should" to identify preferred mechanisms:
  Since the OPTIONS method is standard, it should be used
  to query the CN, while SLP should be used to get the media
  capabilities of local devices, since it is already being used for
  them.

I interpereted this sentence to say "OPTIONS" is mandatory to implement for SIP, and the CN supports SIP (or it wouldn't be SIP session mobility!),  so this mechanism is the appropriate
one for interrogating the CN.  SLP is already in use for local device discovery and supports
device capability discovery, so it is the preferred solution for these devices.

However, section 6.2 seems to identify a functional requirement:

  "Other differences in device capabilities, such as display resolution
  and bandwidth limitations, should also be reconciled during transfer."

I generally recommend limiting the use of must and should in non-2119 contexts.  This isn't
a hard rule, but it usually increases teh document clarity.

[Ballot discuss]
This is a DISCUSS discuss...

I interpreted this document differently from other ADs (based on other stated ballot positions).

I thought the whole point was that the tools for Session Mobility are already present in SIP, SLP, and other related protocols.  In fact, there may be a variety of choices.  I thought this document was identifying the mechanisms and modes that should be preferred when implementing SIP
Session Mobility.  I notice other ADs interpreting this as a roadmap for future work, or
establishing new conformance requirements.

The language needs to be sharpened before this should go forward.

[Ballot comment]
As Sam noted, the liberal use of "must" and "should" is confusing.  In some cases, I interpreted
these key words as
references to mandatory behavior of SIP and SLP implementations, or preferred options where
multiple mechanisms are expected to be available.

as in

or preferred options as in section 6.1:

  Since the OPTIONS method is standard, it should be used
  to query the CN, while SLP should be used to get the media
  capabilities of local devices, since it is already being used for
  them.

[Ballot discuss]
This is a DISCUSS discuss...

I interpreted this document differently from other ADs (based on other stated ballot positions).

I thought the whole point was that the tools for Session Mobility are already present in SIP, SLP, and other related protocols.  In fact, there may be a variety of choices.  I thought this document was identifying the mechanisms and modes that should be preferred when implementing SIP
Session Mobility.  I notice other ADs interprerting this as a roadmap for future work, or
establishing new conformance requirements.

The language needs to be sharpened before this should go forward.

[Ballot discuss]
To me this document presents a sketch of how things can be done. However, as it is only a sketch there are a number of missing details that results in issues. I found a number of them only in the media handling part that would in some cases require substantial work to get things to work correctly in the general architecture. The issue with this is that for example the abstract and the introduction do not correctly present the real scope of the document as being a suggestion for future direction, rather than a specific solution. I would like to have a clarification on the scope in the document.

[Ballot comment]
I was disappointed that section 9 didn't discuss future directions for
DTLS SRTP keying.  Given the complexity of this spec, I think that
DTLS SRTP may well be in use by the time this is deployed.


Section 9 talks about the use of S/MIME to secure the crypto
attribute.  I'm not sure that actually works well with the rest of the
spec.  In particular, it seems that thee MN needs to stitch together a
bunch of SDP and that would be incompatible with the SDP being
encrypted.  I'd hold a discuss on this if I thought there was any
danger of someone trying to use S/MIME for this application.  I think

a discussion of how extensions to SDP (new attributes) interacts with
the spec is important.  What does the MN need to do when using 3pcc
when it sees a SDP attribute it does not understand?
Will this use of 3PCC make it harder to deploy new SDP attributes?

[Ballot discuss]
I'm trying to understand the consensus and status of this document.
It's not clear to me whether this document describes a protocol or
whether it describes how to use existing protocols.  There are a lot
of MUST statements but I'm not sure if they are normative requirements
on implementations of this or simply facts that fall out of using
other protocols correctly.  In particular, I'm having trouble figuring
out whether this is a protocol that failed to reach sufficient consensus  to be standards track or whether this is an informational document potentially with reasonably broad consensus.
I think an explanation of this would help the reader.

[Ballot discuss]
> Since the Session
> Initiation Protocol (SIP) [1] has been chosen by the Third Generation
> Partnership Project (3GPP) as its standard for session establishment
> in the Internet Multimedia Subsystem (IMS) [17] and it is being
> deployed in hardware and software IP multimedia clients, it is
> helpful to specify an architecture to provide this ubiquitous service
> using SIP.

Is this proposal a part of the 3GPP architecture? I was not
aware of it and its also not on the dependency list. If not,
please reword the above to avoid misunderstanding that this
is a part of the 3GPP architecture.

MDIR review from Pete McCann:

This draft specifies an architecture and call flows for
moving media flows among a collection of devices.  It
should be noted that this is distinct from the problem
of network mobility and is complementary to any given
network mobility scheme such as Mobile IP.  The draft
defines mechanisms for discovering local devices, and
gives SIP call flows for moving media streams to different
devices using only standard SIP behavior on correspondent
nodes (CNs) and the local devices but under the control
of one or more mobility-enhanced devices.

One thing that troubles me is the use of the Service
Location Protocol for discovery of local devices.  I
think it is quite likely that different devices in the
same room will be served by very different ISPs, such
as a 3G wide-area wireless cellphone and a wired PC
sitting on a desk.  The draft seems to require a common
SLP server with which all devices are registered along
with their location information.  Assuming the goal
of ubiquitous communication as given in reference [27]
is accomplished with different administrative domains,
how would a 3G wireless phone figure out which SLP server
to send a query to?  Maybe the SLP server is administered
by the user himself and knows about all the devices that
the user may encounter a priori.  However, this seems
to limit the scalability of the approach.  Unless there
is some sort of global infrastructure that maps a user's
location to a unique SLP server, this seems like a hard
problem to solve.  An effort to deploy such an infrastructure
seems to be on the same scale as deploying a new DNS, with
the added complexity that administrative boundaries must
coincide with geographical locations.

The draft defines two modes for session transfer, one where
the MN stays in control of the SIP session using 3rd party
call control and the other which uses REFER to take the MN
out of the session completely.  In each mode, the draft
also gives mechanisms for "retrieval" of a session back to
the MN.  I am not qualified to completely evaluate the SIP
call flows but they appear to be correct.