Session Description Protocol (SDP) Extension for Setting Audio and Video Media Streams over Circuit-Switched Bearers in the Public Switched Telephone Network (PSTN)
draft-ietf-mmusic-sdp-cs-23

racker.
IANA Actions - YES

NOTE: This version -23 has made two edits in the IANA Considerations
section. 

1) This version has added an additional value 'external' to
the "cs-correlation" Attribute Values registry located at:

http://www.iana.org/assignments/sdp-parameters

"cs-correlation" Attribute Values
Registration Procedure(s): Specification Required
Reference: [RFC-ietf-mmusic-sdp-cs]

Value Description Reference
callerid Caller ID [RFC-ietf-mmusic-sdp-cs-21]
uuie User-User Information Element [RFC-ietf-mmusic-sdp-cs-21]
dtmf Dual-tone Multi-Frequency [RFC-ietf-mmusic-sdp-cs-21]
external External  [RFC-ietf-mmusic-sdp-cs]

2) This version has changed term "Multifrequency" to "Multi-
Frequency" for the 'dtmf' 'cs-correlation' attribute in section
8.1.

Authors should review the comments and/or questions below. Please
report any inaccuracies and respond to any questions as soon as
possible.

Note:  The (new) actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.

[Ballot comment]

Thanks for addressing my discuss.

(I still didn't check the comments below vs -20. Feel
free to let me know if I ought.)

----

- req-7 is very odd, why?

- the last para of section 4 is part of the protocol
so probably belongs in section 5.

- 5.2.3.2, last sentence: why is the number of digits
a secret for which I have to pay?  Implementers will
just make stuff up here unless this is only ever
implemented by large vendors. Neither seems like a
good plan.

- 5.2.3.3, I would argue that [ITU.Q931.1998] maybe
ought be normative since I'm not sure you fully
describe how to use the UUIE such that I don't have to
read that. For example, is any octet a valid protocol
discriminator, or could two values be equivalent, or
do I even care?  Better might be to add 2119
language to this description such that [ITU.Q931.1998]
can really be informative, but you're close to
being there already so not a discuss.

- 5.2.3.3, 2nd last para, 1st sentence, correlation
is a fine thing but is it worth saying twice? :-)

- 5.2.3.4, the DTMF section seems to lack a reference
that tells me how to generate DTMF tones. Isn't
that needed?

- 5.5: I didn't get the point of this fwiw.

- section 7: 2nd para, I don't understand how one
avoids a bidding down attack here. We do require
that from e.g. TLS and I'm not sure why its ok
to not admit that e2e security is a gonner if
one uses this particulal SDP stuff.

[Ballot discuss]

Just to note -19 doesn't seem to address my discuss
point, didn't check the comments.

5.2.3 describes 3 mechanisms for correlation, none of
which are foolproof and doesn't say which, if any, are
mandatory to implement. That seems to me to be liable
to result in non-interop. The last para before 5.4
(and the lack of implementaion) also seems to
emphasise that this specificaion is not really that
concerned with interop. The discuss point is: why
ought we push out an RFC that's not really aiming
for interop, or am I missing something?

[Ballot comment]


- req-7 is very odd, why?

- the last para of section 4 is part of the protocol
so probably belongs in section 5.

- 5.2.3.2, last sentence: why is the number of digits
a secret for which I have to pay?  Implementers will
just make stuff up here unless this is only ever
implemented by large vendors. Neither seems like a
good plan.

- 5.2.3.3, I would argue that [ITU.Q931.1998] maybe
ought be normative since I'm not sure you fully
describe how to use the UUIE such that I don't have to
read that. For example, is any octet a valid protocol
discriminator, or could two values be equivalent, or
do I even care?  Better might be to add 2119
language to this description such that [ITU.Q931.1998]
can really be informative, but you're close to
being there already so not a discuss.

- 5.2.3.3, 2nd last para, 1st sentence, correlation
is a fine thing but is it worth saying twice? :-)

- 5.2.3.4, the DTMF section seems to lack a reference
that tells me how to generate DTMF tones. Isn't
that needed?

- 5.5: I didn't get the point of this fwiw.

- section 7: 2nd para, I don't understand how one
avoids a bidding down attack here. We do require
that from e.g. TLS and I'm not sure why its ok
to not admit that e2e security is a gonner if
one uses this particulal SDP stuff.

