[Insipid] Belated IETF 85 INSIPID meeting notes

["DRAGE, Keith (Keith)" <[e-mail]>]

The following are the notes for the INSIPID meeting held at IETF 85.

Apologies for the lateness of producing these.

Thanks to both Roland Jesske and Alan Johnson for being scribes in the meeting.

Regards

Keith

--------------------------------------------

IETF-85, Atlanta, GA, USA
INtermediary-safe SIP session ID (INSIPID) WG
==================================================


Chairs: Gonzalo Salgueiro ([e-mail])
        Keith Drage ([e-mail])      

MONDAY, November 5, 2012, 15:20-17:20 (Room 209)

Introduction and Status Update
------------------------------

- Agenda bash, Note Well, notetakers and jabber scribes, etc.
- WG status since IETF84 in Vancouver
- Action items, milestone dates, etc.

Discussion of requirements draft
--------------------------------

(Paul Jones)

draft-ietf-insipid-session-id-reqts-02.txt

- Changes since IETF84 in Vancouver
- Dealing with transfer requirement (chairs to lead this)
- Other open issues?
- Ready for WGLC?

Paul presented the changes of draft since the -00 version and planned editorials for version -03 and use cases 1-7

Robert: We need a definition of what the session-id should solve.
 discussion about definition of communication session
 discussion about other terminology in draft

Functional description could be used for definition what session-id is.

Polk: he has the same problem

Robert: Don't define session define the thing what you want to have.

Keith: why not in real document, i.e. the solution document.

Robert: needed to be in the requirements document due to the fact that here it is needed to be clear what should be solved.

Christer: All the terms used (e.g. dialog, session ect) needs consolidation and correction.  

Hadriel: Commenting on what the Id should be used for. It is not just session it is more dialog because of the use in REFER or REGISTER.

Paul J.: Problem known, and corrected description needed.
  - Paul wants to allow inclusion in RTCP, but not define how to do it

Gonzalo: Asked for RTCP/RVPT

Keith: Was agreed to be in the scope.

Gonzalo: Ask for opinion now. 

Robert wants requirement for identifier to be small enough to include in datagrams

Keith: Asks now if Requirement 9c (which reflects this option) needs to be removed (as Gonzalo requested).

Gonzalo: This WG was founded under the circumstances to have at least a minimal solution that works.

Hadriel: Clarified that Requirement 9c is about explicit as a syntactical requirement. So this must be covered by the text. This was agreed.

Decision of meeting: Requirement 9c must be reworded to reflect the syntactical requirement.

Chairs: Gonzalo and Paul work on text to replace REQ-9C and post to list.

Paul Jones: All other requirements are stable.

Discussion on Call Transfer-3 Slide

Chairs described outcome of virtual interim discussion and list discussion on this topic.

Gonzalo: Middle two bullets needs at least the definition what we want to have. (As already discussed earlier)

Robert: With that proposed text it is not intended to be a session.

Paul J.: Yes that will be a Session.

Robert: Then we need more text to describe this explicitly. Because it is not covered now by the text.

Paul K.: Call Transfer is splicing two half Calls together. We are talking about call legs. If we have a path of multiple B2BUA. So we have to splice a couple of dialogs together.

Hadriel: Assumes that you want to have to track the media. So in case of transferring the call is not an issue of the signalling but more an issue of the media. So the signalling is not in interest.

Paul J.: We want to look on the signalling in such cases of transfer. That it could be tracked. We want to see the correlation of the signalling. We want to see the call from A to B to C to D ect.

Hadriel: A-B and A-C a Call will be transferred to B-C. But you want to track the media.

Keith: But that is not in the requirements. So this is only needed for signalling.

James Polk: The B2BUA are not to be supposed to change the UUID / Session-Id. Session-Id should correlate two sessions seen from each end.

Christer: Proposes that this is the solution that correlates dialogs.

Keith: Which entities need to know that?

Christer: Issue of operator / service provider.

