IETF70 SIPPING Tuesday 9:00 am Notes by Brian Rosen ---------------------------------------------------- 1. Agenda Bash 2. Document Reports - lots of documents moving through Offeranswer-04 in review Henning: Lots of discussion of issues related to offer/answer in SIP Forum, this is related to that discussion Chairs: Post note on review of offeranswer in SIP Forum list Christer: Not a restriction of 3264, just clarification. May actually need some restrictions. At least should point out where some restrictions may be needed Basic KPML Rohan: Thinks this is a good idea. Jonathan: Too late, how many ways do we need to send DTMF Hadrial: Doesn't solve the problem: could send a static KPML document, but have to recieve anything Text over IP turntaking Chairs: need review to see if this is a reasonable approach Real Time Text Gateway BCP Domain Marking Requirements 3. Overload Simulation shows all simple (ignore, drop, retry) fails miserably. 503 stateless seriously worsen performance but so much faster that it's still in there. Keith: Is this statefull/stateless terminology in requirements Jonathan: no Volker: Stateless transaction allows proxy to check more INVITEs (3000 vs 500) After scenarios were simulated, simulations of solutions was tried. "Nortel" improves quite a bit. "AT&T" algorithm is even better. Rohan: Any IPR? Jonathan: I think there is some, but don't know Lars: All of these things fail, it just delays failure. They all collapse. Have expertise in IETF, lets use it Jonathan: We HAVE asked, no response Lars: Only looking at one topology, which may bias results Henning: Not like most congestion control functions Lars: Not implying something that exists would work, but need people with expertise Henning: There is expertise in the group Rohan: Is this all UDP? TCP would be different Jonathan: Yeah Volker: TCP is better, but still collapses Other algorithms have been proposed, but not yet simulated. Targeting proposal for Philadelphia (stretch goal) ?? Are people doing these on a single simulation platform? Jonathan: no, but we have calibrated them on the early simulation work. Henning: They are aligned. This took a lot of work. 4. Profile Datasets Sam Ganesan Base dataset, schema, extension mechansisms - a series of small datasets Includes rules for aggregation of individual properties and precedence between datasets Out of scope: individual properties themselves Lots of related and derived drafts. Some are based on this draft, which is not a WG item! Question: Should this be a WG item? Chairs: Humm for make this a WG item Consenus: weak but yes 5. draft-elwell-sipping-update-pai Update 3325 to add methods, in a trusted UAC and in a response Is there interest? Is SIPPING the right place? Is Informational appropriate? Jon: 3325 is Informational, this would have to be to update it. SIPPING is appropriate Jonathan: Support it; people are doing this, it works. This an 3325 Cullen: What is not here is what happens and what its used for Keith: Problems exist now, this doesn't change it. Jonathan: Doesn't want process <> reality to get in the way of doing the right thing Cullen: Previous comment was as an individual Jon: Doesn't think the P is actually a problem (domain restrictions) Cullen: There could be alternatives to this, should we wait Jonathan: Are constraints of applicability a limit to standards track? There are some things in 3261 like that Chairs: Humm for support, Humm for wait for alternatives Result: Weak consensus for adopt 6. Application profile - Salvatore Loreto Adds an application profile to ua-profile event package Allows a SUP UA to SUBSCRIBE to single or multiple application profile data Needs something to make app ids unique, perhaps a URN Need requirements for handling profile data in the NOTIFY Henning: Should be possible to make this simpler. This is way over-engineered Keith: you never define application: when it is appropriate to use application vs device or user 7. Presence Scaling Requirements - Avasalom Houri Requirements derived from scaling analysis Should not hinder any curreny policy or policy capabilities Linear scalability, not a lot more state, ... Should allow arbitrary federation topologies Some optimization proposals have been documented Jonathan: Thing these are pretty good Chairs: Where would this work happen? SIMPLE or SIPPING or SIP Robert: Need a round of conversations on that Jonathan: Channeling Keith: extensions to 3265, must land in SIP. Keith: Requirements here makes sense, decide where mechanisms after that Robert: Asked that requirements come to sipping not simple Chairs: Humm to adopt as sipping wg item Result: Strong consensus to adopt 8. SIP URI Service Discovery - Henning Schulzrinne DNS Based service discovery. Uses DNS-SD (Apple Bonjour). Some clients do it already. Multicast doesn't work because late joiners can't learn existing users Proposes _sipuri_udp, ... Some security issues: no authenticated services Open Issues: AOR or separate name space to avoid collisions Resolution mechanism deviates slightly from 3263 Keith: Discussed in SIP in Prague. Didn't adequately define the problem for which this is the solution Henning: Deployment scenarios are described - for example ad hoc networks Henning: Motivation is have these networks, installing proxy is not reasonable, this is a solution Cullen: Don't know how to move this forward, other proposals for DNS-SD are out there Henning: "Promises were made"... Cullen: Need to make the DNS guys bless this Henning: It's a quagmire over there. This doesn't change DNS-SD. Cullen: Before we could do this here, the DNS guys have to be happy. Could get RAI consensus, but not IETF consensus Dan York: Question why users would pay attention to warnings Henning: Option by diambiguated name space vs just a warning. There is no way to authenticate Alan Johnston: Like it. Need procedures to describe how to extend 3263 lookup procedures Marko: Same concern as Cullen, more than one local service discovery Henning: Happy to write a draft for Microsoft proposal, but have better things to do Marko: Maybe have to support more than one ??: SAP? Whatabout SSH like mechanisms for user ids? Keith: Solution belongs in SIP Chairs: Started here, agenda issues Keith: Need problem statement then work in SIP Chairs: Need DNS guidance, but also want to know if sipping community is interested Rohan: Need DNSOPS input first Chairs: Lets judge interest first Humm for interest Result: Strong support, chairs to consult with DNSOPS 9. SPAM Score - Dan Wing Spam Assasin for SIP Score the SIP message, along with call volume, etc. Then make routing decisions. Extensions to Via header. Summary score + detail David:Should have one header per domain, need some nesting, make decision downstream Chairs: Is there interest or not, can work on mechanisms EKR: Too many headers in email. No evidence we can standardize mechanisms to assign score Dan: Don't want to do that, just define mechanism to carry result EKR: This is way ahead of the technology Jon: Agree with EKR. If we had some observations (actual SPIT)... Dan York: Think we should do it. If we don't, will have lots of different headers like email. Need some authentication of sources Keith: Document in RFC queue states a bunch of techniques, this is one. Are we going to have a document per technique? Chairs: No plan yet ??: Support the work. If we dont start now, we'll just lose time if we don't start now RJ: Important. Some larger challenges in overall call handling, example, mass notification of school closing ??: We have drafts that say we will have SPIT, it makes sense to do this Jonathan: This is a process discussion. Looks like a great "Experimental" draft Henning: Classical case for Experimental, waiting will yield what we have today in email. Cullen: Length of line indicates interest and complexity of the problem. A lot of email techniques dont fit into a score of 0-100. Not ready for a mechanism. Need a BOF. Hadriel: There was a BOF request Cullen: BOF request was a disaster. Resulted in a bar bof, which was a disaster. Hadriel: Too early to do this Jon: Not a skeptic that SPIT will happen. The part that is interesting is not the color of the syringe that holds the vaccine. This is trivia. Not something we can do engineering on. Possible BOF out there. David: Calling traffic is determinsistic, ways to determine emergency notification. May not be able to quantify what 50 means, but we can send the data. Already getting messages with lots of weird places to put them. Lots of IPR in this area, beware. Chairs: May not be either or, BOF vs this draft Hannes: Complex problem. This is an architectural problem, would like to start the discussion there. Suggest a study group. Chair: what is the difference between a study group and a design team? Hannes: Study group looks more like a WG with meetings and agendas. Jon: Some diseases can be fought with abstinence. Don't see a plan for work which is relevant and achievable Chairs: Lots of interest, not sure how to progress. Will discuss with ADs. Jonathan: Suggest humm in interest in working on SPAM scoring (as opposed to this draft). Humm on whether spam scoring is useful Result: Weak consensus its useful to work on it 10. draft-wing-sipping-srtp-key Dan Wing Solves problem of recording of secure calls for auditing, regulatory requirements, ... Henry: Can be solved by recording at the end station Jonathan: Lots of existing systems do it in the network Cullen: Some cisco products to it indeed in the endpoint Eric: If you don't trust the endpoint so maybe do the recording where you do trust it Requirements: Work with every SRTP keying mechanism, Allow SIP encrypted. ALow SDP encrypted, endpoints must cooperate. Does not require B2BUA. Allow recording of all or selected calls. Proposal: Let SRTP keying happen. Take the key, encrypt it, and send it Christer: Transcoders have the same problem; not specific to recording Dan: Don't know if this works, especially issues of when this happens Dean: Sympathetic. Not sure use case works (old devices, could use a media relay). Dan: Would need a B2BUA EKR: How are you going to capture sip signaling Dan: Not. Modify endpoint to send SDP and the key to recording device Dan York: This is critical to rolling out SRTP Alan: Agree needed in marketplace. Mechanism is reasonable Francois: Weak in explaining requirements and use cases. Need to improve for next version. Chairs: Humm for interest Result: Strong consensus. Chairs will discuss with security ADs