Subject: [MMUSIC] [Fwd: I-D Action:draft-garcia-mmusic-sdp-cs-00.txt]

From: Miguel Garcia <[email-masked]>
Date: Mon, 18 Feb 2008 09:34:21 +0200

We have just published an Internet-Draft that indicates how to describe 
circuit-switched media streams in SDP. Comments are welcome.

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

Subject: I-D Action:draft-garcia-mmusic-sdp-cs-00.txt
From: "ext [email-masked]" <[email-masked]>
To: [email-masked]
Date: Sun, 17 Feb 2008 23:30:01 -0800 (PST)
List-Id: <i-d-announce.ietf.org>

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Describing CS audio streams in the Session Description Protocol (SDP)
	Author(s)       : M. Garcia-Martin, S. Veikkolainen
	Filename        : draft-garcia-mmusic-sdp-cs-00.txt
	Pages           : 21
	Date            : 2008-02-17

This memo describes use cases and requirements for controlling
circuit-switched media streams using the Session Description Protocol
(SDP).  Additional, it proposes conventions on how to use SDP and the
SDP capability negotiation framework for agreeing on alternative
media streams between the endpoints.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-garcia-mmusic-sdp-cs-00.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-garcia-mmusic-sdp-cs-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-garcia-mmusic-sdp-cs-00.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
I-D-Announce mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/i-d-announce
_______________________________________________
mmusic mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/mmusic

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 18 Feb 2008 08:43:49 +0100

Hi,

Is this draft related to the draft Tom Taylor put together some years
ago?

http://tools.ietf.org/id/draft-taylor-mmusic-sdp-tdm-01.txt

Regards,

Christer 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Miguel Garcia
> Sent: 18. helmikuuta 2008 9:34
> To: mmusic
> Subject: [MMUSIC] [Fwd: I-D Action:draft-garcia-mmusic-sdp-cs-00.txt]
> 
> We have just published an Internet-Draft that indicates how 
> to describe circuit-switched media streams in SDP. Comments 
> are welcome.
> 
> /Miguel
> --

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 18 Feb 2008 09:49:59 +0200

I think that draft was targeting a gateway that would be able to 
describe CS and IP bearers, so it has a slightly different level of 
scope. However I read the draft, and we got some points of inspiration. 
The result is that Tom's draft is expired, so, there is no point in 
creating any dependency on it.

/Miguel

---

From: Tom Taylor <[email-masked]>
Date: Mon, 18 Feb 2008 03:16:50 -0500

That draft was a lot more ambitious, since it had all the ISDN bearer capability 
stuff in it too IIRC. I was finally persuaded it was easier to go with industry 
practice and encapsulate the Q.931 information element as binary data. As the 
Miguel's draft shows, however, the basic job of identifying a circuit bearer 
still has to be done in some circumstances.

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 18 Feb 2008 12:49:27 +0100

Hi, 

A question is related to the choise of using the sdp-cap/med-neg
mechanism.

The draft defines a way of providing an alternative c- line.

But, what if the PS and CS bearers have different direction attribute
values, and/or if one bearer requires pre-conditions, and the other
doesn't (see example below)?

I am just wondering whether there is a point where it is better to use
the grouping framework instead (ANT), as you describe in Annex A.

v=0
o=bob 280744730 28977631 IN IP4 host.example.com
s=
t=0 0
a=group:ANT 1 2
m=audio 25000 RTP/AVP 0
c=IN IP6 2001:DB8::1
a=mid:1
a=sendrecv
a=pre-condition stuff...
m=audio 1 CS gsm amr
c=CS
a=inactive
a=mid:2

Regards,

Christer

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 18 Feb 2008 14:17:46 +0200

The problem with ANAT is that it is dead. Now that IPv4/IPv6 is done 
with ICE, and not knowing a single implementation of ANAT, I don't dare 
to propose it here.

I would draw your attention to Section 13 of the ICE draft, when it 
says: "This specification deprecates RFC 4091."

So, I don't think it makes sense to keep on considering ANAT.

With respect the unidirectional cases you propose, I would like to here 
what are the real use cases, not the theoretical uses cases. I don't 
have a clear idea of where are we going to find this use cases in real 
scenarios.

In any case, you can tie attributes to capabilities with the a=acap 
attribute defined in the SDP capability negotiation, so you can still 
solve those theoretical problems.

/Miguel

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 18 Feb 2008 14:50:04 +0100

Hi, 

>The problem with ANAT is that it is dead. Now that IPv4/IPv6 
>is done with ICE, and not knowing a single implementation of 
>ANAT, I don't dare to propose it here.

Well, you can see MY mail as a proposal then, to at least consider it :)

>So, I don't think it makes sense to keep on considering ANAT.

I didn't say ANAT - I said ANT :)

Seriously, ANAT was done for a specific purpose, and it was then decided
that ICE works better for that specific purpose.

Eventhough the solution now technically would look very similar to ANAT,
it's about solving a completely different problem. I don't think we
should be forbidden to dig up old stuff if we face a new problem for
which it can be used.

>With respect the unidirectional cases you propose, I would 
>like to here what are the real use cases, not the theoretical 
>uses cases. I don't have a clear idea of where are we going 
>to find this use cases in real scenarios.

In 3GPP there is work on somthing called IMS centralized services. The
work is still on a rather high level, so I can't give you any documented
use-cases where alternative direction attributes etc would be needed. My
comment is simply based on some personal thinking.
 
I also think we need to be carful regarding backward compability. SDP
cap neg already "breaks" offer/answer by allowing some parameters to
change in the m- line (the SDP cap neg specs says that a additional
offer/answer can be used to "synchronize" intermediates etc). Now you
are doing the same thing for the c- line, so I am afraid that things
could get messed up in intermediates before the offerer even gets a
chance to send a new offer...

>In any case, you can tie attributes to capabilities with the 
>a=acap attribute defined in the SDP capability negotiation, 
>so you can still solve those theoretical problems.

Are you saying that a=acap can be used to provide alternatives for ANY
attribute? If so, I appologize for having missed that.

Regards,

Christer

> > o=bob 280744730 28977631 IN IP4 host.example.com s= t=0 0 
> a=group:ANT 
> > 1 2 m=audio 25000 RTP/AVP 0 c=IN IP6 2001:DB8::1
> > a=mid:1
> > a=sendrecv
> > a=pre-condition stuff...
> > m=audio 1 CS gsm amr
> > c=CS
> > a=inactive
> > a=mid:2
> > 
> > 
> > Regards,
> > 
> > Christer
> > 
> 
> --

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 18 Feb 2008 16:39:03 +0200

Inline.

> chance to send a new offer...

I agree that we ought to be careful with backwards compatibility. Notice 
that the draft does not mandate to use SDP negotiation capabilities, but 
in most cases it really makes sense.

On the other hand, if there is a issue with the SDP negotiation 
capability, then it should be solved in that draft, not in this one, 
which merely applies it.'

> attribute? If so, I appologize for having missed that.

Yes, that is the case.

/Miguel

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 18 Feb 2008 22:56:20 +0100

Hi,

>in most cases it really makes sense.

I agree that it doesn't mandate it (personally I am not even aware of current scenarios where it would be needed), but it does define an extension to SDP cap neg, which allows to provide alternative c- lines. And, I think we need to discuss whether that is the correct way to go, or whether to use something else.

>On the other hand, if there is a issue with the SDP negotiation capability, then it should be solved in that draft, not in this one, which merely applies it.'

The issue the the current SDP cap neg only applies to the m- line. You now "extend" that issue to the c- line.

Again, the solution (which I guess applies to both the m- and c- line) to handle intermediates which don't support SDP cap neg is to send a second offer after the choise is done, but I am just afraid things may get messed up already by the initial answer... 

So, we need to discuss it.

>>attribute? If so, I appologize for having missed that.

You are probably right. My misstake.

Regards,

Christer