[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MEDIACTRL] SDP review of mediactrl framework

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?