IETF SIPPING WG, Wednesday, Nov 20th, 2002. Reported by: Vijay K. Gurbani Logistics: Brian Rosen retiring; Gonzalo Camarillo (Ericsson) new co-chair. Dean Willis remains as co-chair. Rohan: SIPPING has become quite a productive working group, my initial doubts notwithstanding. RFC'd: nao-reqs, isup-sip, dictionary; IESG review: 3pcc, overlap; WGLC: 3g reqs, mwi, dialog pkg; IETF LC req: content indirection, overlap, reg pkg, basic flows, pstn flows; ... Lot of individual work going on as well: app interaction, conferencing, config, qsig, deaf/xcode, netannc, osp token. WG item: cc-transfer, e164, cc-fw, conf-models, conf pack, nat-scenario, svc flows, fax flows, aaa reqs, req hist, conn reuse. Keith D: WHere is filters work going on? Rohan: It is out of scope of sipping; going on in opes and lemonade; maybe out of scope in opes. Jonathan R: On event filtering, we should scope the req work and treat it package by package. Filtering is a body type in SUBS; it's not a SIP extension. simple can do it as well. We do not do general reqs; only do pkg by pkg reqs. We can look at reqs for rate limiting in sipping. ROhan: Anyone expressed an interest? Eric Burger: many packages need this (rate limiting); everything else appears to be pkg specific. Some people thought that there could be a generic framework for rate limiting; everything else is pkg specific. Jon P: No problem doing presence specific limit filtering. Sean Olson: Lets learn from presence first and then let's see what we learn from this before doing rate limiting general framework. Rohan: We need reqs for rate limiting that will come to sipping. . Registraton Event Package, Jonathan Rosenberg Changes: In IETF LC. One change: add shortened event to the state machine. Open issues: default expiration matching default registration expiration (default lifetime: 3600 sec, same as default registration time). Made people nervous due to race conditions/synchronization problem. Proposal: change to 4200s. XML vs sipfrag: why convert reg msg to XML? Because we want to separate data from the protocol. We are reporting changes in data. It is possible for registration information to change not thru registrations. The data is in XML, not in the registration message. Not a complicated piece of data. JDR asserts that we should stick with XML. ANy comments? Sean Olson: XML seems like overkill here. Rohan: Is it worth changing at this late stage? What format would you prefer? Sean: Boils down to the processing loads, unpackaging and packaging XML. Depends on the end point. Jon P: I support XML for this. There are other things we will want to do along this vein and having XML at this early stage makes sense. JDR: We can negotiate other types if needed; dosen't rule out sipfrag. Cullen: Depends on how you will feel if people write parsers to parse just that syntax and break on other syntaxes. Extensibility mechanism of XML is much richer. Keith D: This can boil down to a new version of binary vs. text. Gonzalo: We will like to ask for consensus. SIP-T Issues, Jon Peterson Current work done; SIP-ISUP is in authors 48 right now. Overlap I-D is still in progress; not a general solution -- there is none. What should we do? SG11 is considering using this from the IETF. No solution: we can abandon this I-D and say use en-bloc signaling and do NOT use overlap signaling (SG 11 may standardize their own in that case). Adam R: A lot of people will have a compelling reason to do overlap more than not. Maybe we should give guidance in that area. Rohan: People who are using overlap have a business reason to do so. We do not have an answer to that. IETF does not make business/policy decisions and by not publishing this draft you make a policy decision. Gonzalo: I would like to publish this draft since we have a lot of information we have captured in this I-D. Many people ask this every week. Cullen: Maybe we can publish it as Informational. Allison Mankin: trouble is IESG is very sensitive about SIP-T; Steve Bellovin is from VoIP security and this looks like a thing with a lot of security issues. You would have to do a lot to make it look it as a documentation walled off from its security implications. Maybe we can have a phone conference to finess the security flaws. Lets also talk about them doing their own document so it does not bother us too much. Rohan: Folks would do this if there was an ITU spec; I would rather there be an IETF spec. Adam: thru the development of this document there's been many proposals on how to do this. I fear if we hand this off to other group who does not have the SIP depth, we will get a solution that does not interoperate with many SIP devices. Keith D: I am not convinced ITU will go away and devise a solution. The main justification for having it is that the calling user is working from a telecom system that cannot send an en-block number in the first place. If we train the user to enter the whole number as in wireless, then you do not need this. Jon: TG and CPC are currently being considered in iptel. Jonathan: They have not been accepted as WG items; TG may be, it does not seem controversial; I am not sure about CPC. Jon: NEw directions for SIP-T: SDP mapping: draft by Gonzalo on early media other SDP mapping aspects: code mapping and absence of SDP (in case of 3PCC). Q.931->SIP mapping: widely implemented without a standard, not sure what value a standard will add to it. Privacy-identity mapping for SIP-T: SG11 already looking at this. We are looking at the P-Asserted-Identity version, not the long- term identity we discussed in sip yesterday. Rohan: Any comments? Jon: Let's at least do the privacy mapping for long term identity. Allison: Now that there is a motion of cryptographic work by ITU, we can go informational if you want. Jonathan: If we do not say anything, how likely is it that people will break existing things? I am concerned about 3pcc cases where 2 devices being 3pcc'd together were behind gateways. I would propose this as a bar -- i.e. how likely is it that people will break existing things. Mary Barnes: One of the reasons there isn't any ITU involvement here is that most are in their meetings. Jon: Anyone will object if we say that we will NOT do Q.931 mapping? Allison: We can put it in the 'non goals' of the charter. Rohan: We can figure out if this is a non-goal for us right now since it is not critically affecting our current work load. Gonzalo: I would like to minimize educational I-Ds. Takes away a lot of our cycles. We have to work on things that may be harmful to us if we do not pay attention. Jon: I will take a stab at Privacy-mapping I-D. Rohan: Unless someone objects, we will not do any Q.931 work until at least next meeting. Gonzalo: For SDP mapping, it has to be done; not high priority but we will have some cycles to work on this. Cullen: We should probably take it to the list just to be sure we got everyone covered. Gonzalo: Consensus: do people agree on working on document on how to use existing tools on providing early media in SIP? A document that explains how to use UPDATE and other tools to do early media? 3PCC/SDP interworking with PSTN - No one hummed. Jonathan: One reason for low volume of hum is that we do not have a good idea on what the problems are. Maybe too early to hum. Rohan: We should go to the list. Jonathan: We should get an I-D first. Message Waiting I-D, Rohan Mahy Updated the I-D; most major change. Henning: couple of things are complex enough to be non-trivial and not important enough to be useful. Given that we do any other events stuff align it with event style description rather than having a restrictive count only description? ROhan: I think the semantics of this are good; I dont think that people are interested right now in implementing it with XML. We do have a built in extensibility. My preference is to go ahed and leave the I-D as is. I originally had an optional XML body first, but was yanked out due to lack of interest. Rohan: Any objections on using text based format? Open issues are minor and editorial in nature. I was blocked for Jonathan to do an update on caller-prefs and now that it is done, I can update this I-D. Transfer, Alan Johnston A Refer-To URI needs to allow the transferee to reach the transfer target. One way is to put Route header in a Contact, but this is illegal as per rfc3261. Jonathan: This problem keeps popping up in many places; in conferencing it happens as well. My preference is not to solve it here, but rather do it in a separate I-D. Rohan: Who will write the I-D on this besides Jonathan? Remaining work: close open issues, track REFER as it completes, add uses showing Referred-By. SIP Service Examples, Alan Johnston Open issues: call hold SDP. Request History, Mary Barnes Added specific req to address Optionality. Removed security req which states that it was a MUST to determine if an entry had been removed. Removed solution oriented text. Solution draft: defines History-Info header, defines histinfo option. Vijay: It seems to me that some of this can be used in Jiri Kuthan's SIP diagnostics. Maybe we can use this work to apply in that context. Mary discussed issues with History-Info -- ABNF issues: explicit counter: plain counters do not work due to forking options: indexiing using a dot delimiter to reflect the depth of forking Forking: need to add more scenarios Privacy: if you need privacy, use draft-ietf-sip-privacy-general Security: primary concern is in regard to a rogue app/proxy challenging HI entries. Jonathan: You are already assuming some level of trust in these intermediaries; i.e. they are proxying the request in the first place. It strikes me as a "sips" kind of thing; then you can guarantee that no rogue element has put anything in since all are trusted. Jon P: Maybe you can use the Auth-ID body draft. Rohan: Answering Jonathan's comment: idea is not to assume a weird trust relationship b/w all intermediaries. What you get is some optional information in a signed auth-ID body that asserts that proxy A retargetted to location Y. Maybe we should allow proxies to add bodies (they add headers). Jonathan: This is hard to spec right. Maybe we can start with writing reqs so we can spec it right. Cullen: The more you think about our security stuff the more you think that we will be heading down that path anyway. Gonzalo: Hum for people thinking that the req document is ready for WGLC? . Rohan: Do we feel that the reqs have sufficiently been presented in public that we are ready to ask SIP to consider a mechanism? Rohan: Let's hum for the following question: <50-50 split on the following question: Favor of waiting before implementing a solution> Favor of asking SIP to proceed> SIP Routing Diagnostics, Jiri Kuthan Narrowed the scope due to the discussion of mailing list; scope now is diagnostics of SIP routing only. Proposal: Let the UAS be talkative and disclose what they know about circumstances under which a request failed. Proxy Hints: disclose aggregated processing logic; mirror hints upstream so that troubleshooters located upstream can see it Issues: privacy concern. Henning: one proposal is to use sipfrag and include the diagnostic in sipfrag. Jiri: I would rather have a standardized way of doing this to make it easier to implement and deal with. Henning: We have the same problem with email processing; the email server sends error messages that say where the message died. Robert Sparks: Reqs developed for history would apply to this quite well. We should start with that and see how far it gets us. Jonathan: This is good start; it is similar to history but more broader in scope. We should start working reqs. 17:35 meeting adjourned.