SIPPING Session 1, Monday March 17th, 2003 19:30-22:00
Reported by Vijay Gurbani and Mary Barnes
Minor change from posted agenda; ieprep stuff moved to Wed. afternoon.
Gonzalo to talk about Early Media
Alan Johnston, Services Example
SIP Service Example I-D: Recent changes: new flow showing click2dial
using REFER. Replaced domain names w/ examples.com.
To Do: actual flows really stable except couple of them; need to add
text discussing how to implement services and tradeoffs between
them. By next time, this I-D should be complete.
Transfer: This version had few changes: added a section on use of
Referred-By header. Added selected message details. Added
many more call flows on attended transfer and unattended transfer.
Added a security consideration section. No known open issues with
the I-D. Open for WGLC.
Gonzalo: about a globally routbale URI, JOnathan is presenting
something. Will it have any influence on your I-D. Alan: No. But
if we agree on a solution it will be nice to reference it.
Rohan: We have 3 RFCs which have been published, considering the amount
of work we had on our plate. 2 on IESG queue; bunch of individual
I-D. 3 in here that are ready for WGLC. A lot of work is blocked
on other stuff -- call control, ICE, work going on in midcom, etc.
Node about publishing individual docs: it does not mean we do an expert
review. We do it only when we have a P header. A couple of
folks have asked for an expert review; we may do an announcement to the
SIPPING WG list and announce that FYI some work may be beneficial to the
community in general and may benefit from a review. Such documents
should not affect WG documents.
Maybe useful for us to split things into smaller groups -- some I-Ds
document usage of SIP, others talk about services (cc-conferening,
cc-transfer). It may be appropriate to let some of this work
proceed without supervision of the WG. We may end up doing this in
Vienna in order to get up to speed. Will like to get comments on
the mailing list or after session on if this is okay.
Jonathan Rosenberg, Caller Preferences Use Cases.
Problem statement: not clear what problems caller-prefs is trying to
solve. This I-D tries to make this more obvious by defining use
cases. Will provide some explanatory text on how to do this in a
proxy. Propsal: adopt as a work item for an informational RFC.
<Hum level taken; adopted as WG item>
ICE, Jonathan Rosenberg
We don't have a sufficiently good answer for NAT traversal in SIP.
Depends on business models, many different ways to solve it. 10
different solutions is as good as no solution. STUN, TURN, MIDCOM,
RSIP, etc. are all piecemeal solutions. How can we expect interop?
ICE is not a new protocol; it is a methodology for using address fixing
protocols. ICE explains how to use the other protocols for NAT
traversal. ICE properties:
- Always will find a means for communicating if one
physically exists.
- Always find the lowest latency communication path.
- Always finds the communication path cheapest for
the service provider.
- Does not require any knowledge of topology, NAT
types or anything.
I-D is not trivial; this is not a trivial problem. Benefit is
that it is one algorithm which lives in a client.
Henning: will mobility introduce some problems?
Jonathan: Not if IP address changes outside of 1RTT.
Drawbacks: both sides have to support it. May require an extra
RTT in call setup. Will reveal private IP addresses to outside
world. Requires muxing STUN and media on the same port.
Proposed plan: solves industry problem - lack of cohesive way to work
across NATs now. Also facilitates IPv4->IPv6 (and vice versa)
inter-work cases. Pre-conditions can be specified so that phones
are never rung unless both endpoints can hear each other.
??: This may be relatively heavy protocol. If we can convince
everyone to support this, it is okay. Otherwise it is hard to work
it in practice. Jonathan: This is a hard problem; how do we make this
hodge-podge work? ??: This just describes the hodge-podge. Jonathan: How
do I determine, if I am a phone vendor, which scenarios to support? ??:
I am sceptical that it will work -- relatively heavy for client
implementations.
Juha: There are NAT implementations that understand SIP. Why not
work on these implementations instead of having clients to change?
We should not give a message to the NAT vendors that they do not have to
do anything. Jonathan: It is easier to upgrade a pair of phones than
hoping that the NATs will work.
Rohan: How many people will implement this? <A couple of hands
raised>.
Will one of the implementor write a short I-D on the pre-conditions
in SIP.
Dave Oran: Even if you do this in endpoints, other things in the middle
will break. Expectation of what pepole have today is at least
somewhat correlated with reality. My concern is that this may
raise expectations.
Rohan: Hum on if we want to pursue this and document what happens when
you fall back. Hum on: If you think you will like this to be
documented by the sipping
WG and also to have the fallbacks mechanism to be documented by the
sipping WG. <Hum succeeded>
Jonathan Rosenberg, Session Policy Requirements.
What happens when a service provider wants to insist on some aspects of
a session (media flows through a realy, video not be used, etc.) So far
this has been done with SDP modification. Well known problems:
does not work with data encryption, requires proxies to have knowledge
of session descriptions, proxy complexity increases, ...
Solution: 3GPP does this -- they use 488 as a response code to list
codecs which are acceptable. This has some drawbacks as well.
Do we want to work on this problem? That is the real issue for us
to decide now.
Many people approached the mic and agreed to the requirements being
valid.
Gonzalo took a hum level on taking the requirements as base for the
work going forward. Hum level indicated interest.
Jonathan Rosenberg, URI Leasing.
Problem: SIP requires a call to be routed to a specific UA instance.
Would also like an alternative to dialog sharing.
Globally ROutable UA URI (GRUU): routable from anywhere, routes to a
specific UA instance, and maybe temporaily scoped (for cases like
conference I do not want the URI to be valid forever; after the
conference ends, the URI should become invalid).
Alternatives for getting a GRUU: Use user AoR; use device IP as URI
(NAT, firewall problem); caller preferences; embeded route headers (not
allowed in Contact URI, long term loose Routes have reliability
problems; route may only work from certain places).
Gonzalo: Need more discussion and work on mailing list before
reaching any conclusion right now.
App Interaction Design team, Jonathan Rosenberg
Some discussion on KPML: SIP vs. HTTP issue on posting requests.
Multiple apps: one app consuming input destined for other app.
Continuing issues: framework scope and complexity, supporting immediate
barge functionality in KPML, lifecycle management of UI components.
Dean: What if I want to use KPML to map my keyboard to a conference
control application. Can I do that with KPML?
Jonathan: Please send the use cases to me so we can document them for
consideration into a possible use cases document.
Alan Johnston, SIPPING Conferencing Design Team.
We have 6 docs that the design team has put out so far; some more
forthcoming soon. High-level reqs I-D; 2) a framework I-D; 3) call
control for conferencing I-D (add users) The following I-Ds relate to
conference policy -- how do we manipulate the media for desired mixing,
how to setup a conference, access control, ...1) ...
2) Media policy data reqs I-D; how media is mixed and how mixing ops
are performed 3) Media policy manipulation - looks at media operations
to change the topology (e.g. creating a side bar).
Related documents: conference package, floor control reqs, floor
control using SOAP, and caller prefs.
Status of work: reqs, framework and call control are relatively stable;
should fit together and tell a consistent story. Ready for
adoption by WG as official documents.
Other I-Ds relate to conferenc policy -- split into two parts:
memberships and general policies -- stable. Media policies is in
infancy. Need feedback from the group on media work.
Policy group needs working group home. Rohan: mmusic will NOT be
chartered to do this; so it is either us or a new BOF. Will work
it out with the ADs later. We have NOT (ed: corrected by dwillis)
been told that we have to stop working on this.
Open issues: conference policy protocol, floor control, notifications.
Dean: Reqs, framework, and call control I-Ds are ready to be
approved as WG documents. Proposal: we adopt them as WG
docs. Dean called for a hum; proposal accepted.
Open reqs: discovery, focus role migration, cascading and camera
control.
Gonzalo Camarillo, Media encoding for hearing impaired users Status:
have not progressed much since last IETF. Now that we have media
policy I-D and session policy reqs, we will make more progress for the
next IETF.
Jon Peterson, SIP Emergency
<Trying to backfill previous notes; Jon's talk was too short to
catch up. Hope someone else was able to capture Jon's notes>.
Event Throttle Requirements, Aki Niemi
Aki went through the model and the requirements (see slides). Issues:
Is the model accurate and appropriate? Do we need both leaky-bucket and
the strict throttle models, or is only one of them enough?
Dave Oran: Quarantining and throttling are not the same thing. One
introduces delay the other control rates.
Rohan: Jonathan, Dave Oran and Dean will review the I-D and the
update from them before this becomes a WG document.
Persistent Connection Management Requirements, Vijay K. Gurbani
draft-jain-sipping-persistent-conn-reqs-00.txt
draft-ietf-sipping-connect-reuse-reqs-00.txt
Background:
Based upon Rohan's original proposal
This proposal: one bi-directional
persistent connection model:
Pros:
o all pros of connect-reuse id
o Introduces predictability
o Supports hint/forced aspect
o Yields more control to implementer
Cons:
2 solution options:
o new via header field parm:
o New header, supported/require
Discussion:
o Cullen: Why wouldn't you do this
normally? If every proxy puts persistent
o Rohan: by hint or forced model, every UAS
would not automatically leave connection up forever.
o Cullen: But, you still need to configure the
policy; so why can't you just configure your proxy. Why do you
need a signaling solution?
o Rohan: From one organization to another, they
might not need persistence. This is different than only being
able to use one connection and that if its dropped, must be re-opened.
o Jonathan: Baffled by the scope. Important
needs for connection reuse: client-server to NAT is the real problem.
o Vijay: Even with that example, with just
connect-reuse there's still a problem.
o Jonathan: Thinks this is just something missing
from RFC 3261. Client can re-establish if it wants.
o Vijay: Nat is one thing. If you had 3 or
4 proxies; are you going to re-negotiate the certificate? Doesn't
think every proxy or UAS is going to leave connection open.
o Jonathan: You already have to be able to handle
with scenarios where the connection can go down. Thinks
connect-reuse is sufficient.
o Dean: Important in proxy-proxy case.
Don't want to keep closing and re-opening.
o Dave O: Sounds like my kids negotiating
bedtime; there's seems to be only one reason to close a TCP session -
to recover resources. If you don't buy that.
o Vijay: Agree with argument.
o Dave O: Interesting thing is which one do you
kill when you need to recover resources. IF this proposal adds
value to the policy decision therewith.
o Rohan: Original proposal semantics were just
being able to reuse connection. Vijay's proposal: IF you claim you
need a persistent connection, this info says that it won't do you any
good to close this, because I'll reopen.
o Dave O: Would this keep other guy from
crashing?
o Rohan: this would mean if it crashed, it would
immediately re-opened.
o Dave: No. It won't allow re-establishment.
o Dave: In the end, all the kids would go to bed
at 3am. You would get inflation of bedtime.
o Rohan: it would be an implementation by
implementation basis.
o Dean: this is the same as persistent behavior
until something takes it away.
o Sean: this is the same as "Everyone just do
the right thing".
o Jonathan: the spec says the minimum. This
sounds like a clarification to the spec.
Conclusion:
o Hum vote in support of: New bug in SIP spec,
that proxies shouldn't close connection unless there's a reason (i.e.
don't need a protocol solution)
Continuing discussion:
o Jonathan: may want further clarification; this
isn't suggested to solve the NAT issue.
o Cullen: this doesn't mean proxies are going to
use LRU.
o Dan: this isn't proposed to solve the
hijacking problem.
Continuing discussion:
o Vijay: thinks this leads to more simplicity
o Dean: fix the spec to encourage using TCP
connections. Write a separate operational document.