Re: [MEDIACTRL] Control Framework SDP Review - Issue 3

["Jonathan Lennox" <jonathan at vidyo.com>]

I wouldn't suggest that you try to make receiving the ACK part of the
CFW state machine, since it's not at the same state machine layer as the
offer/answer exchange, and there are cases where it isn't present (e.g.
delayed offer, or reliable provisional responses).

I'm not sure I follow what the issue is with the race between the SDP
answer and the SYNC, anyway.  The endpoint receiving both may need to
wait until it gets the SDP answer before it can respond to the SYNC, but
is this a problem?

-- 
Jonathan Lennox
Vidyo, Inc
jonathan at vidyo.com


> -----Original Message-----
> From: mediactrl-bounces at ietf.org [mailto:mediactrl-bounces at ietf.org]
On
> Behalf Of Chris Boulton
> Sent: Friday, October 02, 2009 9:45 AM
> To: mediactrl at ietf.org
> Subject: [MEDIACTRL] Control Framework SDP Review - Issue 3
> 
> Issue 3:
> 
> 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.
> 
> [Chris] That is possible.
> 
> 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.)
> 
> [Chris] Agreed.  I would propose that we use Jonathan's suggestion of
> making the cfw-id unique per endpoint.  The endpoint initiating the
> connection then inserts its own cfw-id into the SYNC message.  This
> will then allow an endpoint receiving connections to cope with a
forked
> SIP call.  We would also need guidelines that inform SIP UAS acting in
> the 'active' role that they must wait for the incoming ACK before
> sending the SYNC message otherwise we create a race between the SIP
> response and the SYNC.  Using multiple entities to generate the cfw-id
> also means that we need to tighten up on exactly how its generated - I
> will propose some text in the next couple of days.  This is a
> worthwhile change and provides a more complete solution.  Any
comments?
> Suggestions or problems?
> 
> This raises another interesting point that the document is not very
> strong on procedures for terminating.  I also think we need to add
some
> text to the end of both sections 4.1 and 4.2 on how to act when
> terminating a session.  While we infer its linked to the SIP session
> etc I think we need to be more explicit.
> 
> --
> Chris Boulton
> CTO & Co-founder
> NS-Technologies <http://www.ns-technologies.com>
> m: +44.7876.476681
> _______________________________________________
> MEDIACTRL mailing list
> MEDIACTRL at ietf.org
> https://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl