Transcoding Services Invocation in the Session Initiation Protocol (SIP) Using Third Party Call Control (3pcc)
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: Internet Architecture Board <email@example.com>, RFC Editor <firstname.lastname@example.org>, sipping mailing list <email@example.com>, sipping chair <firstname.lastname@example.org> Subject: Document Action: 'Transcoding Services Invocation in the Session Initiation Protocol (SIP) Using Third Party Call Control (3pcc)' to Informational RFC The IESG has approved the following document: - 'Transcoding Services Invocation in the Session Initiation Protocol (SIP) Using Third Party Call Control (3pcc) ' <draft-ietf-sipping-transc-3pcc-03.txt> as an Informational RFC This document is the product of the Session Initiation Proposal Investigation Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-transc-3pcc-03.txt
RFC Editor Notes Page 6, second to last paragraph: OLD: B may want to hide its capabilities, NEW: B may want to hide its lack of native capabilities, ------------ Page 9, last paragraph: Expand FID acronym. OLD: There are various possible solutions for this problem. One solution consists of using the SDP group attribute with FID semantics  NEW: There are various possible solutions for this problem. One solution consists of using the SDP group attribute with FID (Flow Identification) semantics  ----------- Section 3.5. Add the following paragraph after the second paragraph of the section: NEW: Note this example uses unidirectional media streams (i.e., sendonly or recvonly) to clearly identify which transcoder handles media in which direction. Nevertheless, nothing precludes the use of bidirectional streams in this scenario. They could be used, for example, by a human relay to ask for clarifications (e.g., I did not get that, could you repeat, please?) to the party he or she is receiving media from. --------- OLD: 4 Security Considerations This document describes how to use third party call control to invoke transcoding services. It does not introduce new security considerations besides the ones discussed in . NEW: 4 Security Considerations RFC 3725  discusses security considerations which relate to the use of third party call control in SIP. These considerations apply to this document, since it describes how to use third party call control to invoke transcoding services. In particular, RFC 3725 states that end-to-end media security is based on the exchange of keying material within SDP and depends on the controller behaving properly. That is, the controller should not try to disable the security mechanisms offered by the other parties. As a result, it is trivially possible for the controller to insert itself as an intermediary on the media exchange, if it should so desire. In this document, the controller is the UA invoking the transcoder, and there is a media session established using third party call control between the remote UA and the transcoder. Consequently, the attack described in RFC 3725 does not constitute a threat because the controller is the UA invoking the transcoding service and it has access to the media anyway by definition. So, it seems unlikely that a UA attempts to launch an attack against its own session by disabling security between the transcoder and the remote UA. Regarding end-to-end media security from the UAs' point of view, the transcoder needs access to the media in order perform its function. So, by definition, the transcoder behaves as a man in the middle. UAs that do not want to a particular transcoder to have access to all the media exchanged between them can use a different transcoder for each direction. In addition, UAs can use different transcoders for different media types.