Paul K.: We are talking about structures, stars and meshes. So we do not know how to solve such constructions. We need to define what is needed also to such kind of scenarios. Example PBX-A and PBX-B are connected and each PBX can transfer that call.

Gonzalo: Distinguish between scenarios where the identifier needs to be the same and where it needs to be different.

Robert: Asks the A-B / A-C transfer to B-C scenario. Which identifiers are needed?

James: We want to correlate in transfer cases. He want to see the id to be used to see how the transfer happens.

Keith: Who needs to know about the transfer. The magic in the middle that is neither A/B or C?

Hadriel: What is in cases when you do conferences instead of transfer? What is needed?

Paul-J: Session-id A-B, A-C is needed in that case.

Hadriel: Session-id will not be passed by SBC then?

Robert: Do we have a Requirement that the ID is to be unspoofable?

Paul-J: The use of UUID was chosen to be unique.

Are we using the id for charging purposes? Answer: NO

Hadriel: It is not for billing so seen from this point of view there are no security concerns.

Mary: Asked if this is an idea to be used for billing. 

Conclusion: It should be forbidden.

Robert: Can I use this to do a bad thing that somebody else can be treated. 

Answer: No

Paul K.: The endpoints want to care about the ID. (This concludes: As long as it is used and inserted by end devices).

Keith/James: Please sent text to improve that Call Transfer case. Also to have the text what we want to do.

Chairs: no conclusion.  Need to focus on actual requirement. Please send real text to the list.

Chairs: -03 will be issued with changes discussed including Gonzalo's text about syntax.

Review and discussion of proposed solution
------------------------------------------

draft-jones-insipid-session-id-01.txt

- Summary of changes since -00 version (Paul)
- Backwards compatibility update in latest version (Christer)
- Review and Discussion of session id call flows
- Ready to adopt text as WG doc?

James Polk presenting.

James: presents changes of 00 to 01.

Robert: You do not explore what happens if one of the entities middle/end does not understand the ID.

James: Proposes an open section to work on that.

Robert: You have used a MUST NOT for adding the ID and in other sections to mandate that ID. So here a correlation and clarification in the text is needed.

Christer Holmberg presenting.

Christer: Presents the need to have a backward compatibility mechanism. Syntax must be backward compatible.

Usage: What happens when a version 1 UAC interacts with a UAS Version 2 and vice versa.

James: Aggress on the approach.

Paul-K: The old version should be released as an historical document.

Robert: Make it as a company document.

Marry: Asking for checking the old implementations if they do not crash.

Keith: Concludes to update that the draft will be updated to be backwards compatible.

Nobody in the room objected against that the draft-jones-insipid-session-id-01.txt describes backward compatibility to the session-id as defined in the Kaplan draft (draft-kaplan-dispatch-session-id).

Chairs - Any objections to the backwards compatibility as described in
-01 version - No objections noted.

Decision: to keep the new draft backwards compatible with regard to draft-kaplan-dispatch-session-id

James Polk presenting the changes within the draft

ABNF presentation was discussed on the list and seems to be OK.

Andrew: What was the reasoning to change the ordering in consideration of backward compatibility?

James: The order is not important. What is needed is appearing as two values.

Gonzalo: It is not really clear what the re-INVITES are doing. So clarification is needed.

Conclusion/Decision: Call Flow of presentation will be put into the draft.

Gonzalo: differentiate about the entities which correlate and which are putting in the ID (UUID)

Paul-K: Questions in which cases the values should flip?

Conclusion was that this appears in Requests equivalent to the mechanism used for "from" and "to" header.

Christer: Asked for documentation of the reasoning of rowing of the ID's.

Christer: Asked for keeping the rowing in the Response: à Keith: Take this to the list.

Christer: Asked for consistency.

New document is promised one week after meeting.

Decision: After that it will be asked for adoption of draft on the mailing list.

Wrap-up
-------

(Chairs)

- Next steps, action items, etc.
- Are more virtual interims needed?

Chairs: Authors will revise solution draft
Chairs: We will have a call for adoption of the revised draft by end of
November