Re: [MEDIACTRL] SDP review of mediactrl framework

["Spencer Dawkins" <[e-mail]>]

Hi, Jonathan,

Thank you very much for your feedback on the SDP usage in the mediactrl 
control framework. This is un-sticking basically every document in 
mediactrl, so we appreciate it a lot.

You have a couple of points that I'll ask the authors to respond to, but 
there are a couple I think I can field... inline ...

Thanks,

Spencer


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

It seems reasonable that we give guidance about using the Control Framework 
that recognizes that forking could occur.

SIP AORs have multiple contacts for a reason - because each of the contacts 
makes sense for the AOR. Some may make more sense than others (I might fork 
to my desk set and to my cell phone), but any contact should be acceptable, 
or the AOR shouldn't be registered with the contact (I shouldn't expect to 
fork between my Control Server and my cell phone.

So I would be OK with text that reminds the reader that

(1) SIP AORs used with Mediactrl may fork,

(2) MediaCtrl clients may receive multiple responses if a proxy does fork 
requests, and

(3) Medicatrl administrators must ensure that if a MediaCtrl AOR has 
multiple contacts registered for forking, each contact must be capable of 
doing MediaCtrl, so that forking to each of these contacts makes sense.

I don't think it's appropriate to discourage forking, which could be helpful 
if multiple Identical Control Servers are all registered with the same AOR 
for loadsharing, for example.

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

OK, let me split this into two cases.

In the case where a Control Client is misconfigured as a Control Server, 
there are two servers, so neither would be sending a CFW SDP offer (I don't 
think either would reasonably send an INVITE to ther other at all). I don't 
think either would become connected to the other.

In the case where a Control Server is misconfigured as a Control Client, 
there are two clients, and you're correct that either could initiate a 
connection, using an SDP offer with CFW. But a Control Client wouldn't have 
any reason to accept an SDP offer with CFW. Again, I'm not sure how either 
Control Client would send back an SDP answer, so I don't think either would 
become connected to the other.

I know third-party call control is always a torture test, but I'm not sure 
how third-party call control would change this - no Control Client would 
accept an SDP offer with CFW, no matter where it comes from.

So I'm not thinking that we need text here (speaking as an individual) - 
what do others think?