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

From: [email-masked]
Date: Mon, 31 Oct 2011 05:03:08 -0700

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-09.txt
	Pages           : 30
	Date            : 2011-10-31

   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-09.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-09.txt

---

From: <[email-masked]>
Date: Mon, 31 Oct 2011 12:06:15 +0000

Hi,
We have submitted a new version of the sdp-cs draft (http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-cs-09.txt), addressing Paul's comments.

Below is a list of changes in the -09 version:

Number format
-	Use the term “international E.164 number” throughout the document
-	Require a “+” sign in all international E.164 numbers

Added the following lines to addresstype specification in 5.2.1:
“
    When the <addrtype> is PSTN, the connection address is defined
    as follows:

    o  an e164-address

    When the <addrtype> is "-", the connection address is defined
    as follows:

    o  the value "-", signifying that the address is unknown.
OR
    o  any syntactically valid value, which is to be ignored..
“

Syntax of cs-correlation changed in 5.2.3.1 

UUIE protocol discriminator
-	Clarified that only the “User information” part of UUIE is to be included as the value of uuie-mech, and used for comparing the incoming UUIE
-	Added an OPEN ISSUE still here

Moved the usage of “a=connection:existing” to 5.5.4 Modifying the session.

Added text in 5.5.4 on how connection reuse works.

E.164 syntax in 5.6
- we didn’t include a reference to RFC3966 since we don’t want to include the visual separator, and otherwise the benefit of having the RFC as reference would be small

Changed the number in the examples. +15551234 -> +35891234567 (I know this at least is a syntactically correct representation 

Things which did not make this version:

TODO: Add example with CS audio/video stream.
TODO: Security considerations needs more work based on Flemming's earlier comments (including caller's E164 number in SDP).
TODO: Clarification on the mechanism works with 3PCC.

Thanks
Simo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext [email-masked]
Sent: 31 October, 2011 14:03
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action: draft-ietf-mmusic-sdp-cs-09.txt

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-cs-09.txt
_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 31 Oct 2011 15:30:25 -0400

Thanks. This clears up a lot.
In looking over the changes, I noted the following other things:

Syntax (in 5.2.3.1 and 5.6):

As written, this will allow individual correlation mechanisms to be 
repeated, possibly with differing values. E.g.

a=cs-correlation: dtmf:123 dtmf:456

I'm not sure, but I *doubt* you intend to allow that.
To address it, you have a couple of choices:

- fiddle the syntax to disallow it.
- put in textual rules to forbid it.

In section 5.2.3.2, you have:

    For example, the numbers +358-9-123-4567 and 09-123-4567
    could be considered as the same number.

This could be interpreted as indicating that the international E.164 
number might contain separator characters. Based on your syntax, the one 
in the cs-correlation attribute can't have them. I'm not sure if the one 
received as callerid info from the PSTN can have them or not.

In section 5.2.3.3:

The protocol discriminator must be specified *somewhere*.
Either you can specify a fixed one as part of this mechanism, or else 
you must allow it to be specified as part of the value.

In section 5.5.4:

"If either party wishes to drop and reestablish an existing call..."

This implies that one must use one o/a exchange to drop the existing 
call and another one to establish it again. That shouldn't be necessary. 
Sending the same sort of offer one would do to establish the initial 
session (including a=connection:new) should be fine.

	Thanks,
	Paul

On 10/31/11 8:06 AM, [email-masked] wrote:
>      When the<addrtype>  is PSTN, the connection address is defined
>      as follows:
>
>      o  an e164-address
>
>      When the<addrtype>  is "-", the connection address is defined
>      as follows:
>
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic