Subject: Re: [MEDIACTRL] SIP Control Framework

From: Salvatore Loreto <[email-masked]>
Date: Mon, 08 Oct 2007 14:41:08 +0300

Hi all,

after a quickly read on the framework work, I have some more comment to
the ones pointed out by Lorenzo :

In section 2, in the Method term definition you state "Three Methods are
defined" but then you list 4 methods

In section 3, you states "The ability to have multiple control channels
allows for stronger redundancy and the ability to menage high volumes of
traffic in busy system".
But then in the draft you don't explain how.
(I could say that for this issue an SCTP association is better then a
TCP connection.But then we should work on a COMEDIA for SCTP.)
Moreover the way you define and use Keep-alive contradicts, or doesn't
take in consideration your statement about redundancy.

  "If no 200
   OK response is received to the K-ALIVE Control Framework message,
   before the local 'keep-alive' timer fires, the 'active' client SHOULD
   tear down the SIP dialog and recover the associated control channel
   resources.  The 'active' client MAY choose to try and recover the
   connection by renegotiation using COMEDIA."

If multiple control channels are allowed and likely setup, a failure on a single one
should not cause the SIP dialog tear down.

In Section 7 you state:

   o  The 'Dialog-ID' message header is constructed by concatenating the
      Local-tag, Call-ID and Remote-tag (as defined in Section 11.1)
      from the SIP dialog and separating with a '~'.  See syntax defined
      in Section 16.1 in Appendix A and examples in Section 9.6.  For
      example, if the SIP dialog had values of 'Local-tag=HKJDH',
      'Remote-tag=JJSUSHJ' and 'Call-ID=[email-masked]' - the
      'Dialog-ID' header would look like this:
      'Dialog-ID=[email-masked]~JJSUSHJ'.

but then in 16.1 there is an error, because you don't use the Call-ID at all:
   
   If used within a
   package, the value contained in the 'connection-id' attribute MUST be
   constructed by concatenating the 'Local' and 'Remote' SIP dialog
   identifier tags as defined in RFC3261 [2].  They MUST then be
   separated using the '~' character.  So the format would be:

               'Local Dialog tag' + '~' + 'Remote Dialog tag'

References updating:
	-ref 9 is now RFC 4556
	-ref 10 is now RFC 4574

On Tue, 2007-09-11 at 11:29 +0200, Lorenzo Miniero wrote:
> Hi Chris and all,
> 
> just some lines to give you all a small review on the framework work.
> I already
> thought it was a very good work, so I'm happy to see it as a WG item
> now.
> 
> I noticed you removed the headers in the initial negotiation
> (Requires: escs,
> Control-Packages: ..), leaving this further negotiation to after the
> channel
> has been setup. I think it's good to have it there, considering it's
> more
> flexible, but wouldn't a previous negotiation be good as well? e.g. if
> the MS
> doesn't support a CP the AS needs, then the control channel wouldn't
> need to be
> opened at all. I remember a discussion in Prague about having these
> negotiation
> in the SDP itself, even if I'm not sure it would be the best solution.
> What are
> your feelings about this?
> 
> Then, I have a doubt regarding the chosen acronyms. SCFW is used in
> control
> messages, but ESCS instead is used in the COMEDIA negotiation.
> Wouldn't a
> single name be better to avoid confusion?
> 
> I also noticed a potential ambiguity in the text. At the beginning the
> Content-Length header in control framework messages is stated to be a
> MUST,
> even if no payload is attached (which would mean CL=0). But in the
> 10.1 figure,
> it is reported to be optional. Which one is true? I'd prefer to have
> it
> optional for bodyless messages, but that's just my two cents.
> 
> Finally, a couple of errors I've found in the example at the end:
>         1) the SIP BYE and its 200 OK both still have leftovers from
> the
> previous version (the Requires: escs and the Control-Packages header);
>         2) REPORT messages with an XML blob body are missing the
> Content-Length
> header.
> 
> 
> That's all for now, just a very brief review consequent to a first
> read of the
> renewed document. I hope it helped.
> 
> Cheers,
> Lorenzo
> 
> 
> 
> --
> Lorenzo Miniero, Junior Researcher
> Dipartimento di Informatica e Sistemistica
> Universit degli Studi di Napoli "Federico II"
> Via Claudio 21 -- 80125 Napoli (Italy)
> Phone: +390817683821 - Fax: +390817683816
> Email: [email-masked]
> 
> 
> 
> 
> 
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
> 
> 
> _______________________________________________
> MEDIACTRL mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl
> 
> 

_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: Lorenzo Miniero <[email-masked]>
Date: Mon, 08 Oct 2007 15:16:11 +0200

Hi Salvatore,

just a quick note inline upon one of the points you raised.

<cut>

>                'Local Dialog tag' + '~' + 'Remote Dialog tag'

The Dialog-ID refers to the identifier needed to correlate an AS-related 
SIP Dialog, i.e. a SIP dialog which is handling/going to handle a 
control channel, with the control channel itself. The connection-id, 
instead, refers to the negotiated media connection(s) (e.g. audio or 
video) the MS is needed to manage. So they are not the same identifier.

