Subject: [sipcore] Mary's notes from SIPCORE session on Friday, March 26 13:00-14:00

From: Mary Barnes <[email-masked]>
Date: Fri, 26 Mar 2010 16:13:22 -0500

Below are my raw notes from the IETF-77 Friday SIPCORE session.

Mary.

================================================================================

Table 2 (Adam):
-----------------------
Call for consensus:
1. All documents defining new header fields and methods...define in
semantics and no longer table 2.
2. Produce an RFC that defines new procesdures for adding elements to
table 2 as a new header field and methods

Discussion of what would be for the form for item 2:
-  Adam: we're not defining this yet.
- Keith: what will be the form for item 2. webpage?  Adam: No.
- Adam: it could be an RFC.
- Jonathan Lennox: can we write a document that says that table 2 is
no longer normative. Adam: not deciding that yet.

Consensus call:
- Overwhelming hum for item 1. [Note: one in jabber room also support item 1]

Gonzalo: let's make sure that we don't just go update things for
completeness - address when there are real (e.g., interop problems)

Options (Christer)
--------------------------
Procedural Problems:
[Note: potential gap in notes 13:15-13:20]

1) Proc Problem:  response code.   3261 states that response code
should be the same in an INVITE
Q: does this mean the OPTIONS request should be rejected if the UAS is
currently in a call and would reject an INVITE?
Proposal: Clarify that OPTIONS is about returning general capabilities.

Discussion:
Adam: agree with John E. - we need to have a meta discussion before we
dive. But, other aspects of options are dependent on call state.
Christer: we need to provide guidance on this.

2) Proc Problem: to tag. If the OPTIONS request contains a TO tag, but
no associated dialog exists, procs seem to allow both 481 and 200
responses and even cause dialog to be recreated.
Q: Do we need to clarify behavior
Proposal: If dialog does not exist, return a 481.

Discussion:
Keith: if you use 481, then you're just dropping.  Suggests that you
can still allow folks to respond to OPTIONS, then use 200 (per
previous chart) - if you didn't want to respond to options then you
can send whatever you want.
Christer: asks for clarification.
Robert: Keith isn't arguing against this case. This isn't special about OPTIONS.
Brett: Lack of clarity (ie. not requiring 481)
Robert: suggests that Brett is implying to be careful with RFC 5057 implications

General comment: Adam - doesn't want to focus so much on details -
wants to figure out if group wants to work on problem.

3) Problem: Accept-contact. 3841 states that a request can be rejected
if UAS doesn't suipport feature tags in Accept-contact

Forking problems:
[refer to charts for details]

Questions:
1) How does proxy make a decision whether to return 3xx or fork?
Proposal: use Request-Disposition:redirect
Issue: if there is no RD header, does proxy still return 3xx or assume
default RD.

2) Does proxy return contact addr/gruu of the UAS(s) or something that
hides addresses
Proposal: Policy decision

3) If OPTIONS request contains Accept-contact with capability feature
tags, does the proxy only return contacts for UAS that matches
capabilities?
Proposal: Yes.

Discussion:
Adam: get back to general discussion of whether group wants to work on this.

Way Forward options:
1) Do nothing.  Adam: reworded do we want to work on this at all -
doesn't imply everything is clear)
2) BCP clarifying issues. Adam: this is too specific - do we want to
solve this problem at all?

Discussion:
John E: not certain yet. But do something simple with 2 - more inline
with warnings, etc.
Cullen: don't think we can get consensus on any of these problems.
Don't see a compelling problem. Prefers alternative 1)
James P: [missed this point]
Hadriel: hasn't seen these as problems - these are more features.
Prefers option 1.
Christer: even if we go with option 1 - is there someone that thinks
there is a problem?
Hadriel: has never seen a 3xx to an OPTIONS.
Christer: some folks need this, though.
Peanut Gallery: if you use proxies and not SBCs, you do see this.
Hadriel: to get the feature you want, you need a new capability - not
an interop problem
Brett: Don't think this can be useful to capture things in a way that
pre-conditions did.
Christer: agree - you need something else if you want to do beyond
what options does.
Brett: example of simring ... you can't guarantee subsequent invite
would be routed the same.

Adam: we're back to discussing fiddly bits - need to discuss meta issue.

Robert: tangental point - wants to raise level of awareness on the use
of the BCP acronym.  There will be mounting pushback on the use of
BCPs that are really INFO.

Keith: Will we have an Internet draft for the next discussion?
Adam: most folks are aware of this from ML discussion.

Conclusion: None -  take discussion to the list.

Draft-sipcore-location-conveyance (Jon P):
--------------------------------------------------------------

Proposing to simply - there's been a gradual accumulation of parms,
error codes, etc.
-  reduce to cover only necessary cases
-  Improve predictability from the perspective of the UA

Important use cases:
- Proxies asserting location

Propose to go back to UA just inserting PIDF-LO and proxy can change
or add to.  All the parms, etc. on who added what can be included in
PIDF-LO, thus architectural separation from SIP.

If we do this...
- no need for "used-for-routing", "inserted-by", etc. [Refer to charts]

Discussion:
James W: right now can support a Location URI and a PIDF LO.
John E: have we considered the possibility of looping?
Jon P: sure we did account for that. The possibility to reject is
necessary for a number of cases.
John E: if flow itself includes an indication.
Jon P: don't think we need new stuff, just new language.
Keith: this is not a good idea. There are use cases that we are
needing to support.
Jon P: you haven't elucidated use case.
Keith: in an emergency call, if UAC inserts a location. The network
adds to that. Wants the functionality of both.
Jon P: walks through - in example on chart 4, both original and
corrected location are included in PIDF LO
Keith: what if UAC doesn't include a header, would that also use a 424.
Jon P: if you think UAC supports geo location, then you could use 424.
Hadriel: nice idea in theory, but there's already stuff that is
deployed. In reality, UAs don't support "jack".
Jon P: don't think specialized intermediaries are going to listen to
anything that we say.  They just want location expediently. They'll
chop and dice how they want.
Hadriel: want to change mechanism but not use case?
Jon P: want to remove mechanisms for that use case that won't be used
Hadriel: people (proxies) are inserting PIDF LO and just forwarding it
along. The guy that is receiving this stuff should be the one doing
all the work to get the information.
Jon P: you don't really care about these headers being removed since
they're included in PIDF LO (i.e., who inserted).  Anything that SIP
doesn't need for routing should be in PIDF-LO
Christer: if UA doesn't support 424, UA won't add the new location in
the PIDF LO. Is proxy happy if it just has one location that it wants
(i.e., ignore others)
Jon P: that's always been a problem.  Only changing syntax and not semantics
James P: for Christer's concern, as long as a proxy's location is
included, then other doesn't matter
Martin Thomson: haven't been convinced by any arguments against
proposal. May be problems with stuff that is already deployed.
James W: only concern is around strong language about what should be
included...need to keep some of that.
James P: there can be multiple PIDF LOs in request. Maybe should do a
403...This might be okay if you agree to accept limitations.
Cullen: ..concern over end quality of what gets deployed. Thinks this
is far simpler - easier to get right. Understand impact on what's
existingly deployed. This should finish much sooner than what we have
now.

Conclusion: Good discussion ... need to drive this to conclusion.