Transcoding Services Invocation in the Session Initiation Protocol (SIP) Using Third Party Call Control (3pcc)
RFC 4117

Note: This ballot was opened for revision 02 and is now closed.

(Allison Mankin) Yes

(Jon Peterson) Yes

(Harald Alvestrand) No Objection

Comment (2004-10-28)
No email
send info
Reviewed by Mary Barnes, Gen-ART. No comments.

HTA comment: the fact that a transcoder is given permission to be a man-in-the-middle attack needs at least to be noted. But Russ has a DISCUSS that touches on that, so I don't think an extra DISCUSS is warranted.

(Steven Bellovin) No Objection

(Margaret Cullen) No Objection

(Bill Fenner) No Objection

(Scott Hollenbeck) No Objection

(Russ Housley) (was Discuss) No Objection

(David Kessens) No Objection

(Bert Wijnen) No Objection

(Ted Hardie) No Record

Comment (2004-10-27)
No email
send info
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.