Whether the connection-id as it is conceived is enough to always 
univocally address a connection or not (as the Dialog-ID does), instead, 
is another matter. Having it formed as the Dialog-ID may help in this 
sense, even if I think it would add unneeded redundancy and probably 
weigh down the whole control channel communication.

Cheers,
Lorenzo

Università degli Studi di Napoli "Federico II"

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 08 Oct 2007 17:20:00 +0300

Hi Lorenzo,

you are right Dialog-ID and connection-id are two different things, and
I see the way they are different, more or less :-)
What confused me it is see in Section 7 the reference to 

	"See syntax defined in Section 16.1 in Appendix A and examples in
Section 9.6."

Then we could start to argue it a from-tag and the to-tag are enough to
identify a resource inside a dialog.

sal

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 14 Oct 2007 17:00:52 +0200

Hi,

I am not sure whether using the from- and/or to-tags to identify is the
best solution. SBCs have a tendence to modify those along the path.

Regards,

Christer 

> -----Original Message-----
> From: Salvatore Loreto [mailto:[email-masked]] 
> Sent: 8. lokakuuta 2007 17:20
> To: Lorenzo Miniero
> Cc: [email-masked]
> Subject: Re: [MEDIACTRL] SIP Control Framework
> 
> Hi Lorenzo,
> 
> you are right Dialog-ID and connection-id are two different 
> things, and I see the way they are different, more or less 
> :-) What confused me it is see in Section 7 the reference to 
> 
> 	"See syntax defined in Section 16.1 in Appendix A and 
> examples in Section 9.6."
> 
> Then we could start to argue it a from-tag and the to-tag are 
> enough to identify a resource inside a dialog.
> 
> sal
> 
> 
> > The Dialog-ID refers to the identifier needed to correlate an 
> > AS-related SIP Dialog, i.e. a SIP dialog which is handling/going to 
> > handle a control channel, with the control channel itself. The 
> > connection-id, instead, refers to the negotiated media 
> connection(s) 
> > (e.g. audio or
> > univocally address a connection or not (as the Dialog-ID does), 
> > instead, is another matter. Having it formed as the 
> Dialog-ID may help 
> > in this sense, even if I think it would add unneeded redundancy and 
> > probably weigh down the whole control channel communication.
> > 
> > 
> > Cheers,
> > Lorenzo
> > 
> 
> 
>

---

From: Lorenzo Miniero <[email-masked]>
Date: Sun, 14 Oct 2007 17:16:58 +0200

Hi Christer,

however, even if these tags are modified, once they've been setup they still 
should unique for each point-to-point SIP dialog, aren't they? If that's the 
case, the tags would still do the job anyway, considering each pair addresses 
a specific dialog between an AS and a MS. If not, you're absolutely right, 
and an alternative addressing solution should be considered.

Lorenzo

On Sunday 14 October 2007 17:00:52 Christer Holmberg wrote:
> > > >    o  The 'Dialog-ID' message header is constructed by
> >
> > concatenating the
> >
> > > >       Local-tag, Call-ID and Remote-tag (as defined in
> >
> > Section 11.1)
> >
> > > >       from the SIP dialog and separating with a '~'.  See
> >
> > syntax defined
> >
> > > >       in Section 16.1 in Appendix A and examples in
> >
> > Section 9.6.  For
> >
> > > >       'Remote-tag=JJSUSHJ' and
> > 'Call-ID=[email-masked]' - the
> >
> > > > but then in 16.1 there is an error, because you don't use
> >
> > the Call-ID at all:
> > > >    If used within a
> > > >    package, the value contained in the 'connection-id'
> >
> > attribute MUST be
> >
> > > >    constructed by concatenating the 'Local' and 'Remote'
> >
> > SIP dialog
> >
> > > video) the MS is needed to manage. So they are not the same
> >
> > identifier.
> >

---

From: Salvatore Loreto <[email-masked]>
Date: Sun, 14 Oct 2007 19:38:42 +0300

Hi Christer,

I don't understand your doubts, maybe I am wrong: 
it is true that the from- and to- tags can be modified along the path if
there are B2BUA but here we are talking to identify a dialog in a
specific point of the path.  

My doubts was related at the different mechanism used in Dialog-ID and
connection-id, even if they identify to different things one identifies
the media control dialog and the other identifies a specific media, 
generally speaking both identify a media flow associated to a dialog so
in my opinion they should both use the same mechanism: from- to- tags
and call id. I do think there is an error in the drat about it.

regards
Sal

---

From: "Chris Boulton" <[email-masked]>
Date: Mon, 15 Oct 2007 11:50:15 +0100

Hi,

[Chris Boulton] Is true.  SBC's have a tendency to modify just about any
part of a SIP message.  Should this really impact the 'core' solution?
What alternative is there that an SBC wont touch/or may not copy across.
It might be that we need to document such 'relay' functionality in a
separate extension - in a similar way to MSRP?  

Chris.

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 15 Oct 2007 12:59:57 +0200

Hi,

If this connection-id is going to be used between the controller and the
controllee on the control interface, and the value has been changed
somewhere on the SIP path, it won't work, will it?

