Re: [MMUSIC] Progressing draft-garcia-mmusic-sdp-cs-01

Hi,

I think you also need to make it very clear that you are actually not
directly describing a bearer in the c- line, because you cannot start
sending media towards a phone number.

You are providing information (the phone number) used to establish a CS
call. A bearer is then established as part of that call setup.

In other words: in the case of CS ISUP, the c- line contains information
about where to send an ISUP IAM message, in order to establish the CS
call.

Regards,

Christer

________________________________

	From: Simo.Veikkolainen@nokia.com
[mailto:Simo.Veikkolainen@nokia.com] 
	Sent: 29. syyskuuta 2008 11:57
	To: Christer Holmberg; mmusic@ietf.org
	Subject: RE: [MMUSIC] Progressing draft-garcia-mmusic-sdp-cs-01

	I can add a sentence on that. According to RFC4566 p= may
contain "contact information for the person resposible for the
conference", and we want to have a connection specific address. 

	Simo

________________________________

		From: ext Christer Holmberg
[mailto:christer.holmberg@ericsson.com] 
		Sent: 26 September, 2008 14:49
		To: Veikkolainen Simo (Nokia-D/Helsinki);
mmusic@ietf.org
		Subject: RE: [MMUSIC] Progressing
draft-garcia-mmusic-sdp-cs-01

		Hi,

		In the generic description part, I think it would be
good to describe the reason why the existing SDP p= parameter can't be
used.

		Regards,

		Christer

________________________________

			From: mmusic-bounces@ietf.org
[mailto:mmusic-bounces@ietf.org] On Behalf Of
Simo.Veikkolainen@nokia.com
			Sent: 25. syyskuuta 2008 11:01
			To: mmusic@ietf.org
			Subject: [MMUSIC] Progressing
draft-garcia-mmusic-sdp-cs-01

			Hi, 
			We presented
http://tools.ietf.org/html/draft-garcia-mmusic-sdp-cs-01
<http://tools.ietf.org/html/draft-garcia-mmusic-sdp-cs-01>  at the last
MMUSIC meeting in Dublin. Based on the comments we got there, it seemed
that

			1) Some middleboxes may get confused by the new
"PSTN" nettype-value in the c= line. Also, defining a new connection
capability attribute ("ccap") in the context of SDP capability
negotiation framework may be problematic from middlebox point of view.

			2) The draft should be split in two, one
containing the genric description of circuit-switched streams in SDP,
and the other describing the connection capability attribute. 

			We have had some offline discussions regarding
these comments, and came to the conclusion that splitting the draft
(issue 2) makes sense. The generic description of circuit-switched
streams in SDP can be used without the connection capability definition.

			For issue 1), we could not really find any
concrete actions to take. 

			So, the proposal is now to split the draft into
two, but keep the technical content unchanged. 

			How do folks feel with this? 

			Best regards, 
			Simo Veikkolainen 