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

From: <[email-masked]>
Date: Tue, 1 Nov 2011 07:15:38 +0000

Hi Paul, 
See below.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of ext Paul Kyzivat
> Sent: 31 October, 2011 21:30
> To: [email-masked]
> Subject: Re: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-sdp-cs-09.txt
> 
> 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.

It seems I'm not really fluent with the syntax... We don't want to allow repeating individual mechanisms. We'll take a look at the syntax again.
 
> 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.

We should write +35891234567 and 091234567.
 
> 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.

I was thinking the protocol discriminator is picked up by the CS signaling stack, as it would for normal CS calls, and just comparing octets 4...n  of the received UUIE to the value exchanged in O/A would be sufficient. If we need to define the value for the protocol discriminator, one option I guess could be value 0, which indicates User-specific protocol according to Q.931. 

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

Ok, we'll clarify that.

Thanks
Simo
 
> 	Thanks,
> 	Paul
> 
> 
> On 10/31/11 8:06 AM, [email-masked] wrote:
> > 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 J
> >
> > 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
> >
> > 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
> > _______________________________________________
> > 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
> > _______________________________________________
> > mmusic mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mmusic
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 02 Nov 2011 13:57:08 -0400

Inline.

(Keith Drage - there is a question for you below.)

> It seems I'm not really fluent with the syntax... We don't want to allow repeating individual mechanisms. We'll take a look at the syntax again.

Its fairly easy to write the ABNF to allow each kind at most once if you 
fix the order in which they may appear.

         cs-correlation-attr= "cs-correlation:" corr-mechanisms
         corr-mechanisms    = [SP caller-id-mech] [SP uuie-mech]
                              [SP dtmf-mech] [SP ext-mech]

(This has the limitation that there must be a space before the first 
mechanism.)

To allow them in any order is *possible* but unreasonably complex. If 
you want that, then best to just do it with words.

> We should write +35891234567 and 091234567.

WFM

> I was thinking the protocol discriminator is picked up by the CS signaling stack, as it would for normal CS calls, and just comparing octets 4...n  of the received UUIE to the value exchanged in O/…

So the recipient would ignore the protocol discriminator?
That seems pretty odd to me. But I will defer to someone who is more 
familiar with use of these mechanisms in the PSTN. (Keith?)

	Thanks,
	Paul

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 4 Nov 2011 02:02:09 +0100

In regard to your question about the protocol discriminator, I don't see the text as saying ignore it, it is just saying it is outside the scope of this document.

This document is saying how you take the delivered user data and correlate it with something that is in the SDP. The protocol discriminator can form part of the checks of whether I am delivering the user data to the right application in the first place along with what message I've received it in and probably one or two other things, none of which have anything to do with this document.

However I must admit I don't like specification by negatives (MUST NOT) which is what this is. 

Maybe change the text as:

   The first three octets of the User-user information element specified
   in ITU-T Q.931 [ITU.Q931.1998] are the user-user information element identifier, length of user-user contents, and a protocol discriminator, followed by the user information.  An entity performing correlation MUST only compare
   the octets carrying the user information to the "cs-correlation:uuie"
   attribute (the user-user information element identifier, length of user-user contents, and protocol discriminator are not used for this purpose).

I've corrected some capitalization and a typo as well.

Keith

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: 02 November 2011 17:57
> To: [email-masked]
> Cc: [email-masked]; DRAGE, Keith (Keith)
> > It seems I'm not really fluent with the syntax... We don't want to allow
> repeating individual mechanisms. We'll take a look at the syntax again.
> 
> > I was thinking the protocol discriminator is picked up by the CS
> signaling stack, as it would for normal CS calls, and just comparing
> octets 4...n  of the received UUIE to the value exchanged in O/A would be
> sufficient. If we need to define the value for the protocol discriminator,
> one option I guess could be value 0, which indicates User-specific
> protocol according to Q.931.
> 
> >>> -	Use the term "international E.164 number" throughout the
> >> document
> >>> -	Require a "+" sign in all international E.164 numbers
> >>>
> >>> "
> >>> "
> >>> -	Clarified that only the "User information" part of UUIE is to be
> >>> Moved the usage of "a=connection:existing" to 5.5.4 Modifying the
> >> session.
> >>>
> >>> - we didn't include a reference to RFC3966 since we don't want to

---

From: <[email-masked]>
Date: Fri, 4 Nov 2011 09:22:44 +0000

