[Sip] Notes, SIP Session 1 from Vijay Gurbani

["Dean Willis" <[e-mail]>]

HTML posted at
http://www.softarmor.com/sipwg/meets/ietf53/notes/notes-sipwg-session-1-
ietff53-gurbani.html



Notes, SIP WG, Session 1, IETF 54

------------------------------------------------------------------------
--------

Reported by Vijay Gurbani,
vkg@{lucent.com,research.bell-labs.com,acm.org}, edited slighty by Dean
Willis


------------------------------------------------------------------------
--------

19:30 CST meeting started 19:33 Agenda accepted 

Work Plan update:

* We have revised the SIP spec; went to IESG; resulted in a "Yea" from
IESG. SIP events spec is done.

* Session timer is back to haunt us -- goes back to authors for bis
update. 

* Caller pref - pending from author for bis. 

* Precondition extensions -- in WGLC now; in IESG by April SIP 

* Privacy spec from DCS in WGLC now, IESG by April 

* REFER Method; needs bis, security updates. IESG by May? No complaints
from authors. More important since there are many implementations
already. 

* MESSAGE method ready for WG LC -- have not done it yet. 

* PATH method needs rev from editor. Call for volunteers. 

* NAT awareness: rev pending from author. 

* SIP Privacy and Security reqs to IESG? There is a feeling that the SIP
extensions for privacy wrt to 3GPP is not acheivable -- Jon P: some
privacy (user provided privacy vs. network provided privacy) nuances
have not been captured as of today. Henning: that would make a lot of
sense if we know what we wanted -- another req document is not in and of
itself useful. Dean: SIP privacy and security reqs predate the SIPPING
WG -- IESG felt that it is such a critical piece that it should stay in
SIP WG. 

* SIP over SCTP? Gonzalo: we are ready for WG LC for SIP/SCTP. Dean:
Also in July timeframe -- have a draft standard version of SIP -- #1
goal in July of 2003. Original SIP spec was 2543, we want to claim new
number of 3543 :-) 

* State: Charter item of pushing certain things off the SIP signaling
state -- state or cookies specification translated to SIP. Did we ever
come to a consesnus on how to go forward? Rohan: Cookies I-D is good for
doing what you want to do with the state I-D and is more general. I
support it. Dean: Anyone know of implementations? [No implementations
yet] Jonathan Rosenberg: The reason noone has implemented it is because
everyone is using R-R and Contact. It is not entirely clear to me that
this is even needed. Fleming: The difference is that R-R requires the
proxy to be in all signaling. Andrew Zmolek: We looked at R-R issue and
it seemed that we were going to have some trouble -- either the state or
the cookies would do fine JDR: R-R was not sufficient since there was no
reliable way to put something and get it back. With the new R-R update,
this is no longer an issue. rjsparks: You cannot change the state in a
dialog, you can only push and get the state. JDR: Okay, if that is the
requirement, then fine -- if the req is to just push state for the
purpose of a dialog, we have a mechanism already in R-R, Contact. Brian
Rosen: we may work on a requirement document offline, assuming that it
is useful. 

* General Scheduling:  Henning: meta scheduling aspect -- can you get
people involoved long enough to remember what the issue was? Brian: Our
goal is to get a lot of stuff out that has been hanging around for a
long time -- but we do not want to get out 12 LC I-Ds at the same time.
We will revive the LC schedule we had going. Henning: Do other I-Ds that
are not on your list wait until re- chartering? Brian: No. There are
some things that are hanging around for a long time; as long as the ADs
do not breath down on us, we will work on them as we go along. Henning:
Need a priority list. Jonathan: Learn from successes -- Bundle 1 was a
success delivery to 3GPP. With the current mechanism we were randomly
LC'ing. One of the thing the Bundle did is to focus people's energy on
that. Brian: We can consider that; Bundle 1's advantage was that the
drafts were related to one another. These do not. 

