DTMF does not work on incoming calls

[zombie999]

More or less.

We can tell here if you're abusing the service and of course if we see tons of simultaneous calls from one account (phone number) than of course we'll keep an eye on your usage and if it keeps up we would contact you.

But I do know that there are quite a few people here and on FPL in general who want to use Asterisk/PBXes/Trixbox or what have you for the IVR and other advanced options (ie. having separate extensions for different rooms, people, etc...)

It's safe to say that though you do not need to lose sleep over whether or not you'll get that dreaded call from Freephoneline.ca saying your account will be closed, we rarely get abuse on our system and when we do it's fairly isolated and resolved for the most part painlessly.

To answer your question I'd have to say #3 is at least my stand on this policy - We won't provide technical support for it, yet don't have a severely strict policy on using it with our gateway; But still want to realize that it is in fact a residential gateway and if you are using it for business purposes we'll most likely find out and take appropriate action.

Thanks for the reply. I'm not using it for business so I guess I have nothing to worry about. I do once in a while initiate simultaneous calls but this is only to test my asterisk set up and calls are usually short.

What about having 2 simultaneous calls? I sometimes use it for call back but not much. Is that a no no? I know that you can do three way calling using an ATA, so I hope 2 calls at the same time are ok.

[FONGO_kris]

Yes two calls are perfectly fine, we're more looking at the people who are making 14 calls at one time (It's now been fixed so you can't do that FYI).

[keithl]

Kris said: "The server we use supports RFC2833 both incoming and outgoing"

Just to clarify, it is not the direction of the phonecall (i.e. who called whom) but the direction of the audio (i.e DTMF sent from PSTN to FPL sip destination). I do acknowledge, though, that the direction of the phonecall can affect audio in either direction.

I stll see no RFC2833 when a cell phone user calls my FPL number then presses a digit during a call. I just hear the tone.

Again, I'm pretty sure this used to work a few weeks ago.

[FONGO_kris]

When I said 'incoming' I was indirectly referring to Asterisk. Since we do not support it, I of course could not come out and say it . With the RFC2833, our business system, IP-PBX, uses RFC2833 on it's IVR's, and I can call into it just find, even navigate through our directory and find myself!

I do respect however that it may not work for some of you, though I'd have to look into a few things in order to determine the source of this error.

[keithl]

Sorry to flogg a dead horse, but I've done some more investigation using wireshark and 3cx softphone.

If the call originates from the registered sip phone (calling a PSTN number), DTMF (2833) is negotiated as 101 and works perfectly BOTH directions. Wonderful
If the call originates from a PSTN number (calling registered sip phone), DTMF is not offered, just pcmu with a media attribute of abcde:20 (?). The sip phone still sends DTMF2833 but FPL sends only audio.

This is preventing me from accessing my home answering machine (SIP) from away.

I'm pretty sure this used to work but broke around the beginning of Mar '10.

Did I break it in my configuration or is it on your end?

I REALLY need help with this.

Keith
P.S. what about the others who posted in this thread. Is theirs now working?

[FONGO_kris]

Well, just because I like how you started the post I'm going to look into this for you

But all joking aside, it's been working for me while accessing our company DISA which resides on a mixture of Asterisk as well as our own creation, so let me check into it Monday to see if indeed our software phone is just sending our RCF2833 or just PCMU tones - That's all I can really do, being an Asterisk box an all...

[keithl]

Thanks, Kris.

I have discovered one other thing. FPL ONLY offers PCMU (specifically does not offer G729 or 2833) to the softphone when the call originates from PSTN (i.e. my cell). This is consistent with my last post. I tried setting the only codec to 729 (recommendation of FPL) and it wouldn't connect due to no mutually agreeable codec. This might also explain some other peoples "unable to connect"s!

Note that G729 (and, of course, 2833) are acceptable to FPL if the call originates from the softphone, but are not offered if the call originates from PSTN (my cell). Strangely, though, it will correclty handle 2833 (from the softphone) even if it didn't negotiate it (i.e. when the call originated from my cell)!

I'm pretty sure your DISA stuff works because asterisk is a B2BUA, decodes DTMF audio then generates 2833.

I KNOW FPL can do it because it does it perfectly when the call is originating from the softphone. I can't help but think it is the most trivial of settings to make it offer 2833 (and G729) when the call originates from my cell.

I love your service, and specifically the support that you, personally, give. I'm really trying to help make FPL THE choice in ITSP. You guys should be really well positioned to take the market by storm when voip reaches mainstream.

We're almost there...

[zombie999]

P.S. what about the others who posted in this thread. Is theirs now working?

I tried it 1-2 weeks ago and it still didn't work.

[keithl]

Pretty please, Kris?

I really want to see FPL very, very wife friendly (actually, girlfriend). The only "hangup" right now is the SIP answering machine. Yes, yes, I know I can use an audio one with an ATA, but:

1) I don't want to (I love the SIP one)
2) SIP should work!

I will investigate anything you want. I can come to Kitchener to demonstrate and dump my limited experience if that helps.

As a bonus, it will cut down your Bandwidth requirements as well since you only offer PCMU (G.711) for outgoing calls (specifically to things other than your softphone). When fixed, you will offer G.729 (which is what you THINK you are doing now!)

Pleassssee...

Always appreciative of your help,
Keith

[FONGO_kris]

The only "hangup" right now is the SIP answering machine. Yes, yes, I know I can use an audio one with an ATA, but:

1) I don't want to (I love the SIP one)
2) SIP should work!

Now what baffles me about this is that our answering machine runs off the server, which is SIP. So I'm about 30% clear on what you mean here

[beverly]

The other day i was playing around and got to those pesky beeping noise when talking to someone.
I ended up disabling DTMF/zeroing the DTMF Playback Length (touch tone relay¿? why?) and what do you know, i'm still able to do banking on the phone, check the VM box, everything DTMF did (even press buttons while on an important call to my boss/lawyer/job interview) even increase the FXS Port Output/Input Gain for once. (-3) without the beeps

this works for me, does it work for you?

I also disabled Detect ABCD/Playback thing (i have no idea what this does, but it looks important)[SPA1001 didn't have this, but PAP2T did]

[keithl]

Kris:

I have a SIP answering machine (not the FPL one) which will answer the incoming SIP call if I don't answer it with the SIP phone. Very simply, I've clearly observed that if one phone registers on the FPL account and a call is initiated from FPL to the registered phone (i.e. I call my FPL number from my cellphone and a call is initiated from FPL to the registered phone at home), FPL only offers PCMU and offers neither G.729 nor 101 (RFC DTMF), therefore the call is successful (using PCMU) but RFC DTMF is not (it is strictly done audio in RTP). When I press a key on my cell, you send the audio, not the 101. Calls from the registerd phone to FPL (i.e I call my cell from my home SIP phone) successfully negotiate G.729 and 101 (RFC DTMF).

I'm SURE this is not what FPL thinks is happening (you THINK you are negotiating both G.729 and 101) and I'm also SURE this is not what you want (specifically, you want to use G.729)

Beverly:

Your issue is the exact opposite. You are referring to DTMF generated by pressing keys on the SIP phone. What I am referring to is DTMF generated by pressing keys on the PSTN phone (my cell). Exacly the opposite. Note that your "fix" likely worked because, through that configuration, you forced your ATA NOT to negotiate RFC DTMF. Since it went in audio, it worked. For techincal reasons I would suggest you fix the actual problem and use RFC DTMF (specifically G.729 cannot reliably transmit audio DTMF).

[zombie999]

The only "hangup" right now is the SIP answering machine. Yes, yes, I know I can use an audio one with an ATA, but:

1) I don't want to (I love the SIP one)
2) SIP should work!

Now what baffles me about this is that our answering machine runs off the server, which is SIP. So I'm about 30% clear on what you mean here

He's just using a fancy new name for something you cannot support. No one said that company policy is not to support customer's SIP answering machine, right?

[FONGO_kris]

Only assume since he said "the" sip answering machine and not "my" sip answering machine, it was ours. Regardless, it would act just like (I can only assume) and analog answering machine, which we do not support you're right zombie999.

[keithl]

I respect that you are busy, but please don't discard this.

Forget about answering machine, PBX or anything else.

In reviewing all replies to my posts, I see I haven't made myself clear. Only 3 things involved: a PSTN caller, FPL and a SIP hardphone with using a config file. I refer to 101 which is telephone/event (RFC2833 DTMF).

The good news:
1) FPL supports G.729 and 101 and accepts others such as PCMU
2) FPL prefers the use of G.729
Great

Calls from SIP hardphone to PSTN
1) SIP phone proposes G.729, 101 and maybe more such as PCMU
2) FPL accepts G.729 and 101
3) FPL completes call to PSTN
Great

Calls from the PSTN to SIP hardphone:
1) FPL receives phone call from PSTN
1) FPL proposes PCMU ONLY to SIP hardphone!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
2) SIP hardphone accepts PCMU and completes call
OOPS! WHAT HAPPENED TO G.729 and 101

All I'm saying is that you may THINK that FPL proposes G.729 and 101, but it doesn't. I'm asking you to see if it is a tiny, tiny configuration issue (on your end).

ALL CALLS FROM PSTN TO A SIP HARDPHONE (via FPL) WILL ONLY USE PCMU.

Is that a little clearer?

Hopeful
Keith

[zombie999]

ALL CALLS FROM PSTN TO A SIP HARDPHONE (via FPL) WILL ONLY USE PCMU.

This is why they ask people to set the option "use preferred codec" to "NO" or else incoming calls won't work if preferred codec is G729.

[keithl]

Yes, I know, but I think they didn't know WHY.

Also, they USED to propose PCMU AND 101 (can't speak for G.729), now it is just PCMU. Getting worse...

I'm sure it is an itsy bitsy teensy weensy configuration item on their end. Fix this and they reduce their bandwidth use (by using more G.729) and reduce the support calls (from those who put use only preferred codec).

Plus, I get my DTMF!!!

Just trying to help

Keith

[aca905]

Any news on this? I have the same issue. DTMF on incoming calls from PSTN fail.

Thanks,

Keith

[FireROR]

somehow the DTMF stop working....


I use to have dtmfmode=inband, and it stop working today... I tried dtmfmode=rfc2833 but still failed...

[FONGO_steve]

somehow the DTMF stop working....


I use to have dtmfmode=inband, and it stop working today... I tried dtmfmode=rfc2833 but still failed...

Try again now

[FireROR]

It works again next morning. Nothing was changed on my side.

[kakgungor]

I respect that you are busy, but please don't discard this.

Forget about answering machine, PBX or anything else.

In reviewing all replies to my posts, I see I haven't made myself clear. Only 3 things involved: a PSTN caller, FPL and a SIP hardphone with using a config file. I refer to 101 which is telephone/event (RFC2833 DTMF).

The good news:
1) FPL supports G.729 and 101 and accepts others such as PCMU
2) FPL prefers the use of G.729
Great

Calls from SIP hardphone to PSTN
1) SIP phone proposes G.729, 101 and maybe more such as PCMU
2) FPL accepts G.729 and 101
3) FPL completes call to PSTN
Great

Calls from the PSTN to SIP hardphone:
1) FPL receives phone call from PSTN
1) FPL proposes PCMU ONLY to SIP hardphone!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
2) SIP hardphone accepts PCMU and completes call
OOPS! WHAT HAPPENED TO G.729 and 101

All I'm saying is that you may THINK that FPL proposes G.729 and 101, but it doesn't. I'm asking you to see if it is a tiny, tiny configuration issue (on your end).

ALL CALLS FROM PSTN TO A SIP HARDPHONE (via FPL) WILL ONLY USE PCMU.

Is that a little clearer?

Hopeful
Keith

Just wondering if this issue has been addressed? I am experiencing the same issue with incoming calls not using the G.729 codec. My outgoing calls on a SIP phone use G.729 just fine.

Thanks,
Kent

[FONGO_kris]

A conclusion (not a resolution) has been reached:

1. The soft-switch requests G711u on incoming calls for our service, as it is among the best of quality, and most reliable codec for use with our service - It has also been proven to fail the least.

2. **Officially**, freephoneline only supports G711, 723, & GSM - reasoning is above

This does not mean we reject any other negotiation method, it simply means that if it does not work as you'd like it to (or at all in the case of auto attendants on incoming calls) we are unable to assist in the matter.

[zombie999]

2. **Officially**, freephoneline only supports G711, 723, & GSM - reasoning is above

Interesting, when I got my SIP settings, it said I should use G729.

Any way, I tried setting my ATA to use G723, and no it does not work, it will use G711.

Tried setting asterisk to use GSM and I get only silence. Call does not fail, interesting.

G711 is the best, I agree.

[kakgungor]

A conclusion (not a resolution) has been reached:

1. The soft-switch requests G711u on incoming calls for our service, as it is among the best of quality, and most reliable codec for use with our service - It has also been proven to fail the least.

2. **Officially**, freephoneline only supports G711, 723, & GSM - reasoning is above

This does not mean we reject any other negotiation method, it simply means that if it does not work as you'd like it to (or at all in the case of auto attendants on incoming calls) we are unable to assist in the matter.

@admin: The reason I was surprised about G729a was because when I first got my config file, the SIP Settings page on FreePhoneLine.ca said that I should set the preferred codec to G729a. Is there any way to have my account accept G729a for incoming calls?

Also, I'm not able to get calls to connect (incoming or outgoing) using the GSM codec. I simply get an error. Do you have any suggestions for that?