IETF84 - STRAW WG meeting TUESDAY, July 31, 2012 -- 1700-1830 Afternoon Session III -- Regency E Chairs: Christer Holmberg and Victor Pascual Agenda: http://tools.ietf.org/wg/straw/agenda?item=agenda-84-straw.html Note takers: Dale Worley and Roland Jesske Jabber scribe: Ben Campbell Jabber log: http://www.ietf.org/jabber/logs/straw/2012-08-01.html Meetecho Session Recording: http://ietf84.conf.meetecho.com/index.php/Recorded_Sessions#tue Audio Recording: http://www.ietf.org/audio/ietf84/ietf84-regencye-20120731-1700-pm3.mp3 - - Agenda bashing and IETF Note Well (5 min) Presenter: Chairs Slides: http://tools.ietf.org/agenda/84/slides/slides-84-straw-0.pdf * Chair shows and announces the Note Well statement. * Chairs present the agenda (Introduction, Session should be seen as tutorial and starting point of work) - - Introduction to the WG (10 min) Presenter: Hadriel Kaplan Related reading: STRAW WG charter http://tools.ietf.org/wg/straw/charters Slides: http://tools.ietf.org/agenda/84/slides/slides-84-straw-1.pdf * Hadriel Kaplan presents Introduction to the WG. While the SIP specification's rules officially end at the B2BUA, many popular and important SIP features do not work in systems with B2BUAs unless the B2BUAs have specific behaviors to support the features. Problem statement à B2BUA are not only SBC. So could be also other entities e.G. PBX ect. It's impossible to specify everything that all types of B2BUAs must do for SIP but very few things any B2BUA must do to make a specific mechanism work. Like loop detection (Max-Forwards) The principle of the WG is to define what things any B2BUA must do to make particular common SIP features work through a B2BUA. This definition is on a feature-by-feature basis, rather than trying to determine a suite of rules for B2BUAs that will make "any" SIP feature work. * Daryl: It helps but does not guarantee that it will work. The STRAW defined procedures will help for implementers. * Hadriel: Every RFC we will provide will work or. * Robert: This is a theoretical discussion. - - Role-types of B2BUAs (20 min) Presenter: Hadriel Kaplan Related reading: A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents http://tools.ietf.org/html/draft-kaplan-dispatch-b2bua-taxonomy-00 Slides: http://tools.ietf.org/agenda/84/slides/slides-84-straw-2.pdf * Hadriel Kaplan presents Role-types of B2BUAs. Presented a rough taxonomy of B2BUA types. The taxonomy is understood to be inexact, it categorizes B2BUAs based on their degree of intervention (as compared to a proxy), which corresponds with their intended functionality. Discussion ensued as to the limits of what constitutes a B2BUA for our purposes, and how that might be defined. The case of conference servers is particularly problematic, as they can be considered either an "application" (a peer of a human user) or a particularly elaborate B2BUA (since all outgoing media is generated from incoming media). * Slide: Proxy B2BUA Keith: Does it have to sent BYE à Yes Paul: Could keep contact? Hadriel: Yes Keith: Still proxy behaviour but will be a B2BUA due to replacement of elements. Hadriel: Will replace headers or send also Messages. Andrew: Will it be a functionality not a BOX? Hadriel: Yes * Slide: Signaling B2BUA Andrew Hutton: Sees also the modification of SDP as signalling Hadriel: sees this as an other type of B2BUA So this is not seen as manipulating SDP for media changes only to fix SDP. Will be further discussed on the list. * Slide: Media Aware B2BUA Keith: Should reference RTP RFC terminology the differentiate between media aware and media terminating B2BUA. Will be taken into account. (List discussion) * Paul: What is the Criteria for B2BUA? One-to-one, call initiation into two direction or??? Hadriel: Some documents will define the taxonomity itself. Paul: For Conference servers perhaps is not interesting for STRAW but e.g. for a PCC it is seen. Keith: Will have documents in STRAW that is covered by the taxonomy document. Conference is out of scope for him. Partaha: Thinks that it is needed more taxonomy functions. Hadriel: Please put it on the list for discussion. Martin: Conf is more an APP Server and there are Edge Servers and Application Server. Are these types covered? Hadriel: Yes * Daryl: Proposes to mention within the draft the differences between types and add examples. E.g. -This is a Media aware B2BUA and does... -If you deal with media than this is the procedure to do it. -If it is a Signaling then... And add some examples. - - Loop detection/prevention (20 min) Presenter: Hadriel Kaplan Related reading: Loop Detection Mechanisms for Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) http://tools.ietf.org/html/draft-kaplan-dispatch-b2bua-loop-detection-00 Slides: http://tools.ietf.org/agenda/84/slides/slides-84-straw-3.pdf * Hadriel Kaplan presents Loop detection/prevention. Several simple techniques don't work. Proposal: B2BUA should copy and decrement Max-Forwards, should propagate and support Max-Breadth (if it forks requests), and should do the 3261/5393 Via check (if it preserves Vias). General agreement. * Robert: Pointing the RFC5393 à will end up one Call, If you have forking than you will have many Messages before ending by max forwards. Hadriel: proposes to pass thought the Max-Breadth. Robert: Andrew: Please not remove Max-Forwards. Robert: Max Forwards didn't work for proxies. Others: It works Robert: Yes better than nothing. Keith: There are still Scenarios where this will not work. Conclusion à not everything will work. Conclusion: We will get rid of loops within STRAW. - - Media-loopback test calls (20 min) Presenter: Hadriel Kaplan Related reading: A Media-based Traceroute Function for the Session Initiation Protocol (SIP): http://tools.ietf.org/html/draft-kaplan-dispatch-sip-traceroute-00 Slides: http://tools.ietf.org/agenda/84/slides/slides-84-straw-4.pdf * Hadriel Kaplan presents Media-loopback test calls. Much discussion ensued about the proposed mechanism (Draft proposes a new header which is decremented by passing each media aware B2BUA. This is needed for trouble solution) Martin Dolly raised the issue that service providers would be unlikely to allow loopback calls to cross service provider boundaries, and that carriers rarely use test calls as a tool. (Carriers monitor networks by taking continuous statistics and test networks by testing components at a level that is not addressed by ordinary SIP routing.) * Brian: Could be useful. But why should this to be implemented? Hadriel: This is seen more for test calls to trace it. Martin: This will work within a carrier network, but we will not let others in our network. Such test calls will be only traced border to border. * Paul: Likes the concept but not the new header. Why Max Forwards is not enough. So when M-F=0 the B2BUA can answer the call. Hadriel: When a loop exists then the B2BUA will answer this but does not help while circulating. * Hadriel: There will be a media loopback RFC soon. Daryl House: What the difference between this Media loopback and the proposed mechanism. Hadriel: For test calls to a B2BUA and wanted to have it explicitly answered. E.G. for cases where the Call sucks. * Brian: Problem is that you cannot replicate the path. But do stepwise testing. Hadriel: No will really will go through the path. Andrew: No guarantee that this can be replicated, but could help. Martin: If you have unpredictable results than it will not help. Brian: will not work 100% but will work in 95% of cases. Dale: You need not a 100% reproducibility 95% is enough. So if you make 20 Calls you will get at least a result. * Daryl House: Asks if this is really a use case for this WG. Hadriel: Was asked at least by 2 SP from US Martin: Really disagrees with the mechanism to. It makes these things worse. Not better, because more measurements and effort are needed with no or minimal result. - - Technical discussion and open Mic (15 min) * Chairs present Next Steps: Goals and Milestones * Christer: Not yet asking for adoption but asking for comments on the list and discuss the discussed proposals. E.G definition of other B2BUA roles. Phone call planned not a interims. * Daryl: Asks for discussion of the existing B2BUA roles. Paul: Proposal to add later also further roles to the draft when definition of existing roles are finalized and agreed. Conclusion: This means that the draft will be frozen for some of the B2BUA roles but could be extended by new defined roles. - - End of Meeting