[Freeswitch-dev] Exchange 2007 UM - DTMF problem

Mon Jun 30 14:35:00 EDT 2008

Amazing.

We’ve been running around Microsoft RFC4733 incompatibility issue the whole
day after the problem mysteriously disappeared this morning just to find out
that this well-encountered bug is solved on restart…

Yes, FreeSWITCH DTMF problem with Microsoft Exchange 2007 Unified Messaging
Server is solved with a simple server restart (for the Exchange, not the
FS). Go figure…

BTW, we’ve also confirmed that having it start at zero is the whole problem.
But that is not required anymore.

  _____  

From: freeswitch-dev-bounces at lists.freeswitch.org
[mailto:freeswitch-dev-bounces at lists.freeswitch.org] On Behalf Of UV
Sent: Tuesday, July 01, 2008 12:24 AM
To: freeswitch-dev at lists.freeswitch.org
Subject: Re: [Freeswitch-dev] Exchange 2007 UM - DTMF problem

The only way to confirm my hypothesis (which is based on comparative
analysis between working “pass-rfc2833=true” and non-working
“pass-rfc2833=false” scenarios) is to actually change the code and retest
it.

We’ll be testing it later today.

The code will be changed as described in the previous email. Any comments /
recommendations on that?

  _____  

From: freeswitch-dev-bounces at lists.freeswitch.org
[mailto:freeswitch-dev-bounces at lists.freeswitch.org] On Behalf Of Anthony
Minessale
Sent: Tuesday, July 01, 2008 12:01 AM
To: freeswitch-dev at lists.freeswitch.org
Subject: Re: [Freeswitch-dev] Exchange 2007 UM - DTMF problem

Have you confirmed for sure that having it start at zero is the whole
problem?

2008/6/30 UV <uv at talknet.com.au>:

I thought of moving this thread over here.

We're trying to make the FS work with MS Exchange 2007 (in a
non-RFC4733-compliant mode). For this to work, we need to get the Duration
count start from 0 instead of starting from 160 (or any other sample rate).

We assume these are the lines needed to be changed:

>From /src/switch_rtp.c

1042                          rtp_session->dtmf_data.out_digit_sofar =
samples;  

1043                          rtp_session->dtmf_data.out_digit_sub_sofar =
samples;  

To /src/switch_rtp.c

1042                          rtp_session->dtmf_data.out_digit_sofar = 0;  

1043                          rtp_session->dtmf_data.out_digit_sub_sofar =
0;  

Are we missing anything? Are we breaking anything? (except compliancy)

-----Original Message-----
From: freeswitch-users-bounces at lists.freeswitch.org
[mailto:freeswitch-users-bounces at lists.freeswitch.org] On Behalf Of UV
Sent: Sunday, June 29, 2008 7:45 PM
To: freeswitch-users at lists.freeswitch.org
Subject: Re: [Freeswitch-users] Exchange 2007 UM - DTMF problem

Apparently, not only MS do not comply with RFC4733 but also SJphone, Xlite
(eyebeam) and Cisco (Call manager, IP phones, etc) amongst others.

Is there anyway I can make FS's Duration to start from 0? I'm happy to
change the code myself with a little guidance.

-----Original Message-----

From: freeswitch-users-bounces at lists.freeswitch.org

[mailto:freeswitch-users-bounces at lists.freeswitch.org] On Behalf Of Steve

Underwood

Sent: Sunday, June 29, 2008 3:42 PM

To: freeswitch-users at lists.freeswitch.org

Subject: Re: [Freeswitch-users] Exchange 2007 UM - DTMF problem

Hi,

Brian West wrote:

> So if you can tell me where this is wrong as per 2833 and the  

> clarification via 4733 ?

> 

> rfc4733 obsoletes  rfc2833 and says this:

>     The special duration value of zero is reserved to indicate that the

>     event lasts "forever", i.e., is a state and is considered to be

>     effective until updated.  A sender MUST NOT transmit a zero duration

>     for events other than those defined as states.  The receiver SHOULD

>     ignore an event report with zero duration if the event is not a

>     state.

> /b

> PS: http://www.rfc-editor.org/rfc/rfc4733.txt

>   

As well as that definition in RFC4733, they also have an example working 

in the way the text describes. They send DTMF with a packet rate of one 

every 50ms. The first packet of the DTMF sequence contains a duration of 

400.

What does FS actually do when a sequence starts at 0? Does it just drop 

the first packet, or the whole sequence? If it just drops the first 

packet, and the far end cares, that's seriously broken on their part. It 

means a single lost packet screws up the whole sequence. Not good. If FS 

drops the whole sequence, that might be a little too aggressive.

Some will argue that a gateway should be totally transparent in these 

situations, but total transparency is only workable in simplistic cases.

In the end, if MS are doing this you can be sure it will not be fixed, 

and must be tolerated.

Regards,

Steve

_______________________________________________
Freeswitch-dev mailing list
Freeswitch-dev at lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
http://www.freeswitch.org

-- 
Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/

AIM: anthm
MSN:anthony_minessale at hotmail.com
<mailto:MSN%3Aanthony_minessale at hotmail.com> 
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
<mailto:PAYPAL%3Aanthony.minessale at gmail.com> 
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org
<mailto:sip%3A888 at conference.freeswitch.org> 
iax:guest at conference.freeswitch.org/888
googletalk:conf+888 at conference.freeswitch.org
<mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org> 
pstn:213-799-1400 

No virus found in this incoming message.
Checked by AVG.
Version: 8.0.101 / Virus Database: 270.4.3/1525 - Release Date: 29/06/2008
15:09

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20080701/8801f233/attachment-0001.html 