Document Action: 'Transcoding Services Invocation in the Session Initiation Protocol (SIP) Using Third Party Call Control (3pcc)' to Informational RFC

[The IESG <[e-mail]>]

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-02.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.

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 [3]
NEW:
There are various possible solutions for this problem. One solution
consists of using the SDP group attribute with FID (Flow Identification)
semantics [3]


-----------
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 [2].

NEW:
4 Security Considerations

RFC 3725 [2] 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.


_______________________________________________
IETF-Announce mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf-announce