[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sip] Moving along with the INFO discussion

I would think it would be advisable for the UAC in this case to provide some sort of feedback to the user that the dtmf isn't working. E.g. instead of playing the dtmf tone to its user, it could play nothing, or some error tone. Would probably hear the normal tone for the first button pressed, but after that, when the UAC has received an error for the INFO, the other behavior would kick in.
This of course doesn't *solve* the problem. But then nothing will short of the UAS supporting the dtfm.
If the UAS doesn't support DTMF, there will be a problem even if the dtmf is sent in the media stream. Probably if telephone-events can't be negotiated the tones will simply be sent in the audio stream, and there will be no feedback if they aren't understood. So almost anything done here will be an improvement. 

	Paul

Sanjay Sinha (sanjsinh) wrote:

I agree, it depends on the use cases and one rule does not apply in all
cases. Another use case is for an IVR system and in that case as well,
where if dtmf usage does not work, there is no point in continuing with
the dialog.
Sanjay 
-----Original Message-----
From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On Behalf Of Eric Burger 
Sent: Wednesday, July 23, 2008 12:45 PM
To: SIP IETF
Subject: Re: [Sip] Moving along with the INFO discussion
In this case, I would offer we have the same, awful user experience. Alice connects to the VM system, and the call is immediately dropped (dialog dies). Alice calls her service provider and says, "Voice Mail is broken." Or, Alice connects to the VM system, and the VM system is totally unresponsive (dialog does not die). Alice calls her phone manufacturer and says, "your phone doesn't work" or calls her service provider and says, "my phone doesn't work."
Now assume your very highly paid customer service rep at the service provider trying to debug the dialog does not die scenario... 

On Jul 15, 2008, at 6:19 PM, Dean Willis wrote:

[snip]
Alice is an INFO sender for DTMF. She's talking to a new voice mail system and starts sending it info-dtmf-relay. The VM doesn't understand, so it 4xxes the INFO. Is Alice better served by
having the
call drop or her DTMF attempt ignored? I suspect here that "ignore", with its potential of a UI indicator to Alice saying "My attempt to send info-dtmf-relay failed", is probably better than the call dropping.
How about the ISUP and QSIG use cases? I'm guessing they would fail typically not with the new 4xx, but with the 415 Unsupported as documented in RFC 3372.
So it looks like you've convinced me; it's better for the
INFO failure 
to NOT drop the dialog or dialog usage.

[snip]
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use sip-implementors at cs.columbia.edu for questions on current sip Use sipping at ietf.org for new developments on the application of sip 


_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip


_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip