[SIP] Draft SIP WG Minutes

["Tom-PT Taylor" <[e-mail]>]

Better late than never.

The SIP WG met for its first session on Monday afternoon, under the
chairmanship of Dean Willis <[e-mail]>, Brian Rosen
<[e-mail]>, and Joerg Ott <[e-mail]>.

1. Agenda Bashing
   ==============

Dean Willis introduced the meeting and session agendas.  In response to
strong representations from the Area Directors, the meeting will feature
larger segments in contrast to the brief discussions of earlier meetings.

2. Status (Dean Willis - charts)
   =============================

Currently tracking about 70 drafts.
Reached saturation point.

The Chairs are trying to get control of the workload.

2.1 Proposal For Reorganization
    ---------------------------

Proposal: split into SIP and SIPPING work groups.  Split in drafts would be
about 24:40.  Remaining drafts would be "out of scope".

Distinguish SIP from uses of SIP.

Actions: immediate split of mailing lists.
Separate WG meetings next time around.
Continue with same chairs until stable.

Discussion:
  Henning Schulzrinne <[e-mail]> noted a potential problem with
messages posted to wrong list: it will mean extra traffic getting the
message redirected.
  Allison Mankin <[e-mail]> observed that if the lists become
moderated to prevent message rerouting, they must have a published policy
which says all that messages will be posted (except possibly spam).  The
Chair could have a sorting policy which assigns messages to list.
  IETF mailing list interactions will create complications.
  Brian Rosen has enforced SIP/implementor's list separation through direct
notes to offenders.
  Jonathan Rosenberg <[e-mail]> remarked that any sorting
policy won't reduce total volume, just ease processing.
  It was noted that some offenders of the current separation policy are
familiar names in SIP work.
  Last Call procedures will encourage division by referring draft to
appropriate list.

  Brian Rosen asked for comments on base idea of splitting groups.  None
were offered.

Dean explained the new web tracking of the workload.  It can be found on the
SIP WG supplemental home page.

Last Call: Chairs will push harder for comments to move drafts forward in
time to meet milestones.

2.2 Draft Charters For SIP and SIPPING
    ----------------------------------

The draft charters for SIP and SIPPING are shown on SIP WG supplemental home
page.

Key charter items for SIP:
 - 2543bis
 - call control
...
Flemming Andreassen <[e-mail]> noted that there are open issues
regarding the privacy draft.

Key charter items for SIPPING
 - SIPT
 - hearing impaired
 - ...

SIPPING won't normally process a Standards Track change/extension to SIP.
The use of extensions etc. would be described in SIPPING.

Rohan Mahy <[e-mail]> remarked that adding codepoints doesn't need to
go to SIP.

Area Director decree: all features which may be "required" MUST be
documented as standards-track items in SIP WG.  SIPPING would define
requirements.

Jonathan noted an open issue on ambiguity regarding Contact parameter
registration.  Allison agreed this could be a SIPPING work item.

2.3 Open Issues
    -----------
 
IN interworking.  Area Director agreement that a design team (SIN) review
related drafts and identify issues which would prevent IN from interworking
with the IN.  There was insufficient support to make this an IETF work item
(SIPPING charter item) at this point.

Firewall passage: MIDCOM owns control

Jonathan Rosenberg led a brief discussion on where call control fits.  The
basic principle is that "how to" is in SIPPING, extensions like REFER go
into SIP.

Dave Oran <[e-mail]> suggested that in effect we would double number
of drafts we have now.  In response, H.323 interworking was cited as a
current counter-example -- no extensions are involved, so the drafts will
all be targetted to SIPPING.

Generally: there will be a number of corner cases.  Sorting them out will
require exercise of chair judgement, fed by arguments from authors.  We
could see a flow where the initial work is done in SIPPING, moves to SIP,
and finally back to SIPPING to define usage of the resulting protocol.

Security: generally a core SIP item to ensure that it is fully integrated
with the protocol.  Michael Thomas <[e-mail]> suggested giving it to
SIPPING first because many of the issues are implementation-related.
Allison Mankin pointed out that every SIPPING draft should discuss security
issues.

A speaker referred to the work in 3GPP/3GPP2 on SIP usage to talk to
application servers: is this part of the IN mess?
Henning Schulzrinne responded that this work is not necessarily part of IN.
The speaker was concerned that the work as currently directed represented at
the least an issue of misunderstanding of Internet architecture.  The Chairs
noted that one shouldn't confuse IN with 3GPP.