* What do we do with: sipping-conferencing-models? sip-3pcc?
app-componente? sip-vxml? Jonathan: need to finish bis update; but done
as far as I know.  Rohan: 3PCC is a very pure usage draft describing the
usage of baseline bis offer answer model. Most of the stuff above is
usage or framework, we should get it done in SIPPING. Brian Rosen: You
are basically saying what Jonathan said: Put it in Bundles. Rohan: Sure.

 

SIP Change process, Allison Mankin:

This is not a SIP draft; it is an individual transport area draft.
People have said that there is no need to control SIP information. The
Replaces header was done in a freeform manner -- this is not good. WG
discipline needed over extensions of SIP. RFC 3261 (new bis) has an IANA
consideration which is very different then what you have seen before.
You need a standards track RFC for headers, method, response codes,
warning codes. One place you do not need to do this is for the Events
RFC -- just need WG yes for these. serverfeatures did not go too far
with IESG since it offered unbridled extensions. We now have P-header
(not X-header, more constrained). Still need a RFC, but you do not have
to have the buy in of SIPPING or SIP. The string with P- is reserved if
they are to have a future life. Henning: while I agree with the notion,
the naming has the same problems that X headers had. Attaching a meaning
to "P-" is not good. Allison: They do not have option tags and have to
have applicability statements. Henning: There are 2 issues: naming and
process/applicability. If we have a header name which was registered
(say, foo); that header has the property that as long as it is in the
non-RFC track, it looks like a normal header. If it reaches standards
track, it retains its name. Lets say P-bar header becomes popular and
widely implemented. Now, if P-bar header goes to standards track, they
will have to rename this header. Allison: can you make a P-header a
standards track header -- add an option tag. Dean: The P- name will
still be registered and be useful. Now you will basically have to track
P- and non-P extension headers -- makes the symbol table little large --
that's okay. Dave Oran: feel uncomfortable in mixing naming conventions
and algorithimic behavior. I do not like the idea of having to parse
inside header string. Jonathan Rosenberg: The name of the option tag is
unrelated to the name of the header. Henning: HTTP extension model is
different then SIP extension model. There is no correlation in header
names and option tags. Allison: If the I-D has any implications of this
sort, we can fix it. Gonzalo: We have option tags that have no headers
associated with them. Keith Drage: We need to make sure that this I-D
does not contain any requirements on SIP implementation -- a SIP
implementor must not have to read this I-D. 

 

The UPDATE method - Jonathan Rosenberg :

Open issues 1) Glare with PRACK - UPDATE only specifies glare resolution
with itself. You can have glare with PRACK. Rejecting PRACK is bad.
Solution: can't send UPDATE if you have sent an answer in 18x for which
you have not gotten a PRACK. Will put some words with general caveats.
2) Repairable response codes -- automata can fix these without human
intervention. What about 493 Undecipherable? May require user
intervention to fix it. Proposal: include it, add text saying it retries
if it would otherwise retry with that response. [No one objected]. 3)
Generate 155 instead of 4xx MAY or SHOULD -- for backward compatibility.
SHOULD is better if the UAS supports this capability, the proxy may not.
This makes it work at proxies transparently. Comment: This text is
screaming for a reason header, otherwise the UAC will have to infer what
the problem is. JDR: I did not talk about reason header for a reason --
it is on a slower track. For the basic cases we are worried about
immiedately, the UAC can infer from the headers. Going forward, the
reason header is the way to go. Gonzalo: The last review of the reason
header already has this, so we can use it. Jonathan: Does the group
agree that the message sip (or sip frag) is the appropriate approach? Or
wait for the reason header (which is on a slower track). Rohan: Can we
pull out 155 out of this, then? [No consensus on this] 

 

Manyfolks open issues (Gonzalo Camarillo)
draft-ietf-sip-manyfolks...-05.txt 

We are now defining a framework for preconditions of different types. We
define the current status of the precond vs. desired status. We always
know if current status is better or worse then desired status. Two
status types: e2e -- always present in manyfolks (-04). Segmented status
type introduced in -04. 

