Re: [Insipid] Notes from INSIPID call 4oct2012

[Gonzalo Salgueiro <[e-mail]>]

The minutes from the virtual interim have been posted to the Proceedings page:

http://www.ietf.org/proceedings/interim/2012/10/04/insipid/minutes/minutes-interim-2012-insipid-5

Thanks,

Keith & Gonzalo

On Oct 4, 2012, at 11:22 AM, Paul Kyzivat wrote:

> Notes for INSIPID call 4oct2012
> 
> Paul Kyzivat is the note taker.
> 
> Attendees: Paul Kyzivat, Gonzalo Salgueiro, Keith Drage, Andy Hutton, Christer Holmbert, Dan Romascanu, Hadriel Kaplan, Laura Leiss, Paul Jones, Peter Dawes, Adam Roach. (Maybe others joined later?)
> 
> 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 sesson 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 an 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.
> 
> Moved to discussion of section 4 on requirements:
> 
> Keith stated that we have agreed to remove REQ3 and leave the remainder unchanged. Nobody disagreed.
> 
> 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.
> 
> 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.
> 
> [I lost audio and may have missed some notes]
> 
> 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.
> 
> 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 three people involved are Paul J, Hadriel, 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.
> 
> 
>