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 Propo

[Atle Monrad <[e-mail]>]

Folks

I'd like to support Andrew on this topic.

I don't know if bundling these attributes together in one draft was done just for convenience or of there are other reasons. What is clear is that these three attributes were not related initially.

3GPP has no use of all attributes as explained by Andrew. I hope that this late change can be reverted (or modified in a less radical way) and the draft completed soon.

3GPP has been waiting for completion of this draft for long now. I think we can assume that there are implementations in the field, thus these last minute changes may cause problems.

Please also consider that the 3GPP-feature using this draft is "IMS Centralized Service Control". This feature is part of 3GPP Rel-8, a release that was completed from 3GPP point if view by June 2008.

Thanks
/atle

________________________________


Atle Monrad
3GPP CT Chairman

Group Function Technology - Standardization and Technical Regulation
Ericsson


From: [e-mail] [mailto:[e-mail]] On Behalf Of Andrew Allen
Sent: 21. august 2013 19:31
To: Flemming Andreasen; mmusic
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 Propo


In my view since including all the correlation attributes in the SDP is a SHOULD strength implementing all the correlation attributes should  also be of SHOULD strength or at most MUST implement except when it is known that a particular correlation mechanism will work for the deployment scenario that  circuit-switched bearer is used. It seems to me kind of silly to have a MUST implement (but might not ever try and use requirement).



To my knowledge 3GPP are currently the only party interested in using this draft. To publish this draft with mandatory aspects which are not needed and not acceptable to 3GPP application will in my view be a mistake and result in an RFC that will either not be implemented or will not be implemented as written because the overhead of implementing the DTMF and UUI correlation mechanisms is not justified and since these are not needed in the 3GPP use case and will not work with the 3GPP architecture either.



In the 3GPP application of this draft the negotiation of the circuit-switched bearer does not take place end to end between the terminals but instead between the terminal and an IMS network infrastructure component (the SCC AS) that acts as B2BUA and the CS call is then interworked to SIP and patched in with the session with the remote party. In addition the E.164 number provided by the IMS network infrastructure component is unique for that circuit-switched bearer setup so no additional correlation mechanism is really needed. The Mobile terminal always acts as the active party in establishing the circuit switched bearer in the 3GPP scenario.



Mandating the callerid mechanism for correlation is acceptable to me since it basically has no impact on the mobile terminal or the IMS network infrastructure component except the inclusion of the cs-correlation attribute and the inclusion of that by the interworking MSC in the P-Asserted-Identity (which is already done). It may have the advantage that now the IMS network infrastructure component does not have to allocate a unique E.164 number for each session but could just use the callerid for the correlation. I think this also does mean that the SCC AS can then be sure that the CS session setup is coming from the terminal  that was negotiated it in the O/A exchange and not some attacker trying to hijack sessions using as the dialed number an E.164 number that was previously assigned to him. Also since in the 3GPP scenario the circuit-switched network is local to and under the control of the operator the callerid mechanism can be guaranteed to work.



The DTMF and UUI mechanisms are quite intensive to implement and both have issues for the 3GPP application. DTMF will result in a delay in the setup end to end of the media and also would require media to be routed to the IMS network infrastructure component (which is only a signaling B2BUA) and force it to have to support  DTMF tone detection. UUI will almost certainly not work as most operators switchers do not pass this information and also would require support for the CUSS UUI mechanisms to deliver the UUI in SIP from the interworking switch to the SCC AS.


I am not against the end to end use of CS SDP but I think it does have some issues such as the cost of long distance or even international circuit switched bearers when the only leg that is a problem is the access for one mobile user. Also a device that needs to use circuit switched bearers cannot do so with those device that don't also support CS SDP or that also have access to a circuit-switched connection. So I don't think the correlation issues with end to end use are the primary obstacles to successful interoperability. One way to address the interoperability issues is an architecture like 3GPP's where the circuit-switched bearer is negotiated between the device and an interworking function at the edge of the network which is where the quality problem exists in the first place not to set up a CS call end to end.

In my view it is not the end of the world if in some scenarios the user has to manually accept the circuit switched bearer and patch it into the multimedia session. In fact there may be some really valid use cases where the device that receives the CS setup is not the same device that negotiated the CS session using SDP. Think of a webex type conference where you connect into a conference using SIP and then get the conference bridge to call you back with a PSTN call to your POTS phone - Manual acceptance seems fine to me in this case and automatic correlation will not work. Similarly an internet  gaming session established using SIP might call the user back at his POTS line for audio conversations associated with the game.


One possibility is to state in the draft that if you cannot confirm that the CS call is part of the session negotiated using SDP using a correlation mechanism or some other means you MUST NOT accept the CS bearer as part of the session without manual user acceptance.

I am Ok for the callerid correlation mechanism to be made mandatory to implement. I think this is the mechanism with the least burden for implementations and also the one most likely to work. I do not agree that the DTMF and the UUI should be mandatory to implement.

I also think it should be realized that implementations may only support one direction for the CS call establishment and that the endpoints only need to support the aspects of the correlation mechanism for the direction(s) they support. Also some users might also not wish to be a passive party (such as when calling party pays for example when cellular roaming) even if they have the capability to do so. Thus some implementations may only support the aspects of the correlation mechanism for the direction (active or passive) that they support.

Andrew

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Flemming Andreasen
Sent: Friday, August 09, 2013 6:10 PM
To: mmusic
Subject: [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 Propos...

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<http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-21#section-5.2.3.2>, Section 5.2.3.3<http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-21#section-5.2.3.3> and Section 5.2.3.4<http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-21#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]><mailto:[e-mail]>

To:

IETF-Announce <[e-mail]><mailto:[e-mail]>

CC:

mmusic chair <[e-mail]><mailto:[e-mail]>, mmusic mailing list <[e-mail]><mailto:[e-mail]>, RFC Editor <[e-mail]><mailto:[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]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/mmusic

.




---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.