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

From: Chris Boulton <[email-masked]>
Date: Fri, 02 Oct 2009 14:44:48 +0100

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

---

From: "Jonathan Lennox" <[email-masked]>
Date: Fri, 2 Oct 2009 11:11:44 -0400

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
[email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Chris Boulton
> Sent: Friday, October 02, 2009 9:45 AM
> To: [email-masked]
> Subject: [MEDIACTRL] Control Framework SDP Review - Issue 3
> 
> Issue 3:
> 
> [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
> _______________________________________________
> MEDIACTRL mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl

---

From: John Dally <[email-masked]>
Date: Mon, 05 Oct 2009 13:02:45 +0100

> wait until it gets the SDP answer before it can respond to the SYNC, but
Hello,

I would prefer waiting for the SIP ack before sending the CF sync - 
rather than having to block the CF sync if the 200 OK hasn't been 
received. It will also define the sequence more tightly (eg 
implementations may choose to wait for the SIP ack anyway).

    Cheers

       John