[Sip] Draft SIP Minutes

[Joerg Ott <[e-mail]>]

Folks,

attached are the SIP minutes from the Yokohama meeting.
Please double-check that this matches what really happened
at the meeting.

Thanks,
Joerg

SIP WG Meeting at the 54th IETF
===============================

Minutes by Joerg Ott ([e-mail])
Notes by Renee Cohen, Vijay Gurbani, and Joerg Ott.

The SIP Working Group met twice at the 54th IETF; the sessions were
chaired Dean Willis, Brian Rosen, and Joerg Ott.


Agenda Bashing and Status Uppdate (Chairs)

The meeting agenda was accepted; the only minor change was that the
discussion of MIME types was postponed from the first to the second
session, pending input from the ADs.

A brief overview of the status of the drafts was given, noting that
the most important ones are published and quite a few had been
finalized (see overview slide from Rohan Mahy) and several ones are
moving ahead in the process.  One draft, defining the REFER method,
had issues found during last call and went back to WG item status (as
discussed below).


REFER: Open Issues (Robert Sparks)
   - draft-ietf-sip-refer-05.txt
   - draft-sparks-sip-refer-3265disc-00.txt
   - draft-ietf-sip-referredby-00.txt

The draft on the REFER method lacked clean documentation on how to use
SIP events.  A separate document was created
(draft-sparks-sip-refer-3265disc-00.txt) that suggests clarifying
wording and also defines a mechanism to signal whether or not an
implicit subscriptions on reception of a REFER have been created.  A
poll on the list, however, showed that no one has actually implemented
optional subscriptions and hence this mechanism is not needed.  It has
been agreed to make implicit subscriptions mandatory; a new revision
of the REFER draft (-06) will be issued this week including the
clarifying text and reflecting the list agreement.  The AD (Allison
Mankin) remarked that this change will not require another IETF Last
Call; as no one saw a need for another WG Last Call was, the document
will be send to the IESG queue where it left off when the issues were
encountered.

As another change the REFER draft was split into two parts after the
SIP interim meeting, factoring out the Referred-By: header (which had
strong security issues that were not resolved in the original
document).  The Referred-By draft now makes use of the S/MIME
mechanism.  So far, there has been only very little discussion on the
list and no issues have come up that would warrent discussion at the
meeting.  People are encouraged to review the draft.


MESSAGE: Open Issues (Ben Campbell)
   - draft-ietf-sip-message-05.txt

The MESSAGE draft is currently in IETF Last Call and is waiting for
IESG feedback.  Minor changes have been made so far in response to
feedback.

The major issue of this draft is congestion control.  Quite some
concern has been raised about the artificial message size limit.  The
updated draft provides compromise wording for this: while specifying a
size limit, it also states that this may be exceeded if the sender is
sure that all links on the path are congestion-safe.  The draft does
not specify how a UAC determines that this condition is satisfied.  A
new draft on SIP and congestion control (discussed later in this
session) addresses this issue.

Furthermore, the use of the Expires: header has been clarified: it is
now suggested that a value of 0 shall indicate that immediate delivery
is requested.  Delta-time stamps (from the Date: header, if present,
or time of reception, otherwise) are provided for as absolute times.
If an Expires: header is present, a Date: header should also be
provided.  Treatment of expired messages is up to the local policy at
the UAS.

Finally, it has been suggested that UACs "MUST" register with the
parameter methods="MESSAGE", which is currently a SHOULD.  Discussion
has shown that people are in favor of leaving this a "SHOULD" (as with
all other methods) as is written in the current draft.  It was agreed
to keep the "SHOULD".


Caller Preferences Open Issues (Jonathan Rosenberg)
   - draft-ietf-sip-callerprefs-06.txt

The caller preferences work has been around for quite some time and
has experienced little use in the past.  The latest update of the
draft makes use of RFC 2533, with significant simplifications though
to keep caller preferences simple and straightforward to implement:
the the general idea is used, the allowable input is significantly
restricted, however, and the syntax is kept backward compatible.  In
particular, only a conjunctive normal form is needed, i.e. a
disjunction with each term being expressed as a conjunction of feature
tags.  Computing the interscetion between two such terms can be done
linearly without the complexity that comes with the full RFC 2533
algorithm.  Note also that RFC 2533 is used only internally: the
syntax on the wire has not been changed but the internal processing
rules have, to comply with the simplified version of RFC 2533.

A number of semantics changes have also been made: firstly, RFC 2533
already supports MIME types, but differently from how caller
preferences have been using it before.  The "type" tag as already
registered by RFC 2533 allows only complete MIME types, no wildcards
as were used before.  Therefore, two tags are now used by caller
preferences: the "type" tag as per RFC 2533 and an additional "media"
tag carrying top level types for alignment with existing tags.  Note
that this breaks backwards compatibility here.  A Boolean "automata"
tag has been added to indicate e.g. voice mail server, robots,
etc. and an "events" tag to indicate support for RFC 3265 event types.
There have also been some changes in priority matching rules: multiple
ones can be specified and Accept-Contact: header allows for explicitly
asking for a certain priority.  The weighing parameter Q now needs to
be the last parameter amongst the Accept/Reject-Contact header values.

New is also the way of explicitly specifying preferences: previously,
methods and priority information were handled differently from other
preferences; while the latter were explicitly specified, the former
were inferred from the request method and the priority header.  The
revised version of the draft allows to also specify those explicitly.
The implicit variant is still supported but is overridden by the
explicit one.

Further changes include a significantly restricted URI matching:
either user and host are matched or just the host.  In all cases, URI
parameters are now ignored.  Also, the feature sets that can be
present in Accept-Contact: (INVITE) and Contact: (REGISTER) headers
have been unified and are now able to express exactly the same
information.  Finally, the "&" construct has been removed for a single
tag as each tag represents one axis in an n-dimensional space; the
feature collection is represented as a point in this n-dimensional
space and there must not be more than one value on the same axis;
hence, the "&" construct does not make sense here.  During the
discussion, the need was identified to express more than one value for
some given tags (e.g. audio, video for media) and hence those cannot
be part of the same dimension.  It was suggested to use a Boolean tag
for each media type instead (e.g. audio=yes, video=yes) so that
independent dimensions are created.  As this approach was agreed, the
issue was raised how to manage the resulting name space: for each new
MIME type, a new tag would need to be registered and name clashes may
come up.  Proxies do not have to be aware of registered values; they
just process "tag=value" pairs, regardless of whether or not "tag" or
"value" are registered.  Therefore, this was deemed a minor problem
that should be dealt with when real (rather than theoretical) issues
arise.  For now, some clarifying statement regarding the modified use
of the tags will be included in the next revision of the draft.

Finally, two open issues were discussed: When used in the Contact:
header within an INVITE transaction to declare one's own features,
various parameters overlap with SIP headers (e.g. methods and Allow:,
Events: and Allow-Events:, etc.).  This can be resolved in numerous
ways: (1) allow both and define one to take precedence over the other,
(2) forbid caller preferences from using parameters that are also
present through headers, and (3) disallow the use of caller
preferences in INVITE/200.  The proposal to choose (1) with headers
taking priority was accepted.

The other issue refers to extensions to parameters that result from
work other than caller preferences: there is no way to indicate that a
certain Contact: parameters actually belongs to caller preferences as
opposed to being some other extension.  Discussion has shown that it
actually does not matter: unless the same parameter is present in both
the calling and the called entity's Contact: parameters, they will
simply be ignored.  This is found to also address the issue of the
earlier discussion on naming and registration of tags.  The revised
draft will state this as an issue but will also point out that it does
not really matter.

At least one more revision of the draft will be needed, taking into
account discussions during this meeting as well as feedback received
by mail.


SIP NAT Open Issues (Jonathan Rosenberg)
   - draft-ietf-sip-nat-02.txt

