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

[<[e-mail]>]

-----Original Message-----
From: ext Paul Kyzivat [mailto:[e-mail]] 
Sent: 10 February, 2014 17:49
To: Veikkolainen Simo (Nokia-CTO/Espoo); [e-mail]
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-22.txt

Simo,

What you describe below is enough to get me to shut up. :-)

On 2/10/14 5:44 AM, [e-mail] wrote:
> Hello Paul, all,
>
> I've copied the bullets from your email below, and propose the following text to address your concerns:
>
> * 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.
>
> -> Add in 5.6.4. Modifying the session
>
> If either party would like to remove existing RTP based media from the session and replace that with a circuit-switched bearer, it would create a new Offer to add the circuit-switched media as described in Section 5.6.1. above, and remove the RTP based media by setting the port number to zero. Once the Offer/Answer exchange is done, but the circuit-switched bearer is not yet established, there may be a period of time when no media is available. Also, it may happen that correlating the circuit-switched call fails for reasons discussed in Section 5.3.3. In this case, even if the Offer/Answer exchange was successful, endpoints are not able to receive or send media. It is up to the implementation to decide the behavior in this case; if nothing else is done, the user most likely hangs up after a while if there was no other media in the session. Note that this may also happen when switching from RTP media to another RTP media (for example when firewall blocks the new media strea!
 m).

I find it interesting that you describe adding a new m-line for the cs session and rejecting the old one. It should also be valid to simply replace the old (rtp) m-line with the new (cs) m-line.

[SV] This was actually something I was supposed to check before updating the draft text, as I wasn't quite sure whether the old media description should be explicitly rejected first and the new one added. But, as you say, it should be enough to simply replace the old m-line with the new m-line.

If you are thinking of using two m-lines, then make-before-break is just a matter of keeping them both active for awhile.

[SV] That is also possible, though in this case you would receive two media streams for a while (typically, two audio streams from the same source). But of course, implementations could be clever enough to suppress the other until cut-over is done. 

Simo

	Thanks,
	Paul

> If either party would like to remove existing circuit-switched media from the session and replace that with RTP based media, it would create a new Offer and set the circuit-switched port number to zero, and add a description for RTP based media. The endpoint MUST then terminate the circuit-switched bearer using whatever mechanism is appropriate for the technology in question.
>
> * 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?
>
> -> add in 5.2.3.5. The External correlation mechanism
>
> The external correlation mechanism relies on the human user to do the decision on whether the call is related to the ongoing session or not. After the user accepts the call, that bearer is considered as related to the session. There is a small chance that the user receives at the same time another circuit-switched call which is not related to the ongoing session. The user may reject this call if he is able to determine (e.g. based on the calling line identification) that the call is not related to the session, and continue waiting for another call attempt. If the user accepts the incoming circuit-switched call, but it turns out to be not related to the session, the endpoints need to rely on the human user to take appropriate action (typically, they would hang up).
>
> * For DTMF correlation, does the user see media in the call before the correlation is successfully completed.
>
> I think this is an implementation specific matter. We could add a recommendation of some sorts, but really it is up to the implementation to decide.
>
> * potentially (but maybe not in this draft) a discussion of how to 
> achieve make-before-break semantics. (E.g., Using multiple m-lines.)
>
> This seems to be a larger issue which is not specific to circuit-switched media alone, to probably it would be best to address it in a standalone document.
>
> Regards,
> Simo
>
> -----Original Message-----
> From: mmusic [mailto:[e-mail]] On Behalf Of 
> Veikkolainen Simo (Nokia-CTO/Espoo)
> Sent: 07 February, 2014 10:38
> To: [e-mail]; [e-mail]
> Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-22.txt
>
> See below [SV]
>
> -----Original Message-----
> From: ext Paul Kyzivat [mailto:[e-mail]]
> Sent: 05 February, 2014 21:11
> To: Veikkolainen Simo (Nokia-CTO/Espoo); [e-mail]
> Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-cs-22.txt
>
> 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.
>
> [SV] Correlation can only occur after the correlation information has been exchanged, and the CS call is received. I'm not sure what you mean by INVITE being completed, but I would say correlation can be done already before the last request (ACK) has been sent, or after the whole INVITE related request-response exchange has been completed (in case the CS call is received late).
>
>> - 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.
>
> [SV] Again, I'm not sure I'm able to follow your thought but correlation is needed before the CS media is considered as part of the session.
>
>> - 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. :-(
>
> [SV] Ok now I think I see your point. The O/A needs to be completed before correlation can take place. If this happens mid-call, it can indeed happen that the correlation fails and there is no media. On the other hand, there are a number of reasons why the same could happen to RTP based media as well. So, it can either be considered as an call failure case, or the other possibility would be to first add the CS media, and if it succeeds, do another O/A to remove the RTP based media. The drawback in this case is that the endpoints would receive two media streams for a short while.
>
>> - 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.
>
> [SV] For both DTMF and external, the CS call needs to be accepted first, but when using DTMF it is possible (and advisable) to not play back the media to the user until correlation has been done. For external case, the media would need to be played back .
>
>> - 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?
>
> [SV] From a protocol point of view, I would say the call is considered as related to the session if the user accepts the call. But, you're right that the user cannot be really sure before some words are exchanged on the CS call.
>
> What happens if the user decides the CS call *isn't* correlated?
>
> [SV] The user would likely hang up.
>
>> 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.)
>
> [SV] Agreed, adding a CS call introduces an additional level of uncertainty.
>
>> - 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.)
>
> [SV] I need to go through these with more thought with my co-author. We'll get back to this.
>
> Thanks
> Simo
>
> 	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
>>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>