But, maybe I missunderstood wrong. If the value is going to be used
locally only it doesn't matter whether someone has modified it.

Regards,

Christer

> Sent: 14. lokakuuta 2007 19:39
> To: Christer Holmberg
> Cc: Lorenzo Miniero; [email-masked]
> Subject: RE: [MEDIACTRL] SIP Control Framework
> 
> Hi Christer,
> 
> it is true that the from- and to- tags can be modified along 
> the path if there are B2BUA but here we are talking to 
> identify a dialog in a specific point of the path.  
> 
> 
> My doubts was related at the different mechanism used in 
> Dialog-ID and connection-id, even if they identify to 
> different things one identifies the media control dialog and 
> the other identifies a specific media, generally speaking 
> both identify a media flow associated to a dialog so in my 
> opinion they should both use the same mechanism: from- to- 
> tags and call id. I do think there is an error in the drat about it.
> 
> 
> regards
> Sal
> 
> 
> 
>

---

From: Diego B <[email-masked]>
Date: Mon, 15 Oct 2007 13:52:23 +0200

I agree with Chris,
If SBCs/ B2Bua are everywhere modifying the SIP messages, the core 
solution must not be
impacted. We can not document the undocumented behavior
of those SIP elements.
Today they change To/From tags and tomorrow they will change other
fundamental parts of the SIP messages breaking a new feature.

I may be naive  but, can't we ignore the presence of B2BUAs between ASs 
nad MSs while defining the
core solution ?

Diego B

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 15 Oct 2007 13:56:27 +0200

Hi,

Didn't Chris in some other thread/WG say that the solution WILL take
SBCs into consideration?

I agree that SBCs in theory basically can modify anything. But, I think
it is a less chance that it would modify something media control
specific than SIP "core" information.

Regards,

Christer 

> From: Diego B [mailto:[email-masked]] 
> Sent: 15. lokakuuta 2007 14:52
> To: Chris Boulton
> Cc: Christer Holmberg; Salvatore Loreto; Lorenzo Miniero; 
> [email-masked]
> If SBCs/ B2Bua are everywhere modifying the SIP messages, the 
> core solution must not be impacted. We can not document the 
> undocumented behavior of those SIP elements.
> Today they change To/From tags and tomorrow they will change 
> other fundamental parts of the SIP messages breaking a new feature.
> 
> I may be naive  but, can't we ignore the presence of B2BUAs 
> between ASs nad MSs while defining the core solution ?
> 
> Diego B
> 
> Chris Boulton wrote:
> > Hi,
> >
> > I am not sure whether using the from- and/or to-tags to identify is 
> > the best solution. SBCs have a tendence to modify those 
> along the path.
> >
> > [Chris Boulton] Is true.  SBC's have a tendency to modify 
> just about 
> > any part of a SIP message.  Should this really impact the 
> 'core' solution?

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 15 Oct 2007 15:38:05 +0300

Hi,

actually IMHO we can not ignore the B2BUA functionality,
moreover somewhere in the draft the Control client has some B2BUA type
functionality itself.

So if someone has figured out problems when there are B2BUA in the path
we have work to resolve these and not just pretend the B2BUA don't exist
at all.

Sal

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 15 Oct 2007 15:50:12 +0300

Hi Christer,

now I see you doubts, 
I was just thinking to the local usage (between the Control Client and
Control Server).

Actually the draft doesn't describe (or maybe I have re-read it) how the
UA interacts with the Control Client. In actual fact in this interaction
you are right, using the from- to- tag identification method could cause
some problem if there are B2BUAs along the path.

Sal

---

From: Diego B <[email-masked]>
Date: Mon, 15 Oct 2007 14:56:49 +0200

But, What exactly is SBC, Can you tell which part of a SIP message an 
SBC may change or not ?

> specific than SIP "core" information.
I agree with you, so why taking SBCs ( or B2BUAs ) into consideration 
while defining the "core" ?
( this is my naive question ;) )

Diego B

Christer Holmberg wrote:
>>> What alternative is there that an SBC wont touch/or may not 
>>>       
>> copy across.
>>     
>>> It might be that we need to document such 'relay' 
>>>       
>> functionality in a 
>>

---

From: Diego B <[email-masked]>
Date: Mon, 15 Oct 2007 15:03:45 +0200

Hi
Yes, we can take into consideration that
there may be some SIP elements in the path
that may change the to/from tags and caller-id,
so building the connection-id based on those headers/fields may not be a 
good idea after all.

But, which header/parameter may not be changed/ignored by a B2BUA ?

Diego B

---

From: Lorenzo Miniero <[email-masked]>
Date: Mon, 15 Oct 2007 15:31:57 +0200

Hi Salvatore and all,

actually the problem only exists in case a B2BUA/SBC element is between 
the AS and the MS, since it's the dialogs between them that need to be 
correlated and addressed in the control channel. So these tags aren't 
affected in any way by what happens between the AS and the UAs instead, 
which is only important for the AS (e.g. to appropriately map dialogs 
with the UAs and with the MS) and not for the MS, which is not aware of 
them.

That said, if really a B2BUA between the AS and the MS might change 
everything, could the only solution be (which doesn't mean I like it) a 
new header? AFAIK unknown headers should be kept unchanged... as long as 
they're not removed for the same reason, which of course would cause our 
issue not to be solved at all.

Lorenzo

---

From: "Krishna Prasad Kalluri" <[email-masked]>
Date: Mon, 15 Oct 2007 16:41:42 +0200

Hi Lorenzo,

If I understand your mail correctly, you mean SBCs may not be there between AS & MS?

If the AS and MS is not in the same network (Is there any restriction to have AS & MS in the same network ?) then SBC can be there between two different operator networks also. 

Regards
/Krishna

-----Original Message-----
From: Lorenzo Miniero [mailto:[email-masked]] 
Sent: den 15 oktober 2007 15:32
To: Salvatore Loreto
Cc: [email-masked]
Subject: Re: [MEDIACTRL] SIP Control Framework

Hi Salvatore and all,

actually the problem only exists in case a B2BUA/SBC element is between the AS and the MS, since it's the dialogs between them that need to be correlated and addressed in the control channel. So these tags aren't affected in any way by what happens between the AS and the UAs instead, which is only important for the AS (e.g. to appropriately map dialogs with the UAs and with the MS) and not for the MS, which is not aware of them.

That said, if really a B2BUA between the AS and the MS might change everything, could the only solution be (which doesn't mean I like it) a new header? AFAIK unknown headers should be kept unchanged... as long as they're not removed for the same reason, which of course would cause our issue not to be solved at all.

Lorenzo

Salvatore Loreto ha scritto:
> Actually the draft doesn't describe (or maybe I have re-read it) how 
> the UA interacts with the Control Client. In actual fact in this 
> interaction you are right, using the from- to- tag identification 
> method could cause some problem if there are B2BUAs along the path.
> 
> Sal
> 
>> If this connection-id is going to be used between the controller and 
>> the controllee on the control interface, and the value has been 
>> changed somewhere on the SIP path, it won't work, will it?
>>
>>> it is true that the from- and to- tags can be modified along the 
>>> path if there are B2BUA but here we are talking to identify a dialog 
>>> in a specific point of the path.
>>>
>>>
>>> My doubts was related at the different mechanism used in Dialog-ID 
>>> and connection-id, even if they identify to different things one 
>>> identifies the media control dialog and the other identifies a 
>>> specific media, generally speaking both identify a media flow 
>>> associated to a dialog so in my opinion they should both use the 
>>> same mechanism: from- to- tags and call id. I do think there is an 
>>> error in the drat about it.
>>>
>>>
>>> regards
>>> Sal
>>>
>>>
>>>
>>>

Dipartimento di Informatica e Sistemistica Università degli Studi di Napoli "Federico II"

---

From: Diego B <[email-masked]>
Date: Mon, 15 Oct 2007 17:05:21 +0200

> AFAIK unknown headers should be kept unchanged... as long as they're 
> not removed for the same reason, which of course would cause our issue 
> not to be solved at all. 
That is my concern. Working with several vendors SBCs / B2BUA / 
Application Server, your last phrase is true.
I think we will need to define the "connection-id" issue by taking some 
assumptions on SBC behavior.

Diego B

Lorenzo Miniero wrote:
> Hi Salvatore and all,
>
> actually the problem only exists in case a B2BUA/SBC element is 
> between the AS and the MS, since it's the dialogs between them that 
> need to be correlated and addressed in the control channel. So these 
> tags aren't affected in any way by what happens between the AS and the 
> UAs instead, which is only important for the AS (e.g. to appropriately 
> map dialogs with the UAs and with the MS) and not for the MS, which is 
> not aware of them.
>
> everything, could the only solution be (which doesn't mean I like it) 
> a new header? AFAIK unknown headers should be kept unchanged... as 
> long as they're not removed for the same reason, which of course would 
> cause our issue not to be solved at all.
>
> Lorenzo
>
>
>> now I see you doubts, I was just thinking to the local usage (between 
>> the Control Client and
>> Control Server).
>>
>>>> From: Salvatore Loreto [mailto:[email-masked]] Sent: 
>>>> 14. lokakuuta 2007 19:39
>>>> To: Christer Holmberg
>>>> I don't understand your doubts, maybe I am wrong: it is true that 
>>>> the from- and to- tags can be modified along the path if there are 
>>>> B2BUA but here we are talking to identify a dialog in a specific 
>>>> point of the path. 
>>>>
>>>>>> things, and I see the way they are different, more or less :-)

---

From: Lorenzo Miniero <[email-masked]>
Date: Mon, 15 Oct 2007 17:10:36 +0200

Hi Krishna,

yes, as long as the AS and MS have no SIP intermediaries in between 
(i.e., they talk directly, even if they're on different networks), then 
the tags-based addressing is not an issue: this is how we are 
implementing our prototype, and the tags do their job fine.

Considering that, as you noticed, AS and MS may be on different networks 
(which besides is one of the scopes of the MediaCtrl WG) with SBC/B2BUA 
standing in the path, we can not safely rely on the assumption of having 
this direct connection.

Lorenzo

---

From: "Chris Boulton" <[email-masked]>
Date: Mon, 15 Oct 2007 16:38:07 +0100

Hi Krishna,

[Chris Boulton] totally agreed.

this direct connection.

[Chris Boulton] This is the core issue.  The SIP Control framework is
designed to work as per IETF SIP rules.  I agree that if an SBC is
between the two clients (as Lorenzo points out this is not the general
case between an AS and an MS) the Framework breaks.  Or - putting it a
different way - the SBC breaks.

So - here is my preference (and I would appreciate chair guidance).  I
think we should keep the core framework pure.  We can mess about and try
to shoe horn this to work for SBCs BUT at the end of the day you are not
guaranteed any behavior.  You could add a new header instead and it not
be copied over (there are no rules to mandate this).  We should stick
with the best solution.

If folks feel that this is a big enough deal to solve - then we should
create an extension to the Control Framework that gives guidelines on
how an intermediary MUST act e.g. A Control Framework aware SBC.

Thoughts?

Chris.

---

From: Diego B <[email-masked]>
Date: Mon, 15 Oct 2007 18:21:59 +0200

I totally agree.
An extension then can be created to "negotiate" the connection-id with 
the MS and use the
negotiated connection-id instead of the tags/call-id defined in the core.

Diego B

---

From: Eric Burger <[email-masked]>
Date: Mon, 15 Oct 2007 18:45:10 -0700

I would offer the following guidance:

1. In an ideal world, SBC's are not broken.  If they change the from/to
tags, great, as they are changing ALL the from/to tags.  The whole point of
a working SBC is they are transparent to the endpoints.

2. We want real adoption of Mediactrl.

3. We are the *I*ETF, which means a restriction saying the protocol will
only work in a single administrative domain will not be acceptable.

4. In light of #2, I would offer that if the "right" thing is to have a new,
immutable connection ID, that would work for us.

5. In light of #1, if the "wrong" thing is to have a new, immutable
connection ID, then we have to give guidance to the SBC folk, and in light
of #2, realize this is going to be a rare occurrence.

>> how an intermediary MUST act e.g. A Control Framework aware SBC.

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

---

From: "Chris Boulton" <[email-masked]>
Date: Tue, 16 Oct 2007 10:08:16 +0100

[With my 'working group document' editor's Stetson on.] 

1. In an ideal world, SBC's are not broken.  If they change the from/to
tags, great, as they are changing ALL the from/to tags.  The whole point
of
a working SBC is they are transparent to the endpoints.

[Chris Boulton] Agreed.  So just like SBC's alter SDP for RTP - we would
need to provide guidance on changing SDP for Control Framework.
Additional guidelines would be needed for manipulation of Control
Framework messages.

[Chris Boulton] 100% Agreed.

[Chris Boulton] Agreed.

4. In light of #2, I would offer that if the "right" thing is to have a
new,
immutable connection ID, that would work for us.

[Chris Boulton] The 'IF' is important.

5. In light of #1, if the "wrong" thing is to have a new, immutable
connection ID, then we have to give guidance to the SBC folk, and in
light
of #2, realize this is going to be a rare occurrence.

[Chris Boulton] I am not against it - I just think the difference
between the two is marginal.

- The existing tag based mechanism could be lost due to message mucking.
- A Mutable connection ID could be lost due to inconsistent B2BUA
behavior etc.

We shouldn't fool ourselves into thinking that one will solve all.  From
a parsing perspective I can see that adding the connection information
in a new header result in the intermediary having to do less work - as
it doesn't have to manipulate Control Framework messages.  I can also
see Keith sitting up and taking notice when we talk about 'new' SIP
headers.

My preference is for the mechanism to remain the same and to create
(somewhere) guidelines for intermediaries - in the same way MSRP has a
relay extension.  This is my view without the Stetson and so more folks
need to shout now with concrete reason and alternatives.

Chris.

---

From: Spencer Dawkins <[email-masked]>
Date: Wed, 17 Oct 2007 11:28:34 -0500

OK, some of this is "as co-chair", some is "as individual".

As co-chair:

The requirements draft does not include requirements about traversing SBCs 
(I just checked).

Did the working group just finish working group last call without checking 
to see if all the requirements are listed as requirements? :-(

As individual:

I would like to see a core solution that does not address SBC traversal. I 
have actually seen SBCs with my own eyes, so this isn't a denial thing. My 
concern is that SBC traversal won't be either simple or quick to specify in 
a way that is guaranteed to work. I would prefer to have MEDIACTRL base 
functionality defined without waiting until we figure that out.

For an example of why I think this will be complicated...

The requirements draft says "The protocol shall include security mechanisms" 
(this is, in fact, the entire Security Considerations section, reproduced 
for your convenience).

My understanding is that it's OK for us say this in a requirements draft 
because we expect to use the security mechanisms that already exist for the 
protocols we're extending. For SIP, that's hop-by-hop TLS.

If a device is "transparent", how does TLS work? Aren't the domain names in 
the certificates wrong?

If an SBC is explicitly addressed, in SIP, it's functioning either a (B2B)UA 
or a proxy - TLS would be fine. Is that what we're talking about?

Spencer

p.s. I am also not excited about picking a new SIP header that 
SBCs-with-undefined-functionality can choose to strip or munge, but that's a 
later discussion, so please ignore this comment for now.

Auditor: "what do you MEAN that your SBCs pass unrecognized SIP headers? 
ever heard of covert channels?" (sound of door slamming on MEDIACTRL 
functionality)

---

From: "Even, Roni" <[email-masked]>
Date: Wed, 17 Oct 2007 18:44:46 +0200

Spencer,
I think this is opening a can of worms. Do we need to address it in the requirements?

The intention is to use SIP to open a control channel. Now you put an SBC in the middle, it needs to understand this m-line and to support TCP, this is asking a lot from SBCs (some of them only support audio and if they support video they allow just one video stream and so on, no support for BFCP). 

Now my frustration with SBCs: If you want to be sure that the protocol will work through all SBCs and since we have a mode by which we use one dialog to control the media server, we can disguise the control channel as an audio channel over UDP, this way it may work for all SBCs.

To open the control channel
 m = audio 53456 RTP/AVP 102
a=rtpmap:102 XXX
a=mediactrl

Roni 

> From: Spencer Dawkins [mailto:[email-masked]]
> Sent: Wednesday, October 17, 2007 6:29 PM
> To: [email-masked]
> Subject: [MEDIACTRL] SBC traversal - not "if", but "when"
>

---

From: Spencer Dawkins <[email-masked]>
Date: Wed, 17 Oct 2007 13:59:32 -0500

Hi, Roni,

I think we agree ("can of worms").

At this point (speaking as individual), I would like to defer work on 
explicit SBC considerations.

My concern (speaking as co-chair) is whether the WG agrees with taking this 
approach (WG consensus matters more than co-chair opinion).

What I would NOT like to see (speaking as co-chair) is for us to start 
focusing on requirements that we didn't reach WG consensus on (yet?), before 
we've even forwarded the requirements draft to Jon with a request to 
publish.

Thanks,

Spencer (the individual and Spencer the co-chair)

From: "Even, Roni" <[email-masked]>

Spencer,
I think this is opening a can of worms. Do we need to address it in the 
requirements?

The intention is to use SIP to open a control channel. Now you put an SBC in 
the middle, it needs to understand this m-line and to support TCP, this is 
asking a lot from SBCs (some of them only support audio and if they support 
video they allow just one video stream and so on, no support for BFCP).

Now my frustration with SBCs: If you want to be sure that the protocol will 
work through all SBCs and since we have a mode by which we use one dialog to 
control the media server, we can disguise the control channel as an audio 
channel over UDP, this way it may work for all SBCs.

Roni

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 18 Oct 2007 08:51:05 +0200

Hi,

A couple of comments:

First, as I said before, I think Chris on the SIP/SIPPING list said,
when proposing that our work could also be used for other things than
media control, that the framework WILL take SBCs into consideration.
Now, whether we take SBCs into consideration or not, I think it needs to
be clarified.

Second, a clarification: when I brought up the SBC issue I didn't mean
that the control channel itself would go through an SBC. I meant that
the SIP signalling, used to establish the control channel, could go via
an SBC/AS/B2BUA that modifies some information - including the To- and
>From tags. Therefor I don't think it would be good to assume the values
will be the same in the eyes of the AS and the MS. If we choose to NOT
explicitly say that SBCs will be taken into consideration, we can still
keep it in mind and choose not to use the To- and From tags.

Regards,

Christer

> Sent: 17. lokakuuta 2007 22:00
> To: [email-masked]
> Subject: Re: [MEDIACTRL] SBC traversal - not "if", but "when"
> 
> Hi, Roni,
> 
> At this point (speaking as individual), I would like to defer 
> work on explicit SBC considerations.
> 
> My concern (speaking as co-chair) is whether the WG agrees 
> with taking this approach (WG consensus matters more than 
> co-chair opinion).
> 
> What I would NOT like to see (speaking as co-chair) is for us 
> to start focusing on requirements that we didn't reach WG 
> consensus on (yet?), before we've even forwarded the 
> requirements draft to Jon with a request to publish.
> 
> Thanks,
> 
> The intention is to use SIP to open a control channel. Now 
> you put an SBC in the middle, it needs to understand this 
> m-line and to support TCP, this is asking a lot from SBCs 
> (some of them only support audio and if they support video 
> they allow just one video stream and so on, no support for BFCP).
> 
> Now my frustration with SBCs: If you want to be sure that the 
> protocol will work through all SBCs and since we have a mode 
> by which we use one dialog to control the media server, we 
> can disguise the control channel as an audio channel over 
> UDP, this way it may work for all SBCs.
>

---

From: "Chris Boulton" <[email-masked]>
Date: Thu, 18 Oct 2007 09:22:05 +0100

Greetings - some comments in-line.

Chris.

Hi,

A couple of comments:

[Chris Boulton] OK - Not sure I said core Framework.  I have always
advocated that this should stay clean and end-to-end.  I do remember
(and also in this thread) saying that if we feel intermediaries need to
be catered for then we should provide an extension - in the same way
MSRP has the relays document (TBD and separate in my opinion). 

Second, a clarification: when I brought up the SBC issue I didn't mean
that the control channel itself would go through an SBC.

[Chris Boulton] Agreed.  This can come in two flavors.  1)Your classic
SBC mode that mingles and mangles with SDP to be the central focus
(which would mean Control Channel traversal) OR 2)Just recommend ICE.
Just recommending ICE is fine - there is actually an empty placeholder
in the doc to talk about this topic.

 I meant that

[Chris Boulton] I would be interested in some figures (estimates from
folks).  In reality, how many SBCs in the path are only Signaling boxes
and don't want to be a media relay?  In reality, how man AS to MS
interactions (MSML, MSCML using INFO) today pass through an SBC (as the
driving case for this work).  

In my opinion as an individual, SBC's that I have seen generally want to
see what's going on in the media plane and AS to MS connections are
co-located.  This is the reasoning for me saying 'keep the Control
Framework clean' and if you want to use this extension (maybe as an SBC)
- then knock yourself out.

I think that if we choose an extension as per above, it doesn't matter
where we put the ID.  The SBC would be 'aware' and would act accordingly
on both the SIP and media plane.

Just my thoughts.

Chris.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 18 Oct 2007 23:34:57 +0200

Hi,

 
[Christer] That can be done, but if we already in the core spec defines something which is based on the fact that something is not changed, it will be difficult to fix that with whatever extension.

 
[Christer] Now I got lost. What does ICE have to do with this??? Recommend ICE for what???

>I meant that the SIP signalling, used to establish the control channel, could go via

[Christer] The SBC may change the SDP information, so that the control channel also traverses the SBC. But, if the end-points are using the To- and From- tags to identify the connection, and the SBC modifies the tags, it doesn't help - the end-points will see different values no matter if the control channel traverses a relay or not...
 
Regards,
 
Christer

---

From: "Chris Boulton" <[email-masked]>
Date: Fri, 19 Oct 2007 10:51:15 +0100

[As document editor] OK folks - I think we have had a reasonably good
discussion on this topic and the last thing I think we want is for the
thread to run away (see INFO discussions on SIP list :-)).

I'm going to solicit feedback on the list from you all on a couple of
topics that I think are important.

1) Should SBC's and the like be taken into consideration in the core Sip
Control Framework?

2) There is currently a mechanism for identifying a dialog within the
Control Framework.  At the moment we currently use the dialog
identifiers to identify a dialog.  Is this an appropriate mechanism?
Your answer to this should be influenced by the answer to 1) as in the
default case it does not work through SBC's that muck about with stuff.
If you are saying that you would like a different mechanism - please
suggest a strawman proposal to be considered.

Come on folks - get stuck into this one - your input is important at
this stage.

Thanks.

Chris.

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: 18 October 2007 22:35
To: Chris Boulton; Spencer Dawkins; [email-masked]
Subject: RE: [MEDIACTRL] SBC traversal - not "if", but "when"

Hi,

 
[Christer] That can be done, but if we already in the core spec defines
something which is based on the fact that something is not changed, it
will be difficult to fix that with whatever extension.

 
[Christer] Now I got lost. What does ICE have to do with this???
Recommend ICE for what???

[Christer] The SBC may change the SDP information, so that the control
channel also traverses the SBC. But, if the end-points are using the To-
and From- tags to identify the connection, and the SBC modifies the
tags, it doesn't help - the end-points will see different values no
matter if the control channel traverses a relay or not...
 
Regards,
 
Christer

---

From: Diego B <[email-masked]>
Date: Fri, 19 Oct 2007 12:21:12 +0200

Hi;
I agree with this one, using the SIP dialog identifier.
(Replaces also use call-id and tags as seen by one of the end-points, 
SBC/B2BUA vendors are
starting to deal with this very nicely).

But I also think we must create an extension, in a later stage,  that 
negotiates the
connection-id based on a different value. If the AS can discover the SIP 
dialog-id as seen by the MS,
(using a STUN like end-to-end mechanism ) that can be used as identifier.

Chris Boulton wrote:
>> Now, whether we take SBCs into consideration or not, I think it needs
>>     
> to
>   
>> be clarified.
>>     
>
>> I meant that the SIP signalling, used to establish the control channel,
>>     
> could go via
>

---

From: "Chris Boulton" <[email-masked]>
Date: Fri, 19 Oct 2007 11:30:26 +0100

[Chris Boulton] [responding as a contributor].

[Chris Boulton] No.

[Chris Boulton] I am not yet convinced that changing how we do this will
benefit the SBC case.  The tags will change which will cause a problem -
just adding a new SIP header will cause a problem (no guarantee it will
make it through).  It is my view that if this is to pass through an SBC
then the SBC needs to be aware what is going on.  For that I think we
need an extension that maps both sides of the game - as it does today
for SIP and RTP.  I don't think a half way house will please anyone.

The one advantage I can see from having a unique identifier explicitly
expressed in the message is that an SBC acting as a B2BUA (for Control
Channel as well) would not have to muck with Control Framework messages.
This is quite appealing.  

Could this unique-ID be an SDP attribute rather than being inferred from
the tags?  

Chris.

---

From: Lorenzo Miniero <[email-masked]>
Date: Fri, 19 Oct 2007 13:25:21 +0200

Hi Chris,

 > Could this unique-ID be an SDP attribute rather than being inferred from

I had been thinking the same lately, considering the heavy use the MS 
makes of unique labels. However, are we sure that SBCs would leave SDP 
unaltered as well? If they do, then I think your idea would probably 
work fine.

Lorenzo

---

From: Steve Buko <[email-masked]>
Date: Fri, 19 Oct 2007 05:26:30 -0700

1) Should SBC's and the like be taken into consideration in the core Sip Control Framework?

[Steve Buko] IMO, no.

[Steve Buko]  I agree with Chris on this one.  The use of the "tags" may not be perfect, but adding a new header isn't any better IMO.

|-----Original Message-----
|From: Chris Boulton [mailto:[email-masked]]
|Sent: Friday, October 19, 2007 6:30 AM
|To: Chris Boulton; Christer Holmberg; Spencer Dawkins;
[email-masked]
|Subject: RE: [MEDIACTRL] SBC traversal - not "if", but "when"
|
|[Chris Boulton] [responding as a contributor].
|
|1) Should SBC's and the like be taken into consideration in the core Sip
|Control Framework?
|
|[Chris Boulton] No.
|
|2) There is currently a mechanism for identifying a dialog within the
|Control Framework.  At the moment we currently use the dialog
|identifiers to identify a dialog.  Is this an appropriate mechanism?
|Your answer to this should be influenced by the answer to 1) as in the
|default case it does not work through SBC's that muck about with stuff.
|If you are saying that you would like a different mechanism - please
|suggest a strawman proposal to be considered.
|
|[Chris Boulton] I am not yet convinced that changing how we do this will
|benefit the SBC case.  The tags will change which will cause a problem -
|just adding a new SIP header will cause a problem (no guarantee it will
|make it through).  It is my view that if this is to pass through an SBC
|then the SBC needs to be aware what is going on.  For that I think we
|need an extension that maps both sides of the game - as it does today
|for SIP and RTP.  I don't think a half way house will please anyone.
|
|The one advantage I can see from having a unique identifier explicitly
|expressed in the message is that an SBC acting as a B2BUA (for Control
|Channel as well) would not have to muck with Control Framework messages.
|This is quite appealing.
|
|Could this unique-ID be an SDP attribute rather than being inferred from
|the tags?
|
|Chris.
|
|
|
|
|_______________________________________________
|MEDIACTRL mailing list
[email-masked]
|https://www1.ietf.org/mailman/listinfo/mediactrl
|Supplemental Web Site:
|http://www.standardstrack.com/ietf/mediactrl