The previous version of the draft addressed two different problems:
(1) receiving responses through a NAT ("rport" parameter) and (2)
receiving requests through a NAT (Translate: header in REGISTER).  The
Translate: header had various issues: for UDP, frequent
re-registrations are required; it introduces NAT-specific parameters;
and it duplicates STUN.  The revised draft is scoped to do exactly
what is needed to make SIP work with STUN, SPAN, and TURN -- no more,
no less.  As a result, only the "rport" parameter remains as, without
this, STUN would not work.  In the long run, TCP (or better: TLS) is
the right answer and, in this case, only the registration problem
needs to be solved.  A point was made that MMUSIC was already dealing
with such efforts but Jonathan responded that the MMUSIC work affected
the SDP and thus the media streams; the work he presented here was
purely for SIP.  Some discussion arose around encouraging people to
move to IPv6 (as opposed to applying fixes to "evil" IPv4 equipment
such as NATs).  The point was made, however, that the SIP NAT has
actually broader applicability and does not just deal with NATs.  This
will be reflected in a renaming of the draft in the next revision,
then again as a -00 draft.  The document is now rather short and
cleaned up; WG Last Call will be issued soon.


Session Timer (Brian Rosen)
   - draft-ietf-sip-session-timer-09.txt

No one in the group had any issue with session timer.


Digest Authentication Enhancement Open Issues (James Undery)
   - draft-undery-sip-auth-01.txt
	
Current authentication for SIP is essentially based upon RFC 2617: it
is deployed today, it is simple, and works for UAC-to-UAS as well as
for UAC-to-proxy.  The last revision of the authentication enhancement
draft was perceived by far too complex so quite some complexity was
taken out and only a few core items remain: fixes to authentication,
bid-down protection, and header integrity protection.  A "realm"
parameter was added to Authentication-Info: and a generic extension
mechanism was included in case future authentication algorithms would
need different parameters from those required by digest
authentication.  To counteract bid-down attacks, the proposed
algorithms and the "qop" parameter are included in the nonce.  To
provide header integrity protection, a message/sipfrag may be included
in the body.

The only open issue raised was on the acceptance of this work in
general: do people find this extension too much or do they want it.
Numerous people strongly supported the idea; in particular, the work
was viewed as urgently needed: it should be progressed quickly or
halted (to pursue some other approach) -- but not hang around
endlessly.  S/MIME was brought up as desirable but others stated that,
particular with small devices, not too many of them will be doing
S/MIME (just for the purpose of registration).  Hence a simpler way is
needed.  Basically, S/MIME can be shrunk or digest can be extended.
For the former, however, there had been no proposals so far.  So this
draft may be the right way ahead.  Other comments were made to provide
more detail on bidding down attacks and possibly make recommendations
which algorithms (not) to use.  Another comment raised that digest
itself is insecure and should not be used at all.  James indicated
that the algorithm he proposed was not specific to digest; if the two
ends decide to use digest they know that they took a concious decision
without interference from a man-in-the-middle.

The chairs concluded that they'll have a discussion with their
security advisors on this and try to move this work along.


SIP Congestion Safety (Dean Willis)
   - draft-willis-sip-congestsafe-00.txt

Dean presented the general problem background on SIP and congestion
control.  SIP allows for UDP and TCP/SCTP as transport protocols.  The
use of UDP brings along a number of problems.  With TCP and SCTP,
multiple transactions may share the same transport connection
including their retransmission timers.  For UDP, however, SIP defines
retransmission timers with exponential backoff on a per transaction
basis.  Using UDP, a node may be involved in a number of independent
transactions at the same time, without having those transactions share
the congestion state (timers, etc.) with each other.  No standard way
is defined to adapt (re)transmission behavior across multiple
independent transactions to changing network conditions.  Proxies may
even change the transport to UDP, so the originating UA has no
knowledge whether or not TCP or SCTP will be used all the way.  A
similar problem exists if the proxies do not re-use TCP connections
but rather open up new ones for new transactions (but for TCP,
connection re-use is at least being defined to deal with this
problem).  Another issue with UDP are large SIP messages: if messages
get larger than the MTU size, IP fragmentation will result in
sequences of fragments with no inter-fragment rate limiting.  RFC 3261
"solves" the problem by imposing an artificial upper limit of 1300
bytes on a message sent by a UA if the messages may ever traverse a
non-congestion controlled link.  As transport may be changed by
proxies, UAs should essentially never send messages larger than 1300
bytes -- but messages of larger size will be required, e.g. because of
S/MIME, MESSAGE bodies, etc.  RFC 3261 does not provide a solution --
unless networks are engineered in a way that only TCP is used between
proxies.  Some backwards compatibility issues are raised indicating
that one may be required to use UDP (which is countered stating that
even RFC 2543 need to support TCP).