Open issues: Meaning of Require: precondition -- 2 appraoches: I refuse
everything I don't understand. Or be liberal and accept the offer if the
preconditions can be met without your intervention? Which is better? 1
or 2? Comment: you can have a thing called "criticality" which gives a
hint on what to do. Gonzalo: I will decide after speaking to Mark. 

 

Reason code, Gonzalo Camarillo.:

Requirements: same functionality needed in several WG items -- why is
this request (or response) being sent? 

Useful in many works: ISUP/SIP mapping, in manyfolks (precondition
failure, unacceptable here), HERFP, 3pcc. 

Jonathan: Throw in another use: in the event that you fork the request
to a bunch of phones and one of them picks up. The proxy generates
CANCEL. The reason for CANCEL is not because the user hung up, but
because 1 of N answered. 

Rohan: Lot of overlap in the reqs that generated this document and
request history. 

Eric Burger: This is H.450 all over again. 

Jonathan R: Don't we have an enumerated list of response code in the bis
already? This is exactly that, and then some. 

Comment: we have one address space for responses, and we have just added
one more with the Reason header. Has a kitchen-sink feeling to it. 

Henning: The motivation was exactly to prevent reinventing the same
thing everytime. We are not adding new error classes that will have to
be percolated to all existing implementation. This is a fine grained
status code which is there if you need it. Example: Q.850 error code
will not be pertinent to many implementations, but to the one that it is
pertinent to, it can use it without too much perturbation. 

Brian Rosen: What do we do now? 2 possibilities: crisp set of reqs,
which are clear and this is a resonable solution. Or we do not have a
crisp set of reqs. We need to determine this first. Lot of discussion on
if this does or does not solve the job. But do we know what the job is?
Should we push this back into sipping and generate a req document? Those
who think we have a sensible set of reqs and we can move forward? Those
who need more reqs? [The hum level was 50-50, no consensus by humming on
if we have the reqs captured right.] 

Dave Oran: Need hum on slightly different -- do we get involved in reqs
that requires identity (being able to communicate why you are sending it
to this particular party). 

Brian Rosen: That is a reasonable suggestion -- so considered. We will
get the reqs out before Yokohama and bring the solution out before then.
Those of you who hummed against it should participate in the list when
we discuss this on it. 

 

 

Fleming Andreson, SIP Extensions for Media Authorization.
draft-ietf-sip-call-auth-04.txt :

Changes: Category is informational -- Header is now
P-Media-Authorization. Applicability statement about appropriate use
(SIP Proxy and Policy Server (PDP) must belong to the same domain)
Updated rules about when to add a P-Media-Authorization header.
Additional security considerations -- don't encrypt message bodies
(proxies need to examine them). 

Open issues: None known (authors list need to be trimmed), currently in
WGLC. 

Jonathan: I will send you some minor reviews. More look-see needed in
the security section. This token is about media authorization --
authorization follows authentication. DOes the I-D point out this issue?


Fleming: You do not neccessarily need to authenticate before
authorization. Some entity has been given an authorization token to
access some resource. 

Jonathan: More discussion maybe needed on the security section -- you
are 

giving a token to a party that you may not have authenticated. If that
is 

your model, fine; a couple of sentences would probably suffice in the
I-D. 

Brian Rosen: The WGLC is going to get over, if anyone wants to raise
more issues please do so. It fills the needs, even though it has a lot
of limits. LC be it, we will move forward. 

 

 

Ben Campbell, SIP Extensions for IM :

-05 draft; recent changes -- remove CPIM mapping to separate draft.
Would like to include in 3rd bundle to IESG. 

Highlights - sends IM; does not initiate a dialog, does not discuss
message sessions; actual message in bodies. 

Open issues: No recent discussions. Needs minor editorial changes
(forking, threading -- couple of sentences). Anything else? Is it ready
for LC? One more revision -- no change in substance, more editorial. 

Brian Rosen: Ok, as soon as you have the revision, we will post it as
LC. 

Brian Rosen: Administering this list is no fun -- people forward their
email to accounts that consistently run over quota. The list is setup so
that only subscribers can post. 

 

 

21:29 CST - WG adjourned. 


_______________________________________________
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