Subject: [MEDIACTRL] Fallback video content in msc-ivr/1.0

From: Jean-François Bertrand <[email-masked]>
Date: Tue, 04 Nov 2008 15:44:23 -0500

Is it possible to implement a fallback video content in msc-ivr/1.0 in a
similar fashion as in VoiceXML(see
http://www.voicexml.org/Review/Mar2006/features/video_interactive_services.html by Burke/McGlashan)?

Exurb:

   "Within the <audio> element, fallback content can be specified; for 
    example, 

      <audio src=”http://www.example.com/myvideo.3gp”>
          <audio src=”http://www.example.com/standardvideo.3gp”/>
      </audio>

    If “myvideo.3gp” cannot be found or played, then the fallback video
    “standardvideo.3gp” is played."

With this approach, it is possible to avoid codec renegotiating when the
video format of the preferred file does not match the negotiated video
codec.  

In short, would a construct like below be supported in msc-ivr/1.0?

   <mscivr version="1.0" xmlns="urn:ietf:params:xml:ns:msc-ivr">
    <dialogstart>
     <dialog>
      <prompt>
       <media loc="http://www.example.com/hires-welcome.3gp">
         <media loc="http://www.example.com/standard-welcome.3gp">
           <media loc="http://www.example.com/welcome.wav"/>
         </media>
       </media>
      </prompt>
     </dialog>
   </mscivr>

thanks

Jean-François Bertrand, ing.
Sr. Software Designer
BroadSoft, Inc. 
Montreal, Qc, Canada

_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: "McGlashan, Scott" <[email-masked]>
Date: Mon, 10 Nov 2008 17:35:02 +0000

I would like to know if others in the working group would like to see this change.

Assuming the SIP AS operates in B2B mode, it should know the codecs supported by the MS. It can also use the <audit> operation to discover the supported playback MIME media types. However, there are still cases where playback could fail: the MS is unable to play the media on the transport codec due mismatch (e.g. bitrate) or lack of transcode support (e.g. playing h264 file on h263 codec), or an error in the playback data. Or even if retrieval of the resource fails. In these cases, use of fallback content could be successful. In the mediaCtrl solution, I think one difference with VoiceXML should be that if a <media> element (including fallback <media>) cannot be played, then the MS raises an error. VoiceXML 2.1 simply ignores media playback error - which can lead to problems if the app developer thinks that a prompt has been played to the user  ....

Thoughts?

Scott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jean-François Bertrand
Sent: Tuesday, November 04, 2008 21:44
To: [email-masked]
Subject: [MEDIACTRL] Fallback video content in msc-ivr/1.0

Is it possible to implement a fallback video content in msc-ivr/1.0 in a similar fashion as in VoiceXML(see http://www.voicexml.org/Review/Mar2006/features/video_interactive_services.html by Burke/McGlashan)?

Exurb:

      <audio src="http://www.example.com/myvideo.3gp">
          <audio src="http://www.example.com/standardvideo.3gp"/>
      </audio>

    If "myvideo.3gp" cannot be found or played, then the fallback video
    "standardvideo.3gp" is played."

With this approach, it is possible to avoid codec renegotiating when the video format of the preferred file does not match the negotiated video codec.

thanks

---

From: Lorenzo Miniero <[email-masked]>
Date: Mon, 10 Nov 2008 18:55:08 +0100

I think this may safely remain part of the business logic... you try a  
prompt and it fails: the event raised by the MS tells you what went  
wrong (e.g. unsupported format, or unretrievable resource) and you  
react accordingly, maybe by trying a different prompt if the  
unsupported format was the case. This would do exactly what a fallback  
option would allow, but with the logic behind it as part of the  
application in the AS.

Adding this feature now, might add further similar requests (e.g. "why  
can't I add a default error prompt if my collect failed?"), which  
could easily eventually drive us into a rat hole :)

My two cents,
L.

Quoting "McGlashan, Scott" <[email-masked]>:

> Assuming the SIP AS operates in B2B mode, it should know the codecs   
> supported by the MS. It can also use the <audit> operation to   
> discover the supported playback MIME media types. However, there are  
>  still cases where playback could fail: the MS is unable to play the  
>  media on the transport codec due mismatch (e.g. bitrate) or lack of  
>  transcode support (e.g. playing h264 file on h263 codec), or an   
> error in the playback data. Or even if retrieval of the resource   
> fails. In these cases, use of fallback content could be successful.   
> In the mediaCtrl solution, I think one difference with VoiceXML   
> should be that if a <media> element (including fallback <media>)   
> cannot be played, then the MS raises an error. VoiceXML 2.1 simply   
> ignores media playback error - which can lead to problems if the app  
>  developer thinks that a prompt has been played to the user  ....
>
> Thoughts?
>
> Scott
>
>
>
> Is it possible to implement a fallback video content in msc-ivr/1.0   
> in a similar fashion as in VoiceXML(see   
> With this approach, it is possible to avoid codec renegotiating when  
>  the video format of the preferred file does not match the  
> negotiated  video codec.
>

-- 
Lorenzo Miniero, Junior Researcher
Dipartimento di Informatica e Sistemistica
Universita' degli Studi di Napoli "Federico II"
Via Claudio 21 -- 80125 Napoli (Italy)
Phone: +390817683821 - Fax: +390817683816
Email: [email-masked]
_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: "Chris Boulton" <[email-masked]>
Date: Tue, 11 Nov 2008 09:21:25 -0000

I agree with Lorenzo on this one.  As long as the feedback is appropriate then this can easily be achieved and remains in the applications control.

Chris.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lorenzo Miniero
Sent: 10 November 2008 17:55
To: McGlashan, Scott
Cc: Jean-François Bertrand; [email-masked]
Subject: Re: [MEDIACTRL] Fallback video content in msc-ivr/1.0

My two cents,
L.

---

From: "Stephane Bastien" <[email-masked]>
Date: Tue, 11 Nov 2008 08:29:43 -0500

Hi,

This implies that the application layer must closely monitor the SDP and 'guess' the negotiated codec, which can change as the call evolves (e.g., video-capable mobile phone transfers a call to a desktop video phone, resulting in a SIP reINVITE that renegotiates codecs).

We usually try to isolate the application layer from such low-level complexity, which should be handled by the Media Server.

Stephane

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Chris Boulton
Sent: 11 novembre 2008 04:21
To: Lorenzo Miniero; McGlashan, Scott
Cc: Jean-Francois Bertrand; [email-masked]
Subject: Re: [MEDIACTRL] Fallback video content in msc-ivr/1.0

Chris.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lorenzo Miniero
Sent: 10 November 2008 17:55
To: McGlashan, Scott
Cc: Jean-François Bertrand; [email-masked]
Subject: Re: [MEDIACTRL] Fallback video content in msc-ivr/1.0

My two cents,
L.

---

From: Eric Burger <[email-masked]>
Date: Wed, 12 Nov 2008 18:25:10 -0800

And I would offer no one writes the code to check.

On Nov 11, 2008, at 5:29 AM, Stephane Bastien wrote:

> Hi,
>
> This implies that the application layer must closely monitor the SDP  
> and 'guess' the negotiated codec, which can change as the call  
> evolves (e.g., video-capable mobile phone transfers a call to a  
> desktop video phone, resulting in a SIP reINVITE that renegotiates  
> codecs).
>
> We usually try to isolate the application layer from such low-level  
> complexity, which should be handled by the Media Server.
>
> Stephane
>
> I agree with Lorenzo on this one.  As long as the feedback is  
> appropriate then this can easily be achieved and remains in the  
> applications control.
>
> Chris.
>
>
>> http://www.voicexml.org/Review/Mar2006/features/video_interactive_services.html 
>>  by
>> Burke/McGlashan)?
>>
>> Exurb:
>>

---

From: "Chris Boulton" <[email-masked]>
Date: Thu, 13 Nov 2008 09:26:04 -0000

[Chris Boulton] OK - I apologize in advance if I am off track.  I am assuming a scenario where:

- App server attempts a simple 'play prompt'.
- The play prompt fails with the appropriate error response/event (something like a 429?) as it doesn't support the media type extension.

Eric - are you saying that people don't write code to catch this?  I would offer that in my experience people have been writing code to catch such scenarios and do not just assume that the prompt succeeded.

Chris.

---

From: "Stephane Bastien" <[email-masked]>
Date: Thu, 13 Nov 2008 08:29:09 -0500

In the past, I found that over half of applications that use IVR services handle errors reported by a Media Server by hanging-up the call. Looking at the error code, parsing the SDP to find a better codec, and trying another play command requires too much development effort for the gain in functionality.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Chris Boulton
Sent: 13 novembre 2008 04:26
To: Eric Burger; [email-masked]
Subject: Re: [MEDIACTRL] Fallback video content in msc-ivr/1.0

Chris.

---

From: "eburger" <[email-masked]>
Date: Thu, 13 Nov 2008 13:39:17 +0000

Guys - consider this a RARE occasion, when Stéphane and I agree. 

Do we want to specify a bunch of complexity that no one will use? Putting this into the spec means you will have to write a bunch of error prone code, to which the client writes code like: 
   if( media_service(foo) ) ... 
or 
   (void)media_service(foo)

Why waste your time?

In fact, normally in the IETF we whine that our product managers don't want to implement a corrected standard. Before you say we need this rich error handling capability, ask your product manager if they will pay your engineering to actually implement what you spec here. If they say yes, it is your money and time, so I would consider sanctioning the work. However, if they say no, please don't consume Work Group resources on this. 

--
Eric Burger

Sent from my mobile device; sorry if terse. All mobile users need lemonade.  See <http://www.standardstrack.com/ietf/lemonade> for more information.

-----Original Message-----
From: "Stephane Bastien" <[email-masked]>

Date: Thu, 13 Nov 2008 08:29:09 
To: Chris Boulton<[email-masked]>; Eric Burger<[email-masked]>; <[email-masked]>
Subject: RE: [MEDIACTRL] Fallback video content in msc-ivr/1.0

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Chris Boulton
Sent: 13 novembre 2008 04:26
To: Eric Burger; [email-masked]
Subject: Re: [MEDIACTRL] Fallback video content in msc-ivr/1.0

Chris.

---

From: "Chris Boulton" <[email-masked]>
Date: Thu, 13 Nov 2008 15:25:54 -0000

Just to make my position clear - I am not against adding this - I just want to make sure that we are not feature creeping.  If the guys who are implementing this currently think its useful then that sways my feelings (Chris with splinters from sitting on the fence :-).

Chris.

-----Original Message-----
From: eburger [mailto:[email-masked]] 
Sent: 13 November 2008 13:39
To: Stephane Bastien; Chris Boulton; [email-masked]
Subject: Re: [MEDIACTRL] Fallback video content in msc-ivr/1.0

Why waste your time?

--
Eric Burger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Chris Boulton
Sent: 13 novembre 2008 04:26
To: Eric Burger; [email-masked]
Subject: Re: [MEDIACTRL] Fallback video content in msc-ivr/1.0

Chris.

---

From: James Rafferty <[email-masked]>
Date: Thu, 13 Nov 2008 10:28:19 -0500

Eric,

This product manager DOES ask Engineering to implement standards the new, corrected way, but we usually have to implement the broken version as well, for compatibility purposes.  :-(

On this particular question, I'd say the normal handling gets specified in the document and what to do in case of mismatch errors is left to the implementation.

James

James Rafferty
Product Line Director, Integrated Media Gateways
Dialogic, Inc.
15 Crawford Street
Needham, MA 02494
USA

Tel:    781 433 9462
Mobile: 781 929 3895
Fax:    781 433 9268
Email:  [email-masked]
Web:    www.dialogic.com
This e-mail is intended only for the named recipient(s) and may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. No waiver of privilege, confidence or otherwise is intended by virtue of communication via the internet. Any unauthorized use, dissemination or copying is strictly prohibited. If you have received this e-mail in error, or are not named as a recipient, please immediately notify the sender and destroy all copies of this e-mail.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of eburger
Sent: Thursday, November 13, 2008 8:39 AM
To: Stephane Bastien; Chris Boulton; [email-masked]
Subject: Re: [MEDIACTRL] Fallback video content in msc-ivr/1.0

Why waste your time?

--
Eric Burger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Chris Boulton
Sent: 13 novembre 2008 04:26
To: Eric Burger; [email-masked]
Subject: Re: [MEDIACTRL] Fallback video content in msc-ivr/1.0

Chris.

---

From: Eric Burger <[email-masked]>
Date: Thu, 13 Nov 2008 10:57:42 -0600

I would buy the VoiceXML case of a typo or mis-synchronization with a  
dynamically created object. For example, the object hasn't been  
created yet when the AS asks the MS to render it.

I don't buy the AS tells the MS to render an object, the MS retrieves  
the object and it is in the wrong format, and the AS would then do  
anything other than politely barf. You say, "sorry, I can't do that"  
because the MS just said it failed, versus, "sorry, I can't do that"  
because the MS said that you asked it to play a H.263+ video with a  
GSM codec whilst the MS can only render H.264 with AMR. Either way,  
all apps tend to do is "sorry, I can't do that". Are there any apps  
anywhere that would retry rendering somewhere else?

On Nov 13, 2008, at 3:26 AM, Chris Boulton wrote:

> - The play prompt fails with the appropriate error response/event  
> (something like a 429?) as it doesn't support the media type  
> extension.
>
> Eric - are you saying that people don't write code to catch this?  I  
> would offer that in my experience people have been writing code to  
> catch such scenarios and do not just assume that the prompt succeeded.
>
> Chris.
>
>