[Insipid] Notes from INSIPID call 4oct2012

[Paul Kyzivat <[e-mail]>]

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.