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

From: <[email-masked]>
Date: Thu, 25 Sep 2008 11:00:35 +0300

Hi,
We presented 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

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

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 26 Sep 2008 13:48:56 +0200

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: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
	Sent: 25. syyskuuta 2008 11:01
	To: [email-masked]
	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.

	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. 

	Best regards, 
	Simo Veikkolainen

---

From: <[email-masked]>
Date: Mon, 29 Sep 2008 11:57:04 +0300

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:[email-masked]] 
	Sent: 26 September, 2008 14:49
	To: Veikkolainen Simo (Nokia-D/Helsinki); [email-masked]
	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: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
		Sent: 25. syyskuuta 2008 11:01
		To: [email-masked]
		Subject: [MMUSIC] Progressing
draft-garcia-mmusic-sdp-cs-01

		Hi, 
		We presented

		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. 

		Best regards, 
		Simo Veikkolainen

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 29 Sep 2008 11:49:28 +0200

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: [email-masked]
[mailto:[email-masked]] 
	Sent: 29. syyskuuta 2008 11:57
	To: Christer Holmberg; [email-masked]
	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:[email-masked]] 
		Sent: 26 September, 2008 14:49
		To: Veikkolainen Simo (Nokia-D/Helsinki);
[email-masked]
		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

			Hi, 
			We presented

			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. 

			Best regards, 
			Simo Veikkolainen

---

From: <[email-masked]>
Date: Tue, 30 Sep 2008 12:35:32 +0300

Sent: 29 September, 2008 12:49

	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.

[Simo] This is correct (except that the call signalling may be something
else than ISUP as well). On the other hand, setting up a CS bearer can
be seen analogous to setting up a TCP connection for media. I can try to
clarify this in the draft, though.
 
Best regards,
Simo

	Regards,
	 
	Christer

		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

			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

				Hi, 
				We presented

				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.

				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. 

				Best regards, 
				Simo Veikkolainen

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 30 Sep 2008 11:40:57 +0200

Hi,
 
Currently, the draft only allows "-" as port value for CS.
 
I think you should also allow port "0", if one wants to remove CS. And,
in that case you should also clarify that it is not only the CS bearer
which is removed, but the whole CS call (in the ISUP case, an ISUP REL
will be triggered).
 
And, if you want to draw parallels with TCP, would it be possible to use
port "9" instead of "-"?
 
Regards,
 
Christer

	Sent: 30. syyskuuta 2008 12:36

		Hi,

		 
		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.

	[Simo] This is correct (except that the call signalling may be
something else than ISUP as well). On the other hand, setting up a CS
bearer can be seen analogous to setting up a TCP connection for media. I
can try to clarify this in the draft, though.
	 
	Best regards,
	Simo

		Regards,
		 
		Christer

			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

				To: Veikkolainen Simo
(Nokia-D/Helsinki); [email-masked]

				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

				Hi, 
				We presented

				Best regards, 
				Simo Veikkolainen