[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Title: 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 at nokia.com [mailto:Simo.Veikkolainen at nokia.com]
Sent: 30. syyskuuta 2008 12:36
To: Christer Holmberg; mmusic at ietf.org
Subject: RE: [MMUSIC] Progressing draft-garcia-mmusic-sdp-cs-01

 

From: ext Christer Holmberg [mailto:christer.holmberg at ericsson.com]
Sent: 29 September, 2008 12:49
To: Veikkolainen Simo (Nokia-D/Helsinki); mmusic at 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 at nokia.com [mailto:Simo.Veikkolainen at nokia.com]
Sent: 29. syyskuuta 2008 11:57
To: Christer Holmberg; mmusic at 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 at ericsson.com]
Sent: 26 September, 2008 14:49
To: Veikkolainen Simo (Nokia-D/Helsinki); mmusic at 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 at ietf.org [mailto:mmusic-bounces at ietf.org] On Behalf Of Simo.Veikkolainen at nokia.com
Sent: 25. syyskuuta 2008 11:01
To: mmusic at 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 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 at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic