INtermediary-safe SIP session ID (INSIPID) WG ================================================== Interim meeting 4th October 2012 Chairs: Gonzalo Salgueiro (gsalguei@cisco.com) Keith Drage (keith.drage@alcatel-lucent.com) Attendees: Paul Kyzivat, Gonzalo Salgueiro, Keith Drage, Andy Hutton, Christer Holmberg, Dan Romascanu, Hadriel Kaplan, Laura Leiss, Paul Jones, Peter Dawes, Adam Roach. Salvatore Loreto, Roland Jesske 14:00-14:05 Note well, agenda bash, notetakers, etc (Chairs) ------------------------------------------------------------- Paul Kyzivat is the note taker. No changes to agenda. 14:05-14:50 Discussion of requirements draft: use cases (cont'd) ---------------------------------------------------------------- Paul Jones, James Polk draft-ietf-insipid-session-id-reqts-01.txt Christer expressed concern that we not do anything that excludes solving the transfer use case. Keith proposed that 3.2 of requirements be removed (on recording). Andy, speaking for the siprec group, agreed. Keith said 3725 on 3pcc doesn't cover any 1 in 1 out cases and so doesn't apply to us. There may still be 3pcc use cases that *are* 1 in 1 out, which would apply to us. Paul Jones was concerned about removing 3.5. He wasn't concerned with matching a conference per se, but with correlating participants. He felt the proposed *mechanism* supported this, and he didn't want to lose that. Keith was concerned that if we leave this requirement in then when selecting a mechanism we will be constrained to one that supports this. Paul J explained how his intended mechanism supported this. Hadriel commented that PBXs *want* to hide transfers, so one end doesn't know that the other end has done the transfer. In that case the session id, or half id, won't appear to change. Christer said he didn't know of any requirement for the session id to identify participants. Adam and others were concerned with keeping 3.5 as a requirement. So solution might satisfy this even without a requirement, but there is no guarantee that we will choose a solution that satisfies it. Regarding 3.6: this justifies requirement 10. Andy said this leads to possibility that session ids can change during a session. Discussion ensued about preservation, or not, of session id across multiple dialogs. Hadriel drew a distinction between a SIP transfer via REFER, and a transfer at a higher layer (such as a PBX using reinvite) that might not be supported by this mechanism. He thinks that a B2BUA/PBX that does the transfer via reinvite should be able to preserve the id if it wants, but not be *required* to do so. Keith asked Hadriel about how he interprets 3.6 – does it imply REQ2 or not? He didn't think it should require it. Hadriel said that he didn't see REQ2 being implied. Hadriel doesn’t imagine that PBXs will be sending reinvites to ensure that the session id is preserved after a transfer. Adam said that will mean that many implementations (PBX style) won't be compliant with insipid. Hadriel again stated that he didn't think this applied to SIP PBXs. I disagreed. Adam says that there must be some level of correlatability in case of transfers, or else the mechanism will be of little use. He is arguing for preserving REQ2. Keith decided to postpone further discussion of this one for now because there is no sign of resolving it now. To be continued on list. Regarding 3.7: Keith proposed to remove part about accounting and billing. Asked if anybody objected to removing. No objections raised. Regarding 3.9: Keith asked about desire to preserve this. Andy spoke in favor of this, at least for 2 point calls. Keith observed that this figure is 0 in, 2 out. He wondered if it would still be in scope for 0 in, 3 out. And stated that he thought *that* could be out of scope. Keith proposed that 3.9 be updated to make it clear that this only applies for two endpoints. Paul J thought it already did, but agreed it could be made more explicit. 14:50-15:05 Discussion of requirements draft: requirements (cont'd) -------------------------------------------------------------------- Paul Jones, James Polk draft-ietf-insipid-session-id-reqts-01.txt Moved to discussion of section 4 on requirements: Keith stated that we have agreed to remove REQ3 and leave the remainder unchanged. Nobody disagreed. Summary of changes needed to requirements document as result of interim ----------------------------------------------------------------------- 1) Use case in section 3.2 is removed. 3.2. Session Recording A SIP Session is established between UA A and UA B with a SIP B2BUA acting as a middlebox. Both UA A and UA B establish a recording session with a session recording server (SRS) using the SIPREC protocol. The SRS needs to be able to determine from the metadata provided by UA A and UA B that the media streams are associated with the same communication session (CS). Derived Requirements: REQ1, REQ3, REQ4 2) Use case in section 3.5 is removed. 3.5. Identification of devices in the same conference SIP messaging can easily be multipoint in nature, specifically with several UAs communicating with a multipoint control unit (MCU) as part of a conference. The ability to distinguish all participants in single focus based multipoint conference to be identified as in the same communications session with all the other participants (i.e., in a single star configuration), verses in another conference session. Derived Requirements: REQ3 3) In section 3.7, removes references to "accounting, billing". 4) In section 3.9 add a sentence that indicates the use case does not extend to 3 or more SIP UAs. Existing text already indicates two SIP UAs. 5) In section 4, REQ3 is removed. REQ3: It must be possible for a device other than the conference focus to correlate sessions participating in a multipoint or multi- party conference on a single focus by observing the end-to-end session identifiers of each session. 15:05-15:25 Discussion on backwards compatibility to Kaplan draft ------------------------------------------------------------------- Christer Holmberg Moved to discussion of backward compatibility by Christer: He has been considering draft-kaplan-dispatch-session-id-00 and –03. It is -00 that is referenced by 3gpp, while -03 is the latest, though expired. (They differ in characters allowed in the id.) The requirements he derived are that syntax must be backward compatible with those drafts, and that a recipient must be prepared to receive a value from something implementing one of those drafts. He also inferred that it must be possible to detect when peer is following the Kaplan draft and then refrain from adding value for other end. Paul Jones wondered if that is necessary – wouldn't the other half, encoded as a parameter, be ignored? Christer thought *maybe*. Need to investigate. Question came of of whether to go with -00 syntax (a-z) or -03 syntax (a-f => hex). Christer proposed to follow -00. But Hadriel stated this was a bug, that intent had always been to use hex. General agreement to support backward compatibility to -03. I asked if this implied adding additional formal requirements. There was consensus *not* to do that – that individuals might have a *desire* for backward compatibility and can factor that in when evaluating proposed mechanisms. 15:25-15:55 Discussion of proposed session id solution (conclusion of Vancouver presentation) ----------------------------------------------------------------------------------- Paul Jones, James Polk draft-jones-insipid-session-id-00.txt (expired) Regarding draft-jones-insipid-session-id-00: Hadriel said he has read the Jones mechanism draft, and doesn't understand how it does the things that are claimed for it. Paul Jones did an overview of his draft. Hadriel questioned the call transfer case in slide 7. Paul Jones was envisioning a B2BUA that does signaling and not media, so that a reinvite is needed to accomplish the transfer. Hadriel was concerned with the case where the B2BUA bridges media. In that case no signaling is required to accomplish the transfer. There were questions for Hadriel about what he would want changed in this proposed mechanism to address his concerns. He stated that he thinks the main concern is complexity of having two values rather than one value. 15:55-16:00 Wrap-up (Chairs) -------------------------------------------------------------- Keith asked for the various authors to get together and try to agree on those parts of a draft that all agree on, while preserving alternatives where there is disagreement. The four people involved are Paul J, Gonzalo, Hadriel, and Christer. There is an action item for Christer to set up meetings between the three to do this. The alternative, if that doesn't work, is separate drafts in time for the Atlanta meeting. Another action item: for Paul J to make the agreed upon changes to the requirements. Keith will post those changes on the mailing list for others to comment on before doing the update.