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

From: [email-masked]
Date: Mon, 08 Oct 2012 02:10:21 -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-12.txt
	Pages           : 37
	Date            : 2012-10-08

Abstract:
   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).

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-12

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-cs-12

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

---

From: Andrew Allen <[email-masked]>
Date: Wed, 17 Oct 2012 00:31:26 +0000

I have reviewed this and have some minor editorial comments:

One NIT

5.6.2.  Generating the Answer

"The Answerer MUST also include its E.164 number of the "c=" line."

Shouldn't this be

"The Answerer MUST also include its E.164 number on the "c=" line."

Another comment on the new proposed text at the end of 5.6.2:

If the Answerer becomes the active party, generates an SDP answer,	and then it finds out that the circuit-switched call cannot be established, then such endpoint MUST create a new SDP offer where circuit-switched stream is removed from the session (actually, by setting the corresponding port in the m= line to zero) and send it to its counter part. This is to synchronize both parties (and potential intermediaries) on the state of the session.

Instead of "then such endpoint MUST" why not state "then the Answerer MUST"

Also the proposed new text in 5.6.3:

Note that it if deliver of the Answer is delayed for some reason, the circuit-switched call may arrive at the Offerer before the Answer has been processed. In this case, since the correlation mechanisms are negotiated as part of the Offer/Answer exchange,the Answerer cannot know whether the incoming call attempt is correlated with the session being negotiated, the Offerer SHOULD accept the call only after it has received and processed the Answer.

Propose to replace it with:

"Note that it if delivery of the Answer is delayed for some reason, the circuit-switched call attempt may arrive at the Offerer before the Answer has been processed. In this case, since the correlation mechanisms are negotiated as part of the Offer/Answer exchange, the Answerer cannot know whether or not the incoming circuit-switched call attempt is correlated with the session being negotiated, the Offerer SHOULD answer the circuit-switched call attempt only after it has received and processed the Answer."

So that there is no ambiguity that we are talking about the circuit-switched call attempt.

Also at the end of the security considerations section

"Additionally, it is strongly RECOMMENDED that the end user is asked for consent prior to the endpoint initiating a circuit-switched connection which might incur in charges.

Remove in from "incur in charges"

Andrew

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of [email-masked]
> Sent: Monday, October 08, 2012 4:10 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-12.txt
> 
> 
> 	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)
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Sun, 21 Oct 2012 11:26:34 +0200

Hi Andrew,

thanks for your comments. I have accepted all your comments and submitted 
version -13:

http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs/

See inline answers

> "The Answerer MUST also include its E.164 number on the "c=" line."

Yes, fixed

> If the Answerer becomes the active party, generates an SDP answer,	and
> then it finds out that the circuit-switched call cannot be
> established, then such endpoint MUST create a new SDP offer where
> circuit-switched stream is removed from the session (actually, by
> setting the corresponding port in the m= line to zero) and send it to
> its counter part. This is to synchronize both parties (and potential
> intermediaries) on the state of the session.
>

Yes, no problem. Fixed.

> Note that it if deliver of the Answer is delayed for some reason, the
> circuit-switched call may arrive at the Offerer before the Answer has
> been processed. In this case, since the correlation mechanisms are
> negotiated as part of the Offer/Answer exchange,the Answerer cannot
> know whether the incoming call attempt is correlated with the session
> being negotiated, the Offerer SHOULD accept the call only after it has
> received and processed the Answer.
>
> "Note that it if delivery of the Answer is delayed for some reason,
> the circuit-switched call attempt may arrive at the Offerer before the
> Answer has been processed. In this case, since the correlation
> mechanisms are negotiated as part of the Offer/Answer exchange, the
> Answerer cannot know whether or not the incoming circuit-switched call
> attempt is correlated with the session being negotiated, the Offerer
> SHOULD answer the circuit-switched call attempt only after it has
> received and processed the Answer."

Fixed.

> "Additionally, it is strongly RECOMMENDED that the end user is asked
> for consent prior to the endpoint initiating a circuit-switched
> connection which might incur in charges.
>

I am ok with that. Fixed.

Thanks,

         Miguel

>
> Andrew
>
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of
>> [email-masked] Sent: Monday, October 08, 2012 4:10 AM To:
>> [email-masked] Cc: [email-masked] Subject: [MMUSIC] I-D
>> Action: draft-ietf-mmusic-sdp-cs-12.txt
>>
>>
>> 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-12.txt Pages           : 37 Date
>> : 2012-10-08
>>
>> Abstract: 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).
>>
>>
>> _______________________________________________ mmusic mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/mmusic
>
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute
> non-public information. Any use of this information by anyone other
> than the intended recipient is prohibited. If you have received this
> transmission in error, please immediately reply to the sender and
> delete this information from your system. Use, dissemination,
> distribution, or reproduction of this transmission by unintended
> recipients is not authorized and may be unlawful.
> _______________________________________________ mmusic mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/mmusic
>

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