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

[Paul Kyzivat <[e-mail]>]

On 2/4/14 2:18 AM, [e-mail] wrote:
>
>
> -----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.

Not necessarily. I was just trying to sort out the expectations for the 
timing of the events. The answer could be *before* the 200, but it must 
be before the call is established.

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

Sure, but my question is whether correlation is expected to occur before 
or after the INVITE completes.

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

I should have been clearer. For DTMF and external correlation media 
clearly needs to flow on the CS call. My question pertains to whether 
this is considered part of the SIP session prior to correlation.

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

external correlation via also has this problem, and more.

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

I'm finding external correlation to be underspecified.

One one I could conceive of it working is that the incoming CS call is 
treated something like a call waiting situation. The existing (sip) call 
is "suspended" and the user is connected to the CS call, and asked to 
confirm if it is the intended one. If the user signals confirmation, 
then the sip call is resumed, with the CS audio stream in it.

If the external correlation fails, then the sip call is resumed without 
the CS media.

A problem with this is that the O/A completes prior to the CS call 
establishment and correlation. If this happens mid-call (because of a 
desire to switch from RTP to CS media) then the RTP media will be 
abandoned once the O/A succeeds, before correlation. So while waiting 
for a CS call to arrive and be correlated you have no RTP media. :-(

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

For DTMF, the correlation could be done *before* relating the CS call to 
the session. Only bind it to the session after correlation is complete.

But that doesn't work as well for external correlation.

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

The user has to receive (hear) the media (and maybe send some too) 
before he can decide on correlation. Has the CS call be "related to the 
session" then, or not?

What happens if the user decides the CS call *isn't* 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.

Yes, it is not entirely unique, but usually updated O/As are done with 
an option in common to the prior one so that failure is unlikely. The 
failure modes are quite different when transitioning from RTP to CS. 
(And also when transitioning from CS to RTP.)

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

Upon rereading section 5.6.2 I realize that it does say that the answer 
must be received before the CS call is placed and correlated, so it 
implies a break-before-make approach on reINVITE.

What I still think is missing is:

* explanation of how things work when changing media mid call - from RTP 
to CS, CS to RTP, or even CS to different CS. Point out that this is 
break-before-make, and when the user will again perceive to have media.

* much about external correlation. Is this really a mechanism in the 
sense that the others are, that serves as a screen on CS calls until the 
one is found that correlates? Or does it really mean that any incoming 
CS call is taking as the right one, included in the sip session, with 
the user left to take independent action (such as hanging up) if he 
decides it isn't the right one?

* For DTMF correlation, does the user see media in the call before the 
correlation is successfully completed.

* potentially (but maybe not in this draft) a discussion of how to 
achieve make-before-break semantics. (E.g., Using multiple m-lines.)

	Thanks,
	Paul

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