Notes on SIP Session 2 at IETF 63
Reported by Adam Roach
SIP 08/02/2005 @ 1400 - 1615
============================
Refer: Feature Tags (Orit Levin)
--------------------------------
- Topic of discussion: Which feature tags do we want to include
in the REFER? Does the referer include all features it knows
about? Only the ones that it thinks are relevant for the call?
- Paul Kyzivat: Allowing the referer to pick which features
to include is a slippery slope. Doesn't think disclosing
feature tags is a security risk. Proposes that the referer
should (or must) include all feature tags it knows about
- JDR: Disagree with Paul on the security issue. Also, has
a concern that people will start using these to bypass normal
SIP negotiation (e.g. not offering video if the referer does
not indicate support for video). Further, thinks it is realistic
to pick which feature tags make sense to include: presumably,
the purpose of the mechanism is to allow changes in the user
interface, and it should be possible to identify which features
might have an impact on the interface.
- Paul Kyzivat: Don't feel strongly about the topics -- seems to
hinge on security. If there are no security reasons to not
include *all* feature tags, then including all feature tags
can only be a good thing.
- Cullen Jennings: We need to make sure this isn't going to rely
on implementors deciding what things to include. Also, the list
of features can grow to be quite long, if you include everything.
Propose that we set up a concrete registry of feature parameters
that should be included in REFER requests.
- Rohan Mahy: Would it be reasonable to include only those features
that cannot be discovered via SIP negotiation?
- Proposal: Use MAY and SHOULD recommendations around which official
tags are to be included in REFER requests. The text will be vetted
on the list.
- Cullen: This is tricky; as an implementor, I can't tell which tags
I should include in a REFER -- and I can't count on what other people
will send.
- Rohan: There are really only two options. You can either have an
explicit list of what must be included. This will always be out
of date (and consequently always wrong). Alternately, you can leave
it up to the discretion of the implementors, in which case it will
only sometimes be wrong, which is better than always being wrong.
- Cullen: That doesn't make sense. An IANA registry makes a lot more
sense.
- Paul Kyzivat: I don't know why we need this at all. How does knowing
ahead of time that the thing to be invited is a focus make a
difference?
- Orit: Consider isfocus. Most of the time, you're not going to be
talking to a focus. But somtimes you are, and you can either
find out ahead of time, or have to query for it.
- Paul: No, you don't. You get that fact in the 180 or 200 response
to the INVITE.
- Dean Willis: I'm confused and my head hurts. Are we reaching a
consensus?
- Consensus: no.
- Chair proposal: We will have a group of interested parties get
together after the meeting to come up with a plan to conclude the
document.
Refer: Norefersub (Orit Levin)
------------------------------
- Should we use a "Refer-Sub: false" mechanism, or a Supported/Require
alternative?
- Adam Roach: We already decided this. Let's not re-open this.
- RjS: This is not the timme to do this.
- JDR: The new proposal doesn't seem to be general in any way.
- Consensus: Leave it as we defined previously.
- Should remove the use-case discussing single-hop? There was an
explicit request to do this.
- RjS: This seems to work.
- JDR: It's impractical.
- RjS: I've seen deployments that do this.
- JDR: Okay. It's not worth debating.
- Cullen: Is this a recommendation, or simply an observation?
- Consensus: Just an observation. The draft should reflect this fact.
Location Conveyance (James Polk)
--------------------------------
- Topic: Location Header Option-tags
- HGS: This seems to be a table of contents for the body. If
we're going to do that, it should be more generic. We would
basically want this for any non-SDP body type. (Some discussion
around this point, but basically results in agreement with
Henning's comments)
- Dave Oran: I'm not sure how these specific option tags allow
a user agent that doesn't know its location but having the
wherewithal to select, e.g., between civic or geoloc
information. (Longer discussion, taken offline).
- Cullen: SHould look at whether this can be based on the
SIP identity work. (James expresses some concerns that the
ECRIT work shouldn't block on SIP identity).
- Unknown Speaker 1: Is it possible to include information both
from the terminal and by the proxy?
- James: What do you do in the case of conflicts?
- Unknown 1: Use what the UA provides.
- James: Service providers don't want to trust that.
- Topic: Dean doesn't like using OPTIONS to fetch UAC's location.
- Several: Dean isn't the only one.
- Consensus: This should be a SUB/NOT mechanism. (e.g. UA
subscribes to own presence).
- Open Issue: Which event package should be used? (Presence,
new one defined in SIPPING, or new one defined somewhere else)
- Several Speakers: Presence is done, filtering has had a lot
of work done on it. It makes no sense to do this work all over
again with the same end result.
- Others: It may be too heavy to expect people to deploy presence
just for emergency services. It's a bit complicated.
- Rohan: I will put together an email discussing why presence
isn't the right way to do this.
- Proposal: Take this text out of the draft, put it elsewhere,
and progress it separately.
- Will be taken to the list. If we can't close quickly, we will
split the draft.
Response Identity (Feng Cao)
----------------------------
- HGS: This appears to be reinventing TLS using HTTP-digest-like
authentication.
- JDR: We need a way to figure out a way to verify that the
connected party is who they say they are.
- Jon Peterson: Don't conflate the party or parties who respond
with the party to whom you are connected.
- General discussion: It's not clear what this document solves
that TLS does not. The response authentication stuff simply
doesn't make sense, given that SIP mandates TLS.
SIP SAML (Jon Peterson)
-----------------------
- Several people spoke up in support of role-based authorization.
This was followed by a dogpile of varying use cases.
- HGS: The barrier to entry seems to be high -- doing the work
to put in the first installation is wasted, since there's no
one to talk to.
- High level issue: should we split framework from mechanism?
- Cullen: We don't want to freeze the framework before we start
on the mechanism.
- Poll for consensus: Should we take this on as a working group
item?
- Cullen: Where does this go in our schedule?
- Result: Rough consensus to add as a working group item.
Answer and Alert Mode Extensions (Dean Willis)
----------------------------------------------
- Paul Kyzivat: The emphasis thing doesn't seem to make much sense.
Semantics are unclear.
- Dave Oran: I'm not confused. I'm sure it's bogus. You can use
an "Alert-Info" header that specifies a different mode of
ringing operation. You can use "Priority" if you want to emphasize
a call.
- Andrew Allen: We're not sure how priority is getting used.
- JDR: This presumes a discrete set of policies, which need to be
well-defined at the UAS -- otherwise, this is pretty useless.
- Francois Audet: We definitely need to have better defined
semantics for this, including examples.
- JDR: Yes, this does need to have applicablity outside the OMA.
Also, note that this benefits from role-based authorization.
- Paul Kyzivat: In the general case, this has significant ability
to be abused. Loopback and push-to-talk don't allow covert listening.
Once it is applied to two-way calls, you need to have much stronger
security considerations.
- Several others spoke in favor of having stronger requirements
around security and policy.
- JDR: There are two seperable issues here. First, the policy needs
to be clearer, so that we understand how the override and emphasis
stuff works precisely. As a separate issue, we need to be able to
determine how users are authorized to request these kinds of
overrides.
- Comment from OMA participant whose name I didn't catch: OMA has an
authorization model around this mechanism that it may be possible to
leverage.
[Meeting Ends]
---------------------------------------------------------------------------
Key:
RjS = Robert Sparks
JDR = Jonathan Rosenberg
HGS = Henning Schulzrinne