Dean further presented traffic models to outline the problem; this
part provoked quite some discussion on suitability of the model
presented and how much it represented actual traffic on the Internet.
It was also questioned that TCP-style congestion control could be
applied to all kinds of traffic in the Internet.  The discussion
continued for quite some time before being brushed away by the AD
(Allison Mankin) aksing people to focus again on SIP congestion issues
rather than engaging in general debates on congestion control.  As a
valid point remaining from the discussion, it was also noted that the
first traffic model did not actually compare UDP to TCP but rather a
single "connection" to a number of independent parallel "connections".
But this was addressed by Dean anyway in his "Corrected Scenario".

After this background discussion, Dean discussed the contents of the
draft itself: it essentially defines the congestion problem and
congestion-safe behavior by making a couple recommendations: it states
a strong preference for TCP/SCTP over UDP and disallows two concurrent
transactions in the same direction between any two nodes (which
essentially enforces a 2*RTT rate lock step rate limiting).  It also
sets out to define mechanisms that allow UAs to determine that their
requests will be handled in a congestion-safe manner.  An issue was
brought up whether this would also apply to traffic which is not
best-effort but somehow treated preferentially; since in essence, one
cannot know what kinds of lower layer services to expect, the same
behavior as for best-effort is expected.  Just using TCP, however, is
not enough: TCP with connection re-use is what is needed; this was
reinforced several times.  It was also pointed out that proxies must
be able to restrict the overall traffic they transmit: in case they
talk to 500 other proxies with bits of traffic sent to each of these,
this will gain very little in terms of congestion control, unless the
proxies consider all the traffic it is sending to the network.  The
congestion-safety framework should not preclude this.  Another speaker
felt the draft was talking too little about considerations for big
messages and the implications for that.  As something like that was
intended to be in there, further text will be provided.

In addition, proxies could be enabled to reject large requests in case
they know the following path is not congestion-safe, thereby asking
the client to send smaller pieces and pace itself.  In response, it
was pointed out that it's not just the request, however: the response
has far less choices of which ways to take and there is no way to
signal to its sender that it is too big.

Dean also outlined two simplifications that have been proposed: the
use of UDP could be restricted to the link between a wireless UA and
its edge proxy (3G scenario).  In SIP, however, there is no way to
determine up front whether the next hop is going to be a proxy or a
UA; hence this would need to be ensured by network design.  Also, it
has been proposed to deprecate UDP entirely from being used in the SIP
spec (which, of course, bears a huge backwards compatibility issue).
Dean does not believe it can be simplified to either or the too but he
is willing to undertake the effort if there is strong support.

Another issue to discuss (and there has been quite some controversy
among the draft authors) is when congestion-safe behavior should be
followed by proxies: always or only if the UA explicitly "requires"
it.  The former would greatly reduce the UDP throughput, while the
latter would prevent non-upgraded endpoints from flooding the network
with packets.  This is an open issue.  A strong position was taken to
make congestion control a top priority in the WG.  This work should
not be seen as an extension to SIP but rather as a task migrate from
existing behavior to something new.  And this new behavior should then
be applied all the time.  There will be some time before SIP goes to
draft standard (1.5 - 2 years) and this time can be used to upgrade
all the SIP elements (UAs that do only UDP, proxies that are not
congestion-safe) to match this new behavior; hence there is sufficient
time for everyone to adapt.  The approach must be backwards compatible
but, as the proxies already are required to support TCP, new elements
can just replace old ones piece by piece.  Strong support was
expressed that this behavior should be exercised all the time.  There
may not be all the right mechanisms at hand now but the group is
definitly on the right track.  While TCP may sometimes increase load
for few and small messages, small messages will go away and so will
the possibility to use UDP all.  It was emphasized again that in the
mid-term UDP should go away.

Some minor implementation issues were discussed regarding TCP fan outs
from UAs and proxies.  It was established that practice has proven
that large-scale fan-outs can be done.

A mechanism to indicate that congestion-safe treatment is required.
While  only a Require: header is present in the current draft, a
Proxy-Require: header is needed as well.

The final question raised was whether the mechanisms just outlined and
discussed are strong enough to ensure reasonably good behavior of SIP
proxies and UAs.  The general feeling seems to be: yes.  Some work on
the rules and mechanisms is still required.


Open Mike

With ten minutes agenda time left, an open mike session was started
which, after a brief discussion on WG items, again took up the issue
of congestion control.  The group agreed to make congestion control a
WG item.  Some further discussion emerged with the point being made
that just using TCP would, by the nature of the traffic, not solve the
congestion problem as a whole (one needs to do more).  Also, it's not
just congestion control why one would want to use TCP in the first
place but security: from making it more complicated to inject packets
to being able to fully secury connections.  As for congestion, traffic
peaks in proxies also need to be dealt with -- by using the mechanisms
available today in SIP.  Another issue: there may be messages the size
of which cannot be reduced in case a proxy rejects them; in this case,
a different route may need to be used.  Mechanisms may be needed that
allow a proxy to reject a request indicating that a different
transport should be used.  It was also pointed out that TCP
keep-alives need to be turned off as they would cause too much traffic
otherwise.


Session 2
---------

The second session started with a modification in the agenda: the
discussion of a draft on SIP-ISUP mapping which had been left over
from the SIPPING meeting on the previous day was added right in the
beginning.

Beforehand, a the enormous achievements of the editors and ADs
involved in making the huge task of RFC 3261 happen were recognized
with a big applause.  Following this, it was agreed to publish the
changes between bis-09 and RFC 3261 rather quickly and a process for
logging and collecting bugs in RFC 3261 was outlined.  The plan is to
go to draft standard after some time and the logging procedure shall
help to ensure that all issues encountered in the past are actually
rolled in.


SIP-ISUP Mapping (John Elwell)
   - draft-elwell-sipping-qsig2sip-01.txt

This draft originates from ECMA (European Computer Manufacturer
Association) who have developed QSIG.  QSIG is a standard for
interconnecting PBXes in private networks.  The QSIG-SIP interworking
draft is intended to enable integration of traditional telephony and
SIP-based VoIP within an enterprise and thus allow a smooth evolution
of enterprise networks from QSIG to SIP.  The draft specifies a
mapping from QSIG to SIP and vice versa; it does not handle
encapsulation.  The draft complements the work on SIP to ISUP
mapping.

The following issues were identified: Q.850 cause mapping is not yet
entirely done; there are still differences compared to the ISUP draft
but those should be compatible.  Work has progressed during the IETF
week and there will eventually be a line cause mapping.  Another issue
is overlap sending; the QSIG work is technically in line with the ISUP
work but, since the other draft is written using ISUP terms, the text
could not just be referenced but needed to be adapted.  A final issue
is whether or not ISDN (DSS1) interworking should be specified in the
draft.  Because of numerous (partially large) differences between QSIG
and ISDN and numerous scenarios that could be/would need to be
specified, it is suggested to keep this work entirely separate.

A comment was raised that the draft should include extra functionality
as well and not restrict itself to addressing the basic call scenario.
John responded that, as basic calls are a prerequisite for the rest,
this should be addressed first.  The rest should follow in later RFCs.
Another commenter pointed out that MIME encapsulation for QSIG is
specified separately and can just be used.  It was found that the
draft seems to take the right direction and commenters agreed with
keeping DSS1 mapping separate.

The work should move ahead but, as the charter is currently pretty
full, it should take one more round as individual draft before
becoming a SIPPING WG item (aimed at PS).  The way ahead for the draft
will be discussed on the mailing list; the WG chairs will consult with
their ADs beforehand.


Identity open issues (Jon Peterson)
   - draft-peterson-sip-identity-01.txt

The SIP privacy and network asserted identity have passed IESG and are
thus finished: in just six weeks from a -00 draft to RFC, some kind of
a record.  A comment was made that this pace was only possible because
many comments were ignored.  However, the presenter claimed that the
concerns were addressed and debated on the list in length and this
should not be repeated right now.  The chairs pointed out that rough
consensus is good enough for the IETF, unanimity is not needed; so
this work is done and one should move on.

