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

[Paul Kyzivat <[e-mail]>]

I just reviewed the new version. First I looked at just the diffs. But 
those raised some more general questions in my mind, so I re-reviewed 
more of the draft. I'm left with some considerable confusion about how 
this is intended to work in practice, especially with extern 
correlation, but even with the other forms.

In particular, I am unclear of the sequencing of O/A processing, 
correlation processing, and signaling completion. (I realize this is an 
mmusic draft and theoretically independent of sip, but forgive me if I 
discuss this in the context of sip.)

Normally, when first establishing a session with sip, the first O/A may 
occur before the signaling session is established. But early media may 
flow after the first O/A. Often it is expected that the user will be be 
aware and involved in this early media.

Once a session is up, it can be changed with a reinvite containing a new 
O/A. If the O/A and the reinvite are successful, then the results of the 
new O/A replace the old one. If the reinvite fails, then the session is 
supposed to continue as it was before the reinvite. In the interim, from 
the sending of the reinvite until its success or failure, things are a 
little confusing - presumably both old and new media streams must be 
maintained, but which are connected to the user is unspecified.

I see nothing in this draft that explains how the CS media, and 
correlation verification, fit into the above process.

Consider a new call that offers CS media:

- The first O/A must complete before the CS call can be attempted.

- must the CS call complete and be correlated successfully before
   the INVITE gets a 200? If the invite is allowed to complete first,
   what happens if no CS call is established, or if it is but
   correlation fails?

- when does CS media start to flow to the user as part of the
   SIP call? Is it before or after correlation? (E.g., does the
   user hear the DTMF exchange?)

- if media flows to the user before correlation, then what if
   correlation fails? Will another call be accepted and correlation
   be attempted again?

- what if multiple incoming calls arrive before correlation
   has been completed? (If correlation occurs before exposing the
   media to the user, then it isn't an issue.)

- extern correlation complicates this. It isn't like the other
   correlation mechanisms - the user must be exposed to the media
   to decide if there is correlation. How would the user indicate
   "this is the wrong call" in a way that would allow correlation
   to be attempted on another call?

Now consider a call that is initially established with one RTP media 
stream. Later, a reinvite is sent with an offer proposing to to replace 
that with a CS media stream:

- again, there must be an answer before the CS call can be attempted.

- are you assuming that the reinvite will complete before the CS
   call does? If so, then you are in a break-before-make situation -
   the RTP session is gone before the CS session takes its place.

- all the issues above also apply here.

ISTM that there is a bunch of missing explanation of how this is 
expected to work.

I also have a nit in section 5.3.2:

    The fourth correlation mechanism declares support for cases where
    correlation is done by external means.  Typically this means that the
    decision is left for the human user.  This is the way how some
    current conferencing systems operate: ...

"This is the way how some current conferencing systems operate"

should be:

"This is how some current conferencing systems operate"

	Thanks,
	Paul

On 1/31/14 6:01 AM, [e-mail] wrote:
> Hello WG,
>
> We have submitted a new version of http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-22
>
> To recap, there was discussion on the  MMUSIC WG list on which correlation mechanisms should be mandatory to implement (see Gonzalo's email http://www.ietf.org/mail-archive/web/mmusic/current/msg12274.html ). As stated by Gonzalo, 3GPP is going to use this draft, more specifically the plan now is to use the caller id based correlation mechanism. This was the message I got from Andrew after a recent 3GPP CT1 meeting.
>
> We have now made the following changes to the draft:
> -	the endpoint may choose which correlation mechanisms to implement (before all three were MTI).
> -	we have introduced a fourth correlation type ("external") which indicates explicit support for cases where also some external means, typically the human user, can do the correlation. This can be as a fallback in cases where no other common correlation mechanism is found, or the negotiated correlation mechanisms fail due to being not supported in the PSTN network. This is much like current systems like Webex work.
>
> This was also the guidance from the IESG informal telechat in December where Gonzalo presented the draft.
>
> We would like to hear from the WG whether there are any concerns with these changes.
>
> On behalf of the authors,
> Simo
>
> PS. I'll add the proposed change in http://www.ietf.org/mail-archive/web/mmusic/current/msg12792.html to next version, slipped my mind this time.
>
>
> -----Original Message-----
> From: mmusic [mailto:[e-mail]] On Behalf Of ext [e-mail]
> Sent: 31 January, 2014 12:25
> To: [e-mail]
> Cc: [e-mail]
> Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-22.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 Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)
>          Authors         : Miguel A. Garcia-Martin
>                            Simo Veikkolainen
> 	Filename        : draft-ietf-mmusic-sdp-cs-22.txt
> 	Pages           : 37
> 	Date            : 2014-01-31
>
> Abstract:
>     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).
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-22
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-cs-22
>
>
> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>