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)]

[Gonzalo Camarillo <[e-mail]>]

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
>> <[e-mail]> 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
>>>> <[e-mail]>
>>>>   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
>>>>> <[e-mail]>
>>>>>
>>>>> To:    IETF-Announce
>>>>> <[e-mail]>
>>>>>
>>>>> CC:    mmusic chair
>>>>> <[e-mail]>, mmusic mailing list
>>>>> <[e-mail]>, RFC Editor <[e-mail]>
>>>>>
>>>>>
>>>>> 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
>>>>>
>>>>>
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>>
>>>>>
>>>>> .
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> mmusic mailing list
>>>>>
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>> _______________________________________________
>>>> mmusic mailing list
>>>>
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>
>>>>
>>>>
>>>
>>> -- 
>>> Miguel A. Garcia
>>> [phone]
>>> Ericsson Spain
>>>
>>
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>