Notes on SIPPING Session 2 at IETF 62
Reported by Spencer Dawkins
FRIDAY, March 11, 2005, 0900-1130
0900 - 0905 5 minutes Chairs
Agenda Bash
• Not a lot of agenda bashing
1035 - 1050 15 minutes Orit Levin
Conferencing Package
draft-ietf-sipping-conference-package-09.txt
• Dean - we should be able to
send the entire conferencing package off to the IESG soon
• Have gotten WGLC suggested
changes on indexing of <user>, <endpoint>, <media>,
and conferencing media containers
• Index of <endpoint>
- list consensus is that the key becomes a single attribute "entity" of
type "string"
• Index of media container - will
remove <active-media> container from schema (not useful and
confusing), will index <available-media> by the "label" attribute
(corresponding to SDP label) - agreed at ad hoc meeting
• Roni - how do I know what media
is actually being used in the conference? "Available" is what is
provided in the basic SIP conferencing package, but you can't tell what
available media are actually being used - could "used" just be an
attribute for the media? This is possible. Is this an XCON issue? Roni
thinks that it is not, but is applicable to basic SIP conferences
• Cullen - we need to be very
clear about the relationship between SDP labels and SIP conferencing
labels - they don't have to be the same - is this an arbitrary sting
from a conferencing server?
• Index of <media> of an
endpoint - Brian Rosen has suggested having a global conference "label"
as the <media> index. Orit believes that ID should remain the
<media> key - label is also used for flow control - can we leave
the ID the way it is, in this area?
• Cullen - this dtaft was WGLCed,
and it was so broken it couldn't be implemented - can't base consensus
now vs the WGLC draft discussions
• Cullen - we do have to have 1:1
correspondance, servers can't do this the way the spec reads today
• Dave Oran - I've read the draft
multiple times and still don't know how products should work - that is
NOT a good sign
• Brian also suggested changing
the label for a user from a URI to a string
• Henning - given the discussions
we've made this week, it seems premature to be finishing up the draft
• Sense of the room is that we
have strong backing to leave the label imprecise
1025 - 1035 10 minutes John
Elwell Redirection Reason
draft-elwell-sipping-redirection-reason-01.txt
• List discussion - is Q.732 OK
instead of inventing a new namespace?
• Can a Reason header field be
used in responses? We designed SIP to use Response Code already
• Jonathan - all this stuff is
supposed to be in URIs anyway
• Are we trying to add this to
History and solve this problem too?
• Are we talking about adding
History TO a URI? Can 302s contain History-Info? Does the UA see
retargeting?
• Robert Sparks - we're talking
about providing information that will go into the NEXT request, right?
• Francois - History is a dumb
idea, you're just recording what happened
• What's the 302 ambiguity
problem, anyway?
• Rohan - We're not talking about
registries of new things that happen in the PSTN
• Jon Peterson - we should be
taking this to the list
• Gonzalo - are we talking about
something new or something legacy?
• Rohan - although 3364 was done
in MMUSIC, updates will be done here - Jon Peterson - actually, we're
still discussing this, based on where we would get the best feedback,
and that may still be MMUSIC
0905 - 0915 10 minutes Cullen
Jennings Multipart
draft-jennings-sipping-multipart-00.txt
• Moved out the the certs draft
• RFC 3261 did not provide a way
to migrate to to new body types in offer-answer - visualize moving from
SDP to SDPng
• Pass an offer for secure dialog
and one that does not - this allows downgrade attacks, but people are
doing it
• Sending one type and trying
another when it is rejected doesn't work - if you have voice mail that
supports secure offers, you'll always be connected to voice mail
• Henning - what if this is
actually what you want to happen? is this going to be a real problem in
practice?
• Add Prerequisites? Just send an
offer and do something if you get a 415?
• Just let you pick the best body
type you understand?
• Jonathan - could you base this
on secure presence? Not for PSTN gateways
• It's not just secure/non-secure
- there are a range of possibilities
• Henning - possible to have
combinatorial explosion in the future?
• Like solution two - wireless
providers that could offer unicast/multicast - Henning - is this
applicable? Won't both be in SDP body parts?
• Eric - is there any reason
we're not signing the whole request so we can tell if an alternative
drops out a part that we like? Attacker can blow away all the parts and
provide anything they like, in the absence of Identity?
• -------------------------------
• Problem is that semantics
aren't clear enough here - need to make security issues clear
• Rohan - there's currently not a
solution in a single SDP
• How will this proposal work? If
you have encryption and get retargeted to a device that doesn't have
the right key, what happens then?
• Jonathan - this definitely
comes down to scope - we are talking about MIME alternatives, anything
else is out of scope - we have mechanisms for extending SDP that we've
used many times, we don't need multiple mechanisms to do the same thing
• Cullen - the draft IS about
MIME, ANAT isn't mentioned at all
• Cullen with revise and resubmit
• Francois - what if you need to
change something later in a call? This is about where we start (as
compatible as possible), we can change things later in the call if we
need to
e0915 - 0925 10 minutes Cullen
Jennings Status Update HashCash & Pay
draft-jennings-sipping-pay-01.txt
draft-jennings-sip-hashcash-01.txt
• Both about responding to SPAM
(actually, to SPIT)
• Fixed rate or "free" SIP
providers create problems that PSTN billing used to solve
• Some calls will always cost
(Inmarsat calls, etc.)
• Paper isn't free, but it's
cheap enough - don't want to make calls too cheap; if I get the same
number of calls that I get SPAM today, I'll turn my phone off.
• Trying to raise the cost to the
sender, doesn't have to be raised much to be effective
• Need to work for very small
payments (one cent or less) -simple and lightweight system doesn't need
to include larget payments
• There is a community that wants
the Pay approach
• How to mitigate "ring a million
phones at once" problem
• Document has not gotten strong
security review
• Like this draft - one problem
is computers that will call
• What about "receive
notification from airlines" problem? People want get these, but won't
add the senders to their whitelists
• Henning - we discussed this
mechanism years ago
• Cullen - if people can still
SPIT, there's no way to move forward - no one will have their phones
open for emergency calls if they get so much spam they turn phones off
• Henning suggested that we add
this to authentication framework
• Francois - how do you avoid a
network storm? Need to work out what happens with this - clients
shouldn't require this from service provider
• Henning - if you made it two
orders of magnitude more cost to send a message, will this work in that
environment
• Spencer - what about botnets?
This is the most significant problem with this proposal. Are there a
limited or unlimited number of bots (owned machines)? Even five percent
of the Internet makes this approach useful.
• Jon Peterson - if this approach
helps other approaches be more effective, maybe that's the best we can
home for
• Is there a crypto solution that
uses reputation?
• We need Identity finished!
• As we move to flat charging,
this becomes more important
• We're talking about the
recipient being able to decide how hard it will be to call the
recipient, and there may not be a prior relationship
• This isn't any different from
Amazon.com or downloading "legal" music - that's negotiated, too
• Jonathan - spammers are
hashcash-rich, I like the payment draft better - how do you introduce
this technology? Has to be mandatory with no fallback or it's not worth
doing. Interdomain-only? The goal isn't to stop all calls, it's to set
a threshold
• Jonathan - we need to be clear
on the problem scope in the draft - where do we use this? Any existing
protocol? SAML, but no one is willing to offer less than 32-cent
charging with SAML
• Rohan - there is a real cost to
the person providing a service in some cases (satellite to a fish
boat), but not in most cases
0925 - 0940 15 minutes Aki Niemi
Event Thorttles
draft-niemi-sipping-event-throttle-02.txt
• Fixed ABNF definitions
adding alternatives to existing alternative sets
• Estimated bandwidth savings,
talked about compression schemes, rewrote model (dropping theory
discussion)<>
• <>Added IANA
considerations
• Discussion - throttle based on
time between notifications or based on net bandwidth consumption - is
"time-based" the right answer? Too hard to throttle based on bandwidth
• Henning - bandwidth approach
needs to add leaky bucket - it's not clear how to figure out bandwidth
before you start consuming it
• Spencer - are we talking about
a number that will be picked or a number that will be adjusted? If
we're picking a number, we need to remember how low available bandwidth
can be on production networks
• Cullen - how much vaiability
are we going to see? Is two orders of magnitude going to be useful? Not
sure I see the use case we're solving.
• In JABBER, we're in TCP, but
what we do is slow down people who talk too much - this can be an
automaton
• Adam - any data that changes
rapidly that gives you overwrites - this helps with those cases - we're
not solving the general congestion problem
• Jonathan - this is
semantic-free rate control - should we be sending a filter that stops
the information at the sender?
• Chairs will poll the list for
consensus
1005 - 1015 10 minutes Henning
Schulzrinne LESS: Language for End System Services
in Internet Telephony
draft-wu-iptel-less-00.txt
• This is a heads-up son-of-CPL,
adding modern services like location-based, event-based
• Triggers - incoming, timer,
UI:command, IM:message, Event:subscription, Event:notification
• Lots of switches, lots of
actions, see the slides for details
• Rohan - what do you want
SIPPING to do with this? Telling Henning if this is interesting, IPTEL
is no more and this is clearly SIP-related
• Rohan - any SIP extensions? No,
more like policy documents
• Ben - remember the overload of
working groups
• Hum of interest? fair amount in
the room
• Adam - we have new-shiny
syndrome - this isn't about a working group, it's about one community
that will be wherever we do this, if we do this
• Allison - sounds attractive,
don't want to bind the working group to do this
• Henning - is SIPPING still a
distribution center?
• Rohan - send an announcement
saying "we've implemented this, come join us" - that's sufficient
• Allison - we're getting
feedback from other communities that there's so much SIP that other
communities are doing their own SIP monolith - would discourage
Informational publication at this time
1015 - 1025 10 minutes Henning
Schulzrinne Session Mobility
draft-shacham-sipping-session-mobility-00.txt
• Also a heads-up for the
community
• Want to move sessions from
device to device
• Split session on multiple
devices that make up one logical device (audio one place, video
elsewhere) - need B2BUAs to make this work