Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-10.txt

From: [email-masked]
Date: Tue, 06 Mar 2012 01:26:27 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.

	Title           : Session Description Protocol (SDP) Extension For Setting Up Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)
	Author(s)       : Miguel A. Garcia-Martin
                          Simo Veikkolainen
	Filename        : draft-ietf-mmusic-sdp-cs-10.txt
	Pages           : 34
	Date            : 2012-03-06

   This memo describes use cases, requirements, and protocol extensions
   for using the Session Description Protocol (SDP) Offer/Answer model
   for establishing audio and video media streams over circuit-switched
   bearers in the Public Switched Telephone Network (PSTN).

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-cs-10.txt

---

From: <[email-masked]>
Date: Tue, 6 Mar 2012 09:34:28 +0000

We have submitted a new version (-10) of Session Description Protocol (SDP) Extension For Setting Up Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN), which can be found at http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-cs-10.txt

Changes in this version include:
-	The port number in "m=" line SHOULD be set to "9" (the discard port) but it MUST be ignored at reception
-	Clarified that the Discriminator byte is included in the cs-correlation:uuie attribute, but we don't specify a value for the Discriminator byte
-	Added a new example with audio and video streams
-	Added a new section "Considerations for Usage of Third Party Call Control  (3PCC)" which recommends the Controller to use "-" as the connection address (to be in line with 0.0.0.0 which is used for IPv4).
-	Added a new paragraph to security considerations on privacy concerns that arise from including the phone number in the SDP

Regards,
Simo & Miguel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext [email-masked]
Sent: 6. maaliskuuta 2012 11:26
To: [email-masked]
Cc: [email-masked]
Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-10.txt

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 06 Mar 2012 14:48:44 -0500

> -	Clarified that the Discriminator byte is included in the cs-correlation:uuie attribute, but we don't specify a value for the Discriminator byte

I know this has been discussed before, but it still bothers me:

Is there a reason why the representation of this UUIE is so different 
from the representation used in draft-ietf-cuss-sip-uui-isdn-02?
These things are talking about conveying the same thing in the same 
manner. IMO it would be much better to be consistent about this.

Is it because implementations of this draft have already been deployed?

> -	Added a new example with audio and video streams

While its good to seen the new example, as shown it has missed the main 
issue that will arise, because it only shows the situation when one of 
the proposed streams is rejected.

If both streams are to be accepted, are they to result in one pstn phone 
call, or two? I would think the intent would be to have only one. But in 
that case, how is it represented in SDP so that its known that only one 
call is made? Is there an assumption that if one phone number is used 
for multiple m-lines, then the same call should be used for both?

	Thanks,
	Paul

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Wed, 7 Mar 2012 11:49:21 +0100

Hi Paul:

Thanks for your comments, see inline answers.

> manner. IMO it would be much better to be consistent about this.

Do you mean that draft-ietf-cuss-sip-uui-isdn defines a User-to-User SIP 
header field, whereas this draft uses a "cs-correlation" attribute in SDP?

If this is the case, I guess there is a justification. The cuss draft 
comes from an angle of making visible in SIP the UUIE in ISDN, 
irrespective of their contents. The goal is to improve interoperability 
between SIP and ISDN.

The CS descriptions drafts needs a correlation mechanism between two 
objects (a CS call and a RTP stream). It offers three mechanisms, of 
which, one happens to be the UUIE. These mechanisms are described in an 
SDP attribute. They are specific for the purpose of correlating two media 
streams.

I think both mechanisms serve different purposes, and the only 
commonality between them is that it happens to be transporting the same 
information. I would not like to see, e.g., that the CS drafts uses two 
correlation mechanisms defined in SDP, and a third one in a SIP header. I 
don't see the point.

I don't see any problem in leaving them as they are.

> Is it because implementations of this draft have already been deployed?

I am not aware of an implementation of the CS descriptions draft, so this 
should not be a problem.

> for multiple m-lines, then the same call should be used for both?

The idea is to have a single PSTN phone call, with audio and video 
components. I haven't heard of requirements indicating other thing.

So, I agree with you that perhaps we ought to describe that for video 
calls, a single PSTN phone call is made. Yes, we miss some text there, 
thanks for catching this up.

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 07 Mar 2012 11:44:21 -0500

Miguel - comments inline.

On 3/7/12 5:49 AM, Miguel A. Garcia wrote:
>>> We have submitted a new version (-10) of Session Description Protocol
>>> (SDP) Extension For Setting Up Audio and Video Media Streams Over
>>> Circuit-Switched Bearers In The Public Switched Telephone Network
>>> (PSTN), which can be found at
>>> - The port number in "m=" line SHOULD be set to "9" (the discard
>>> port) but it MUST be ignored at reception
>>> - Clarified that the Discriminator byte is included in the
>>> cs-correlation:uuie attribute, but we don't specify a value for the
>>> Discriminator byte
>>

I'm not talking specifically about the header field. The situation is 
different here - you need to transport this in SDP rather than directly 
in SIP.

What I am talking about is the representation of the UUI value. 
draft-ietf-cuss-sip-uui-isdn includes the discriminator byte and encodes 
the whole thing in hex. This draft does it differently. ISTM that these 
ought to use the same representation unless there is some justification 
for the difference.

> SDP attribute. They are specific for the purpose of correlating two
> media streams.
>
> correlation mechanisms defined in SDP, and a third one in a SIP header.
> I don't see the point.

I am not disputing use of an SDP parameter rather than a SIP header.

> I am not aware of an implementation of the CS descriptions draft, so
> this should not be a problem.
>
>>

I figured you only had one call in mind.

But because the phone number is specified in c=, which is media level, 
there is the potential that audio and video would have differing phone 
numbers, which would presumably exclude a single call. So there should 
probably be some explanation of that. Perhaps that there will only be 
one call per distinct combination of phone number and cs-correlation 
attribute.

Or do you want to exclude the possibility of different phone numbers 
being supplied? If so, then I might be better to move the phone number 
from the c-line to a session level attribute. While its possible to 
specify the phone number once at session level, its also possible to do 
it at media level, where it might end up different.

Also, I would think you would typically want to specify the 
cs-correlation at session level rather than media level. (In fact you 
show it that way in your new example.) But currently it is defined as 
being only media level. So you should probably change that.

	Thanks,
	Paul

> /Miguel
>
>
>>
>> Thanks,
>> Paul
>>
>>> - Added a new section "Considerations for Usage of Third Party Call
>>> Control (3PCC)" which recommends the Controller to use "-" as the
>>> connection address (to be in line with 0.0.0.0 which is used for IPv4).
>>> - Added a new paragraph to security considerations on privacy
>>> concerns that arise from including the phone number in the SDP
>>
>>

---

From: <[email-masked]>
Date: Thu, 8 Mar 2012 13:39:25 +0000

See below [SV]

-----Original Message-----
From: ext Paul Kyzivat [mailto:[email-masked]] 
Sent: 7. maaliskuuta 2012 18:44
To: Miguel A. Garcia
Cc: [email-masked]; Veikkolainen Simo (Nokia-CTO/Espoo)
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-10.txt

On 3/7/12 5:49 AM, Miguel A. Garcia wrote:
> Do you mean that draft-ietf-cuss-sip-uui-isdn defines a User-to-User 
> SIP header field, whereas this draft uses a "cs-correlation" attribute in SDP?

I'm not talking specifically about the header field. The situation is different here - you need to transport this in SDP rather than directly in SIP.

What I am talking about is the representation of the UUI value. 
draft-ietf-cuss-sip-uui-isdn includes the discriminator byte and encodes the whole thing in hex. This draft does it differently. ISTM that these ought to use the same representation unless there is some justification for the difference.

[SV] draft-ietf-cuss-sip-uui-04 seems to add encoding, package, and content parameters to the UUI data itself. The actual content of the UUI seems to be the protocol discriminator and uui data (hex encoding preferred), the same as in sdp-cs draft. For our purposes only the "uui-data" part of the syntax in Section 4.1 of draft-ietf-cuss-sip-uui-04 would be needed, and not the "uui-param". I don't see much benefit in changing the syntax to be the same in both drafts, but I guess it wouldn't hurt either.

> irrespective of their contents. The goal is to improve 
> interoperability between SIP and ISDN.
>
> which, one happens to be the UUIE. These mechanisms are described in 
> an SDP attribute. They are specific for the purpose of correlating two 
> media streams.
>
> commonality between them is that it happens to be transporting the 
> same information. I would not like to see, e.g., that the CS drafts 
> uses two correlation mechanisms defined in SDP, and a third one in a SIP header.
> I don't see the point.

>> While its good to seen the new example, as shown it has missed the 
>> main issue that will arise, because it only shows the situation when 
>> one of the proposed streams is rejected.
>>
>> If both streams are to be accepted, are they to result in one pstn 
>> phone call, or two? I would think the intent would be to have only 
>> one. But in that case, how is it represented in SDP so that its known 
>> that only one call is made? Is there an assumption that if one phone 
>> number is used for multiple m-lines, then the same call should be used for both?
>

But because the phone number is specified in c=, which is media level, there is the potential that audio and video would have differing phone numbers, which would presumably exclude a single call. So there should probably be some explanation of that. Perhaps that there will only be one call per distinct combination of phone number and cs-correlation attribute.

Or do you want to exclude the possibility of different phone numbers being supplied? If so, then I might be better to move the phone number from the c-line to a session level attribute. While its possible to specify the phone number once at session level, its also possible to do it at media level, where it might end up different.

[SV] I think only one phone number should be supplied; that is how the circuit-switched world works.  So it might be better to specify the phone number once at session level - for other (IP based) media the address could be defined at media level, if they ever are offered together.

Also, I would think you would typically want to specify the cs-correlation at session level rather than media level. (In fact you show it that way in your new example.) But currently it is defined as being only media level. So you should probably change that.

[SV] I agree.

- Simo

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 Mar 2012 12:07:59 -0500

> [SV] draft-ietf-cuss-sip-uui-04 seems to add encoding, package, and content parameters to the UUI data itself. The actual content of the UUI seems to be the protocol discriminator and uui data (hex…

All I'm thinking of here is consistency in the representation of the 
content - that it include the descriminator byte and that it be then 
encoded in hex. At least that way people that are familiar with UUI will 
be less inclined to get confused.

> [SV] I think only one phone number should be supplied; that is how the circuit-switched world works.  So it might be better to specify the phone number once at session level - for other (IP based)…

I'm not going to try to second guess you here. But I suppose it might be 
some work to require the phone number to be at session level unless you 
move it out of the c= line and into something that is only allowed at 
session level, like a session-level-only attribute. But if you leave it 
in the c= line then I think you must address the possibility that 
multiple c= lilnes have different values. At least explicitly call it 
out and say that behavior in that case is explicitly undefined.

	Thanks,
	Paul

---

From: Atle Monrad <[email-masked]>
Date: Mon, 12 Mar 2012 10:22:45 +0100

Folks

As I'm not near to the coding here, I'll not be too opinionated about the coding

However, both draft-ietf-mmusic-sdp-cs and draft-ietf-cuss-sip-uui-isdn are drafts that 3GPP is waiting for being finalised.

Both drafts are referenced in 3GPP Rel-8, which has been completed years ago. Deployments are eagely waiting for both drafts to be completed.

Kindly take this into account.

thanks
/atle

________________________________ 

Atle Monrad
3GPP CT Chairman
Standardization and Regulation,
Group Function Technology and Portfolio Management 
Ericsson

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 8. mars 2012 18:08
To: [email-masked]
Cc: [email-masked]
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-10.txt

On 3/8/12 8:39 AM, [email-masked] wrote:
>>> Is there a reason why the representation of this UUIE is so 
>>> different from the representation used in draft-ietf-cuss-sip-uui-isdn-02?

All I'm thinking of here is consistency in the representation of the content - that it include the descriminator byte and that it be then encoded in hex. At least that way people that are familiar with UUI will be less inclined to get confused.

>> an SDP attribute. They are specific for the purpose of correlating 
>> two media streams.
>>
>>> one. But in that case, how is it represented in SDP so that its 
>>> known that only one call is made? Is there an assumption that if one 
>>> phone number is used for multiple m-lines, then the same call should be used for both?
>>
>> calls, a single PSTN phone call is made. Yes, we miss some text 
>> there, thanks for catching this up.
>

I'm not going to try to second guess you here. But I suppose it might be some work to require the phone number to be at session level unless you move it out of the c= line and into something that is only allowed at session level, like a session-level-only attribute. But if you leave it in the c= line then I think you must address the possibility that multiple c= lilnes have different values. At least explicitly call it out and say that behavior in that case is explicitly undefined.

	Thanks,
	Paul