---

From: "McGlashan, Scott" <[email-masked]>
Date: Fri, 19 Oct 2007 15:17:42 +0200

1) Should SBC's and the like be taken into consideration in the core
Sip Control Framework?

[Scott McGlashan] No.

[Scott McGlashan]  Yes.  As said, long term we could look at specifying
in a separate section/doc a suitable SBC solution (if there is
sufficient interest).

---

From: "Chris Boulton" <[email-masked]>
Date: Fri, 19 Oct 2007 14:15:50 +0100

Hi Chris,

I agree with your thoughts. Just a consideration upon your last

[Chris Boulton] No - I don't think you can rely on that.  You have to
assume that however we do this - there is a change that it could be lost
- unless you have an explicit extension which an SBC would need to
support.  So 2 points:

- Firstly we HAVE to signal this information regardless of SBCs - which
way is best (currently uses dialog IDs)?
- Secondly, do we need an extension for Intermediaries?

Lorenzo

---

From: Eric Burger <[email-masked]>
Date: Mon, 22 Oct 2007 09:03:58 -0700

[as participant]

As far as I know, ALL EXTANT AS-MS connections are without intermediaries.
Even the folks that put up AS sandboxes or MS to play with do so outside
their firewalls.  True, they may be in DMZ's, but often that is to enforce
source routes, not hacking signaling or NATing.

That said, we are working on an Internet protocol, so we cannot rely on the
AS and MS being in the same domain or having no intermediaries.

Considering that, I would offer...  If someone inserts a device that
partitions them from the Internet, like a broken SBC, then they are not
participating on the Internet, and tough cookies.

That is, I do not think the market share for MEDIACTRL will have a
significant negative impact by our ignoring SBC's.

I do want to emphasize, however, I am speaking as a participant, and not as
a chair.  If the work group believes we do need to address SBC's, and we
have consensus, we will address the issue.

On 10/18/07 1:22 AM, "Chris Boulton" <[email-masked]> wrote:
[snip] 
> driving case for this work).
On 10/18/07 5:34 PM, "Christer Holmberg" <[email-masked]>

---

From: Eric Burger <[email-masked]>
Date: Mon, 22 Oct 2007 09:03:58 -0700

[as participant]