Minutes of the DISPATCH WG Session at IETF 75 ================================================= Meeting chaired by:
Mary Barnes and Gonzalo Camarillo
Minutes produced by Mary Barnes based on detailed notes (included below) by Ben Campbell and Keith Drage.
In addition, the DISPATCH Adhoc for Common Log Format minutes are included below.
Slides presented included in the proceedings.
Monday, July 27, 2009
Topic: Agenda Bash
Discussions led by: Chairs
The chairs presented the current status of the WG noting the aggressive schedule to get topics discussed prior to IETF-75 in DISPATCH WG, allowing the dispatching of several topics. A new WG has is in the process of being formed for the Common Log Format topic. An official BoF was scheduled. for the codec topic and the sound level indicator work/discussion was moved to the AVT WG. Specific to the current DISPATCH WG charter, there is not sufficient interest to continue the work related to configuration, specifically the draft-ietf-sipping-profile-datasets-03.txt. However, draft-ietf-sipping- media-policy-dataset and draft-ietf-sipping-config-framework will be progressed as AD sponsored. Additional topics currently under discussion on the DISPATCH WG mailing list were summarized, noting in particular that a mailing list has been setup for the other currently chartered DISPATCH WG item - overload.
Topic: Transporting user to user call control information
Discussion led by: Alan Johnston
Relevant documents: draft-johnston-dispatch-sip-cc-uui-00.txt
The focus of the discussion was primarily on the proposed agenda. Concerns were raised with regards to the lack of semantics in the case that a new header was defined. There was WG support in terms of the community working to solve the problem described in the charter/document. The general consensus was that a new WG would be more appropriate than adding this to another WG's charter (e.g., SIPCORE) or progressing the work as AD sponsored.
Conclusion: Propose to form a "mini-WG". Author should post
an updated charter to the DISPATCH WG mailing list. The ADs will then follow-up
with the formation of the WG.
Topic: Session Recording
Discussion led by: Leon Portman
Relevant documents: draft-jain-dispatch-session-recording-protocol-req-00.txt
It was initially noted that there is IPR associated with the topic. The
motivation for standardization in this area was discussed including use cases.
The use of SIP as a part of the solution set was discussed. It was
suggested that more requirements for the solution need to be identified. A
concern was raised with regards to UAs not knowing that the session recording is
occurring with Jon Peterson wanting notification and UA agreement as a
fundamental requirement. There were no hums against continuing work on this
topic in the IETF.
Conclusion: Form mailing list - bring requirements and problem statement back to DISPATCH WG.
Ad hoc chairs:
Spencer Dawkins: firstname.lastname@example.org
Theo Zourzouvillys: email@example.com
Scribe: Vijay Gurbani: firstname.lastname@example.org
(Special thanks to Vijay for scribing AND presenting at the same time!)
Since the DISPATCH working group was sponsoring this ad hoc session, Gonzalo Camarillo did the introductions.
Robert Sparks (AD) said that he had asked Spencer Dawkins and Theo Zourzouvillys to co-chair the WG-to-be if it is chartered.
Chairs presented and bashed agenda; no changes.
1. Report on where we are including feedback from OPSAREA
2. Close on charter text
3. Take sense of room via hums
4. Milestones presented
Vijay presented the updates on hallway conversations and feedback from a 15-minute slot at OPSAREA, and possible lessons from SYSLOG and IPFIX for SIP-CLF requirements. Vijay’s take from those conversations is that SYSLOG makes sense for SIP proxies, but not per-request, and that SIP-CLF didn’t look like an IPFIX flow to him.
The chairs presented charter text provided by Robert (included in the Chair Slides for this ad hoc session).
Robert emphasized that the interested parties have not decided about sending SIP-CLF files around, and has not chosen a representation (the proposed charter explicitly charges the working group with figuring this out).
Vijay: Regarding aggregating across diverse elements, my initial view was that the aggregation etc. was done locally; i.e., proxy aggregating different transactions to make up a dialog, etc. The idea was not to track a request across a chain of proxies across possibly different domains. If we want to do the latter, then we'll have to use ideas like Hadriel's Session-ID draft.
Hadriel Kaplan: We need use cases. “The use case is correlation.” My customers want to have a consolidated view. They want to aggregate the data as it travels through the different SIP entities in their own domain. Doing so across different domains is another thing.
Adam Roach: Regarding sending data to other aggregators, we have ruled transport out of scope. Hadriel's draft may take a long time to advance, so we should not hang tracking request across diverse elements on that draft – the problem isn’t intractable without Session-ID. We should ensure that extensibility is included so we can do this later.
Eric Burger: Extensibility to include session-id should be considered.
Hadriel: Session-ID is already a draft, so I do not see how it should hold this work up. If SIP-CLF work needs it, we can even have SIPCORE (editor’s note: this should actually be in DISPATCH, based on post-IETF conversations) move it up quickly.
Adam: The level of controversy around Session-ID is an indication that it may not proceed quickly. SIP-CLF is more tractable and we can finish it quickly.
Robert: The word in the charter is "anticipate the need to correlate across diverse elements" not "require". The WG will anticipate this correlation requirement.
Hadriel: If there is a notion of a mandatory vs. optional field, I would rather have the correlation id be a mandatory parameter.
Keith: Regarding transporting CLF files in real time, no need to put this in charter. You put this on the system and send it wherever later.
RjS: We need to reinforce that real-time transportation of the information is out of scope. We’ll make this more obvious in the charter text.
We noted at this point that “extensible” also includes support for SIP header fields that haven’t been specified yet (forward compatible).
Dan Romascanu: What does “format will anticipate” mean?
Robert: By this I mean, "will not preclude".
David Harrington: Some issues IESG will care about are: congestion control. You will need to move this data around. When you do that, then you will need a protocol. I’m assuming this protocol might be used over the bit-I Internet.
Another issue: security. How will you deal with security issues? Nothing in the charter. If it gets transported, how will you deal with security? To say that all this is out of scope is a mistake.
I am a member of the ops directorate; we have a set of guidelines and one of the things not mentioned is what do you do when log files get filled, etc. Do you delete the oldest entries, stop recording … There’s a draft on Operational Considerations you should look at.
Spencer: I know the draft, and agree with David.
Jon Peterson: This is valuable input. Can you tell us about what the resolutions were in syslog on some of these issues?
David: For transport security syslog used TLS.
Vijay: Regarding log files getting full, etc. the model has always been HTTP CLF. The sysadmin knows that they have to roll the logs every hour or every week. It is not part of a protocol. Would it be okay if, for instance, it was specified in the problem statement draft that the logs should be rolled frequently etc (i.e., provide some guidelines to sysadmins).
David: OK with me. SFTP might even be OK, just say SOMEthing in the draft!
Hadriel: agree with David.
Vijay: Discussions about efficiency and what it means to me. Efficiency means different things to different people: for the transport, efficiency may mean making the representation compact so that it can be sent around efficiently. For ops, efficiency may be ensuring that the least amount of disk is used, etc. For SIP-CLF, I define efficiency in terms of optimized searches and quick parsing. Maybe we should define what efficiency means for sip-clf in the charter more clearly.
Spencer: I agree. In hallway conversations, people seemed to assume this meant either bandwidth efficiency or processing efficiency for the SIP proxy generating the logs – that’s not what it means to Vijay and others in this room.
Decisions about representation include integration with tools – if everyone uses Wireshark now, PCAP format would matter more, for example.
Hadriel: On slide 13, say that specifying a real-time transfer mechanism is out of scope instead of saying a real-time transfer mechanism for heuristic analysis is out of scope.
Mark: First issue: produce a log format. Second issue: think about privacy issues later. For the format we do not worry about privacy; for transfer of this data, you will need to worry about privacy.
Hadriel: Security considerations will require privacy issues.
David: please consider privacy early in the process, including privacy for data at rest. The information being logged might tie location information to my identity, for example. The security analysis won’t pass this work if you don’t address that.
Hadriel: What about IPFIX? How did you get your privacy story through the security review there?
David: I was not involved in IPFIX.
Brian: WRT IPFIX, IESG was particular about how security will work. TLS and DTLS bindings are very restrictive. For privacy, if going over wires you do not own, encrypt it. For data at rest, anonymization is an answer – give guidelines about what must be anonymized. IPFIX started out transferring information immediately and went back to develop an IPFIX file format – this is the reverse of the path SIP-CLF is taking, but …
Robert: Efficiency will be defined much better later in the charter. Charter is providing bounds and constraints.
Hadriel challenged the dates, especially for the first draft (“Oct 09 for WGLC means the 00 draft is due, like, next week”).
Spencer asked if everyone who will be working on SIP-CLF had already taken summer vacations (and about half the room said “no”).
Robert said that the proposed dates were likely to change during the chartering process.
Keith asked if the format specification had to be standards-track.
We did not take a “sense of the room” hum on forming a working group, because Robert got lots of feedback and suggestions on the proposed charter during this ad hoc meeting.
The decision to form the WG will go to the list after the charter text is updated. Robert is going on a (well-deserved) post-IETF vacation and expects to send out an updated charter in a couple of weeks.
DISPATCH WG minutes by
- Work group Status
- Common Log Format - new WG proposed. Adhoc on Friday lunch
- Codec - BoF scheduled Thursday 1300-1500
- Sound Level Indicator - passed to AVT
- CBUS proposal deferred, Christer will update at later date.
- On demand media/app sharing -- needs more interest and feedback.
- Profile datasets cancelled
- Media policy dataset - to be completed as AD sponsored
- Discussion: Media policy dataset will remove dependency on profile datasets
- Config framework - will be completed. Ops review complete.
- User to User Call Control (Alan Johnston)
- Requirements and use cases : draft-johnston-dispatch-sip-cc-00
- One proposed mechanism in draft-johnston-sipping-cc-uui
- Charter text discussed on list. Mostly discussion of mechanism rather
than requirements and scope.
- Proposed charter text presented
- Discussion topics:
- Is the charter text clear on scope?
- Do we have the right set of deliverables?
- Are people interested in working on this?
- Martin Dolly: ATT supports the work and will need it.
- Hadriel: Interested in work; not sure if we need a work group
just for this.
- Question: Where would this go? Chairs comment that this sort of work
group would be short lived and lightweight. More like a design team.
- Jon Peterson: Skeptical. This is very generic. Mechanisms carrying arbitrary
blobs of data standardize things that don't interop. The more standardized semantics, the more comfortable
- Question: Is ISDN-UUS underspecified? The charter describes it as an
"example" of what you can do with the proposed mechanism.
- Dean needs to talk to this before he explodes
- REST suggests that you can carry parameters in a r-URI. The semantic is
completely open ended, We've gotten away from that in SIP. RESTful parameter passing no longer works
because of previous design mistakes in SIP. If we have open semantics on a UUI type header, we don't have
to extend SIP for every new thing.
- Jon: Why do you need a standard header?
- Dean: It's not an application specific header--it's a way to move data
- Laura, Deutsche Telekom: Supports work.
- Adam: If this is scoped beyond ISDN Q.931, there is danger of making the
same mistakes as in INFO. Are we going to have packages for this?
- Adam: (re: Dean's comments) Dean is describing a cookie, i.e. application
sending data to itself. That usage is okay.
- Dean: We have a registry of SIP URI request parameters. We don't use it
because r-uri's don't get to peer.
- Hadriel: Would Jon be okay if it was in a MIME body?
- Jon: Roughly, yes.
- Hadriel: should have been in a MIME body, but can't be due to
pragmatic reasons. We should treat this like it was a MIME body, even if it really isn't.
- Chairs: Don't discuss mechanism (body vs header)- discuss whether we want to do
- Martin Dolly: Need to address transition. Not just ISDN to ISDN. Preemptively
disagrees with anything else Jon says :-)
- Francois: UUI is just one way to pass data in ISDN. Different vendors use it
different. UUI is the only one that doesn't describe what the data carried is. Reasonable for ISDN interop,
but not sure it makes sense for transitional scenarios.
- Why do we spend so much time on this? It will be quasi-proprietary for
- Jon Peterson: Proprietary elements in ISDN are similar to just sticking in a
header in SIP. Not necessary to standardize. If this goes beyond ISUP, we need to do semantic translation.
If only ISDN (at least on one end), then tunneling makes sense. This is more like tunneling.
- Jonathan Lennox: Is there an expectation that a gateway can be ignorant of the
semantics of the UUI data? Need to be clear whether this is application data, or protocol semantic data.
- Alan: Only for application semantic data--should never carry sip semantic
- Spencer: Supports this in general. Okay with MIME encoding. Please move quickly,
he has customers who want this in general.
- Dean: Process question: Jonathan Lennox talked about passing arbitrary data up a
level. We have a working consensus that application layer data that doesn't go in the body goes in the r-
uri. The way we get r-uri peer to peer is history info. If we can do it as parameters on history-info, we
don't need a work group.
- If there are more semantics that need to be defined, is this a SIPCORE
- Laura: Responding to John: They use UUI to carry application specific data. For
example, telling a call-center whether a caller is a customer.
- Adam: We have suffered for sins of lack of semantics around INFO for a long time,
lets not do it again.
- Alan: We've dealt with diversion for a long time--if we don't standardize
something, we will have that problem again.
- Jon Peterson: Dean makes a distinction between parameters that are part of the
call control structure, vs blobs with no semantics. Headers do not have a clear distinction--some are used
for routing and some for applications. The "is this my customer" semantic could be done with a header.
- If you want to do proprietary things, use proprietary headers. The are no
less accessible than a standard mechanism to carry proprietary data. The difference is only syntactical.
- Hadriel: If you have something that semantically means "here's
some opaque data". They at least need to know what header to go look for.
- Jon: Less uncomfortable if this is a way to encapsulate an ISDN
- Alan: Proprietary between two applications, not two SIP devices.
- Martin Dolly: Repeats that they need this. Lack of this makes interop worse.
- Francois: When the entity populating the SIP message knows the application, a
MIME body or proprietary header makes sense. Main use case if form when SIP device does not know the
application. Nortel devices don't use UUI but they will transport it.
- Keith: Most of the things Jon P question are actually in the draft. Application
needs to be able to decide whether to reject the call or ignore it if it does not understand the UUI.
Obvious mechanism is an option tag.
- Keith: Answering Francois - UUI is the onlything guaranteed to be end-to-end in
- Chair questions:
- Hum: Should we scope this strictly to ISDN? Or ISDN with extensible mechanism?
(The charter text says the second.) Or do we leave it with wide open semantics.
- A few people hummed for first option, several for second, almost none for
- Result: Take this to list. People in the room seem to want work on this in
principle, and it should be useful beyond just for ISDN
- Robert: This implies we we should dispatch this to _somewhere_
- HUM: Does anyone think we should not work on this at all?
- No hums.
- Robert: Focus on defining the work, not doing the work.
- Dean: We did not discuss where this work would happen.
- Chairs/Cullen: Suggest we need to do this in a mini-work group.
- Robert: Too many people picking at this for an AD sponsored individual submission
- Session Recording (Leon Portman)
- Leon presents use cases
- Christer: Why a requirement to record sessions somewhere other than the endpoint? No
protocol required for endpoint recording. What can you not do by recording in endpoint? Why need a separate
box to record?
- Leon: Someone needs to manage all the recorded sessions. Terabytes of data
created everyday. Also need real-time availability of recordings.
- Chairs: Clarifying questions only--save general questions for end
- Roni: Deployments already do this in SIP, why need standards? Where is interoperation
- Eric Burger: Can we imagine a situatuon where the recording protocol crosses the
Internet, rather than within an organization or between organizations over a vpn?
- Leon: Yes.
- Christer: Is this for personal recording with personal playback, or do you have to
request recordings from third parties? Other standards bodies have done the first sort of work.
- Leon presents on why use SIP for this
- Roni: Nothing in document says what is missing in SIP to achieve this.
- Leon: For example, how to indicate which calls need to be recorded?
- Hadriel: For example, the SRP SIP connetion must ID itself as an SRP connection,
not human-to-human connection
- Scott Lawrance: Who authorizes when a session may be recorded? Some overlaps between this
and the third party authn draft.
- Leon presents proposal for SRTP support
- Leon: Playback out of scope. IPFix not applicable. Other session protocols out of scope.
- Brian Rosen: Need to hone use cases. 2 sets of environments. Recording for quality is
always done at conference bridges. Recording for legal purposes done without parties knowing about it.
Brian does not think those cases need standards work. What other cases are there that require more
- Leon: Case where the call leaves an IVR for recording purposes
- Vijay: Work did not start to record covertly. Caller knows the call is being
- Alan Johnston: Many other use cases need to go into the draft. For example, only
certain segments may need to be recorded. Alan supports the work, but it needs more use cases and
- Hadriel: Not all recording is done in conf bridge.
- Hadriel: This is not sufficient for lawful intercept.
- Jon Peterson: Would a requirement for explicit endpoint authorizaition to record
be acceptable? If not, then this is a lawful intercept technology.
- Hadriel: No, users will do this at voice layer
- Jon, that's okay, as long as they have choice. I.e. not recording
- Eric Burger: Most of the PBX and call recording people in the room say we need
- Roni: Draft does not give enough info to translate to requirements.
- Francois: We need to get started on this. This is the first time we've talked
about this in a civilized way :-) Need good requirements before working on solution.
- Scott Lawrence: Endpoint authorization not relevant in all areas.
- Several jabber room comments support work.
- Theo supports work.
- Roni: need more work on architecture
- Chairs; Take 2 hums:
- 1) Assume Jon Peterson's requirement on endpoint authorization, who is opposed to
doing this work?
- Roni: Is this requirement mandatory to use or implement?
- Gonzalo: Probably mandatory to use
- Jon: We can't work on lawful intercept. Need a requirement to prevent
this from being lawful intercept.
- Gonzalo: We're talking more about tone of draft than mechanism
- Hadriel: If it's a mandatory requirement, the solution must address it
- What about other protocols like IPFIX?
- Jon: Media recording is more blatant than other things (that might also
- Scott: Would a mechanism for endpoints to declare they do not auth
recordings be sufficient?
- Jon P: Yes, if they can expect the call to fail if the
alternative is to be recording.
- Cullen: IPFix _did_ have problems due to raven. Jon is trying to help the
group get work accepted. Either change raven, or explain why this is not a violation of raven.
- Hum Result: No objection to doing this work in the IETF
- Feedback to authors: Keep work going, work on requirements. Will create a mail
- Final comment from Spencer: Thanks for all the dispatching. Looks like a good start to the process.
- Chairs; Request feedback on how the group is going.
DISPATCH WG minutes by Keith Drage:
Mary Barnes (WG co-chair)
Gonzalo Camarillo (WG co-chair)
Oscar Novo (WG secretary)
DISPATCH WG Status
Defined an aggressive schedule to get topics discussed prior to IETF-75 in DISPATCH WG:
May 25th - Cutoff date to notify the chairs and DISPATCH WG mailing list of plans to submit a proposal, including the topic of the proposal.
June 8th - Cutoff for charter proposals for topics. A charter proposal must consist of a minimum of a problem statement and at least one milestone/deliverable.
June 15th - Topics that are to be the focus of IETF-75 were announced.
One topic (session recording) did not meet the deadlines, but had sufficient WG interest that it made the cut
DISPATCH WG Status
Common Log Format - a new WG has been proposed and is in the process of being formed. Friday lunchtime DISPATCH WG adhoc for this work.
Codec - a separate BoF has been scheduled: Thursday, 1300-1500 Sound level indicator - work/discussion moved to the AVT WG
CBUS - Christer to update his proposal at a later date: draft-holmberg-dispatch-cbus-00 On demand media/app sharing - in order to dispatch this work, there needs to be more interest and feedback on this topic: draft-saito-mmusic-sdp-ike-04
DISPATCH WG Status
Items that have been cancelled:
Profile datasets: there is no longer sufficient working group interest to complete this nor to charter any new work in this area:
Items to be completed as AD sponsored (as old SIPPING WG documents):
Media Policy-dataset: must be finished due to other doc dependencies (as AD sponsored): draft-ietf-sipping- media-policy-dataset Configuration framework: will be completed. OPS review completed: draft-ietf-sipping-config-framework
These are realling SIPPING issues.
DISPATCH WG Status
More recent items under discussion (on mailing list):
NGN Reason header: draft-jesske-sipping-etsi-ngn-reason
OMA Push: draft-dolly-dispatch-oma-push
Implicit Registration: draft-kaplan-dispatch-sip- implicit-registrations Interop BCP: draft-kaplan-sipping-interop-bcp HTTP subscribe: draft-roach-sip-http-subscribe
Disaggregated media: draft-loreto-dispatch- disaggregated-media-00.txt Overload.
SIPPING WG document planned to be moved to new (proposed) WG: draft-ietf-sipping-overload-design
Mailing list (for solution discussions) :https://www.ietf.org/mailman/listinof/sip-overload
Note: focus of discussions on the DISPATCH WG Mailing list should be specific to proposed charters, scope of work items, etc.
NGN reason has appeared on BLISS, but has now been dropped from BLISS agenda, so discussions continue in DISPATCH.
OMA Push has been submitted after the agenda blackout.
Overload is proposing a new working group. Is separate mailing list. Address above is incorrect. Should be:https://www.ietf.org/mailman/listinfo/sip-overload
Agenda - Monday 1740-1940
17:40-17:50 Chairs - Status and agenda bash
17:50-18:35 Alan Johnston Transporting user to user call control information
18:35-19:20 Vijay Gurbani Session Recording
* Note: draft-lawrence-sip-third-party-authorization removed from the original agenda - author still needs feedback
Other Items of Interest
SIP Forum UA Config Tech WG status
UA config profile work in SIP Forum (1 of 3) Producing a simple specification to cover the most common situations single source of configuration simple boot process very small number of essential parameters Small group / weekly conference callshttp://www.sipforum.org/content/view/311/253/
Change of direction since report at IETF#74
UA config profile (2 of 3) - Major changes Generalized the mechanism for obtaining a URI from a domain name Motivated by gaps in the existing mechanism, e.g., back -off procedures The derived URI must be an HTTPS URI (i.e., always get config first, then subscribe to receive notifications of changes) Motivated by boot problem of needing SIP configuration in order to use SIP in some cases (e.g., needing outbound proxy) Intention to adopt the more generalised SIP event package for notifying changes, as proposed in draft- roach-sip-http-subscribe Motivated by greater generality, simplicity, and very slow progress of sipping-config-framework
UA config profile work (3 of 3) - Dependencies on IETF work No dependence on sipping-config-framework But dependence on draft-roach-sip-http-subscribe Will not specify data syntax (no dependence on the cancelled profile-datasets work)
Comment that draft-roach-sip... would be easier to track if it was issues as a draft-roach-dispatch.
Call Control UUI for SIP (CCUS)
Proposed CCUS Charter
Requirements and use cases in draft-johnston-sipping-cc -uui-07 was discussed and last called in SIPPING back in 2008.
Requirements and use cases into new draft draft-johnston-dispatch-sip-cc-uui-00
One proposed mechanism still in
Charter text sent to list - some discussion Suggestion to explicitly mention ISDN UUS Service 1
Proposed CCUS Charter Text 1
The Call Control UUI for SIP (CCUS) working group is chartered to define a SIP mechanism for transporting call control related user-to-user (UUI) information between User Agents.
The ISDN User to User Information Service, defined by ITU-T Q.931, is extensively deployed in the PSTN today, supporting such applications as contact centers, call centers, and automatic call distributors (ACDs). A major barrier to the movement of these applications to SIP is the lack of a standard mechanism to transport this information in SIP.
Call control UUI is user information conveyed between user agents during call control operations. As a result, the information must be conveyed with the INVITE transaction, and must survive proxy retargeting, redirection, and transfers. The mechanism must utilize a minimum of SIP extensions as it will need to be supported by many simple SIP user agents such as PSTN gateways. The mechanism must interwork with the existing ISDN UUS Service 1 but should also be extensible for use by other applications and non-ISDN protocols.
Proposed CCUS Charter Text 2
While PSTN UUI is carried in ISUP (ISDN User Part), SIP call control UUI can be generated by a number of protocols that are not ISUP, and as such it is architecturally unreasonable to interwork these protocols at the SIP / ISUP gateway. That is, existing SIP-T approaches defined in RFC3372 do not meet the requirements.
Mechanisms based on the SIP INFO method, RFC2976, will not be considered by the working group since the UUI contents carry information that must be conveyed during session setup at the user agent - the information must be conveyed with the INVITE transaction. The information must be passed with the session setup request (INVITE), responses to that INVITE, or session termination requests. As a result, it is not possible to use INFO in these cases.
The group will produce:
- A problem statement and requirements document for implementing a SIP call control UUI mechanism
- A specification of the SIP extension to best meet those requirements.
Goals and Milestones
Dec 09 - Problem statement and requirements document to IESG (Informational) Mar 10 - SIP call control UUI specification to IESG (PS)
Are people willing to work on this?
Is the proposed charter text clear on what is and is not in scope?
Are the deliverables complete?
Jon Peterson indicating that he is unhappy with new header that essentially has no semantics.
Dean: Need to give up on puting things into Request-URI because we never did the ua-loose route stuff that fixed this. Can do this by reserving header field solely for these purposes.
Laura Leiss: Strongly support. Solution needed now. Soon as possible a standardised solution to avoid proprietary solution.
Adam: WOuld not object to a narrow ISDN based scope but does not want a wider scope. If package (like INFO) defining exactly what this means then less of a problem. Also in case that Dean cites are cookie based, i.e. a sees what a generated. But this is not the case.
Dean: Registry of sup-uri parameters does exist.
Hadriel: Askewd Jon if would be OK in a MIME body. (Jon nodded his head.) Hadriel agreed in a perfect world it would be in a MIME body.
Martin Dolly: As large carrier sees the need for this. Need exists outside ISDN to cover transition from ISDN.
Francois Audet: Only a really small fraction of problem of passing proprietary information. Only one that has no indication of what the blob is. Should not spend an enormous amount of time on this as this is not the most interesting thing to fix.
Jon Peterson: Distinction in SIP-T between the things that would be encapsulated or translated. Should figure out ways of gatewaying things into SIP. Is pushing for translation of the UUI contents at the gateway, rather than a transparent mechanism.
Jonathan Lennox: Sought clarification as to whether thegateway would understand the data. Answer No. Whether the SIP layer should having to make the decision as to whether the SIP layer should ignore the header.
Semantics is should be handed to layer above.
Spencer Dawkins. Spoke for this. Would not be offended if turned out to be MIME encoded. Asked for group to move quickly and get this forward.
Dean Willis: Arbitrary passage of data from one end to the other. Have in SIPCORE history info. If need more robust mechanism, then raises the possibility of whether it should go to SIPCORE, or whether it should go to new WG.
Laura Leiss: Currently use UUS1 for application specific information. Routed to IN.
John Elwell: SOunds like it needs old P-header for use in closed environments.
Jon: Left open call control scope. Header has open scope. Still arguing for translation at a gateway.
1) People agree only for ISDN
2) People say ISDN plus extensions.
3) Do not define semantics - open to put everything there.
Some for 1), more for 2) and none for 3).
Take to list and continue discussing.
Robert: Is dispatch saying this should be dispatched somewhere?
Nobody hummed for not doing this at all.
AD request: Focus on defining the charter rather than doing the work.
Dean asked for hum on whether should be in SIPCORE, or new WG or what. Explained that felt should be new WG.
Cullen: Will potentially need more time that 15 min, therefore this is good pragmatic reason for new WG.
Robert: Understands that it is not safe to do as individual AD sponsored item.
Session Recording Protocol
IETF 75, Stockholm
(Leon Portman on behalf of the team)
Draft authors: Rajnish Jain, Leon Portman, Vijay Gurbani, Hadriel Kaplan, Andrew Hutton, Kenneth Rehor Other presentation contributors: Dan Wing, Alan Johnston, Eric Burger, Francois Audet
Presenter made statement that IPR existed at the start of the discussion.
Some use cases for recording
Trading floor compliance
Contact Center quality management
Financial institution transactions
Insurance and healthcare regulations
Emergency services regulations
In many cases it's not a legal requirement, it's a user requirement - users wanting to protect themselves (i.e., non-repudiation)
Reasons for Standardization
Lack of standard protocol for recording currently limits adoption of IP telephony in the enterprises There are many existing proprietary, non-interoperable protocols Migrating multiple implementations of proprietary protocols to an interoperable standard
Deployment Example 1
Middle-box B2BUA as Recording Client (RC)
Examples: IP-PBX, Media Server, SBC, Mixer
Deployment Example 2
UA as Recording Client
Examples: phones, softclients, gateways
Required SRP interfaces
Recording Control (RC->RS or RS->RC)
Recorded Media (RC->RS)
Call Metadata (RC->RS) (not covered yet)
Why use SIP for SRP?
Recording session (SRP) is a media session Call Control functionality: JOIN, REFER SIP Events framework already available Reuse of existing mechanisms:
Codec and transport negotiation
Roni: Does not understand the purpose. What is currently missing in SIP.
Answer: Need SIP to provide the correlation parameters.
Roni: Things are missing in order to know what is to be standardised.
Hadriel: Need to clearly indicate in SIP later that this is to be used for SRP communication.
Scott Lawrence (via Jabber): Some of these are authorisation issues. Comes into 3rd party authentication discussion.
Orthogonal to session recording
May be useful for recorder (media server) control XCON Orthogonal to session recording UA participants may not be aware, and do not target, a conference server SRP has some unique requirements Call-event and user-status notifications Recording transparency Persistent vs. dynamic mode Either RS or RC invoking recording
SRTP Support - Proposal
Decrypting encrypted streams has policy, privacy, legal, business, and security issues Out of scope of IETF If business conditions dictate privacy of cleartext RTP from the RC, new keys are derived and RTP is sent over a confidential channel (SRTP, IPSec).
If RC only has access to encrypted media, the media is simply mirrored out to the RS
Playback support: out of scope
Playback of streams has policy, privacy, legal, business, and security issues Using IPFIX: not applicable, and very different semantics Support for other session protocols (H.323, H.248, etc.): out of scope
UA as Recording Client
Examples: phones, softclients, gateways
Brian: Need to hone in on use cases. Voice monitored fro QA purposes. User knows about this. Other case is recorder where noone knows recording is in place. Looking for use case where we need more work because these two cases are solved.
Vijay Gurbni: Work is not to surripticiously record. User knows in these cases that they are being recorded.
Alan Johnson. More use cases need to be got into the draft. Common for only certain segments are recorded. In previous work conflated too many security issues and that confused this.
Hadriel Kaplan: Not all solutions do this on a conference bridge. Additional this does not cover CALEA.
Jon Peterson: Is a requirement that the endpoints explicitly authorise the presence of recording. If message is played and caller has opportunity to hang up meets this requirement.
Eric Burger: Looks obvious on one hand. Every PBX manufacturer and every call recorder in room is saying that we need this.
Roni Even: Not enough information on the requirements. Brian is saying that can do using a conf bridge but author is saying that does not scale. Therefore something missing in requirements to identify this difference.
Francois Audet: SHould just start doing this. Need requirements and should not focus on the solution for now.
Scott Lawrence (via Jabber): Wants standard i'f to recorders.
Andy hutton: Need these.
Theo: Also wants this.
Hum: Assuming both endpoints are notified of this requirement, then who would be opposed.
Jon Peterson wants notification and agreement as a mandatory requirement.
Scott: Would Jon be happy for a mechanism to declare that they do not authorise recording, e.g. Requires: no -record. John happy with this.
Cullen: IPfix did have a problem passing because it does not explicitly announce that it was recording.
No hums against doing more work in the IETF.
Mailing list will be requested.