Different Behavior for invoming PSTN and IP Calls

[Detlef]

I am running 2 pbxnsip 2.1.6.2446 (one in VA and one in GA). Both are interconnected with SIP Gateway trunks. GA uses extension 100-199 and VA uses extensions 200-299. All incoming calls go to the auto attendants 100 or 200.

 

The auto attendants have a user input set to forward calls to the other system, so if a caller presses 1 in VA the auto attendant forwards the call to ext. 100 - which is located in GA and is sent there via the gateway trunk and dial plan. If someone calls in GA and presses the 2 the auto attendant there connects the caller to extension 200 - which is the VA auto attendant. That works so far very good if the call comes in over our Grandstream PSTN gateway.

 

Now I added inward numbers from callcentric and the forward to the other's system auto attendant does not work. In fact it forwards the call to the other system and also sends for example the digit 1 that is used in VA to connect the call to the auto attendant in GA additional to GA. Of course the auto attendant in GA expects a 3 digit 1xx extension number and comes back with the message that the extension doesnt exist.

 

How do I prevent the VoIP call from callcentric to send this additional digit that is used to initiate the transfer to the other system also to the other system?

 

Below I added the two logs - first the VoIP call and second the working PSTN call:

 

 

VA - Call from CallCentric to PBX

 

[5] 2008/02/15 09:41:08: Trunk VoIP CC sends call to 200

[7] 2008/02/15 09:41:08: Attendant: Set language to first language en

[8] 2008/02/15 09:41:08: Play recordings/att8.wav space20

[6] 2008/02/15 09:41:12: Received DTMF 1

[5] 2008/02/15 09:41:12: Dialplan default: Match 100@localhost to <sip:100@192.168.0.220;user=phone> on trunk VoIP GA

[5] 2008/02/15 09:41:12: Using <sip:17574685765@66.193.176.35>;tag=3412075315-860014 as redirect from

 

GA - Receiving PBX

 

[7] 2008/02/15 09:41:57: UDP: Opening socket on port 63732

[7] 2008/02/15 09:41:57: UDP: Opening socket on port 63733

[5] 2008/02/15 09:41:57: Identify trunk (IP address/port and domain match) 1

[6] 2008/02/15 09:41:57: Sending RTP for c3fa37dc@pbx#02004e4d5f to 192.168.104.220:54466

[8] 2008/02/15 09:41:57: Found 200 in address book of domain localhost

[5] 2008/02/15 09:41:57: Trunk VoIP VA sends call to 100

[7] 2008/02/15 09:41:57: Attendant: Set language to first language en

[8] 2008/02/15 09:41:57: Play recordings/att2.wav space20

[6] 2008/02/15 09:41:57: Received DTMF 1

[8] 2008/02/15 09:42:00: Attendant: Timeout (press)

[8] 2008/02/15 09:42:00: Play audio_en/aa_not_existing.wav space20

 

=====================

 

VA - Call from PSTN to PBX

 

[5] 2008/02/15 09:45:59: Trunk PSTN VA sends call to 200

[7] 2008/02/15 09:45:59: Attendant: Set language to first language en

[8] 2008/02/15 09:45:59: Play recordings/att8.wav space20

[7] 2008/02/15 09:45:59: Set packet length to 20

[6] 2008/02/15 09:46:05: Received DTMF 1

[5] 2008/02/15 09:46:05: Dialplan default: Match 100@localhost to <sip:100@192.168.0.220;user=phone> on trunk VoIP GA

[5] 2008/02/15 09:46:05: Using "IMS GEAR, INC " <sip:7574685765@localhost> as redirect from

[8] 2008/02/15 09:46:05: Play audio_moh/noise.wav

 

GA - Receiving PBX

 

[7] 2008/02/15 09:46:49: UDP: Opening socket on port 52728

[7] 2008/02/15 09:46:49: UDP: Opening socket on port 52729

[5] 2008/02/15 09:46:49: Identify trunk (IP address/port and domain match) 1

