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

[<[e-mail]>]

-----Original Message-----
From: mmusic [mailto:[e-mail]] On Behalf Of ext Paul Kyzivat
Sent: 31 January, 2014 20:53
To: [e-mail]
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-22.txt

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?

[SV] I assume you mean the 200 carries the Answer. It may happen that the CS call arrives before the Answer, but in this case no correlation can be done. See Section 5.6.3. If the invite (I assume you mean O/A) completes first, but no CS call ever arrives, or correlation - including the "external" mechanism fails, the endpoint should treat the CS call as unrelated; this is described in Section 5.3.3.

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

[SV] CS media starts to flow after the call has been accepted, as in a normal CS call. Correlation may be possible before accepting the call (for "callerid", "uuie", and "external" mechanisms), and for "dtmf" case only after the call has been accepted.

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

[SV] I don' think we have explicitly defined this situation. If a call is accepted and *after* that correlation fails, it means that the DTMF mechanism was used (for other correlation mechanisms, we know before accepting the call whether the correlation was successful). If the DTMF pattern is not received correctly, as we cannot know whether it is related to the session or not. Now, this raises a possible case of including both "dtmf" and "external" mechanisms in the O/A. If DTMF is successfully negotiated but it fails, we can't really use the "external" mechanism since the call is already accepted. Implementations could in this case release the CS call and try a new O/A without the DTMF.


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

[SV] This would be an issue for the DTMF case, as there correlation can be only only after accepting the CS call. An unlikely case, but still possible. In this case, one of the CS calls could be related to the session, while other(s) would be normal CS calls. As only one CS call can be handled at a time, others would either wait or be terminated, depending on the callee's supplementary services settings. 

- 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?

[SV] The external correlation mechanism does not assume the media flows before "correlation" is made - if the user decides to accept the incoming call, it is considered as "correlated". 

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.


[SV] For being able to perform correlation, yes, the Answer needs to be received.

- 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.

[SV] The O/A needs to be completed before correlation can be done, but CS call may arrive before Answer. In this case the endpoint should wait until the Answer is received. If the CS call does not succeed, or correlation is unsuccessful, then yes there is no media as the RTP stream has been dropped. But, this could also happen when re-negotiating RTP media types (endpoints are not able to load correct codecs, new IP addr/port does not work etc.) so the situation not be specific to the CS media type.

- all the issues above also apply here.

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

[SV] Could you check the above whether my comments clarify the situation. We can address them in more details in the draft as well once we know where more explanation is needed.

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"

[SV] Fill fix.

Thanks,
Simo

	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
>

_______________________________________________
mmusic mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mmusic