Subject: [MEDIACTRL] Comment for WGLC mediactrl-framework-02

From: "Even, Roni" <[email-masked]>
Date: Sun, 13 Jul 2008 10:28:50 +0300

Hi,
Some comments In got from an internal review.

1. In section 9.1 there is a requirement for version numbering. What
about backward compatibility is it a MUST for new versions? Is it
implied that by supporting high version number you also support lower
version number?

2. In section 12 both point 4 and 6 has "Control Client opens a TCP
connection to the Control Server. The connection can now be used to
exchange control framework     messages". Why?

Regards
Roni

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Eric Burger
> Sent: Monday, June 30, 2008 11:36 PM
> To: [email-masked]
> Subject: [MEDIACTRL] WGLC mediactrl-framework-02
> 
> WGLC of the Media Control Channel Framework, which you can find at:
> http://www.ietf.org/internet-drafts/draft-ietf-mediactrl-sip-control-
> framework-02.txt
> 
> will close on Monday, 14 July 2008.
> 
> Note there will be a -03 which addresses the RAI review questions
> relating to why we use SIP to establish the control channel.
> 
> Thank you.
> _______________________________________________
> MEDIACTRL mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl
_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: "Chris Boulton" <[email-masked]>
Date: Mon, 14 Jul 2008 11:57:26 +0100

Hi,

[Chris Boulton] I will add some text.  I don't think the Framework
should specify directly but should encourage package authors to clearly
state.

[Chris Boulton] This has already been fixed in the latest version (as a
result of RAI review).

Regards
Roni

On

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 14 Jul 2008 07:02:56 -0500

Speaking as an individual contributor (so Eric can make a ruling if there's 
controversy about what I suggest)...

> should specify directly but should encourage package authors to clearly

If we have a protocol number, we may really want backward compatibility (as 
we want other good things), but it isn't a MUST.

If you drop three functions out of what was version 4 of a protocol, and 
increment the version number, implementers have a right to be irritated, but 
they can tell the difference between version 4 and version 5 packets, and 
they know what to do with both kinds of packets. That's what the MUST would 
be, in my opinion.

So it could be OK to encourage package authors to increment version numbers 
for changes that aren't backwards-compatible (but I hope they would know 
this). But I would not suggest text that says more than this.

IMO, of course.

Spencer

---

From: Eric Burger <[email-masked]>
Date: Mon, 14 Jul 2008 11:49:46 -0400

Speaking as an individual contributor, too, I like Chris' suggestion  
that basically says "it would be nice to have backwards compatibility,  
but no matter what, you need to document backwards compatibility or  
the lack thereof." Note the non-use of RFC 2119 language :-)

By the way, Spencer and I just looked at the ABNF, and the "version  
number" really is just an arbitrary string, making the normative  
language in section 8.1 meaningless. I would offer we need to fix the  
ABNF to be showing something like
	package-name = alpha-num-token '/' *DIGIT '.' *DIGIT

On Jul 14, 2008, at 8:02 AM, Spencer Dawkins wrote:

> Speaking as an individual contributor (so Eric can make a ruling if  
> there's controversy about what I suggest)...
>
> If we have a protocol number, we may really want backward  
> compatibility (as we want other good things), but it isn't a MUST.
>
> If you drop three functions out of what was version 4 of a protocol,  
> and increment the version number, implementers have a right to be  
> irritated, but they can tell the difference between version 4 and  
> version 5 packets, and they know what to do with both kinds of  
> packets. That's what the MUST would be, in my opinion.
>
> So it could be OK to encourage package authors to increment version  
> numbers for changes that aren't backwards-compatible (but I hope  
> they would know this). But I would not suggest text that says more  
> than this.
>
> IMO, of course.
>
> Spencer
>

---

From: "Even, Roni" <[email-masked]>
Date: Mon, 14 Jul 2008 19:05:04 +0300

Hi,
So if there is no mandatory backward compatibility than we will need a
way to know which version of the package is supported by the other side.
Roni

On
> Behalf Of Eric Burger
> Sent: Monday, July 14, 2008 6:50 PM
> To: Spencer Dawkins
> Cc: [email-masked]
> Subject: Re: [MEDIACTRL] Comment for WGLC mediactrl-framework-02
>

---

From: "Even, Roni" <[email-masked]>
Date: Mon, 14 Jul 2008 19:32:17 +0300

Hi,
In section 6.3.4.2

"Once the initial SYNC transaction is completed, either client MAY
   choose to send a subsequent new SYNC Control Framework message to re-
   negotiate the packages that are supported within the control channel.
   A new SYNC message whose Packages header has different values from
   the previous SYNC message can effectively add and delete the packages
   used in the control channel.  If a client receiving a subsequent SYNC
   message does not wish to change the set of packages, it MUST respond
   with a 421 Control Framework response code.  Subsequent SYNC messages
   MUST NOT change the value of the "Dialog-ID" and "Keep-Alive" Control
   Framework headers that appeared in the original SYNC negotiation."

What is the meaning of "either client" do you mean either the control
client or the control server?

A nit, start of second paragraph of 6.3.4.2 change "An server" to "A
server"

Regards
Roni

---

From: "Chris Boulton" <[email-masked]>
Date: Mon, 14 Jul 2008 21:47:35 +0100

That was the reason for having the package name as a string - but with
some embedded meaning.  If the string didn't match - then it's a
different version.  It was intended to be very basic when we first
introduced and so if we want something more sophisticated we should hash
that out.

Chris.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Even, Roni
Sent: 14 July 2008 17:05
To: Eric Burger; Spencer Dawkins
Cc: [email-masked]
Subject: Re: [MEDIACTRL] Comment for WGLC mediactrl-framework-02

Hi,

On

---

From: "Chris Boulton" <[email-masked]>
Date: Mon, 14 Jul 2008 21:51:52 +0100

Hi,
In section 6.3.4.2

[Chris Boulton] you are right - I was trying to emphasize the point that
the roles are logical in the Framework (and then messages are bound by
what's specified in each package).  How about something like:

'Once the initial SYNC transaction is completed, either client acting in
the Control Client role MAY......'.

[Chris Boulton] Merci.

Regards
Roni

---

From: "Even, Roni" <[email-masked]>
Date: Tue, 15 Jul 2008 16:13:39 +0300

Hi,

1. in section 9.1 the ABNF is dialog-id-string = alpha-num-token "~"
alpha-num-token ["~" alpha-num-token]
 While in the example you have Dialog-ID: fndskuhHKsd783hjdla - do you
need a "~" after at least 4 characters?

2. In the table at the end of section 9.1 is Package header field
mandatory in Control method?

3. In the ABNF status-code = 3DIGIT should be status-code = 3*DIGIT

4. How do you co-relate the CONTROL message to a specific SIP dialog is
it based on the socket on which the message arrive. In this case does it
mean that in the COMEDIA negotiation the connection:new is mandatory and
you cannot use existing connection.

Regards
Roni

---

From: "Chris Boulton" <[email-masked]>
Date: Tue, 15 Jul 2008 15:24:16 +0100

Hi,

[Chris Boulton] Good catch.  That is legacy from before we moved to just
a plain token that appears in the SDP as well.  I propose I remove the
'~' from the BNF and just have a string.

[Chris Boulton] The Packages header doesn't really have any meaning in
the context of a CONTROL message.  The 'Control-Package' header
specifies the context of the CONTTROL message.  The 'Packages' header is
really for 'SYNC' session level negotiation.

[Chris Boulton] noted.

[Chris Boulton] Sorry Roni, think I am missing something.  By
establishing the SYNCH both sides are then aware of the correlation
between a connection and the overlying dialog.  The CONTROL messages are
a by-product of the earlier SYNC interaction.  I was under the
impression that 'connection:existing' was for subsequent requests that
do not change the IP address/port combination.  Perhaps I am missing the
use case that you think breaks?

Regards
Roni

---

From: "Even, Roni" <[email-masked]>
Date: Wed, 16 Jul 2008 09:01:50 +0300

Chris,

> use case that you think breaks?
[RE:] see the example

The AS connects to the MS as specified in the first example of section
10. Afterwards it wants to start another control session but this time
it will use connection:exist as shown below,

1.   Control Client->Control Server (SIP): INVITE
        sip:[email-masked]

   INVITE sip:[email-masked] SIP/2.0
   To: <sip:[email-masked]>
   From: <sip:[email-masked]>;tag=8938345
   Via: SIP/2.0/UDP control-client.example.com;branch=z9hG412345786
   CSeq: 1 INVITE
   Call-ID: [email-masked]
   Contact: <sip:[email-masked]>
   Content-Type: application/sdp
   Cotent-Length: [..]

   v=0
   o=originator 2890844526 2890842808 IN IP4 controller.example,com
   s=-
   c=IN IP4 control-client.example.com
   m=application 7575 TCP/CFW
   a=setup:active
   a=connection:exist
   a=cfw-id:fndskuhHKsd783hjcaa

   2.   Control Server->Control Client (SIP): 200 OK

   SIP/2.0 200 OK
   To: <sip:[email-masked]>;tag=023983889
   From: <sip:[email-masked]>;tag=8938345
   Via: SIP/2.0/UDP control-client.example.com;branch=z9hG412345786
   CSeq: 1 INVITE
   Call-ID: [email-masked]
   Contact: <sip:[email-masked]>
   Content-Type: application/sdp
   Content-Length: [..]

   v=0
   o=originator 2890844526 2890842808 IN IP4 controller.example,com
   s=-
   c=IN IP4 control-server.example.com
   m=application 7575 TCP/CFW
   a=setup:passive
   a=connection:exist
   a=cfw-id:fndskuhHKsd783hjcaa

   3.   Control Client->Control Server (SIP): ACK
   4.   Control Client opens a TCP connection to the Control Server.
        The connection can now be used to exchange control framework
        messages.  Control Client-->Control Server (Control Framework
        Message): SYNC.

   CFW 8djae7khaxx SYNC
   Dialog-ID: fndskuhHKsd783hjcaa
   K-alive: 100
   Packages: msc-ivr-basic/1.0

   5.   Control Server-->Control Client (Control Framework Message):
        200.

   CFW 8djae7khaxx 200
   Keep-Alive: 100
   Packages: msc-ivr-basic/1.0
   Supported: msc-ivr-vxml/1.0,msc-conf-audio/1.0

   6.   Once the SYNC process has completed, the connection can now be
        used to exchange control framework messages.  Control
        Client-->Control Server (Control Framework Message): CONTROL.

   CFW i387yeiqzrr CONTROL
   Control-Package: <package-name>
   Content-Type: example_content/example_content
   Content-Length: 11

   <XML BLOB/>

The AS send the message in step 6 how does the MS when it receives it
know if this is for the first control session that has Dialog-ID:
fndskuhHKsd783hjdla or for the second control session that has
Dialog-ID: fndskuhHKsd783hjcaa

Thanks
Roni

---

From: "Even, Roni" <[email-masked]>
Date: Wed, 16 Jul 2008 11:18:53 +0300

Chris,
Some more

1. On the dialog-id-string what will be the size, is it 32 or 96
characters.

2. We noticed that the usage of "K-alive" method and "keep-alive" header
is not consistent in the document, you some time replace them. See
example message 4, the paragraph before 6.3.3.1 and in 6.3.4.1 and I did
not check the whole document.

3. According to 6.1 the transaction-id MUST be unique yet in the
examples in messages 6,8,10 you use the same one

Roni  

> From: Chris Boulton [mailto:[email-masked]]
> Sent: Tuesday, July 15, 2008 5:24 PM
> To: Even, Roni; [email-masked]
> Subject: RE: [MEDIACTRL] More comments for WGLC mediactrl-framework-02
> 
> 
> Hi,
>

---

From: "Chris Boulton" <[email-masked]>
Date: Wed, 16 Jul 2008 09:45:40 +0100

All noted for next version - thanks Roni.

Chris.

-----Original Message-----
From: Even, Roni [mailto:[email-masked]] 
Sent: 16 July 2008 09:19
To: Chris Boulton; [email-masked]
Subject: RE: [MEDIACTRL] More comments for WGLC mediactrl-framework-02

Chris,
Some more

Roni

---

From: Lorenzo Miniero <[email-masked]>
Date: Wed, 16 Jul 2008 10:57:59 +0200

Hi all,

about the third issue raised by Roni, in messages 6, 8, 10 (and 12 as  
well) the transaction id is the same because it actually is the same  
transaction, a transaction being composed of several messages and its  
lifetime extended by the REPORT mechanism. But besides that, didn't we  
agree that transaction identifiers, though unique in the transaction  
lifetime, could be reused subsequently with no harm?

Lorenzo

-- 
Lorenzo Miniero, Junior Researcher
Dipartimento di Informatica e Sistemistica
Universita' degli Studi di Napoli "Federico II"
Via Claudio 21 -- 80125 Napoli (Italy)
Phone: +390817683821 - Fax: +390817683816
Email: [email-masked]
_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: "Even, Roni" <[email-masked]>
Date: Wed, 16 Jul 2008 12:05:55 +0300

Hi,
Yes, my mistake did not notice the 202.

As for re-using transaction-id from the same source the issue is that you cannot reuse them until you are sure that the transaction was terminated. (example, send a control and send another control with the same transaction before getting the 200 from the first one).
>From different sources they have to be unique.
Roni

> From: Lorenzo Miniero [mailto:[email-masked]]
> Sent: Wednesday, July 16, 2008 11:58 AM
> To: Chris Boulton
> Cc: Even, Roni; [email-masked]
> Subject: Re: [MEDIACTRL] More comments for WGLC mediactrl-framework-02
> 
> Hi all,
> 
> >> specifies the context of the CONTTROL message.  The 'Packages'
> header
> >> is
> >> it based on the socket on which the message arrive. In this case
> does
> >> it

---

From: "Chris Boulton" <[email-masked]>
Date: Wed, 16 Jul 2008 10:08:33 +0100

Roni - thanks for the explanation.

I think (others please speak up) that there are two potential solutions
here:

- Restrict in the Control Framework so that the 'cfw-id' must maintain
the same value for the existence of the SIP dialog.  That basically
restricts a 1:1 between the SIP dialog and the control channel whether
it is re-negotiating using 'connection:existing' or re-establishing
using 'connection:new'.
- Allow the 'Dialog-ID' header to appear in a CONTROL message so that it
can be associated with a session.

My personal preference is to keep the association clean and have a 1:1
between a SIP dialog and a control channel and use option 1.  I think
option 2 will quite a bit more complexity in both the specification and
the implementation.  I would really like to hear from the group,
especially those who are implementing.

Chris.

-----Original Message-----
From: Even, Roni [mailto:[email-masked]] 
Sent: 16 July 2008 07:02
To: Chris Boulton; [email-masked]
Subject: RE: [MEDIACTRL] More comments for WGLC mediactrl-framework-02

Chris,

[RE:] see the example

   v=0

   SIP/2.0 200 OK

   v=0

   CFW 8djae7khaxx SYNC

   CFW 8djae7khaxx 200
   Keep-Alive: 100

   CFW i387yeiqzrr CONTROL

   <XML BLOB/>

Thanks
Roni

---

From: "Chris Boulton" <[email-masked]>
Date: Wed, 16 Jul 2008 10:09:43 +0100

Hi all,

about the third issue raised by Roni, in messages 6, 8, 10 (and 12 as  
well) the transaction id is the same because it actually is the same  
transaction, a transaction being composed of several messages and its  
lifetime extended by the REPORT mechanism. 

[Chris Boulton] Correct.

---

From: "Even, Roni" <[email-masked]>
Date: Wed, 16 Jul 2008 12:18:01 +0300

Chris,
I am not sure I understand the first suggestion, do you mean to use the
same transaction-id for all the control session? 
There is another option to allow only new connections.
Roni

> Sent: Wednesday, July 16, 2008 12:09 PM
does

---

From: Lorenzo Miniero <[email-masked]>
Date: Wed, 16 Jul 2008 11:33:10 +0200

Chris,

I also prefer the first option, assuming of course that a  
connection:new in an already existing SIP dialog actually replaces the  
previous connection (which if I correctly remember the COMEDIA RFC is  
exactly how it should work).

Lorenzo

---

From: "Chris Boulton" <[email-masked]>
Date: Wed, 16 Jul 2008 10:53:15 +0100

Chris,

[Chris Boulton] Perhaps I am misunderstanding - I was under the
impression from RFC 4145 that:

'If such an offerer wants to
   continue using the previously-established transport-layer connection
   for the 'm' line, the offerer MUST use a connection value of
   'existing' for the 'm' line.  If, on the other hand, the offerer
   wants to establish a new transport-layer connection for the 'm' line,
   it MUST use a connection value of 'new''.

So - my suggestion was that IF an entity wanted to change some of the
SDP but reuse the already established connection it should use
'existing'.  If it has noted that a connection is down and wants to
re-establish, it uses 'new'.  Throughout this the connection identifier
specifies in the 'cfw-id' SDP parameter does not change.  You are simply
negotiated the underlying TCP between endpoints BUT always using the
same Control Framework session.

[Chris Boulton] I'm happy with that but doesn't that restrict you?  What
if you wanted to change something in the SDP (another attribute) but
didn't want to create a new connection?

Chris.

does

---

From: "Chris Boulton" <[email-masked]>
Date: Wed, 16 Jul 2008 10:53:52 +0100

Chris,

[Chris Boulton] Yes - that's the proposal.

Lorenzo

---

From: "Even, Roni" <[email-masked]>
Date: Wed, 16 Jul 2008 12:58:16 +0300

Chris,
So if I understand correctly what you suggest is that each control
session will use a new connection. Using existing one is only for the
same control session but not to a new one.
If this is what you meant this is OK by me.
Roni

> Sent: Wednesday, July 16, 2008 12:53 PM
> > - Allow the 'Dialog-ID' header to appear in a CONTROL message so
that
> > > 4. How do you co-relate the CONTROL message to a specific SIP
> dialog
> > is
> > > mean that in the COMEDIA negotiation the connection:new is
> mandatory
> > > and
> > > between a connection and the overlying dialog.  The CONTROL
> messages
> > > are
> > > do not change the IP address/port combination.  Perhaps I am
> missing
> > > the

---

From: "Chris Boulton" <[email-masked]>
Date: Wed, 16 Jul 2008 11:05:15 +0100

Chris,
So if I understand correctly what you suggest is that each control
session will use a new connection.

[Chris Boulton] Correct.  So you create a 1:1 association by stating
that the 'cfw-id' must be the same throughout the life of the SIP
dialog. 

 Using existing one is only for the
same control session but not to a new one.

[Chris Boulton] Correct.  You can use 'connection:new' to re-establish
OR 'connection:existing' to change other parts of the SDP but the
'cfw-id' remains that same.

that