The next draft discussed addresses SIP identity in the long term,
moving away from the closed trust domain model required to assert and
verify the identity as it has been developed for 3G needs.  This work
is already a WG item even though it has been submitted as an
individual contribution once more this time.  The revised draft
incorporates numerous comments received on the initial version, some
of which are significant open issues as discussed in the following.

The first major open issue is how to identify the authentication
service in a given administrative domain as the hostname convention
used in -00 has been removed and was not replaced by something else.
This leaves open who -- i.e. which (single) entity in a domain -- is
responsible for asserting an identity and thus can be verified by
recipients of the asserted identity.  Related to this is what
information about the authentication service can be derived from
knowing this entity: is it *the* host responsible for the entire
domain (e.g. yahoo.com) or just *one* host within this domain
(e.g. xyz.yahoo.com); this may have an impact on how trustworthy the
asserted identity is to the receiver.  Discussion came up that this
depended on what the asserted identity and the knowledge about the
asserting entity should be used for.  One might not care which host
actually did the signing/assertion (hosts may change daily anyway) as
long as the signature was ok and one could verify it came from the
right party.  In essence, a UA should be able to express/restrict who
is supposed and/or allowed to sign the asserted identity so that the
right representative is chosen.  This requires a naming convention of
some sort but that name should/need not be a host name.  It would be
nice if the receiver could, by some convention, determine which is the
privileged entity for a given domain without the need for any
pre-arrangements; this is the property sought (which got lost by
removing the host name convention).  It was also noted, however, that
the asserting identity need not be part of the same domain and hence
such (host) naming convention might not even make sense.  The
necessary feature could, as was recommended by some security folks, be
attached as new certificate properties; involving new certificate
characteristics and certification authorities, such an approach was
felt to take a while to be realized and hence impractical for the
shorter term.  The discussion concluded in recognizing that the entire
problem may not be that well understood at this point in time and
further experience will be required.  As a consequence, the group may
not want to say anything specific right now; but the desire was
expressed to do better than this and continue to try to find some
solution here.

Another issue was whether to include and thus sign the entire SIP
message or just parts of it -- the basic question of how many headers
need to be signed.  The solution right now in the draft is to allow
for both message/sip as well as message/sipfrag as MIME contents to be
signed.  At least three headers are required, more are allowed.

Finally, the privacy pieces of the draft were aligned with the
short-term network asserted identity draft to get unified behavior.

There is other minor stuff to be done.  Work is continuing.


BINDing URIs to SIP AORs (Henning Schulzrinne)
   - draft-schulzrinne-sip-bind-00.txt

This new draft addresses the issue of associating data intended for or
carried in an external protocol as well as actions with a SIP
address-of-record.  Providing CPL and SIP CGI scripts, uploading
presence information, user provisioning and configuration are
examples.  There are many facets to this problem and many ways of
solving it.  The present proposal defines just one approach.

The idea is to associate a SIP AoR or a SIP UA's URL with one or more
URIs that can be used to retrieve data or to invoke the desired
actions.  This allows for binding information, modifying information,
and deleting bindings.  Various types of indirection are supported: a
URI may point to the information which may be retrieved from an
external location or included in a message body; small amounts of
information may also be encoded within the URI itself.  The binding
concept discussed here and the concept of content indirection have
some commonalities in that both refer to external data but the
semantics are different: content indirection is used to replace data
otherwise carried within a message body by the data the URI references
while bindings are used to link external data to an AoR (with this
binding being valid for more than just a single message).

The document proposes a Binding: header field with a number of
parameters ("disposition", "expires", and "etag") to control the
actions to be taken for a particular binding.  Any number of Binding:
headers may be present in a message.  In addition, a specific BIND
method is defined to decouple creating and modifying bindings from
user registration; its basic implementation is pretty similar to
the REGISTER method.

