Skip to main content

Minutes for INSIPID at interim-2012-insipid-5
minutes-interim-2012-insipid-5-1

Meeting Minutes INtermediary-safe SIP session ID (insipid) WG
Date and time 2012-10-04 07:00
Title Minutes for INSIPID at interim-2012-insipid-5
State Active
Other versions plain text
Last updated 2012-10-04

minutes-interim-2012-insipid-5-1
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.