DTMF from Remote Office Not getting 'Heard' 2

[stownsend]

We have an IPOffice 500v1 R8.0(44)
We have two Locations that use the IPO, one Local to the IPO and one connected to that office via VPN.

Our Outbound Carrier is a SIP Provider. They say that our DTMF is in bypass-media mode, meaning the audio and RTP stream (where DTMF lives) is directly embedded inside the packets being sent to their Upstream Carrier. The SIP Lines are configured for DTMF to use RFC2833.

When the Remote Office calls a Conferencing service where they need to enter a conference code and PIN, they have issues with the conferencing service recognizing the Digits they Dialed. Sometimes it repeats digits, sometimes it skips them altogether.

This is very prominent in remote office, though I do not hear of any report of it form the users in the Office where the IPO Exists.

Could this be an issue between the 5610/4610 sets we have and the IPO over the VPN?

Thanks!

 

[intrigrant]

If you have a proper setup then all DTMF digits over IP are send "out of band" which means not as a real dtmf tone but via te sgnalling path.
So check the settings for all ip phones and trunks, on SCN trunks it is on by default and cannot be changed.
In sysmonitor you cansee it happen, if a phone sends a digit it will show a message with "dialled digit (x)".

A simple mind delivers great solutions

 

[stownsend]

A bit more information from the users. It's not the IP 5610 phone sets. It's the Polycom IP 5000 SIP speakerphone! They are the only two SIP devices we have...

 

[tidypants]

was there a solution to this, as a client of ours experiences the same problem dialing into conference bridges via SIP lines.

Cheers

 

[stownsend]

The SIP Phones were set to use G729 Compression Codec to the IPO. Our Connection to the SIP Telco provider is G711.

I'vr changed the Codec on the SIP Phone->IPO to also use G711 and also turned off Allow Direct Media Path. To see if that helps resolve the issue.

I'm waiting to hear back from our Remote Office.

Scott<-

 

[stownsend]

Changing everything to to use G.711 and RFC2833 did not make a Difference.

The remote Office is not using SCN. The Remote LAN is VPN Connected to Central Office which has the IPOffice. They login Directly to the IPOffice via the VPN Link. So its just the Polycom setting, the IPO extension settings, and the Line settings to the Telco. Since it is only the two SIP Phones and none of the other Phones in the Office, It would make me think it is the SIP settings on the Phone/IPO Extension that need to be adjusted.

So Still Love. )-:

Scott<-

 

[tlpeter]

Did you try this:

Polycom Phones support DTMF inbound as a standard.

 

SIP 3.2.1 changed the DTMF Payload Type from 101 into 127

In SIP 3.2.2 SIP Info DTMF was added.

 

If you are unable to send DTMF Signals to a IVR or Voice Mail System you may need to change the method or the payload type.

 

Please liaise with your SIP Platform Support in order to gather this Information.

 

Changing from SIP Inbound (RFC2833) to SIP INFO (RFC2976) must be done with a Configuration File loaded from a Provisioning Server.

 

You archive this by adding:

 
<dtmf>
		<voIpProt voIpProt.SIP.dtmfViaSignaling.rfc2976="1" tone.dtmf.viaRtp="0"/>
	</dtmf>

 

Above will enable RFC2976 DTMF Support and disable inbound DTMF.

 

NOTE: A SIP_INFO_DTMF.zip example file is attached

 

Another Solution is to change the Payload Type via:

 
<tone tone.dtmf.rfc2833Payload="101"/>

 

Usually Payload Type 101 or 127 is supported by the SIP Switch.

 

Above will change the SIP Inbound Payload from 127 ( pre SIP 3.2.2 / UCS 3.3.x / UCS 4.0.x) into 101.

 

NOTE: A dtmf_payload_101.zip example file is attached

 

NOTE: Please check your Admin Guide and the Release Notes if your SIP / UC Software Version supports this functionality.

BAZINGA!

I'm not insane, my mother had me tested!

 

[intrigrant]

Good homework! Kick *ss and see stars...

A simple mind delivers great solutions

 

[tlpeter]

Thanks



BAZINGA!

I'm not insane, my mother had me tested!

 

[stownsend]

Thank you tlpeter, looks like this is my issue. Looking a bit more, it looks like I need to push out the Following to my Polycom IP 5000

<?xml version="1.0" encoding="UTF=8" standalone="yes"?>
<localcfg>
   <tones>
      <DTMF tone.dtmf.level="-9" 
	    tone.dtmf.onTime="50"
	    tone.dtmf.offTime="50" 
            tone.dtmf.chassis.masking="0"
	    tone.dtmf.stim.pac.offHookOnly="0" 
            tone.dtmf.viaRtp="1"
	    tone.dtmf.rfc2833Control="1"
	    tone.dtmf.rfc2833Payload="101"/>
   </tones>
</localcfg>

Now for my next trick, not sure how to get it to read that config file. Its not setup to use one currently. We've Managed to get by without having to have a TFTP/HTTP server to serve up Config files to phones. I have a TFTP/HTTP server I can place the files on, though not sure what the Polycom needs to be able to use the sip.cfg file. That and the Polycom is 500 Miles away from anyone Technical to get to the interface on it. There is not much you can change on the Web interface for Boot Options. I'll have to have them ship me one of the phones to work on it here.

Thanks!

 

[stownsend]

I had them Ship me one of the two Soundstation IP 5000 units. Tries the same Tests they did and they all worked for me.

Even so, I worked my way though the Config of the Polycom, I managed to add in the <tones> section of the sip.cfg the Following:

<DTMF tone.dtmf.level="-9" tone.dtmf.onTime="50" tone.dtmf.offTime="50" tone.dtmf.chassis.masking="0" tone.dtmf.stim.pac.offHookOnly="0" tone.dtmf.viaRtp="1" tone.dtmf.rfc2833Control="1" tone.dtmf.rfc2833Payload="101" tone.dtmf.stim.pac.offHookOnly="0" />

My TFTP Server and the Boot log of the Phone show that it is getting my new sip.cfg file.

Connection received from 10.4.5.12 on port 1028 [06/02 16:07:45.262]
Read request for file <0004f2e7403f.cfg>. Mode octet [06/02 16:07:45.262]
Using local port 58335 [06/02 16:07:45.262]
<0004f2e7403f.cfg>: sent 4 blks, 1704 bytes in 0 s. 0 blk resent [06/02 16:07:45.481]
Connection received from 10.4.5.12 on port 1031 [06/02 16:07:45.793]
Read request for file <sip.cfg>. Mode octet [06/02 16:07:45.793]
Using local port 58338 [06/02 16:07:45.793]
<sip.cfg>: sent 388 blks, 198447 bytes in 11 s. 0 blk resent [06/02 16:07:56.731]

Of course my phone still works, I had the remote office do the usual tests and they failed. When they Call the Conferencing service they can press 1234567890 an the Conferencing service will repeat back 1124455699 or something along those lines.

The Remote office is Connected to the Headend office by a 30Meg bidirectional Internet Feed. There are only a few people in the office and not much data going between the offices.
Running a Ping to one of the phones came back with these results:

340095 packets transmitted, 339754 packets received, 0.1% packet loss
round-trip min/avg/max/stddev = 21.241/21.658/137.481/1.419 ms

The 4610 and 5610 IP Phones don't have this issue.

 

[stownsend]

I've Updated the Firmware on the Phones from 3.2.4 to 3.3.5 and that Seemed to Help. Now only the Last digit before hitting # seems to get Duplicated.

Though Still seems like the issue is the Distance the Packets are traveling to get to the IPO as a Phone that was not working in the Remote office works fine in the Corp Office.

Thanks,
Scott<-

 

[tlpeter]

Ditch those phones
Get Avaya conference phones and try them.


BAZINGA!

I'm not insane, my mother had me tested!

 

[stownsend]

Could you recommend an Avaya Ip Conference Speaker Phone? (-: Most of the other Conference room phones we have are Polycom, though all Analog.

Thanks!

 

[tlpeter]

Avaya has bought Konftell which has good conference phones.
Search for the B1xx range as there is also a SIP version of it.

BAZINGA!

I'm not insane, my mother had me tested!

 

[amriddle01]

Better to buy Konftel stock, cheaper even with the more expensive licence and its the same phone


Avaya Implementation Qualified Professional Specialist Technical Engineer (AIQPSTE)