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,

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 [pkyzivat@alum.mit.edu]
To: Gonzalo Camarillo [gonzalo.camarillo@ericsson.com]
CC: mmusic@ietf.org [mmusic@ietf.org]
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,

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

On 9/4/13 10:45 AM, Gonzalo Camarillo wrote:
> 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
>>> <Miguel.A.Garcia@ericsson.com> 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
>>>>> <fandreas@cisco.com>
>>>>>    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
>>>>>> <iesg-secretary@ietf.org>
>>>>>>
>>>>>> To:    IETF-Announce
>>>>>> <ietf-announce@ietf.org>
>>>>>>
>>>>>> CC:    mmusic chair
>>>>>> <mmusic-chairs@tools.ietf.org>, mmusic mailing list
>>>>>> <mmusic@ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>
>>>>>>
>>>>>>
>>>>>> 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
>>>>>>
>>>>>>
>>>>>> mmusic@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>>>
>>>>>>
>>>>>> .
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> mmusic mailing list
>>>>>>
>>>>>> mmusic@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>> _______________________________________________
>>>>> mmusic mailing list
>>>>>
>>>>> mmusic@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Miguel A. Garcia
>>>> +34-91-339-3608
>>>> Ericsson Spain
>>>>
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> mmusic@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>
>

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic