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