Subject: Re: [MMUSIC] Comments on IESG Changes in the -cs draft ? [Fwd: Protocol Action: 'Session Description Protocol (SDP) Extension For Setting Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)' to Proposed Standard (draft-ietf-mmusic-sdp-cs-21.txt)]

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 4 Sep 2013 16:45:06 +0200

Hi,

we have pulled this draft off the RFC Editor's queue. That is, we will
not approve it until we have sorted this issue out.

With respect to use cases, 3GPP intends to use this. However, they do
not need any correlation mechanism, since they can produce a phone
number that is specific to the session. The mobile will call that phone
number and the receiver (which will actually be a network node) will
correlate the new call with the original session. This means that the
terminals do not actually need to implement any correlation mechanism.
The correlation is handled by the network, which produces the
session-specific phone numbers.

So, for 3GPP everything would work fine without defining any correlation
mechanism. Now, since we are defining a general mechanism, it should
work in a general scenario (i.e., a non-3GPP network). What type of
correlation mechanism do we want to include in the document?

If we believe so, we can explain the IESG that we do not need to mandate
any correlation mechanism. Current systems that relay on the human user
to correlate session work fine. For example, WedEx, which is massively
use by IETFers, can place a call to your phone when you are attending a
conference. The correlation between the incoming phone call on your
phone and the web session you have opened with the WebEx server is done
by the human user. That is, the user receives a call that says "welcome
to webex" and assumes it is correlated to the current session (there are
security implications, of course).

Distributed architectures where the SIP session is on one terminal and
the PSTN session is placed/received from/on another can also make all
the correlation mechanisms described in the draft fail.

Is the WG comfortable with this line of argument or do we want to do
something else? I want the WG to agree on what the right thing to do is
before getting back to the IESG.

Thanks,

Gonzalo

On 14/08/2013 4:39 PM, Paul Kyzivat wrote:
> On 8/14/13 4:31 PM, Hadriel Kaplan wrote:
>>
>> I propose we remove the UUI and DTMF correlation options, and just
>> leave it as the callerid one only for now.
>>
>> We can leave the ABNF with the current 'ext-mech' so that a future
>> spec could define something else if need be, and the IANA registration
>> procedures for doing so are already documented in this
>> draft-ietf-mmusic-sdp-cs-21.
> 
> I don't think it makes sense to make such a change without some
> discussion whether the result will meet the needs that people have for
> the intended uses of this mechanism.
> 
>     Thanks,
>     Paul
> 
>> -hadriel
>>
>>
>> On Aug 12, 2013, at 8:51 AM, Miguel A. Garcia
>> <[email-masked]> wrote:
>>
>>> Hi Hadriel:
>>>
>>> As far as I remember, the history of the three mechanisms is kind of
>>> fuzzy. At some point in time in the past, 3GPP hadn't decided on the
>>> architecture to enable CS calls over SIP/SDP, and they were looking
>>> into it. The mechanisms were envisioned by the authors and comments
>>> on the mailing list, and put at 3GPP's disposal for a choice.
>>>
>>> I concur with  your concern that just because we mandate to implement
>>> the 3 of them, these are not going to be implemented. I don't have
>>> any problem in removing from the draft those mechanisms that we
>>> envision they won't be used.
>>>
>>> /Miguel
>>>
>>> On 10/08/2013 1:28, Hadriel Kaplan wrote:
>>>> Wow.  I can kinda understand why they'd say that (interop reasons,
>>>> presumably), but that's a big deal.  The 3 mechanisms are very
>>>> different, with very different architectural and deployment
>>>> implications.  I have a very hard time believing any of us would
>>>> truly implement all three.  In fact, I don't truly believe anyone
>>>> would.
>>>>
>>>> So... I hate to do this, but can the authors summarize the history
>>>> of how we got 3 mechanisms to begin with, and who would really
>>>> implement them all?
>>>>
>>>> Or to put it another way, instead of specifying all 3, would it be
>>>> impossible to take a step back and reconsider the real motivating
>>>> use-case (which as far as I know is 3GPP), and only specify the one
>>>> they need/use?
>>>>
>>>> -hadriel
>>>>
>>>>
>>>> On Aug 9, 2013, at 6:10 PM, Flemming Andreasen
>>>> <[email-masked]>
>>>>   wrote:
>>>>
>>>>
>>>>> Greetings MMUSIC
>>>>>
>>>>> As you can see per the below, the IESG approved the
>>>>> Circuit-Switched Bearers draft for publication, however before
>>>>> doing so, they requested a couple of changes. The resulting
>>>>> approved document can be found at
>>>>> http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-21
>>>>>
>>>>>
>>>>> One of the changes introduced resulted in all 3 correlation
>>>>> mechanisms now being mandatory-to-implement (previously they were
>>>>> not):
>>>>> <quote>
>>>>>     Implementations MUST support the three correlation mechanisms
>>>>>     specified in
>>>>> Section 5.2.3.2, Section 5.2.3.3 and Section 5.2.3.4
>>>>> ,
>>>>>     and SHOULD include all supported mechanisms the initial Offer.
>>>>>
>>>>> </quote>
>>>>> Since this is a non-trivial change that has not been discussed by
>>>>> the WG (and we know of at least one person having expressed
>>>>> concerns with it off-line), we are hereby solicting the WG
>>>>> participants for input on changes introduced as a result of the
>>>>> IESG review with a focus on the above. In doing so, please keep in
>>>>> mind that we are developing standards that work in the general
>>>>> Internet.
>>>>>
>>>>>
>>>>> The following URL provides a diff-file showing the changes
>>>>> resulting from the IESG review:
>>>>>
>>>>> http://tools.ietf.org/rfcdiff?url1=draft-ietf-mmusic-sdp-cs-18.txt&url2=draft-ietf-mmusic-sdp-cs-21.txt
>>>>>
>>>>>
>>>>>
>>>>> Comments are due by August 23 (two weeks from today)
>>>>>
>>>>> Thanks
>>>>>
>>>>> -- Flemming (MMUSIC co-chair)
>>>>>
>>>>>
>>>>>
>>>>> -------- Original Message --------
>>>>> Subject:    [MMUSIC] Protocol Action: 'Session Description Protocol
>>>>> (SDP) Extension For Setting Audio and Video Media Streams Over
>>>>> Circuit-Switched Bearers In The Public Switched Telephone Network
>>>>> (PSTN)' to Proposed Standard (draft-ietf-mmusic-sdp-cs-21.txt)
>>>>> Date:    Mon, 1 Jul 2013 11:56:23 -0700
>>>>> From:    The IESG
>>>>> <[email-masked]>
>>>>>
>>>>> To:    IETF-Announce
>>>>> <[email-masked]>
>>>>>
>>>>> CC:    mmusic chair
>>>>> <[email-masked]>, mmusic mailing list
>>>>> <[email-masked]>, RFC Editor <[email-masked]>
>>>>>
>>>>>
>>>>> The IESG has approved the following document:
>>>>> - '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-21.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 Richard Barnes.
>>>>>
>>>>> 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
>>>>> _______________________________________________
>>>>> mmusic mailing list
>>>>>
>>>>>
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>>
>>>>>
>>>>> .
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> mmusic mailing list
>>>>>
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>> _______________________________________________
>>>> mmusic mailing list
>>>>
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>
>>>>
>>>>
>>>
>>> -- 
>>> Miguel A. Garcia
>>> +34-91-339-3608
>>> Ericsson Spain
>>>
>>
>> _______________________________________________
>> 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, 04 Sep 2013 11:30:07 -0400

Gonzalo,

Interesting. I didn't realize that 3gpp didn't intend to use *any* of 
the correlation mechanisms!

Can you summarize the discussion that led to the request to make all the 
mechanisms mandatory?

ISTM that in many cases where this is used the two endpoints already 
know about each other enough to decide in advance which correlation 
mechanism, if any, to use. (Obviously they at least need to know that 
they both support the basic mechanism.) In such cases its not necessary 
for them to support multiple mechanisms.

The importance of supporting them all comes when the end making the 
request must choose a mechanism without knowing what the other end 
supports. Its not clear to me if that is an interesting use case. (For 
that matter, I'm not sure if there is *any* important use case beyond 
the one planned in 3gpp.)

Maybe some better explanation in the draft would help with this.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 5 Sep 2013 16:37:47 +0000

Hi,

The draft defines a mechanism to indicate which mechanisms (if any) one support, using an SDP attribute.

And, as Paul said, in many cases endpoints may know which mechanism(s) are used without any indication.

So, I don't understand why one should have to support every mechanism. It is not how we normally make protocols...

Regards,,

Christer

Sent from Windows using TouchDown (www.nitrodesk.com)

-----Original Message-----
From: Paul Kyzivat [[email-masked]]
To: Gonzalo Camarillo [[email-masked]]
CC: [email-masked] [[email-masked]]
Subject: Re: [MMUSIC] Comments on IESG Changes in the -cs draft ? [Fwd: Protocol Action: &apos;Session Description Protocol (SDP) Extension For Setting Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)&apos; to Pr...
Gonzalo,

        Thanks,
        Paul

---

From: Atle Monrad <[email-masked]>
Date: Tue, 17 Sep 2013 22:26:41 +0000

All

With the clarifications described in this thread, would it be possible to e.g. revert the changes done at IESG that mandates all the correlation mechanisms?

My rationale for this approach is that his may be the fastest way to completion. This seems also like the easiest approach for 3GPP - possible the only user of the draft.

As it must be assumed that there  are implementations in the field, my fear is that this can re-open old discussions or throw the draft into longer academic discussions.

A timely completion of this draft would be appreciated. May I ask if the authors have some idea when to come to a decision on this topic?

