THURSDAY, November 11
at 0900-1130
----------------------------------
0900 Agenda Bash - Chairs
- Gonzalo summarized SBC Ad hoc from Tuesday Night for people who
went to the social (does that make the rest of us anti-social?)
- USA Today - "Hate SPAM? Get ready for SPIT..."
Allison spoke during the
session about the conferencing framework document.
- We have a framework document here that talks about some XCON
things, and it's been suggested to use XCON as a black box, but want to
make this a SIPPING draft that can go forward quickly, and the XCON
document won't talk about SIP signaling. We want XCON to be usable for any
signaling protocol, not just SIP.
- Jonathan agrees with this separation in general. Can't totally
divorce these things because one guides the other. There's a signaling
plane and a policy plane (what XCON is doing). Need to talk about the
existence of policy, but don't define it.
- May be a non-SIP control of the conference - refer to this in the
SIPPING draft? Need to be careful here.
- We're removing details, not adding text, right? May need to add
some description of policy? Provide text.
- Conferencing package is also affected.
0905 Real-time Text over IP -
Arnoud van Wijk - draft-ietf-sipping-ToIP-00.txt
- Remember that text is a real media type in SIP!
- When designing services, be aware that ToIP is also there and must
be handled same as voice.
- This draft is now a WG item. We still have some issues that need
to be solved/worked out.
- Blocking must not happen in routers, firewalls, emergency calls,
services ...
- How do gateways know preferences of the user? RFC 3840 User Agent
Capabilities? RFC 3841 Caller Preferences? How do we know what services
are available? How do we know what services to invoke?
- Will all PSTN-IP gateways implement text support? How do you route
the call to a text-capable gateway?
- Tricky to define this behavior. PSTN textphone has severe
limittations. How will gateways/users cope with the differences? And
there's a US variant...
- Need to define handling of IP text users calling PSTN emergency
services
- Please contact me with text and comments.
- Open issues with the current document?
- Document is a good description of how to use SIP to provide these
services - but it's called a requirements document. Are there any
requirements, or is the description sufficient? Still thinking about the
need for additions to SIP protocol, may not have additional SIP
requirements if text is just another media type.
0920 Location Conveyance -
James Polk - draft-ietf-sipping-location-requirements-02.txt
- Carrying GeoPriv Location in SIP.
- Some changes since last version, including two new 4XX response
codes ("Bad Location Information", "Retry Location
Body") with IANA considerations
- We've solved problems like this before - think 911 with no
location object - this can't be voluntary, can it? UA has to include it
for the call to occur. We may need a different mechanism here (but don't
want to define it in this meeting)
- Added requirements on support for session mode
(larger-than-one-packet messages), SUBSCRIBE for location information
- Is "session mode" really "content
indirection"? No - look at SIMPLE prior art.
- Added requirement to allow user to turn off location conveyance
- Added discussion of non-dialog location conveyance
- Should a proxy be able to label its location information in the
"Retry Location Body" response?
- How does the UAC get location from UAS? in 1XX or 2XX responses?
Can we exchange locations in the INVITE? Maybe location is about presence,
so you've already got a subscription about this anyway.
- Does a UAC include location information from 3XX responses in
subsequent messages?
- Document is no longer "requirements" and needs to be
renamed.
<>How
does a new UPDATE with new location get sent to a second (and now appropriate)
emergency response center? Isn't fixing this more likely to cause failures than
continuing the previous information? Leave the call where it landed, but could
use a REFER, etc. to help ERCs subscribe to location updates. Is a GRUU what
you want here? At least a contact that gets you to the right instance (this is
a GRUU by definition). UPDATE proves this really wants to be presence anyway.
Jon will send text on this.Already confused about separate documents (not
necessarily WG documents) with inconsistent problem statements. Should UPDATE
be documented somewhere else?
- <>Location should be in one document so people can find it!
This is implementation errors waiting to happen. We need one document
about carrying location information in SIP, with requirements in the front
and mechanisms in the back, and we need to get it completed now.
- Make multipart mandatory? Kill Cullen, he suggested it, but we can
talk about this in SIP later. If we don't do mke multipart mandatory, how
can we make location work?
- What happens if a 200 response with a location object is too big?
This all gets easier if you use SUBSCRIBE and don't put any of this in
responses.
- How does the proxy tell the UAS what location object to put in the
answer?
- Proxies have to remember that the last request failed, but NOT
fail subsequent requests.
- How can location objects be viewable ONLY by an intermediate
proxy? Encryption? Are we going to use end-to-middle here? Don't care what
the answer is, but requiring security for 911 calls seem insane.
- Intermediate includes a location indication about the UAC, but not
FROM the UAC. We are OK with this if the UAC consents, but split if the
UAC does not consent or cooperate - need motivations? 3GPP does this; UA doesn't
know its own location, but network can add it. We're getting close to
"Asserted Location" like "Asserted Identity". There is
implied consent, the inserter probably knows the location... Jon is not OK
with proxy servers adding a body, but wants this requirement in the
document (it doesn't require adding a body). Needs to not require
additional UAC capabilities. Reporting a crime doesn't consent to giving
YOUR location - can't assume implicit consent.
- Next steps:
- Adding response codes moves into SIP?
- Will not break document into requirements and
solutions - disagree on the list? But we don't have to solve every
problem to publish the RFC, right?
<>
0935 Event Package for
Floor-related Information - Eunsook Kim -
draft-ekim-sipping-conf-floor-package-00.txt
- Actual format will be discussed in XCON, we're just trying to
understand here.
- Motivation for policies - panel discussion in a conference with an
audience.
- Propose talking group uses floor control, listening group uses
SUBSCRIBE/NOTIFY
- Proposal contains data format, uses URN, describes an information
hierarchy closely tied to XCON work
- You're providing a second way of providing floor control - what's
the motivation for a second definition? Just support for legacy SIP endpoints?
Mostly providing state without providing floor control.
- Requirements should be done in XCON, doesn't have to be done here
just because it's SIP. Is this information useful without the conferencing
package?
- Existing floor control is OK, but would like to see a better
explanation of what someone would DO with this proposal. Need rationale
and scenarios/use cases.
- XCON ad hoc is coming up with a similar approach, still not
complete agreement on what a floor actually IS.
- Floor control protocol was supposed to be simple, but people want
richer information (don't know what this means, except that it's not in
floor control protocol). Use floot control if you're just listening?
- Creating a new protocol isn't the right way to fix floor control
if we screwed it up - we need to fix it
- "Conference fogging" needs to be discussed.
- Existing floor control program can provide all of the information
the floor controller has...
- XCON chairs need to figure this out, because it's firmly in scope
for XCON - we just want to see more scenarios and use cases.
- There's noting in this proposal that restricts it to CENTRALIZED
conferences (but would others have floor control?)
0950 Event Package for Device
Information -Brijesh Kumar - draft-rahman-sipping-device-info-01.txt
- Purpose is to retrieve a devide profile and status information
- Need this for device monitoring and changes in operating status
- Have defined a core device profile (type, name, model, URL,
software version, etc.)
- Getting feedback from the mailing list - Cullen suggestion -
device could support multiple schemas
- Concern about distinction between capabilities and status. Need a
mandatory-to-implement MIME type for interoperability to understand what
comes back in a NOTIFY - you're adding indirection without helping with
interoperability.
- What are the use cases? If you can't tell us, working group status
is premature.
- Is this about distributed device management in the full FCAPS
sense of "management"? Supporting diagnostics, for example, is a
worthy thing to do, but you need to do architectural work first. The room
doesn't know why you need to know what you want to know - can't support
working group involvement without understanding.
- There's overlap with other packages here.
- Is this about local devices or remote devices? Do you need SIP to
talk to a local entity? Take a look at RFC 3259 and get back to us?
Capabilities are static, and we're also trying to learn status.
- Dean did some scenarios about human and device interaction - very
entertaining!
- Looking for inputs on device profiles.
<>
1005 SIP and SPAM - Jonathan
Rosenberg - draft-rosenberg-sipping-spam-01.txt
- Changes from previous versions - address obscufication,
limited-use addresses, session versus page mode, stronger emphasis on
white lists.
- Not a lot of comments so far - make this a WG draft? What
direction should the document go? Discussion? Framework? Requirements?
- Suggest requirements before framework :-)
- This isn't protocol work, there are a lot of problems here that
will lead to trade-offs. This won't really be requirements beyond
motherhood and apple pie.
- Document now is mostly really a survey, but it does lead to some
conclusions ("strong identity, consent framework...") "Wow,
look at how many of these techniques require strong identity", etc...
- Relationship with ASRG? Coordinate? would be helpful, some
happening already - look at applicability to SIP.
- Adopt as WG item? Hummm is "yes" in the room.
- Informational discussion? Jonathan needs to think about possible
directions, anyway. Two topics - how do we operate systems (BCP) and how
do we change protocols (protocol specs). Requirements may be about
protocol mechanisms, more than "define spam". Any new
mechanisms? Hash-based, payments and risk-based... proposals do include
SIP protocol changes.Start with what we have today? That was the goal for
the draft so far.
1025 Direct Transcoding -
Kang - draft-taegyukang-sipping-transc-itg-00.txt
- Working on intelligent transcoding gateways.
- No additional signaling session, but inserting additional codec
information at a midpoint.
- New opportunity for transcoding between network types (LOTS of
opportunity)
- Looking for feedback here...
- Eric - we have three customers who do this three different ways.
We would like to have a standardized way of inserting this codec
information.
- Transcoding work has been waitlisted because SIPPING had so much
work in flight - we want to support this somehow, and want to work with
you on this requirement
- Security considerations could use some work ...
- Others have played with something like this - need an identifier
for the transcoded resource
1035 RTCP Summary Reports -
Amy Pendleton - draft-johnston-sipping-rtcp-summary-04.txt
- Draft title has changed
- Have changed event names, performance report names, adding new
capabilities beyond voice quality
- Adding call flows
- Adding event timestamping and thresholding
- Finalized details on PUBLISH and event state
- Working to reduce messaging load
- Providers have this capability now in gateway protocols
- This capability will be met - if not this way, by SBCs that
rewrite SDP
- Limit scope to RTCP, not general SIP performance
- Coupling to SIP is very reasonable.
- Like the scope now and don't want to add a lot of stuff.
- We talked about this a year and a half ago and agreed it would be
individual, reviewed in the working group, and then forwarded. Didn't have
consensus to make a WG item then - has this changed?
- Relaying media traffic just to observe it is problematic - this is
better
- We need to be moving to operational considerations for SIP
networks
- We want the quickest path forward - no timing difference for
proposed standard
- How will people find out about this if it's an individual
publication?
- We will issue a working group last call (after asking for official
permission to adopt the draft!) and schedule it on the next available slot