The first open issue raised by Henning was whether or not this
approach solves some of the problems that we have in a reasonably
generic fashion.  The second question is whether the proposal
addresses the right set of applications.  Third, may a generalized
version of PUBLISH solve the binding problems as well?  While Henning
sees views this to be unlikely, it still may need to be discussed.
Henning also talked about a few details but wanted the discussion to
focus on the general problem.  He also pointed out that, not yet
contained in the draft, BIND requests may be routed following caller
preferences and thus need not go to the registrar, effectively
allowing any entity to become a repository for bindings.

There was strong agreement that bindings are needed (and that they are
needed soon) and also that the mechanisms are likely to be different
from the PUBLISH method.  It was also found that this may go well
together with service route discovery, configuration, boot strapping,
and other work that has been going on recently.  Overall, it is
important to carefully scope this work: one may do quite a bit with
such an approach but, at the same time, it can also turn out to be an
infinite rathole of potential abuses (with quite some difficulty to
tell what is an abuse and what is not).  It is unclear what types of
"disposition" are legitemately bound to a URI and which are not.
People felt that nothing was wrong with the mechanism but that
semantics would need to be more clearly understood and defined and so
should be the intended uses.  If one finds alternatives for each
single use case, this specific proposal may not be needed at all.
Another speaker pointed out that this could be a nice and lightweight
rendezvous mechanisms for simple devices; abuse should be avoided,
however.  The author pointed out that, if pursued further, the
mechanism should stay relatively simple.

 From the overall argument, the group appears to be split: some people
want this yesterday, others may not want it at all.  Humming revealed
quite some support but also opposition, thus confirming the impression
from the debate.


SIP Compression open issues (Carsten Bormann, Gonzalo Camarillo)
   - draft-ietf-sipping-sigcomp-sip-dictionary-03.txt
   - draft-camarillo-sip-compression-01.txt

Carsten Bormann presented on the current status of SIP compression.
The signaling compression work is essentially complete; the documents
are in the RFC editor's queue and have even been assigned RFC numbers.
There are two loose ends remaining which may fit into the SIP WG: the
static dictionary for signaling compression and the integration of
signaling compression with SIP.

The static dictionary contains a set of well-defined strings that are
used by SIP and SDP; currently, this table is about 4,000 bytes in
size and is partitioned into five priorities.  There are only a few
open issues remaining: the recent changes in SIP documents need to be
tracked and corresponding additions/modification need to be
incorporated in the dictionary.  The most interesting issue here is
when to stop tracking.

There is obviously no single right point in time for doing so.  The
dictionary should be as complete as possible to gain most efficient
compression from the very first message exchange.  However, while
developed in the context of 3G requirements, the dictionary is of much
broader applicability, so one should not wait too long to enable
devices and applications to make use of it as soon as possible.  Since
the dictionary, once published, is not going to change anymore, it
should still be as complete as possible.  Hence, one of the key
questions is which additional words are missing right now; along with
this, it should be rationalized which keywords will be included and
which ones won't.  Headers that are too specific should not be
included; the size of the dictionary should not double.  A key point
here are P- headers: many people may have P- headers they want to see
documented tomorrow, but the most likely ones (such as those from the
3G community) should be; the proposal is to separate the "P-" from the
remaining header name and just put in "words".  This approach was
accepted and all the SIP specs will be reviewed again to make sure
that nothing important is missing.  The group agreed that the best
thing would be stop adding to the dictionary "now", i.e. as soon as
this review is complete.

As second speaker, Gonzalo Camarillo addressed how to signal
compression within SIP.  The current draft specifies a new parameter
-- "comp=sigcomp" -- for use in two places: in the SIP URI and in the
Via: header.  The parameter is meant to express willingness to
compress rather than support for compression; this distinction shall
help to use compression only where is makes sense.  The draft is quite
short and Gonzalo expects it to be uncontroversial but still asks for
feedback about the general idea.  Humming indicated quite some support
and only a bit of opposition.  The WG will consider this as a WG item,
pending AD approval.

The next steps are (1) to determine how to get SIP URI with the
"comp=sigcom" parameter in it and (2) to do an interop -- a real or a
virtual one -- on this work.  The SIP interop meeting in Atlanta in
October is considered a suitable place for such an event.  Robert
Sparks has volunteered to contribute to organizing the interop and
generating the test cases.