[6] 2008/02/15 09:46:49: Sending RTP for 73767b3c@pbx#452ad5f3c4 to 192.168.104.220:50578

[8] 2008/02/15 09:46:49: Found 200 in address book of domain localhost

[5] 2008/02/15 09:46:49: Trunk VoIP VA sends call to 100

[7] 2008/02/15 09:46:49: Attendant: Set language to first language en

[8] 2008/02/15 09:46:49: Play recordings/att2.wav space20

[Vodia PBX]

How do I prevent the VoIP call from callcentric to send this additional digit that is used to initiate the transfer to the other system also to the other system?

 

So you mean the problem is that the call gets redirected and because everything goes so fast, the tone is still active and when the call arrives at the other system, the system hears the ongoing DTMF and says "whow this guy is quick" and collects the first digit already?

 

A quick and dirty workaround could be to use a IVR node, put one second of silence there and redirect the call after the timeout to the auto attendant.

[Detlef]

So you mean the problem is that the call gets redirected and because everything goes so fast, the tone is still active and when the call arrives at the other system, the system hears the ongoing DTMF and says "whow this guy is quick" and collects the first digit already?

 

A quick and dirty workaround could be to use a IVR node, put one second of silence there and redirect the call after the timeout to the auto attendant.

 

So you mean Callcentric is faster/longer detecting and transmitting the DTMF than the Grandstream gateway? Hmm, I was trying to simlulate that by pressing and holding the key but all the phones I have here right now only send a short DTMF tone even if I hold the key.

 

How does the PBX evaluate those signals? I have inband DTMF detection turned off in both systems, so it must get it via a SIP message? I dont know how that works but isnt that just one message saying the caller pressed 1 and not continously sending that tone?

 

In the log you can see, it all happens in the same second at the receiving pbxnsip, transfer and detecting DTMF and then skipping the default auto attendant recording and then waiting for the timeout.

 

So with the IVR node I would first send the call from the auto attendant to a local IVR node and that one would transfer the call to the other system after playing a blank 1 sec wav ?

[Vodia PBX]

How does the PBX evaluate those signals? I have inband DTMF detection turned off in both systems, so it must get it via a SIP message? I dont know how that works but isnt that just one message saying the caller pressed 1 and not continously sending that tone?

 

Well if the PBX receives a RFC2833 packet and is not already in a RFC2833 stream, well then it assumes the key has been pressed. It does not care that another system already chopped off the first part.

 

So with the IVR node I would first send the call from the auto attendant to a local IVR node and that one would transfer the call to the other system after playing a blank 1 sec wav ?

 

No, the call should first go the the IVR node and just don't do anything (no not react to DTMF at all). Then after 1 second or so the call gets redirected into the "real" auto attendant.

[Detlef]

That with the IVR node seems to work:

 

So now my auto attendants transfers interoffice calls originating from PSTN or IP to silent IVR nodes instead of the direct auto attendant in the other office.

 

[8] 2008/02/15 14:27:17: Found 200 in address book of domain localhost

[5] 2008/02/15 14:27:17: Trunk VoIP VA sends call to 181

[8] 2008/02/15 14:27:17: Play recordings/ivr21.wav

[6] 2008/02/15 14:27:17: Received DTMF 1

[7] 2008/02/15 14:27:17: Attendant: Set language to first language en

[8] 2008/02/15 14:27:17: Play recordings/att2.wav space20

 

But with just "!E!100!" in the DTMF match field it gets stuck there with dead silence after it receives the not wanted DTMF 1. I put in the Timeout field a 1sec - that didnt change anything. The only thing that helped is a "!E!100! ![0-9]!100!" in the DTMF match field and it connects the call directly to the auto attendant for any digit received - even skipping the 1 sec silent wav if its a callcentric call.

[Vodia PBX]

Dirty workaround... Lets take it as temporary solution.

 

Maybe later we come up with a nice idea that does solve this problem automatically - without side effects that we don't want.