> From: ext DRAGE, Keith (Keith) [mailto:[email-masked]]
> Sent: 04 November, 2011 03:02
> To: Paul Kyzivat; Veikkolainen Simo (Nokia-CTO/Helsinki)
> Cc: [email-masked]
> Subject: RE: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-sdp-cs-09.txt
> 
> In regard to your question about the protocol discriminator, I don't see the
> text as saying ignore it, it is just saying it is outside the scope of this
> document.

Right.
 
> This document is saying how you take the delivered user data and correlate it
> with something that is in the SDP. The protocol discriminator can form part of
> the checks of whether I am delivering the user data to the right application in
> the first place along with what message I've received it in and probably one
> or two other things, none of which have anything to do with this document.
> 
>    in ITU-T Q.931 [ITU.Q931.1998] are the user-user information element
> identifier, length of user-user contents, and a protocol discriminator,
> followed by the user information.  An entity performing correlation MUST
> only compare
>    attribute (the user-user information element identifier, length of user-user
> contents, and protocol discriminator are not used for this purpose).
> 

This proposal would work for me.

Thanks,
Simo
 
> > Its fairly easy to write the ABNF to allow each kind at most once if
> > you fix the order in which they may appear.
> >
> > >> 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
> > >> Either you can specify a fixed one as part of this mechanism, or
> > >> else
> > you must
> > octets 4...n  of the received UUIE to the value exchanged in O/A would
> > be sufficient. If we need to define the value for the protocol
> > discriminator, one option I guess could be value 0, which indicates
> > User-specific protocol according to Q.931.
> >
> > >> This implies that one must use one o/a exchange to drop the
> > >> existing
> > call and
> > >> Sending the same sort of offer one would do to establish the
> > >> initial
> > session
> > >> included as the value of uuie-mech, and used for comparing the
> > >> incoming UUIE
> > >>> include the visual separator, and otherwise the benefit of having
> > >>> the RFC as reference would be small
> > >>>
> > >> Up Audio and Video Media Streams Over Circuit-Switched Bearers In
> > >> The Public Switched Telephone Network (PSTN)

---

From: <[email-masked]>
Date: Fri, 4 Nov 2011 09:24:09 +0000

> From: ext Paul Kyzivat [mailto:[email-masked]]
> Sent: 02 November, 2011 19:57
> To: Veikkolainen Simo (Nokia-CTO/Helsinki)
> Cc: [email-masked]; Keith Drage
> >> As written, this will allow individual correlation mechanisms to be
> >> repeated, possibly with differing values. E.g.
> >>
> Its fairly easy to write the ABNF to allow each kind at most once if you fix the
> order in which they may appear.
> 
> To allow them in any order is *possible* but unreasonably complex. If you
> want that, then best to just do it with words.

Fixed order is fine. I'll fix the syntax according to this.

Thanks
Simo
 
> >> 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.
> >
> >> 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.
> >
> > I was thinking the protocol discriminator is picked up by the CS signaling
> stack, as it would for normal CS calls, and just comparing octets 4...n  of the
> received UUIE to the value exchanged in O/A would be sufficient. If we need
> to define the value for the protocol discriminator, one option I guess could
> be value 0, which indicates User-specific protocol according to Q.931.
> 
> >> 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.
> >
> > Ok, we'll clarify that.
> >
> > Thanks
> > Simo
> >
> >> 	Thanks,
> >> 	Paul
> >>
> >>
> >> directories. This draft is a work item of the Multiparty Multimedia
> >> Session Control Working Group of the IETF.
> >>>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 04 Nov 2011 13:21:17 -0400

> I've corrected some capitalization and a typo as well.

This still seems problematic to me.
The UUIE is sent by one endpoint and received by the other.
If the protocol discriminator is not signaled in the SDP, and its also 
not fixed by the spec, then it must be chosen by the endpoint initiating 
the cs, and won't be known to the recipient.

If the recipient puts *any* limitations on what it is, then it will fail 
if the sender chooses something else. In my book that means the 
recipient must ignore the protocol discriminator for this to work.

Does it matter what discriminator is used, or cause any harm to ignore 
it? I don't know. I suppose it depends on how these things are used in 
the PSTN. Does anything enforce consistency between the discriminator 
and the content? Does anything restrict what discriminators may be used?

If the discriminator is so unimportant that it can be ignored, then why 
is it present at all?

Just to be safe, why not either:
- include the discriminator in the string; OR
- just pick a discriminator and wire it into this document

	Thanks,
	Paul

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 4 Nov 2011 19:02:29 +0100

The protocol discriminator is only one of the variables.

Essentially there are a number of things that can vary such as:

-	what purpose am I doing this correlation for in the first place. Section 1 of the document mentions a number of use cases but none of this document describes how I actually use this mechanism within that use case (and that needs to be agreed between both ends before it can occur)

-	which correlation transport mechanism am I using (the document provides at least three in 5.2.3.2, 5.2.3.3 and 5.2.3.4), and the one you choose depends on what is available end to end within that overall use case (and again that needs to be agreed between both ends before it can occur).

So I very much see this document as providing part of a toolkit which I plug into a much wider usage. It is not the part of this document to specify that wider usage. 

I believe 3GPP has one document that specifies how these get pulled together for one specific use case. Other groups and even IETF may have other use cases that need a similar tool.

I don't think it is part of this document to specify those use cases, and I think it is just sufficient to know they exist, and that standards can be applied elsewhere to deal with the options available in using this document.

Keith

> Sent: 04 November 2011 17:21
> To: DRAGE, Keith (Keith)
> Cc: [email-masked]; [email-masked]
> > In regard to your question about the protocol 
> discriminator, I don't see the text as saying ignore it, it 
> is just saying it is outside the scope of this document.
> >
> > This document is saying how you take the delivered user 
> data and correlate it with something that is in the SDP. The 
> protocol discriminator can form part of the checks of whether 
> I am delivering the user data to the right application in the 
> first place along with what message I've received it in and 
> probably one or two other things, none of which have anything 
> to do with this document.
> >
> > However I must admit I don't like specification by 
> negatives (MUST NOT) which is what this is.
> >
> >     in ITU-T Q.931 [ITU.Q931.1998] are the user-user 
> information element identifier, length of user-user contents, 
> and a protocol discriminator, followed by the user 
> information.  An entity performing correlation MUST only compare
> >     attribute (the user-user information element 
> identifier, length of user-user contents, and protocol 
> discriminator are not used for this purpose).
> >
> If the protocol discriminator is not signaled in the SDP, and 
> its also not fixed by the spec, then it must be chosen by the 
> endpoint initiating the cs, and won't be known to the recipient.
> 
> If the recipient puts *any* limitations on what it is, then 
> it will fail if the sender chooses something else. In my book 
> that means the recipient must ignore the protocol 
> discriminator for this to work.
> 
> Does it matter what discriminator is used, or cause any harm 
> to ignore it? I don't know. I suppose it depends on how these 
> things are used in the PSTN. Does anything enforce 
> consistency between the discriminator and the content? Does 
> anything restrict what discriminators may be used?
> 
> If the discriminator is so unimportant that it can be 
> ignored, then why is it present at all?
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 07 Nov 2011 14:16:19 -0500

> -	what purpose am I doing this correlation for in the first place. Section 1 of the document mentions a number of use cases but none of this document describes how I actually use this mechanism wit…

I don't understand your point here. The offerer has decided to offer a 
circuit switched stream. The answerer doesn't have to know why this 
decision was made. It need only decide whether to accept it or not.
In this regard it is like many other things negotiated via o/a.

> -	which correlation transport mechanism am I using (the document provides at least three in 5.2.3.2, 5.2.3.3 and 5.2.3.4), and the one you choose depends on what is available end to end within that…

Again, the offerer provides info for the correlation mechanisms it is 
willing to use. They aren't mutually exclusive - they can be used in 
tandem. So the answerer can answer with the full subset that it is able 
to use. There need not be any external pre-agreement.

> So I very much see this document as providing part of a toolkit which I plug into a much wider usage. It is not the part of this document to specify that wider usage.

ISTM that the protocol discriminator choice is of an entirely different 
character than the others. As it stands, there must either be a separate 
agreement about this, or else the recipient must ignore it.

> I believe 3GPP has one document that specifies how these get pulled together for one specific use case. Other groups and even IETF may have other use cases that need a similar tool.

This mechanism could be used in non-IMS enviroments, without major 
pre-agreements (other than to support the mechanism at all), *if* the 
mechanism for determining the protocol discriminator is specified.

I'll repeat my earlier question - what is the harm in specifying this?

CUSS is defining use of UUI, and it is including the protocol 
discriminator along with the value. Is there a reason not to follow the 
same representation here?

> I don't think it is part of this document to specify those use cases, and I think it is just sufficient to know they exist, and that standards can be applied elsewhere to deal with the options avai…

I don't think this doc need specify those cases.
But it ought to specify a complete mechanism.

	Thanks,
	Paul