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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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
[EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] 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 [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] 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 [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
