[MEDIACTRL] SDP review of mediactrl framework

["Jonathan Lennox" <[e-mail]>]

At the last IETF, I volunteered to review the SDP usage in the mediactrl
framework (draft-ietf-mediactrl-sip-control-framework-10), and after
some nagging from the relevant chairs (thanks!), I've gotten to it.

My first comment is on the use of the values "TCP/CFW", "TCP/TLS/CFW",
"SCTP/CFW" and "SCTP/TLS/CFW" for the SDP <proto> field, with a "fmt"
field of "*".  A more usual use of the proto field would be to use the
existing proto fields "TCP", "TCP/TLS", "SCTP", or "SCTP/DTLS", and then
(after defining "application/cfw" as a media type) use "cfw" as the
<fmt> field.

Thus, instead of having

m=application 7575 TCP/CFW *

you'd have

m=application 7575 TCP cfw

This has the advantage of leveraging other existing work in SDP, e.g.
you would get ICE-TCP "for free" once it's finished.


To be sure, there would be some disadvantages of this.

Notably, "SCTP" and "SCTP/DTLS" are still only defined in an individual
I-D, and there's been only limited attention paid to it in the MMUSIC
community.  On the other hand, if Mediactrl has the expertise to
understand how SCTP should work in a comedia context, it'd probably be
better to let this be available to everything that would want to use it,
rather than just CFW.

Also, Comedia-TLS (RFC 4572) is designed for the symmetric peer-to-peer
model (with mutual authentication and certificate fingerprints), not the
client-server model (with server certificates signed by well-known CAs,
and client authentication optional).  It looks like the intention for
mediactrl was to do the latter, instead.  Would there be significant
difficulties with doing the former?


Another question I have relates to SDP Offer/Answer.  It looks like the
intention is that the CFW session last exactly the length of the SIP
INVITE dialog usage (note that this terminology [from RFC 5057] should
probably be used rather than "SIP dialog").  Does this mean that it is
forbidden, despite offer/answer semantics, to add or remove a cfw
session in a SIP re-INVITE?   If so, this should probably be stated
explicitly.
	

One other concern I have is how CFW interacts with SIP forking.  As far
as I can tell, if an initiator sends an initial SDP offer with setup
mode "passive" or "actpass" (which, as the draft mentions, may be
necessary for topology reasons), and the INVITE is forked, the initiator
could receive multiple answers and thus multiple incoming connections.
As far as I can tell, all such answers will have identical cfw-id
values, and thus the initial offerer has no way to correlate them.  (One
solution to this problem would be for answerers to have their own unique
cfw-id values, separate from those of offerers; the CFW Dialog-ID header
field would then need to be sent in the 200 response to SYNC as well as
in SYNC request.)


I also note that as far as I can tell, neither SDP nor the CFW SYNC
message provides any indication of whether a given endpoint thinks it's
a Control Client or a Control Server.  It seems this is supposed to be
implicit based on the directionality of the initial SIP INVITE request
that set up the call, but in some cases this can get confused in SIP
(notably given third-party call control), and I'm sure the results could
be odd, and hard to diagnose, if two clients or two servers accidentally
end up connected.  Perhaps this should be a property of the relevant
control package, rather than of CFW proper, but it seems like it should
be addressed. 

-- 
Jonathan Lennox
Vidyo, Inc
[e-mail]