The first issue, how to identify that a certain SIP URI can and/or
should be contacted using sigcomp, provoked further discussion.  In
particular, that "comp=sigcomp" is attached to a SIP URI needs to be
learned dynamically.  This holds true for endpoints as well as for
first hop (outbound) proxies (for the first message they send).  To
make use of the dictionary (for the first message) at all, a SIP
entity that wants to transmit a message needs to know up front whether
it can compress it or not.  There may also be more options one may
want to discover than just sigcomp, linking this to configuration in
general.  Configuration protocols such as DHCP (where a SIP option
already is included, even though it is insufficient for this purpose)
or PPP should provide this information, preferrably in URI parameters
as opposed to numerous independent options; but they don't: URIs are
not supported by these protocols which limits the applicability and
extensibility of those configuration protocols.  (SIP implementation
may also not have control of the configuration protocols, making
extensions difficult to implement.)  As a SIP mechanism, UAs use
REGISTER and thus the proxy can learn their compression and other
capabilities.  To learn about the proxy, the UA can use the OPTIONS
method to inquire the proxy; the Max-Forwards: header may be used to
"direct" the message to a particular (the first-hop) proxy.  A further
remark was made on the use of TLS in conjunction with this: when
setting up a TLS connection, encryption as well as compression
algortihms are negotiated; this should also be considered in a revised
draft.

 From the discussion, a workable solution seems possible and the draft
authors are asked to flesh out more details on how this is supposed to
work.  There is another question on whether or not this is a SIP WG
item or if this is much broader in scope (i.e. configuration in
general) and should be looked at somewhere else in the IETF.  Whatever
the approach will be, this does not affect the rest of the draft.


Referrals from SIPPING (chairs)

The SIPPING WG has done requirements work in a number of areas and has
identified various places where SIP extensions are required and where
the requirements work has matured.  The work items discussed for
taking in in the SIP WG were:

* Content indirection: referring to a piece of information by means of
   a URL rather than including the information itself in a message.
   It was agreed to accept Content Indirection as a work item and adopt
   draft-olson-sip-content-indirect-mech-00.txt as basis for future work.

* Join: A UA's pushing itself into an ongoing call thus turning it
   into a three-way conference (e.g. to implement single line
   extensions); note that this is different from joining an ongoing
   conference.  This work item was adopted for the SIP WG.

* IEPREP: since there are no firm requirements available, this work
   item cannot be taken up right now.

The was also a brief discussion on SIP requirements for
hearing-impaired: requirements have been done in the SIPPING WG and a
design team is working on some mechanisms.  But the scope is not yet
clearly defined, so it is too early to consider this as SIP WG item.
At least a reasonable Internet Draft is needed to go for the next
step.  An a-hoc group meeting on this subject was announced, the
agenda being to which pieces are to be worked out next.


Future Work Planning (chairs)

The general idea is to move RFC 3261 to Draft Standard.  Besides this
master plan, there are a number of other work items on the plate to be
moved through the process -- and typically new work items keep coming
around.  Another important issue is the migration from IPv4 to IPv6
and interworking between the two; a charter item needs to be defined
for this.  List discussion, ideas, drafts, etc. on this subject are
solicited.  It was found that the NGTRANS WG also started looking into
SIP; they prefer this being looked at by the SIP community.  The work
may involve the SIPPING WG for some requirements as well as MMUSIC for
negotiation.  It was decided to start the discussion on the SIPPING
list.  Furthermore, an implementers guide was suggested; a work item
also belonging to SIPPING.

Finally, some discussion the state and cookies drafts came up.  People
were not sure whether or not those were really needed.  ITU and 3GPP
had expressed some need; other people felt they might use those
mechanisms if available but do something different if not.  One of the
core issues with state/cookies is that the requirements have never
been clearly defined -- and hence it is hard to devise (potentially
cleaner) alternative mechanisms.  This motivated the idea to push the
work back to the SIPPING WG to develop a clear requirements spec.  A
deadline shall be set and, if by then no requirements have been
defined, the work may as well be disappear altogether.



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip