Subject: [MMUSIC] draft-garcia-mmusic-sdp-cs-01: Modification of c- line

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 15 May 2008 12:23:47 +0200

Hi,

Two issues on the draft:

1.

My main issue with the draft is the change of the c- line (IN->PSTN) in
the SDP answer, and how it 
will affect intermediates (who may have no clue about "PSTN"). I have
heard the "intermediates-should-not-care-about-SDP" statements, but 
that is not how the world works today. And, a 2nd offer/answer is not
necessarily going to solve that problem, if already the first answer 
messes things up (don't shoot me - I'm just the messenger :).
 
So, why not keep the c- line unchanged in the SDP answer? After all,
it's the a=acfg attribute which is going to indicate which alternative 
(RTP or PSTN) was chosen, not the c- line. Intermediates will see this
is a normal SDP offer/answer, and you can then send a 2nd offer/answer 
to do whatever needed (if the PSTN bearer is chosen I guess you would
remove the RTP bearer completely).

This is a little related to the m- line comments Ingemar gave on the
SDPCapNeg draft. But, I think the modified c- line is a more serious
issue. Because, in the example entities are not only negotiation
capabilities on a stream/bearer - they are negotiating what bearer to
use in the first place.

2. 

I wonder whether it would be a good idea to define the new network type
("PSTN") and the SDPCapNeg extension in two separate drafts. Because, I
guess the network type could also be used "stand alone". 

Regards,

Christer

_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Miguel Garcia <[email-masked]>
Date: Fri, 23 May 2008 14:36:30 +0300

Hi Christer.

Inline thoughts.

> capabilities on a stream/bearer - they are negotiating what bearer to

I believe the CS draft, which builds on top of the SDP capability 
negotiation, should not have any deviation from it. So, this issue 
should be solved in the SDP capability negotiation. If the SDPcap allows 
to retain the m= line in the SDP answer, let's apply to CS descriptions. 
Whatever the SDPcap allows us to do, we will do.

> guess the network type could also be used "stand alone". 

This is entirely a documentation issue where we shouldn't waste a lot of 
bandwidth.

I guess you are suggesting to extract Section 5.2.1 as a separate RFC. 
Producing an RFC with just one or two pages of content, and 5 of 
overhead, is not very efficient, in my opinion.

If someone wants to build some new feature with only the contents of 
Section 5.2.1, they can only refer to such section in the draft. As a 
matter of fact, we are doing something similar when we apply the COMEDIA 
  syntax to Circuit Switched streams.

/Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Siemens Networks     Espoo, Finland

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 23 May 2008 14:10:36 +0200

Hi Miguel, 

>>1.
>> 
>>My main issue with the draft is the change of the c- line (IN->PSTN) 
>>in the SDP answer, and how it will affect intermediates (who may have 
>>no clue about "PSTN"). I have heard the 
>>"intermediates-should-not-care-about-SDP" statements, but that is not 
>>how the world works today. And, a 2nd offer/answer is not necessarily 
>>going to solve that problem, if already the first answer messes things

>>up (don't shoot me - I'm just the messenger :).
>>  

>I believe the CS draft, which builds on top of the SDP capability
negotiation, should not have any deviation from it. So, >this issue
should be solved in the SDP capability negotiation. If the SDPcap allows
to retain the m= line in the SDP 
>answer, let's apply to CS descriptions. 

It's not only about "CS descriptions", it's about the whole c= line.
While the m= line only deals with a specific stream, the c= line deals
with (at least in your example) completly different transmission
technologies.

Also, if we do want to extend SDPCapNeg to also cover the c= line,
shouldn't there be a more general section in the draft talking about c=
line alternatives in general, and not only talk about the CS use-case?
For example, in theory I guess I could also provide a a=ccap attribute
line with an IPv6 alternative when the c= line contains an IPv4 address,
etc. 

Then there can be separate chapters describing different use-cases and
examples (including the CS use-case), as also done in the SDPCapNeg
draft. 

>Whatever the SDPcap allows us to do, we will do.

SDPCapNeg today does not specify the change of the c= line. Also, if you
read the SDPCapNeg requirements draft, I see nothing which would justify
the change of the c= line. It only talks about media formats, attributes
etc.

So, in my opinion, whatever we do is an extension to SDPCapNeg - both as
far as requirements and solution are concerned.

>I guess you are suggesting to extract Section 5.2.1 as a separate RFC. 

Yes.

>syntax to Circuit Switched streams.

If kept in the same draft (I think Outbound is a good example why that
may not be a good idea, but if nobody else has an issue I will go with
the majority), I think the separation within the draft should be more
clear. The text should very clearly say that the "PSTN" network type can
also be used stand-alone, without the SDPCapNeg extension, so that
nobody can claim that "In order to use the "PSTN" network type we need
to support the whole draft".

Regards,

Christer

---

From: Bob Gilman <[email-masked]>
Date: Mon, 26 May 2008 09:15:34 -0600

Miguel, Christer -
The exchange below suggests to me that we should include capability
attributes for the elements defined in section 5 of RFC4566 (except,
perhaps, m=) in the CapNeg documents.  The general form would take
     "<type>=<value>
to/from
     "a=<type>cap <value>".
That way, we could handle any new additions or extensions to elements
like the connection information discussed below.  If we did this, the
CapNeg aspects of any extensions would already be covered, and we
wouldn't need some small RFC just to handle the CapNeg parts of a
change, or to create a CapNeg equivalent when the need arises.
Clearly, some types are more likely to be the subject of negotiation
than others, but it can't hurt to make the definitions available and
documented in one place.
-Bob
-------------------------------------------------------------
Bob Gilman        [email-masked]      +1 303 898 9780

---

From: Bob Gilman <[email-masked]>
Date: Mon, 26 May 2008 09:30:22 -0600

Oops.  I omitted the capability number for the <type> capability.
The capability attribute should be
     "a=<type>cap:<cap-num> <value>"
We'd need to specify the parameter identifier, preferably
something like "<type>=".
The capability equivalent of the m-line is already covered in a
special way in <ID-ietf-mmusic-media-capabilities>.
My apologies for the errors.
-Bob
-------------------------------------------------------------
Bob Gilman        [email-masked]      +1 303 898 9780

> than others, but it can't hurt to make the definitions available and
...