Notes, SIPPING Session 1, IETF 56

Reported by Dean Willis

Scribes: Vijay Gurbani, Mary Barnes
Chat coordinator: Al with the Hat

Topic: Service Examples, Alan Johnston

Moving well. No comments.

Topic: cc-transfer, Alan Johnston

Ready for Last Call proposed, no objections.

Topic: Status report: Chairs

Note chairs believe that formal expert review is not required for all individual drafts. Current policy is to announce the draft to the list, and ask the participantst to verify that the draft does not conflict with WG efforts.


Topic: Caller-Preferences Use Cases, Jonathan Rosenberg

Poll: Useful, interest in accepting as WG document? Strong consensus. Suggestion from AD that use cases be packaged with CallerPrefs drafts.


Topic: Persistent Connections, Vijay Gurbani

Basics presented. Discussion ensued. Question: What is the requirement difference between signaled persistence and simply configuring persistence? Assertion: Reuse is only important in the client-server case. Assertion: This sounds like my kids discussing bedtime. There is really only reason to close a TCP connection -- to recover resources. Therefore, the interesting thing, is not how do connections come up, but figuring out which connection to kill if we need to kill one. Assertion made that the mechanism here is equivalent to "just doing the right thing" with TCP, so we should fix it operationally, not by changing the protocol. Hum: Should we change the SIP spec to encourage leaving TCP connections open unless they need to be closed? Strong consensus reported. Proposed that we do minimal bug fixes in SIP, and do a separate document with an operational focus on "how to" reuse TCP, initially as a discussion and possibly leading into a BCP. No objections noted, Vijay Gurbani may volunteer to lead on usage document.

Topic: ICE, Jonathan Rosenberg

Provides general methodology for using address-fixing protocols to get SIP through NAT. Question: What is the impact if some sort of underlying mobility function causes node address changes? Does ICE resolve? Ans: Unknown, but we think it should work if the frequency of address changes is lower than 1/RTT. Question: Does having STUN server on every node open up the network to denial-of-service attacks on NAT translation? Ans: No -- at least, no more than port-scanning already would. Poll: Who read: fairly large number. Question: Muxing STUN and media -- is that required? What is the implication of demux? Ans: It seems to be feasible to use magic-cookies in the TUN level to work it out. Comment: This DOES require widespread deployment to be useful, can we get that? Ans: If it works, people will implement it. Question: What are implications if only one end supports?  Ans: We fall back to what we have now. Question: IS it easier to fix the NAT than to fix the SIP? Ans. Debatable.  There's a lot of $39 NAT boxes out there. Poll: How many people would be interested in implementing? (several) Will one volunteer to write the preconditions (document things like like SDP changes, requirements in SIPPING) Yes-- Cullen Jennings. Poll: Would you like this work to be documented in SIPPING, along with fallback to previous modes? Ans: Loud response, a few dissenters. Proposal: Cullen to work on preconditions, Jonathan to work on furthering ICE draft

Topic: Session Policy Requirements, Jonathan Rosenberg

Reviewed scenarios. Poll: Do we want to work on this? Brian Rosen reports that he really needs this for dealing with 6Mb/s streams and managing admissions policy dynamically. Another comment made that this approach could obviate the need for some B2BUAs. Comment that we should add requirements to do this without "new headers" and it shoud work with e2e encryption (req #1 in presentation). Poll: who thinks we should take this work on as a baseline for requirements? Strong consensus reported, none opposed.

Topic: URI Leasing, Jonathan Rosenberg

Material introduced from slides. Question: This allows for temporally scoped URIs. Can we give an example of where this would be useful? Ans. Assume a conference call running over a set time. Discussion that current document may be a bit complex in this area. The word "temporal" is probably misapplied in this context and the author would like to withdraw it. This all comes down to embedded route headers vs. a lease-and-preference model. Perhaps we need to step up a level and ask what the top-level requirements really are? The draft proposes three explicit. There may be also "without hiding state in the domain name" and some others. Comment: Leasing seems to imply temporal scoping. Huh? Long discussion . . . Comment: It seems that all of the given requirements could be met by relaxing a single restriction in 3261.  Conclusion: More list discussion on requirements needed.


Topic: App Interaction Design Team, Jonathan Rosenberg

Minimal activity since last meeting. We may need to consider use cases illustrating the requirements.


Topic: Conferencing Design Team, Alan Johnstson

Requirements, Framework, and Call Control ready for WG adoption. Conference Policy is splitting into two and should be ready shortly. Media policies work requirements progressing, work on policy manipulation is ongoing, and the policy work needs a new home. MMUSIC is not going to adopt this in their new charter. Observation: This policy work is related to data manipulation in SIMPLE, can we combine it? One is data manipulation, the other is policy RPC.

Open issues recapped in slides. Discussion of absolute vs. relative time in focus. Why not have absolute time? Ans. Simplifies timeing coordination on focus. Comment: We do have requirements for realtime transitional controls for things like camera-follows-speaker. SOAP and ACAP don't combine to meet this requirement. Ans: This is for more persistent policy, not floor-control. Floor-control remains a media problem.

Poll: Do we wish to, as proposed, adopt the requirements, framework, and call control drafts as wg efforts? Strong consensus, no objections.

Question: Is discovery in-scope? It could be a furball.

Request: Make focus migration happen sooner rather than later. This will be required for three-way to more-way migrations. This is also important from a fault recovery standpoint. The call-control is easy, just a REFER series, but handling the policy migration is more interesting.

Topic: Hearing impaired media transcoding, Gonzalo Camarillo

Work proceeding, no surprises.

Topic: Emergency calling design team, Jon Peterson

Work proceeding, will have face-to-face meeting here. Two cases -- regular 911 calls, and PSAP access-link replacement. Can we divide these two cases so that there is something available for "today's PSTN PSAP"?


Topic:  Event Throttling Requirements, Aki Niemi

Notification rate limiting is the "common factor" among most of the event filtering discussions. Issues: Is the model accurate and appropriate? Do we need both the leaky bucket and the strict throttle? Is it ok to leave handling of quarantined notifications out of scope? Is this work useful?

Discussion: It may be important to have a different throttling mechanism for "aggregated/filtered" notifications than for simply prioritized or decimated notifications. The current work does not really consider notification volume/size, just counts. Discussion about the difference between quarantine and gating/throttling functions. One can define a five-token multibucket scenario that's fairly complete. Is this too complicated to be practical? Volutneers to review reqs -- Jonathan, David Oran, and Tomn Taylor volunttered. Poll for adoption: none opposed. Question: Is there standardization required to be able to rate limit?