IETF 74 SPEERMING WG SESSION ============================ March 24 2009, Hilton hotel San Francisco, CA. 15:20 - 17:20 Chairs: Jason Livingood Daryl Malas RAI Area Directors: Robert Sparks Jon Peterson Cullen Jennings WG Secretary: Alexander Mayrhofer --- - chairs open the meeting (15:25) - note well (15:25) - Darly presents agenda (15:25) Sohel Khan requests adding SPEERMINT and DRINKS relation talk at the end (15:26) status: (15:27) ------- Terminology published as RFC 5486 reqs. and voip use cases close to publication architecture draft (15:29) -------------------------- Adam Uzelac speaking few reviews - authors feel the draft is ready for WGLC renamed target - terminating, initiating - originating There will be at least a -09 LUF / LRF clarification Brian: LUF does not always return the same info, returns where to go. LRF tells you how to get there text is from Hadriel, not text from the terminoly John Elwell: RFC 5486 says LUF returns the target domain, not URI Does the draft meet the reqs of enterprises? Shockey: Yes, if enterprises are SSP WGLC on that? Jason: We will wait with last call until -09 at least - major concerns as it stands? Sohel: One comment was whether to use "Enterprise", which we haven't defined Jason requests that anybody who hasn't recently read should do so and post to list Speermint Message Flows (15:38) ------------------------------- Hadriel Kaplan speaks Currently contains one flow for dynamic with TLS, one static with TLS / IPSec / co-located, and two federation-based (ENUM / Redirect) Changes since last time: Added example messages and DNS queries / responses (just major messages) about 5 people indicate to have read the draft if you want a message included, send request to list open issues: examples do not necessary reflect what happens for real - request URI replace, From / to gets changed What to do - best "common practice" or "theoretical" world? Martin Dolly and Stephen norris say it should document "real" things Alex: if people use this as a blueprint to implement things, then it should reflect how it *should* be done John Elwell: If it documents "bcp", it shouldn't be a "standard". Jabber room (David Schwartz): agrees with Alex Hadriel: Changing of To is sometimes the only thing it can work, eg. when phones set their own domain into to as well. Keith Drage: Concerned that trying to fix SIP - if you want to fix it, go to the SIP WG. (15:55) Hiding something (topology) makes the result (the flows) unusable. Hadriel: I was not told to describe what the SBCs do, but rather show what's out there. I'm asking what do you want me to show in a BCP about peering message flows ??: Sometimes there's a place for a "worst common practices" Shockey: 95% of what we talk about is replacing PSTN. Andrew ??: We need to be clear what we document - (bad) practice, or (theoretical) things Daryl: Mail messages flow use cases to the list if you want them in, and don't like what's in. Hadriel: This is not normative for implementing SIP! Remove the UAC? then it would be just SBC alice calling SBC bob? Needed to proceed to WGLC? Need to review message flows, wait for peering profile BCP? Daryl: Section 10 is very useful! NAPTR-use (16:07) ================= Jason Livingood Version -05 released, took time to convert Word template to xml2rfc Open questions: Please read again, as we want to WGLC real soon. Should add a call flow for indirect peering? Adam: no, fine as it is. Please see additional notes in 3.1 David: please add an indirect flow, just for completeness Comments on John Elwell's comments on 3.2 Comments on 3.4 MUST issue appreciated, too. 4.1 and 4.2 - do we need flows? 4.2 feedback on Alex's comments appreciated please review bracketed off things - and provide comments. if no guidance from WG, would need to do decision on my own. Adam: taking people's names worked out last time Jason taking volunteers - alex and Venkatesh - mail contact info to alex. SIP Interconnect Guidelines (16:14) ----------------------------------- Daryl Malas Feedback from SSPs was that actual interworking pretty hard. SIP Profiles are too diverse, spending months to get their profiles working together. SSPs indicate this is the largest hindrance Adam: We don't have profiles. "on demand" creation of specs Attempt to make a framework for SIP peering. Not trying to solve all problems, this draft is trying to solve a subset of most common problems ??: Doesn't that somehow look like BLISS work? Hadriel: some details of the cases are disturbing - sdp does not match invite, eg. Fax support? Daryl: MAY support T.38 General question: Is that useful? Hadriel: Yes, profiles are useful - details need to be worked out. John: profile is good - no opinion whether it's done here or in the SIP forum. Some parts of the draft are overdescriptive, eg. "full number" prevents 123@enterprise to be reachable. Cullen: Charter rules out profiles - removing parts of standards is not a good idea for the same SDO. think about the implication of recommending just to implement part of an RFC. shockey: board member of "other industry forum". this is a logical idea for a BCP to do. can't speak on behalf sipforum, but wouldn't want to do that work there. supports adding this as a bcp WG item, this is an excellent start ??: Concerned about applying requirements to User Agents for SSPs who do not do B2BUA. Intention is that SSPs have something to start off, not necessarily limiting them to this (starting point). John: Media is dictated by the UA Discussion whether media Brian: may end up that MUST support text Adam: thinks that it shouldn't be a WG item. Hadriel: concerned about codec/media thing as well ??: You definitely want to avoid multiple transcodings Hum taken on whether work on that should be continued, and is worthful to the WG. concensus that it's valueable, and work should be continued Open Discussion (16:47) ======================= Design team meeting? probably somewhere in the east coast US, one day of concentrated work - if interested, please communicate availability to the chairs. Doodle link provided in Agenda Individual Drafts to be expected? What implementor specific drafts are needed? Open Mike time (16:49) ====================== Sohel: Relation DRINKS / SPEERMINT? Daryl: SPEERMINT defines peering from the architecture, and flows, and defines LUF / LRF. within LUF/LRF, data has to be provisioned - DRINKS defines how to provision that data into there. meeting ends (16:51)