[Ballot comment]
== former DISCUSS positions, moved to comment on the basis of plan to move forward which has been agreed upon in email ==

In the last paragraph on page 22, the text requires certain behaviors of the recipient of the Offer.  One option that is not discussed is that the recipient may not be willing to establish a connection to some E.164 numbers based on a priori knowledge of cost, or other reasons.  The document says the recipient of the Offer SHOULD become active if the offer included an E.164 number, but does not say what to put in the Answer if the recipient for some reason does not do what it SHOULD do.  I think this can be addressed by updating the following two sentences to address this situation.

At the bottom of page 23, the last bullet point says to compare the callerid subfield value to the caller ID received from the circuit-switched network, but doesn't say what to do if it matches, although the following two bullet points on the next page do say.  This should be really easy to fix with text similar to that in the subsequent bullet items.

In section 5.6.3, the document is not clear about how to proceed if the circuit-switched connection is established before an Answer is received. How long does the Offerer wait before treating the circuit-switched connection as a regular incoming call? It would really work better for the establishment of an active connection from the Answerer were to require a separate Offer/Answer cycle with the Answerer becoming the Offerer, but I don't know enough about SDP to know if this is practical. In any case, the document should say what to do when the Answer is late or never arrives at all.

===

Comments:

In 4.1, the document talks about Alice and Bob, presumably two human beings, making decisions about whether to use circuit-switched or IP transport for their media streams.  I think this is highly improbable; I presume that the actual scenario is that Alices' and Bob's phones will be making these decisions.  I think it would be clearer to describe the real use case here and not speak of it in terms of a weird and unlikely UI interaction that Bob and Alice would somehow perform in order to trigger the protocol interaction that this section is trying to illustrate.  This may seem like a minor nit, but the set of actions that this text intends to describe is actually a lot smaller than the set of actions I wind up imagining as I read it, because I can't help but imagine all the UI interactions that wouldn't actually happen in a real example.

In 5.2.2, bottom of page 9, this isn't a complete sentence, and I don't know what it means:

  The RTP audio and video media types, which, when
  applied to PSTN circuit-switched bearers, represent merely an audio
  or video codec.

At the top of Page 20, the draft uses the term "dynamic payload type" without defining it.  This paragraph refers to Section 6 of RFC 4566, which does not really clarify the meaning to me, although it might to a better-informed reader.  Depending on who you expect to read this document, it might be good to say what a dynamic payload type is—that is, why it's dynamic, and not whatever the opposite of dynamic would be.  Also, the reference to Section 6 actually links to Section 6 of this document, not RFC 4566—you probably need to tweak your xml2rfc source.  I noticed an external section reference that _did_ work earlier in the document, I think.

Second-to-last paragraph of 5.6.1:

  Also 'holdconn' is a permissible value in the 'a=setup' attribute.
  It indicates that the connection is not established for the time
  being.

I think you mean this:

  Also 'holdconn' is a permissible value in the 'a=setup' attribute.
  It indicates that the connection is not to be established for the time
  being.

Why even generate an Offer in this case?

In 5.6.2, the draft talks about the recipient of an Offer not being willing to use circuit-switched media for the session.  What happens if the recipient doesn't _support_ using circuit-switched media?  I don't know much about SDP; I presume that unknown address types result in a failed negotiation, as mentioned in the first paragraph of 5.6.3.  It might be worth mentioning this briefly either in 5.6.2 or 5.6.3, with a reference to the base spec where it says what happens in this case.

In figures 4 and 5, is there some reason why the uuie value is the same?

Section 7 doesn't talk about the attack where the attacker sends an Offer that tricks the Answerer into establishing a circuit-switched connection to an expensive destination, such as a paid service billed through the phone, or a country with high termination rates where the recipient will profit from receiving a call.  I don't know enough about the context to know if this is dealt with in some way; it might be good to say something about how it is dealt with if it has been dealt with, and of course if it hasn't been dealt with, it needs to be addressed, or we will be reading about it on Boingboing next year.

[Ballot discuss]
In the last paragraph on page 22, the text requires certain behaviors of the recipient of the Offer.  One option that is not discussed is that the recipient may not be willing to establish a connection to some E.164 numbers based on a priori knowledge of cost, or other reasons.  The document says the recipient of the Offer SHOULD become active if the offer included an E.164 number, but does not say what to put in the Answer if the recipient for some reason does not do what it SHOULD do.  I think this can be addressed by updating the following two sentences to address this situation.

At the bottom of page 23, the last bullet point says to compare the callerid subfield value to the caller ID received from the circuit-switched network, but doesn't say what to do if it matches, although the following two bullet points on the next page do say.  This should be really easy to fix with text similar to that in the subsequent bullet items.

In section 5.6.3, the document is not clear about how to proceed if the circuit-switched connection is established before an Answer is received. How long does the Offerer wait before treating the circuit-switched connection as a regular incoming call? It would really work better for the establishment of an active connection from the Answerer were to require a separate Offer/Answer cycle with the Answerer becoming the Offerer, but I don't know enough about SDP to know if this is practical. In any case, the document should say what to do when the Answer is late or never arrives at all.

[Ballot discuss]
In the last paragraph on page 22, the text requires certain behaviors of the recipient of the Offer.  One option that is not discussed is that the recipient may not be willing to establish a connection to some E.164 numbers based on a priori knowledge of cost, or other reasons.  The document says the recipient of the Offer SHOULD become active if the offer included an E.164 number, but does not say what to put in the Answer if the recipient for some reason does not do what it SHOULD do.  I think this can be addressed by updating the following two sentences to address this situation.

At the bottom of page 23, the last bullet point says to compare the callerid subfield value to the caller ID received from the circuit-switched network, but doesn't say what to do if it matches, although the following two bullet points on the next page do say.  This should be really easy to fix with text similar to that in the subsequent bullet items.

In section 5.6.3, the document is not clear about how to proceed if the circuit-switched connection is established before an Answer is received. How long does the Offerer wait before treating the circuit-switched connection as a regular incoming call? It would really work better for the establishment of an active connection from the Answerer were to require a separate Offer/Answer cycle with the Answerer becoming the Offerer, but I don't know enough about SDP to know if this is practical.  In any case, the document should say what to do when the Answer is late or never arrives at all.

[Ballot discuss]
In the last paragraph on page 22, the text requires certain behaviors of the recipient of the Offer.  One option that is not discussed is that the recipient may not be willing to establish a connection to some E.164 numbers based on a priori knowledge of cost, or other reasons.  The document says the recipient of the Offer SHOULD become active if the offer included an E.164 number, but does not say what to put in the Answer if the recipient for some reason does not do what it SHOULD do.  I think this can be addressed by updating the following two sentences to address this situation.

At the bottom of page 23, the last bullet point says to compare the callerid subfield value to the caller ID received from the circuit-switched network, but doesn't say what to do if it matches, although the following two bullet points on the next page do say.  This should be really easy to fix with text similar to that in the subsequent bullet items.

In section 5.6.3, the document is not clear about how to proceed if the circuit-switched connection is established before an Answer is received.  How long does the Offerer wait before treating the circuit-switched connection as a regular incoming call?  It would really work better for the establishment of an active connection from the Answerer were to require a separate Offer/Answer cycle with the Answerer becoming the Offerer, but I don't know enough about SDP to know if this is practical.  In any case, the document should say what to do when the Answer is late or never arrives at all.

[Ballot comment]
In 4.1, the document talks about Alice and Bob, presumably two human beings, making decisions about whether to use circuit-switched or IP transport for their media streams.  I think this is highly improbable; I presume that the actual scenario is that Alices' and Bob's phones will be making these decisions.  I think it would be clearer to describe the real use case here and not speak of it in terms of a weird and unlikely UI interaction that Bob and Alice would somehow perform in order to trigger the protocol interaction that this section is trying to illustrate.  This may seem like a minor nit, but the set of actions that this text intends to describe is actually a lot smaller than the set of actions I wind up imagining as I read it, because I can't help but imagine all the UI interactions that wouldn't actually happen in a real example.

In 5.2.2, bottom of page 9, this isn't a complete sentence, and I don't know what it means:

  The RTP audio and video media types, which, when
  applied to PSTN circuit-switched bearers, represent merely an audio
  or video codec.

At the top of Page 20, the draft uses the term "dynamic payload type" without defining it.  This paragraph refers to Section 6 of RFC 4566, which does not really clarify the meaning to me, although it might to a better-informed reader.  Depending on who you expect to read this document, it might be good to say what a dynamic payload type is—that is, why it's dynamic, and not whatever the opposite of dynamic would be.  Also, the reference to Section 6 actually links to Section 6 of this document, not RFC 4566—you probably need to tweak your xml2rfc source.  I noticed an external section reference that _did_ work earlier in the document, I think.

Second-to-last paragraph of 5.6.1:

  Also 'holdconn' is a permissible value in the 'a=setup' attribute.
  It indicates that the connection is not established for the time
  being.

I think you mean this:

  Also 'holdconn' is a permissible value in the 'a=setup' attribute.
  It indicates that the connection is not to be established for the time
  being.

Why even generate an Offer in this case?

In 5.6.2, the draft talks about the recipient of an Offer not being willing to use circuit-switched media for the session.  What happens if the recipient doesn't _support_ using circuit-switched media?  I don't know much about SDP; I presume that unknown address types result in a failed negotiation, as mentioned in the first paragraph of 5.6.3.  It might be worth mentioning this briefly either in 5.6.2 or 5.6.3, with a reference to the base spec where it says what happens in this case.

In figures 4 and 5, is there some reason why the uuie value is the same?

Section 7 doesn't talk about the attack where the attacker sends an Offer that tricks the Answerer into establishing a circuit-switched connection to an expensive destination, such as a paid service billed through the phone, or a country with high termination rates where the recipient will profit from receiving a call.  I don't know enough about the context to know if this is dealt with in some way; it might be good to say something about how it is dealt with if it has been dealt with, and of course if it hasn't been dealt with, it needs to be addressed, or we will be reading about it on Boingboing next year.

[Ballot discuss]
Like Stephen and Spencer, I have serious concerns about whether this protocol actually leads to interoperability, even setting aside the concerns about correlation techniques.

D1. The document claims to cover "circuit-switched" cases, when in reality it is very PSTN-specific.  Namely, in order to work, it needs the CS network to support CPNI, UUIE, or DTMF.  Also, in order for "c=" lines to make sense, the CS network needs to support E.164 numbers for addresses.  Please clarify that this addresses the use of the CS half of the PSTN (or at least CS networks that meet the above criteria), not a general CS network.

D2. If we consider this document as focused on the PSTN, then it seems like the "-" addrtype should be removed, since all CS endpoints have an E.164 address.  (And in any case, its use is illegal according to Section 5.6.)

D3. The line "m=audio 9 PSTN -" can only work if the CS channel is actually an audio channel and not, say, a CS data channel. Likewise for video.  So this line should only be included / accepted by the active party if the active party knows that it the CS channel it will establish will have the appropriate mechanisms.  Please update 5.6.1 / 5.6.2 to require that this information about the CS layer be taken into account.

[Ballot comment]
I'm an uneasy no-objection on this one, but I appreciate Stephen's DISCUSS.

I understand the problem they're trying to solve. I know the people who are working on it, and they're smart. They're trying to make up for some of the many deficiencies of the PSTN, which even the people who own the PSTN hate so much they want to decommission it (at least in the US). There's no chance that the PSTN would change to make their job one bit easier. I don't think objecting would be productive. They have a real problem to solve, and they're throwing everything at the wall to see what sticks, so I don't think me objecting would lead to a better specification. And they're going to end up with a solution whether I'm happy or not.

I don't think publishing it will make the Internet any worse. It might even provide ammunition to people who want to push for faster PSTN decommissioning ("see what we have to put up with? and it still may not work!").

But I do wonder whether it belongs on the standards track.

-- my non-rant follows --

I am confused. I'm reading

5.2.3.  Correlating the PSTN Circuit-Switched Bearer with SDP

  The endpoints should be able to correlate the circuit-switched bearer
  with the session negotiated with SDP in order to avoid ringing for an
  incoming circuit-switched bearer that is related to the session
  controlled with SDP (and SIP).

as saying that correlation matters, and then I'm reading three subsections that describe mechanisms that may not work ...

5.2.3.2.  Caller-ID Correlation Mechanism

      Note that there are no guarantees that this correlation mechanism
      works or is even available, due a number of problems:

5.2.3.3.  User-User Information Element Correlation Mechanism

  Please note that there are no guarantees that this correlation
  mechanism works.

5.2.3.4.  DTMF Correlation Mechanism

  If the endpoints successfully agree on the usage of the DTMF digit
  correlation mechanism, but the passive side does not receive any DTMF
  digits after successful circuit-switched bearer setup, or receives a
  set of DTMF digits that do not match the value of the "dtmf"
  attribute (including receiving too many digits), the passive side
  SHOULD consider that this DTMF mechanism has failed to correlate the
  incoming call.

... and then, a bit further down ...

5.3.3.  Considerations on correlations

  Note that it cannot be guaranteed that any given correlation
  mechanism will succeed even if the usage of those was agreed
  beforehand.  This is due to the fact that the correlation mechanisms
  require support from the circuit-switched bearer technology used.

  Therefore, even a single positive indication using any of these
  mechanisms SHOULD be interpreted by the passive endpoint so that the
  circuit-switched bearer establishment is related to the ongoing
  session, even if the other correlation mechanisms fail.

  If, after negotiating one or more correlation mechanisms in the SDP
  offer/answer exchange, an endpoint receives a circuit-switched bearer
  with no correlation information present, the endpoint has two
  choices: it can either treat the call as unrelated, or treat the call
  as related to the ongoing session in the IP domain.

Am I misunderstanding this? Or misstating it?

[Ballot discuss]

5.2.3 describes 3 mechanisms for correlation, none of
which are foolproof and doesn't say which, if any, are
mandatory to implement. That seems to me to be liable
to result in non-interop. The last para before 5.4
(and the lack of implementaion) also seems to
emphasise that this specificaion is not really that
concerned with interop. The discuss point is: why
ought we push out an RFC that's not really aiming
for interop, or am I missing something?

[Ballot comment]



- req-7 is very odd, why?

- the last para of section 4 is part of the protocol
so probably belongs in section 5.

- 5.2.3.2, last sentence: why is the number of digits
a secret for which I have to pay?  Implementers will
just make stuff up here unless this is only ever
implemented by large vendors. Neither seems like a
good plan.

- 5.2.3.3, I would argue that [ITU.Q931.1998] maybe
ought be normative since I'm not sure you fully
describe how to use the UUIE such that I don't have to
read that. For example, is any octet a valid protocol
discriminator, or could two values be equivalent, or
do I even care?  Better might be to add 2119
language to this description such that [ITU.Q931.1998]
can really be informative, but you're close to
being there already so not a discuss.

- 5.2.3.3, 2nd last para, 1st sentence, correlation
is a fine thing but is it worth saying twice? :-)

- 5.2.3.4, the DTMF section seems to lack a reference
that tells me how to generate DTMF tones. Isn't
that needed?

- 5.5: I didn't get the point of this fwiw.

- section 7: 2nd para, I don't understand how one
avoids a bidding down attack here. We do require
that from e.g. TLS and I'm not sure why its ok
to not admit that e2e security is a gonner if
one uses this particulal SDP stuff.

[Ballot comment]
Two comments you may or may not address:

Section 1., paragraph 2:

>    However, SDP can be used to describe other transport protocols than
>    RTP.  Previous work includes SDP conventions for describing ATM

  A nit from the Transport side: RTP is a 'media transport protocol'
  and not a 'transport protocol' per se.


Section 1., paragraph 5:

>    In some scenarios it might be desirable to establish the media stream
>    over a circuit-switched bearer connection even if the signaling for

  The concept of a 'bearer' from the phone networks might not be
  known to all readers of RFCs.

acker.
IANA Actions - YES

NOTE: This review was based on version -18 of the draft document.

Thank you,

Pearl Liang
ICANN/IANA


On Wed May 15 08:33:51 2013, iesg-secretary@ietf.org wrote:
> Evaluation for  can be found at
> http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs/
>
> Last call to expire on: 2013-02-01 00:00
>
>
>        Please return the full line with your position.
>
>                      Yes  No-Objection  Discuss  Abstain
> Gonzalo Camarillo    [ X ]    [  ]      [  ]    [  ]
>
>
> "Yes" or "No-Objection" positions from 2/3 of non-recused ADs,
> with no "Discuss" positions, are needed for approval.
>
> DISCUSSES AND COMMENTS
> ===========
> ?
> ---- following is a DRAFT of message to be sent AFTER approval ---
> From: The IESG
> To: IETF-Announce
> Cc: RFC Editor ,
>    mmusic mailing list ,
>    mmusic chair
> Subject: Protocol Action: 'Session Description Protocol (SDP)
>    Extension For Setting Up Audio and Video Media Streams Over
>    Circuit-Switched Bearers In The Public Switched Telephone Network
>    (PSTN)' to Proposed Standard (draft-ietf-mmusic-sdp-cs-17.txt)
>
> The IESG has approved the following document:
> - 'Session Description Protocol (SDP) Extension For Setting Up Audio
>    and
>    Video Media Streams Over Circuit-Switched Bearers In The Public
>    Switched Telephone Network (PSTN)'
>  (draft-ietf-mmusic-sdp-cs-17.txt) as Proposed Standard
>
> This document is the product of the Multiparty Multimedia Session
>    Control
> Working Group.
>
> The IESG contact persons are Gonzalo Camarillo and Robert Sparks.
>
> A URL of this Internet Draft is:
> http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs/
>
>
>
>
> *Technical Summary
> *
>
> The document 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 Publich Switched Telephone Network (PSTN)
>
> *Working Group Summary
> *
>
> The WG had some discussion around the format to use for E.164 numbers
> and whether to align this with the existing definition in RFC 3108.
>    The
> RFC 3108 definition was seen as deficient and the WG agreed it was
> better to align with relevant parts of the tel URI format defined in
>    RFC
> 3966, not least since SDP address types are defined in the context of
>    a
> particular network type, and hence RFC 3108 compatibility is not a
> concern (the implication is that the "E164" address type may differ
> between network types in SDP).
>
> *Document Quality
> *
>
> There are currently no known implementations of the draft, however the
> draft is a dependency for 3GPP, so future implementations are
>    expected.
>
> The document has received good overall review in the WG, some of which
> resulted in changes to the detailed specification. The document has
>    been
> reviewed in detail several times, including of the last few versions.
> The major contributors to these as well as earlier discussions are
> listed in the Acknowledgements section of the document.
>
>
> *Personnel
> *
>
> Document Shepherd: Flemming Andreasen
> Responsible AD: Gonzalo Camarillo
>
>

IANA has reviewed draft-ietf-mmusic-sdp-cs-17 and has the following comments:

We have questions about one of the actions requested by the authors of
this document.

We understand that, upon approval of this document, there are five actions which we must complete.

First in the SDP att-field (media level only) subregistry of the Session Description Protocol (SDP) Parameters registry located at:

http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml

a new SDP attribute will be registered as follows:

Type: att-filed (media level only)
SDP Name: cs-correlation
Reference: [ RFC-to-be ]

Second, a new subregistry is to be created called the "cs-correlation" Attribute Values registry. It will be located in the Session Description Protocol (SDP) Parameters registry located at:

http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml

Registration and maintenance in this new registry is done by Specification Required as defined in RFC 5226. There are initial registrations in this new registry as follows:

Value of 'cs-correlation' attribute Reference Description
----------------------------------- ------------- -----------
callerid [ RFC-to-be ] Caller ID
uuie [ RFC-to-be ] User-User
Information Element
dtmf [ RFC-to-be ] Dual-tone Multifrequency

Third, in the nettype subregistry of the Session Description Protocol (SDP) Parameters registry located at:

http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml

a new SDP nettype will be registered as follows:

Type: nettype
SDP Name: PSTN
Reference: [ RFC-to-be ]

Fourth, in the addrtype subregistry of the Session Description Protocol (SDP) Parameters registry located at:

http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml

two new addrtype values will be registered as follows:

Type: addrtype
SDP Name: E164
Reference: [ RFC-to-be ]

Type:
SDP Name: -
Reference: [ RFC-to-be ]

IANA Question -> the authors request that "The current "addrtype" sub-registry structure does not capture the fact that a given addrtype is defined in the context of a particular "nettype". The sub-registry structure should be to correct that as part of this registration."

Should another column be added to the addrtype registry with entries for "context?" If so, should entries be made for the existing registrations? What should these be? As such, please make the "NOTE to IANA' for revising
the sub-registry (in section 8.3) as action items, rather than "NOTE".

Question -> the document describes the two new addrtype values as
depicted below:

Type SDP Name Reference
---- ------------------ ---------
addrtype E164 [RFCxxxx]
- [RFCxxxx]

Should the term 'addrtype' be added to the 2nd addrtype value '-'?

Is the special character '-' for the 2nd addrtype acceptable in
the registry as per RFc4566? Can AD confirm this?

Fifth, in the proto subregistry of the Session Description Protocol (SDP) Parameters registry located at:

http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml

a new proto will be registered as follows:

Type: proto
SDP Name: PSTN
Reference: [ RFC-to-be ]

We understand that these five actions are the only ones required to be completed upon approval of this document.

Note: The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Session Description Protocol (SDP) Extension For Setting Up Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)) to Proposed Standard


The IESG has received a request from the Multiparty Multimedia Session
Control WG (mmusic) to consider the following document:
- 'Session Description Protocol (SDP) Extension For Setting Up Audio and
  Video Media Streams Over Circuit-Switched Bearers In The Public
  Switched Telephone Network (PSTN)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-02-01. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

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 file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs/ballot/


No IPR declarations have been submitted directly on this I-D.

/(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the title
page header?/

Proposed Standard. Title page indicates "Standards Track".

/(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:/

/Technical Summary:/

/Relevant content can frequently be found in the abstract and/or
introduction of the document. If not, this may be an indication that
there are deficiencies in the abstract or introduction./

/Working Group Summary:/

/Was there anything in WG process that is worth noting? For example, was
there controversy about particular points or were there decisions where
the consensus was particularly rough?/

/Document Quality:/

/Are there existing implementations of the protocol? Have a significant
number of vendors indicated their plan to implement the specification?
Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If there was a
MIB Doctor, Media Type or other expert review, what was its course
(briefly)? In the case of a Media Type review, on what date was the
request posted?/

/Personnel:/

/Who is the Document Shepherd? Who is the Responsible Area Director?/

*
Technical Summary
*

The document 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 Publich Switched Telephone Network (PSTN)

*Working Group Summary
*

The WG had some discussion around the format to use for E.164 numbers
and whether to align this with the existing definition in RFC 3108. The
RFC 3108 definition was seen as deficient and the WG agreed it was
better to align with relevant parts of the tel URI format defined in RFC
3966, not least since SDP address types are defined in the context of a
particular network type, and hence RFC 3108 compatibility is not a
concern (the implication is that the "E164" address type may differ
between network types in SDP).

*Document Quality
*

There are currently no known implementations of the draft, however the
draft is a dependency for 3GPP, so future implementations are expected.

The document has received good overall review in the WG, some of which
resulted in changes to the detailed specification. The document has been
reviewed in detail several times, including of the last few versions.
The major contributors to these as well as earlier discussions are
listed in the Acknowledgements section of the document.


*Personnel
*

Document Shepherd: Flemming Andreasen
Responsible AD: Gonzalo Camarillo

*
*

/(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the IESG.
/

The document shepherd has performed a detailed review of -11, and
versions 13-16 of the document.


/(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?/

There has been several reviews of the document from various
knowledgeable people and as such there are no concerns.


/(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that took
place./

No such review is required.

/(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here./

No specific concerns or issues


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why?

The authors have confirmed that they are not aware of any IPR.

/(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures./

There are no IPR disclosures


/(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others being
silent, or does the WG as a whole understand and agree with it?/

There is solid concensus behind the document with several people having
participated in the overall process.


/(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)/

There are no such issues.


(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

The document has been checked by idnits and the I-D Checklist and no
nits have been found.


/(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews./

The document provides extensions to SDP only and as such the necessary
review has already been done by the MMUSIC WG.


/(13) Have all references within this document been identified as either
normative or informative?/

Yes

/(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?/

Not applicable

/(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure./

Not applicable.


/(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed in
the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary./

No change to existing RFCs


/(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226)./

The IANA Considerations section has been reviewed and no issues found.

/(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries./

The document defines a new subregistry for the 'cs-correlation'
attribute under the Session Description Protocol (SDP) Parameters
registry with a "Specification Required" registration policy.

The document authors would be approproate Designated Experts for new
registration in this subregistry.

/
/

/(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc./

ABNF has been verified with Bill Fenner's ABNF parser - the problems
reported by the parser are not actual issues. There is no other formal
language in the document.