3. Bis Issues (Jonathan Rosenberg) (charts)
   ========================================

Jonathan noted that the volume of mail on the list is now such that it is no
longer feasible for issues to be tracked by the leadership of the WG.  He
urged WG participants to take responsibility for tracking issues they raised
until final resolution.

3.1 Issue: SDP in response: subset of SDP in INVITE?
    ------------------------------------------------

RFC 2543 is inconsistent between the text and the examples.

Requiring that the responder send back a subset of the codecs indicated by
the initiator prevents the responder from indicating sendonly capabilities.
It is suggested as an alternative that the text indicate that each end
indicates what it can receive.

Michael Thomas noted that SDP is not adapted to negotiation.  UAs should use
re-INVITES as required for this purpose.

General agreement: the text should say that each end indicates its own
receive capabilities.

3.2 Issue: Cseq Incrementing
    ------------------------

The text says that sequence numbers should be "contiguous".  Incrementing by
1 is useful for ordering.
 
Robert Sparks <[e-mail]> noted that the receiving end cannot
be guaranteed to see increment by 1 because of 407 sent back from an
intermediate node on a re-INVITE.

Rohan Mahy suggested that we try to capture the motivation for any agreed
solution in the meeting minutes, so we don't have to hold the discussion
again.

Resolution: the UAC should still increment by 1.
The receiver should do a sanity check on gaps and reset if it finds too
large a gap.

3.3 Issue: TCP Connection Handling
    ------------------------------

(1) Proposal: closing of TCP connections does not affect SIP state.
Assuming otherwise results in problems (per slide).
The proposal raises potential backward compatibility problems.  Jonathan
asked the implementors in the crowd whether tyhese were real.  There was
positive support for the proposal.  This will be confirmed on the list.

(2) Need text on using persistent connections with TCP.  The proposed text
was shown on a chart.

Matt Holdrege <[e-mail]> asked if these proposals would be carried
over to SCTP.  Jonathan Rosenberg cited lack of SCTP expert involvement and
of understanding of how SCTP applies to SIP (why it would be needed).
Allison Mankin noted that SCTP application discussion has just started in
the Transport Area WG.

There was a general view that this isn't a core specification item as
phrased -- more of a BCP.  Jonathan will think of words capturing the intent
at the standards level.

3.4 Issue: Response Failover
    ------------------------

We would like calls to survive mid-transaction proxy failures.
Usage of the "received" parameter prevents SRV-based reroute.
Proposal: try the address given in the "received" parameter first.  Upon
indication of failure, use domain lookup on the Via header URI.
Problems: this only works on stateful proxies.  There are complications if
the crashed proxy forks.
Rohan Mahy suggested that the text prohibit ("SHOULD") a forking proxy from
inserting a URI in its Via header which points to proxies which cannot
handle forked requests.

3.5 Issue: Tags
    -----------

Agreed at last meeting: From tags should be mandatory.
The specification says a tag should be unique within a UA instance.  There
is value in making tags unique per call leg.  (Helpful with billing.)  On
this last point, Bill Marshall <[e-mail]> noted that a rogue UA
could reuse tag values to confuse billing system.  Jonathan had a different
context in mind.

Jonathan's proposal: make tags unique per call.  A tag MAY contain a portion
to associate it with the creating UA instance.  
Billing or whatever would actually have to gather tags off 200 OK -- INVITE
only has the From tag.

Henning Schulzrinne suggested we not specify implementation too closely, so
that in particular, application to billing is a possibility rather than a
recommendation.  Rohan Mahy suggested that the proposal solves a non-problem
for well-behaved implementations, and by definition the others may not do
the right thing.  It was also noted that this use of tags needs at least one
trusted side.  

Jonathan(?) referred to the discussion of the use of tags to distinguish the
call-leg, as proposed in the Replaces draft.  These discussions support the
per-call uniqueness requirement.  Jonathan proposed that we add text to
indicate the implications of different implementations of tags.

4. SIP Events (Adam Roach <[e-mail]>) (charts)
   ================================
   draft-roach-sip-subscribe-notify-03.txt

A new version of the draft is due.

Current issues:

(a) State agent -- generalization of presence agent.

(b) Subscriptions can be initiated by other than SUBSCRIBE -- 481 must
remove all subscriptions.

(c) PINT compatibility
Lawrence Conroy <[e-mail]> noted the need for text to resolve the
inconsistency between the PINT work and the way SUBS/NOT has evolved.  Adam
assured him that the necessary text is present (assume lack of event header
implies PINT). 

(d) Throttling needs to be done.

(e) Instant notification should be sent upon subscription, even though state
is not actually resolved.  To do this, the suggestion is to send the
notification with neutral information. 
Jonathan Rosenberg and Henning Schulzrinne pointed out that the required
action may depend on the package -- a designer issue, not a blanket
requirement.  Package guidelines should require designers to talk about how
this situation is handled.  Jonathan has other guideline items which he will
provide to Adam.

(f) Authorization of subscriptions.  Jonathan Rosenberg suggested
authorization procedures also should be defined on a package by package
basis.  The question was raised, whether a QAUTH generalized mechanism is
required.  Rohan Mahy suggested that this is a special case of feature
authorization.  Ian Rytina <[e-mail]> stated that QAUTH
has a place, but not in presence.  The issue will be further discussed in
SIMPLE/IMPP.  In general, this is an example of a SIPPING discussion item,
with outcome to be acted on by SIP.

(g) SUBSCRIBE response codes.
202 non-committal -- have to wait for Notify to give final result.
Are 403 or 603 allowable?
Does 200 mean subscription is definitively approved?
Jonathan suggests that this should be part of the package definition

(h) Denial of service concerns:
UASs should keep no state for unauthenticated SUBSCRIBE messages, to protect
themselves against denial of service attacks..
Is it reasonable to allow each userid/password combination have only one
pending SUBSCRIBE at each node?  Dean Willis pointed out that in the failure
recovery case, restart would be slow.
More discussion needed.

(i) Forking
Lots of discussion at interim meeting, no resolution.
The UAC gets multiple NOTIFYs back although only one 20x response was passed
by the forking proxy, with Record-Route ambiguity as a result.
It took some discussion for Adam to demonstrate the problem.
Proposed: two solutions, one of which SHOULD be used by any subscriber.
[Sorry I don't have them, hope they are shown on Adam's charts -- PTT] The
event package should specify the preferred response.
Rohan Mahy noted that there is a general issue with proxies forking methods
they don't understand.
Jonathan Rosenberg was concerned that this violates the basic SIP working
assumption: that the final result of INVITE is a relationship between two
parties at most.  As a result, may be more general problems buried here
which mean a lot of work.
The suggestion is that this is an instance of a general non-INVITE forking
problem.  The general fix is to strengthen proxy "SHOULD" record-route on
non-INVITE methods to "MUST".
   


====================================
Part I Tuesday am

The proposed agenda was accepted with insertion of a resumed exposition of
the revised Last Call process.  Dean Willis(?) explained the 1a, 2a etc
notations on the web display of WG work items by indicating how they
correspond to stages of processing defined elsewhere on the page.

1. REFER Issues and Call Control (Robert Sparks) (charts)
   draft-ietf-sip-cc-transfer-04.txt
   draft-biggs-sip-replaces-00.txt
   ======================================================

Robert began with a review of recent changes to the REFER method
(draft-ietf-sip-cc-transfer-04.txt).  The major one was that NOTIFYs
generated in response to REFER will use the Event: refer package.

Road map: 
Model document in progress (Rohan Mahy)
Splitting current draft -- extension vs. usage.
Need Join/Replace for Transfer.

Robert Sparks ran through motivation for Replaces: header
Issues brought up:

Existing call-leg identifier: the draft proposal to use tags only and not
the full From: and To: headers had led to a lot of private discussion.  No
new points were brought up at the meeting.

Tom Taylor <[e-mail]> asked for opinions on Replaces
behaviour if the existing call-leg is not already fully set up.  A number of
people responded.
 - Jonathan Rosenberg was uncomfortable with the idea -- tags may be
lacking.
 - Dave Oran thought that unwinding the state machine might be tricky.
 - Rohan Mahy was of the view that processing would have to wait until
states of the new and old call synchronized.
 - Dave Oran questioned what would happen if original call forked and was
ringing simultaneously at two points.  Rohan Mahy argued that a referred
INVITE goes through same process as original and therefore could follow the
fork.  Henning Schulzrinne responded that two separate processes could see
separate call dispositions.
 - Christian Huitema <[e-mail]> viewed the suggestion
as nonsensical.
Nevertheless, Tom Taylor pointed out, the Replaces draft would have to
define UA behaviour under such circumstances, even if this behaviour were to
ignore the header.             

Robert Sparks continued with a walk-through for attended call transfer.

Henning Schulzrinne noted that the repeated use of Replaces in a
conferencing situation could lead to untraceable results.

As a separate issue, he preferred Refer BYE rather than triggered BYE (as
the draft has it now) -- have to be very careful not to mess up operation of
other features.  Speaking to that issue, Jonathan Rosenberg suggested that
the entity that has resource constraints is the one which should manage the
resource constraints.  Robert Sparks had the view that the problem is user
experience more than management of the pipe into the phone.  Jonathan said
the protocol should make the semantics explicit: Join + BYE.  Rohan Mahy was
concerned that Join implies need for mixing.  He wanted to see clean
separation of semantics between mixing and replacement.

Robert(?) clarified the semantics of Replaces: resources from the old call
are reallocated to the new one and old call is terminated.  He will provide
call flows.

Rohan Mahy(?) made a final remark: Join without mixing makes no sense.  We
MUST resolve this stuff this week -- it is a major bottleneck on feature
development.

2. Overlap Signalling Handling (Gonzalo Camarillo
<[e-mail]>) (charts)
   ========================================================

The authors of the SIP-T draft are splitting drafts so overlap signalling
handling will be a separate topic.

Three approaches:
 - en bloc
 - multiple INVITEs
 - INFO.

Tom Taylor warned that which policy is used where is a matter of local
policy, not standardization -- real-life implementations will have to
support all three.

Gonzalo continued with an analysis of the pros and cons of the three
policies.  He judged that both forced en bloc conversion and INFO messages
(as the only means of carrying updated signalling) would be untenable.  This
leaves multiple INVITEs, where each INVITE carries complete state.

The presented chart showed overlapping calls, a potential problem.  An
earlier INVITE could succeed because the partial called number is valid.
Dave Oran suggested that the UAC should wait for a 484 before sending its
next INVITE.

Jonathan Rosenberg noted that the succession of INVITEs actually displayed
Replaces: semantics.  He would have to think through the consequences if
Replaces were used.

Christian Huitema noted that in legacy usage the PBX can hold on to a call
while information accumulates.

Tom Taylor pointed out that if the call terminates on an egress gateway, it
has moved beyond reach of any but mid-call services in the SIP network.  We
need contingency plan if more digits arrive.  Jonathan Rosenberg agreed that
there is a problem if the call goes to egress gateway with too few digits.

Gonzalo Camarillo noted a general problem: successive INVITEs may not follow
the same path.  The result of successive INVITEs could be extra IAMs rather
than SAMs propagated onwards into the PSTN.

Further discussion curtailed for lack of time.


3. SIP-H.323 Interworking Requirements  (Radhika Roy) (charts)
   ======================================================

Radhika Roy <[e-mail]> presented status and recent changes for two
documents.  Review of the requirements document
draft-agrawal-sip-h323-interworking-reqs-02.txt leading to Informational RFC
status has been requested in various WGs in lieu of WG Last Call.  The
latest issue of the interworking specification is
draft-agrawal-sip-h323-interworking-00.txt.


4. Privacy (Flemming Andreasen)
   ============================ 
   draft-dcsgroup-sip-privacy-02.txt

Status: no real participation in the WG.
New call for comments on list.
Got comments from Mark Watson <[e-mail]> -- generalize
components of the proposed Remote-Party-ID header.  The comments were
resolved after substantial discussion.  The discussants gave up on the
proposed inclusion of location information.

Flemming showed the proposed requirements and their proposed resolution

Dave Oran requested consensus that the different types within the updated
proposal be IANA registered.  Agreed.

Comments:
Jonathan Rosenberg noted that this is a Proxy-Requires extension and thus
breaks interoperability.  There may be ways to deal with it (e.g. sequential
forwarding of the message until a path is found which works).

Jon Peterson <[e-mail]> asked if it were the general view
that this should be THE SIP privacy mechanism.

Henning Schulzrinne agreed with Jonathan that the feature can operate, but
forking gets messy.  The IESG will insist on a full description of how a
call will fall back to baseline operation if the extension fails.  Jonathan
confirmed that observation.

Allison Mankin noted that work in progress may provide a method to give
location information which is privacy oriented.

Dean Willis followed up on Jon Peterson's question, posing it again to the
meeting.  Jon amplified: do we want to rely on the presence of trusted
network intermediaries for SIP privacy?  Dean Willis suggested that we may
need more development of requirements before we can answer that question.
Jonathan Rosenberg noted the need for the network to pierce veils of
anonymity e.g. for malicious call trace.  However, this is much tougher for
SIP than for the PSTN.  Dave Oran stated that the question was too broad: we
can't commit to this for all SIP for all time, but real networks do have
call trace requirements.  Radhika Roy noted that the requirement to
interwork with the PSTN adds a dimension to the problem.

Addressing the content of the draft, Henning Schulzrinne observed that it is
very dangerous to rely on a network entity to clean up.  This issue has to
be fully addressed in the draft.  

Jonathan Rosenberg suggested that current work focus on the requirements of
malicious call trace -- e.g. when it has to be possible, in-call or later.
Dean Willis raised a process issue: can we consider regulatory requirements?
Allison Mankin responded that regulatory requirements are informational,
feeding into IETF requirements for privacy and security.  We would hope that
the latter are more stringent.  Note also RFC 2804.  (Comments from audience
to effect that the IETF shows more willingness to support malicious call
trace than wiretap.)  Allison suggested that the WG put together a privacy
requirements draft.  She observed that the current privacy draft looks very
good.

The suggestion was made that this document should retain its present scope,
while the requirements document could have expanded scope.  Michael Thomas
noted a potential need for media anonymization.  The question is whether
this is good enough for what it is trying to do.  Dave Oran responded that
anonymization is solved.  However, this work is driven by two requirements
-- the need for an identity besides that supplied by user for processing the
call, plus anonymity.

Brian Rosen asked what the next move should be.  He suggested the document
should be split into requirements and protocol parts, and asked if there
were any objection to this.  He called for a hum of opposition to
progressing this document to standards track.  A clarification: this would
be a mechanism, but there could be others.  Jonathan Rosenberg wondered if
Experimental be acceptable.  Allison Mankin replied that Experimental is
probably not appropriate.  The WG should take time to get it right if
necessary.

The question was put: is there opposition to moving forward according to
plan (July LC)?  No opposition was shown.


5. 3GPP Proposals (Keith Drage <[e-mail]>) (charts)
   =====================================

Keith provided URLs pointing to current documents.  (These are already on
the supplementary WG web site.)

He walked through a signalling path chart showing how many operators could
potentially be involved in a call (A's visited network, A's home network,
B's home network, B's visited network).

Keith presented the 3GPP functional architecture.  Some questions were
raised about the BCGF.  It was explained as a routing function which knows
where gateways are.  Jonathan Rosenberg expressed satisfaction with the
match to the SIP architecture.

Keith provided the 3GPP approval schedule, noting its dependency on a series
of drafts: 2543bis, manyfolks resource, 100rel, privacy, call-auth,
subscribe-notify [and perhaps others].  Michael Thomas expressed concern
regarding the applicability of call-auth.

For path requirements, Keith suggested a need for a new header for
hop-by-hop registration (3 registrars).  Jonathan Rosenberg pointed out that
this can be done with the current protocol.  Jonathan Lennox
<[e-mail]> asked a question to clarify the route manipulation
involved.

Several issues need settlement.  One is Via, Route, and Record-Route hiding
as in draft-byerly-sip-hide-route-00.txt.  Another is notification of the UA
in a proxy-initiated deregistration.  Jonathan Rosenberg suggested using the
SIP presence draft as a potential solution.  A member of the audience
indicated that this was how they were implementing the process.


6.  Further Discussion Of List Issues (Jonathan Rosenberg)
    ======================================================

(a) Network-initiated deregistration:
Solution: use presence -- is there a consensus?
Dave Oran observed that the dertegistration notice could trigger something
like notification of police (in the event of cell phone theft).  Henning
Schulzrinne asked if this is really a subject for standardization, and
expressed his opinion that it is not.

(b) 409 and Multiple Contacts:
Can the current prohibition on change of action values be removed?  Jonathan
was not sure that the resulting behaviour would be well defined.  Robert
Sparks suggested that the behaviour can be reasoned out.  Jonathan was not
convinced.  Robert provided an example of a potential application prevented
by the current text.

A lengthy discussion ensued.  There were various proposed interpretations,
but none was accepted as definitive.  There are possible ways to resolve the
issue, but it has to go to the list.

(c) Record Routing:
Need more comments on the new text.
Issue -- what about new methods?  Current text says they should not be RRed.
Nevertheless, Record-Route may be justified e.g. for firewall traversal.
Jonathan proposed to allow RR on any method.  The UA ignores RR if it
arrives on a method where it is inappropriate.  Adam Roach noted that the
2543bis draft says that proxies should put RR on all methods for robustness
(hence including BYE).  There is a bigger issue here: what does it mean to
refresh RR state?
Called on time.


Tom Taylor
Multimedia Control and Applications Standards
Ph.  [phone]
[e-mail]