INSIPID IETF#83 PARIS NOTES

WG Charter has IETF consensus

Deliverables.

Only deliverable one identified – to specify a SIP identifier that has the same aim as the From-tag To-tag and Call-ID conjunction.

Probably also end up with a requirements document.

 

draft-jones-ipmc-session-id-reqts-01 (James Polk)

To create an identifier that middleboxes wonÕt muck with that is (nearly) identical in goal to that of the dialog-ID in SIP when there are no middleboxes between UAs in a call (flow/session/whatever)

Adam Roach brought up a requirement for Carol to Join the session between Alice and Bob (Call Barge) when the B2BUA also acts as a mixer. Adam is concerned that currently incorrect assumptions are made about the architecture for join.

Use cases

¥       End-to-end identification of a communication session

¥       Association of session signaling and media flows, made possible by including the session identifier in media-related messages (e.g., RSVP or RTCP)

¥       Identification of devices taking part in the same multipoint conference

¥       Tracking sessions transferred from one endpoint to another

¥       Facilitate the recording of SIP sessions and correlating those sessions

¥       Logging for the purposes of accounting, billing, debugging, communication tracking (such as for security purposes in case of theft of service), etc.

 

Requirements

¥       REQ1: It must be possible for an administrator or an external device which monitors the SIP-traffic to use the identifier to identify a set of dialogs which have a relationship with each other, such that they represent the same SIP session, with as high a probability as possible.

ISSUE: (Daryl Malas) High Probability as possible replace with definitively know

¥       REQ2: It must be possible to identify the end-to-end session when a session is transferred or if two different sessions are joined together via an intermediary (e.g., a B2BUA or SBC).

ISSUE: (Adam Roach) Consultative transfer when two independent sessions are joined together. List discussion

¥       REQ3: It must be possible to identify all sessions participating in a multipoint or multi-party conference by observing the end-to-end session identifiers of each session.

ISSUE: There may be different session identifiers on different legs of a conference but there needs to be a way to identify that they are all part of the same conference.

ISSUE: Concern whether conferencing requirements are in scope

 

¥       REQ4: It must be possible to pass the identifier unchanged through SIP B2BUAs or other intermediaries.

ISSUE: (Brian Rosen) Discussion is needed as to why SBCs change the existing identifiers so that we ensure that SBCs donÕt need to remove the new identifier

ISSUE: (Robert Sparks) This does not mean the new identifier works through PSTN and other gateways

ISSUE: (Daryl Malas) No requirement can mandate that an SBC not muck with this identifier

ISSUE: Some SBCs may still need to change the new identifier

¥       REQ5: The identifier must not reveal any information related to any SIP device or domain identity, including IP Address, port, hostname, domain name, username, Address-of-Record, MAC address, IP address family, transport type, etc.

 

ISSUE: Requirement to be able to verify that no sensitive information –NOT AGREED

 

REQ6: The identifier must not reveal to the receiver of it that the Call-ID, tags, or any other SIP header or body portion have been changed by middleboxes, with as high a probability as possible.

ISSUE: Remove with as high a probability as possible

ISSUE: Ensure session identifier is not similar to Call-ID

¥       REQ7: It must be possible to identity SIP traffic with an end-to-end session identifier from and to end devices that do not support this new identifier, such as by allowing an intermediary to inject an identifier into the session signaling.

¥       REQ8: The identifier should be unique in time and space, similar to the Call-ID.

¥       REQ9: The identifier should be constructed in such a way as to make it suitable for transmission in SIP, H.323, RSVP, and RTCP

OPEN ISSUES

¥       Should this set of requirements be woven into an early section of WGÕs existing milestone, brought forward as a separate milestone, or left to remain a draft only?

 

Peter Dawes has additional requirement that has been sent to the list

 

Monthly conference calls (starting in 3 or 4 weeks)