Thanks
/atle

________________________________

Atle Monrad
3GPP CT Chairman

Group Function Technology - Standardization and Technical Regulation
Ericsson

From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 5. september 2013 18:38
To: Paul Kyzivat; Gonzalo Camarillo
Cc: mmusic_ietf.org
Subject: Re: [MMUSIC] Comments on IESG Changes in the -cs draft ? [Fwd: Protocol Action: 'Session Description Protocol (SDP) Extension For Setting Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)' to Pr...

Hi,

Regards,,

Christer

Sent from Windows using TouchDown (www.nitrodesk.com<http://www.nitrodesk.com>)

-----Original Message-----
From: Paul Kyzivat [[email-masked]]
To: Gonzalo Camarillo [[email-masked]]
CC: [email-masked]<mailto:[email-masked]> [[email-masked]]
Subject: Re: [MMUSIC] Comments on IESG Changes in the -cs draft ? [Fwd: Protocol Action: &apos;Session Description Protocol (SDP) Extension For Setting Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)&apos; to Pr...
Gonzalo,

        Thanks,
        Paul

On 9/4/13 10:45 AM, Gonzalo Camarillo wrote:
>>> <[email-masked]<mailto:[email-masked]>> wrote:
>>>
>>>> Hi Hadriel:
>>>>
>>>>> <[email-masked]<mailto:[email-masked]>>
>>>>>    wrote:
>>>>>
>>>>>
>>>>>> Greetings MMUSIC
>>>>>>
>>>>>> <[email-masked]<mailto:[email-masked]>>
>>>>>>
>>>>>> To:    IETF-Announce
>>>>>> <[email-masked]<mailto:[email-masked]>>
>>>>>>
>>>>>> CC:    mmusic chair
>>>>>> <[email-masked]<mailto:[email-masked]>>, mmusic mailing list
>>>>>> <[email-masked]<mailto:[email-masked]>>, RFC Editor <[email-masked]<mailto:[email-masked]>>
>>>>>>
>>>>>>
>>>>>> [email-masked]<mailto:[email-masked]>
>>>>>> [email-masked]<mailto:[email-masked]>
>>>>> [email-masked]<mailto:[email-masked]>
>>> [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>

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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 18 Sep 2013 12:08:01 +0000

Hi,

I think it is important to remember that the question is not only about whether an entity must support something or not.

The main issue, in my opinion, is that it also has impacts on the SIP/SDP messages. The draft now says that entities MUST insert the SDP attribute used to indicate the mechanisms. But, if current implementations don't support any mechanism, they obviously won't insert the SDP attribute (as previously the attribute was only inserted if any mechanism(s) was supported).

Regards,

Christer

From: Atle Monrad
Sent: 18. syyskuuta 2013 1:27
To: Christer Holmberg; Paul Kyzivat; Gonzalo Camarillo
Cc: mmusic_ietf.org
Subject: RE: [MMUSIC] Comments on IESG Changes in the -cs draft ? [Fwd: Protocol Action: 'Session Description Protocol (SDP) Extension For Setting Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)' to Pr...

All

Thanks
/atle

Atle Monrad
3GPP CT Chairman

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 5. september 2013 18:38
To: Paul Kyzivat; Gonzalo Camarillo
Cc: mmusic_ietf.org
Subject: Re: [MMUSIC] Comments on IESG Changes in the -cs draft ? [Fwd: Protocol Action: 'Session Description Protocol (SDP) Extension For Setting Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)' to Pr...

Hi,

Regards,,

Christer

-----Original Message-----
From: Paul Kyzivat [[email-masked]]
To: Gonzalo Camarillo [[email-masked]]
CC: [email-masked]<mailto:[email-masked]> [[email-masked]]
Subject: Re: [MMUSIC] Comments on IESG Changes in the -cs draft ? [Fwd: Protocol Action: &apos;Session Description Protocol (SDP) Extension For Setting Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)&apos; to Pr...
Gonzalo,

        Thanks,
        Paul

---

From: Christian Groves <[email-masked]>
Date: Thu, 19 Sep 2013 22:22:00 +1000

FYI, I was looking at the IANA registry for SDP parameters ( 
http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml) and 
noticed that there was a registration for addrtype E164 linked to this 
CS draft.

There's a problem that there's already an addrtype E164 in RFC3108. This 
earlier usage of E164 should have been registered with IANA but seems to 
have been missed. To complicate things the format of the RFC3108 E164 
addrtype is different to the one in the CS draft.

I've already raised this with IANA but I thought it would be worth 
mentioning in MMUSIC.

Christian

On 2/07/2013 4:56 AM, The IESG wrote:
> This document is the product of the Multiparty Multimedia Session Control
> Working Group.
>
> 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
> and whether to align this with the existing definition in RFC 3108. The
> 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
> draft is a dependency for 3GPP, so future implementations are expected.
>
> resulted in changes to the detailed specification. The document has been