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

>Yes, setting the port to zero should have the same semantics here as
normally with SDP. We'll add that.
>	 
>I don't see port 9 would be any better here. It means "discard",
whereas the intension with the dash is to indicate that port number is
not applicable..

Well, I would say that port 9 means "do not care about this port" :)
But, I guess it is a matter of taste.

Regards,

Christer

________________________________

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

		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

________________________________

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

________________________________

				From: ext Christer Holmberg
[mailto:christer.holmberg@ericsson.com] 
				Sent: 29 September, 2008 12:49
				To: Veikkolainen Simo
(Nokia-D/Helsinki); mmusic@ietf.org
				Subject: 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.

			[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

________________________________

					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 

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic