Subject: [Simple] MSRP: sdp usage compared to BFCP

From: Ben Campbell <[email-masked]>
Date: Fri, 3 Dec 2004 19:03:04 -0600

In the DC meeting, Gonzalo asked us to compare how MSRP and BFCP use 
SDP. Since they are both connection oriented, this seems to be a 
sensible thing to do. So, I took a shot at it;

1) BFCP depends on COMEDIA. MSRP does not.

The reason MSRP does not invoke COMEDIA is mainly a historic one. At 
the time we wrote that part of the spec, COMEDIA had not progressed as 
far as it has now. Instead, MSRP states a default connection 
"direction", and says that other mechanisms can be used to determine 
direction once they become standardized.

2) MSRP uses a URL in an a-line attribute to determine where to connect 
(address, port, protocol). I _think_ BFCP uses the traditional 
mechanism of an address in the c-line and a port in the m-line. This is 
not entirely clear to me, as the BFCP SDP draft says in one paragraph 
that the port is always ignored, and in another paragraph that the 
m-line port is the port too which a client connects. I gather the point 
is to say that the m-line port is only meaningful to the peer that 
opens the TCP connection. Along the same line, BFCP uses the m-line 
format field to determine whether to invoke TLS, while MSRP uses the 
URL in the path attribute.

The main reason is that MSRP uses URLs in the path attribute is, it 
must be able to communicate a path of URLs, rather than a single URL.  
That does not appear to be an issue with BFCP. There has been some 
recent controversy the MSRP usage. I will send a summary of that in a 
separate email.

3) Both MSRP and BFCP use a "*" in the m-line fmt-list field. But I 
think this is for different reasons. MSRP does this because it uses 
a-line attributes to determine the acceptable formats. I gather BFCP 
does this because content-type negotiation is not relevant to it.

It seems to me that each of these differences are due to semantic 
differences between the two protocols. That is, they are appropriately 
different.

I welcome any discussion, both on whether I interpreted the BFCP SDP 
usage correctly, and whether the differences are really appropriate.

Thanks!

Ben.

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 13 Dec 2004 14:04:14 +0200

Hi Ben,

> sensible thing to do. So, I took a shot at it;

thanks for putting this together.

> The reason MSRP does not invoke COMEDIA is mainly a historic one. At the 
> time we wrote that part of the spec, COMEDIA had not progressed as far 
> as it has now. Instead, MSRP states a default connection "direction", 
> and says that other mechanisms can be used to determine direction once 
> they become standardized.

The thing is that, most likely, comedia will be ready before both BFCP 
and MSRP. So, arguing that comedia will not be ready is not a valid 
argument anymore.

Comedia defines two SDP attributes (setup and connection) that are used 
to figure out which end initiates the TCP connection and, on reception 
of a new offer, whether the TCP connection needs to be re-established or 
the existing TCP connection is OK.

I do not think that using these attributes would add too much complexity 
to the protocol and having a way to know whether or not an offer implies 
that the TCP connection needs to be re-established but the rest of the 
parameters should not change seems like important funcionality. So, even 
if you want to avoid using the setup attribute (for some reason) by 
defining a default connection initiator, I believe you may still want to 
use the connection attribute.

> (address, port, protocol). I _think_ BFCP uses the traditional mechanism 
> of an address in the c-line and a port in the m-line. This is not 
> entirely clear to me, as the BFCP SDP draft says in one paragraph that 
> the port is always ignored, and in another paragraph that the m-line 
> port is the port too which a client connects. I gather the point is to 
> say that the m-line port is only meaningful to the peer that opens the 
> TCP connection. Along the same line, BFCP uses the m-line format field 
> to determine whether to invoke TLS, while MSRP uses the URL in the path 
> attribute.
> 
> The main reason is that MSRP uses URLs in the path attribute is, it must 
> be able to communicate a path of URLs, rather than a single URL.  That 
> does not appear to be an issue with BFCP. There has been some recent 
> controversy the MSRP usage. I will send a summary of that in a separate 
> email.

I do not have any problem with MSRP using URIs instead of a c-line type 
of format.

> differences between the two protocols. That is, they are appropriately 

I agree.

> usage correctly, and whether the differences are really appropriate.

In my opinion, differences in 2) and 3) are OK, but regarding 1), we may 
want to use the connection attribute (and maybe the setup attribute as 
well) in MSRP as well, as I said earlier.

Thanks,

Gonzalo

---

From: Ben Campbell <[email-masked]>
Date: Fri, 17 Dec 2004 16:03:34 -0600

On Dec 13, 2004, at 6:04 AM, Gonzalo Camarillo wrote:

>> the time we wrote that part of the spec, COMEDIA had not progressed 
>> as far as it has now. Instead, MSRP states a default connection 
> Comedia defines two SDP attributes (setup and connection) that are 
> used to figure out which end initiates the TCP connection and, on 
> reception of a new offer, whether the TCP connection needs to be 
> re-established or the existing TCP connection is OK.
>
> I do not think that using these attributes would add too much 
> complexity to the protocol and having a way to know whether or not an 
> offer implies that the TCP connection needs to be re-established but 
> the rest of the parameters should not change seems like important 
> funcionality. So, even if you want to avoid using the setup attribute 
> (for some reason) by defining a default connection initiator, I 
> believe you may still want to use the connection attribute.
>

Technically, I agree that using comedia is a good idea. My concern now 
is simply that every new thing we add is that much more delay in 
completing MSRP. I don't think think it is trivial to add it, as the 
presence of relays complicates things.  I see two possible ways to move 
forward with this:

1) Leave MSRP as is, and follow up shortly with a draft on how to use 
COMEDIA with MSRP. I think this could be done in a backwards compatible 
way, by saying that if the COMEDIA attributes are not present, it falls 
back to the default behavior.

2) Go ahead and add COMEDIA support to the base spec, with a small but 
non-trivial delay while we make sure we don't break something.

Thoughts? (encouraged from anyone, but _particularly_ from the 
chairs...)

Ben.

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 18 Dec 2004 00:58:28 -0500

Ben,

I think MSRP should remain independent of comedia.
The reason is because the connection lifetime is often independent of a 
particular media session, which is quite different from comedia.

	Paul

Ben Campbell wrote:
> Thoughts? (encouraged from anyone, but _particularly_ from the chairs...)
> 
> Ben.
> 
>

---

From: Ben Campbell <[email-masked]>
Date: Sat, 18 Dec 2004 00:24:20 -0600

On Dec 17, 2004, at 11:58 PM, Paul Kyzivat wrote:

> The reason is because the connection lifetime is often independent of 
> a particular media session, which is quite different from comedia.
>

Okay, I guess I should have listed that as an option 3. If we were to 
invoke comedia, we would have to very clear about connection 
management, and add things like the existence of a reuseable connection 
preempts comedia, as would the existence of other sessions using a 
connection when a session ends. That is partly why I think that 
integrating comedia is a non-trivial task.

>>>> The reason MSRP does not invoke COMEDIA is mainly a historic one. 
>>>> At the time we wrote that part of the spec, COMEDIA had not 
>>>> progressed as far as it has now. Instead, MSRP states a default 
>>>> connection "direction", and says that other mechanisms can be used 
>>>> to determine direction once they become standardized.
>>>
>>>
>>> The thing is that, most likely, comedia will be ready before both 
>>> BFCP and MSRP. So, arguing that comedia will not be ready is not a 
>>> valid argument anymore.
>>>
>>> complexity to the protocol and having a way to know whether or not 
>>> an offer implies that the TCP connection needs to be re-established 
>>> but the rest of the parameters should not change seems like 
>>> important funcionality. So, even if you want to avoid using the 
>>> setup attribute (for some reason) by defining a default connection 
>>> initiator, I believe you may still want to use the connection 
>>> attribute.
>>>
>> Technically, I agree that using comedia is a good idea. My concern 
>> now is simply that every new thing we add is that much more delay in 
>> presence of relays complicates things.  I see two possible ways to 
>> move forward with this:
>> COMEDIA with MSRP. I think this could be done in a backwards 
>> compatible way, by saying that if the COMEDIA attributes are not 
>> present, it falls back to the default behavior.
>> 2) Go ahead and add COMEDIA support to the base spec, with a small 
>> but non-trivial delay while we make sure we don't break something.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sat, 18 Dec 2004 09:31:45 +0200

Hi,

cc:ing the MMUSIC chairs in case they have an opinion on this.

Colin, Joerg, the discussion is about whether or not MSRP should use
comedia. Ben is asking for chair advice on this.

Ben, Paul, could you further describe the scenario you have in mind? Is
it that two media sessions described by two different m lines use the
same TCP connection?

Regarding using default values so that we can add comedia in the future
in a backwards compatible manner, as Ben suggested, the default values
for the attributes in comedia are (quoting comedia):

    The default value of the setup attribute in an offer/answer exchange
    is 'active' in the offer and 'passive' in the answer.

    The default value of the connection attribute in both offers and
    answers is 'new'.

Did you have the same default values in mind?

Thanks,

Gonzalo

Ben Campbell wrote:

>> I think MSRP should remain independent of comedia. The reason is
>> because the connection lifetime is often independent of a
> management, and add things like the existence of a reuseable
> connection preempts comedia, as would the existence of other sessions
> using a connection when a session ends. That is partly why I think
> that integrating comedia is a non-trivial task.
> 
>> Paul
>> 
>> Ben Campbell wrote:
>> 
>>>>> 1) BFCP depends on COMEDIA. MSRP does not. The reason MSRP
>>>>> does not invoke COMEDIA is mainly a historic one. At the time
>>>>> we wrote that part of the spec, COMEDIA had not progressed as
>>>>> "direction", and says that other mechanisms can be used to
>>>>> determine direction once they become standardized.
>>>> 
>>>> 
>>>> 
>>>> The thing is that, most likely, comedia will be ready before
>>>> both BFCP and MSRP. So, arguing that comedia will not be ready
>>>> is not a valid argument anymore.
>>>> 
>>>> Comedia defines two SDP attributes (setup and connection) that
>>>> are used to figure out which end initiates the TCP connection
>>>> and, on reception of a new offer, whether the TCP connection
>>>> needs to be re-established or the existing TCP connection is
>>>> OK.
>>>> 
>>>> complexity to the protocol and having a way to know whether or
>>>> not an offer implies that the TCP connection needs to be
>>>> re-established but the rest of the parameters should not change
>>>> seems like important funcionality. So, even if you want to
>>>> avoid using the setup attribute (for some reason) by defining a
>>>> default connection initiator, I believe you may still want to
>>> Technically, I agree that using comedia is a good idea. My
>>> concern now is simply that every new thing we add is that much
>>> more delay in completing MSRP. I don't think think it is trivial
>>> to add it, as the presence of relays complicates things.  I see
>>> two possible ways to move forward with this: 1) Leave MSRP as is,
>>> and follow up shortly with a draft on how to use COMEDIA with
>>> MSRP. I think this could be done in a backwards compatible way,
>>> by saying that if the COMEDIA attributes are not present, it
>>> falls back to the default behavior. 2) Go ahead and add COMEDIA
>>> support to the base spec, with a small but non-trivial delay
>>> while we make sure we don't break something. Thoughts?
>>> (encouraged from anyone, but _particularly_ from the chairs...) 
>>> Ben. _______________________________________________ Simple
>>> mailing list [email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 18 Dec 2004 12:53:19 -0500

> it that two media sessions described by two different m lines use the

It could be two different m-lines in the same offer/answer, though that 
would probably be an unusual case.

A more plausible case is that the UA establishes multiple media 
sessions, either concurrently or sequentially, via independent 
offer/answer exchanges. A major use case for this would be a gateway to 
a different IM system. But an ordinary UA on a PC is likely to be in 
this situation too, because multiple concurrent chats are common.

The use of a common path doesn't mean talking to the same target - A 
common relay is all that is required.

We went to a lot of trouble to permit multiplexing multiple sessions on 
a single connection. Lets not mess it up now.

	Paul

>>>> (encouraged from anyone, but _particularly_ from the chairs...) Ben. 
>>>> _______________________________________________ Simple

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 18 Dec 2004 13:13:24 -0800

I really don't follow how this comedia stuff is related to MSRP. I think we
have it really confused.

Let's first consider a case with relays. If alice and bob sends some offers
and answers back and forth, the topic of if they will set up new TCP
connections to the relays it totally independent of anything in the offers
or answers. If they have existing TCP connections to the relays they use the
existing connections. Similarly in the case with no relays - if a useable
connection exists, you use it. If were to add comedia somehow to the offer
answers stuff  - MSRP would explicitly say to ignore it if it told you to
set up a new connection. This was a key design constraint so that the the
congestion control properties of TCP would not be lost by opening an
arbitrary number of connections.

The fundamental reason comedia is not relevant to MSRP is that comedia is
about setting up a TCP connection for a particular media stream. MSRP is
based on setting up a path that is multiplexed over a single TCP connection
and the lifetime of the TCP connection is not bound to the lifetime of
sessions that are set up in the offer answer.

---

From: Hisham Khartabil <[email-masked]>
Date: Mon, 20 Dec 2004 09:41:36 +0100

> present, it falls back to the default behavior.

What is the benefit of adding comedia later? Its either now or never, 
IMO.
> non-trivial delay while we make sure we don't break something.

What is the benefit of using comedia instead of what we have now in the 
draft? If nothing, then I vote for the third option: leave it as it is.

Regards,
Hisham