Transcoding Services Invocation in the Session Initiation Protocol (SIP) Using Third Party Call Control (3pcc)
draft-ietf-sipping-transc-3pcc-02

In section 3.2, the draft says:

   B may have different reasons for invoking T before knowing A's
   session description. B may want to hide its capabilities, and
   therefore it wants to return a session description with all the
   codecs B supports plus all the codecs T supports. Or T may provide
   recording services (besides transcoding), and B wants T to record the
   conversation, regardless of whether or not transcoding is needed.

I found the first example ("B may want to hide its capabilities") somewhat
confusing, until I turned it into "B may want to hide its lack of native capabilities".
If this is what is meant, a direct statement might be easier for other readers
to parse.  

In Section 3.4, the draft says:

 One solution consists of using the SDP group attribute with FID
   semantics [3]

The citation treats FID as acronym with an expansion, so it would probably
be better to expand it here.

In general, this section left me wondering if there was a need for a FID-like
grouping semantic that allowed for different codecs.  This would limit
the need for T to replicate the streams (at least once it was deployed).  Not
something for this document to do, obviously, but is there any work on
that under consideration?

I noted in the examples for 3.5 that the streams were considered send-only
receive/only.  While this is certainly one way to do it, it is actually common
for human relay operators to clarify points (such as asking "FID F-I-D?") as they go.  
Nothing in the draft forbids this, obviously, but an example that took it into account
might be useful.