initial call not answered if I choose call-back

[ndemou]

I'm using a calling card account without call-back just fine. However if I check the call-back option, my calls to the calling card don't get answered (I'm hearing only ringing tones and no "please enter your extension" prompt).

 

Some facts and thoughts:

1) it seems that the system answers the call with early audio (I see "call port 45: state code from 100 to 183") and it plays back the prompt (I see "Play audio_en/ex_enter_extension_number.wav") but the audio doesn't reach the caller

2) the problem appears in 99% of the calls. This 99% gets in from my main trunk to the outside world

3) for the 1% of the calls that get in from a direct trunk with another PBX I _do_ hear the "please enter your extension" prompt

4) I've tested with versions 3 and 4

 

It seems to me very likely that the telco on the other side of the trunk will never pass audio until the call is considered connected (and the caller gets billed for the audio they listen to).

 

Any ideas?

 

[8] 20130716115832: Trunk: Check if the call to +XXXXXX0042 comes from the cell phone <MY-ANI>
[8] 20130716115832: To is "+XXXXXX0042" <sip:+XXXXXX0042@<PBX-IP>;user=phone>, user 2495, domain 270
[8] 20130716115832: To user 700
[8] 20130716115832: Trying to match number +XXXXXX0042 with ERE ([0-9]*)
[8] 20130716115832: Send call to extension ERE returned +XXXXXX0042
[5] 20130716115832: Global trunk <INBOUND-TRUNK>@donotdelete.com sends call to 700 in domain <DOMAIN>
[8] 20130716115832: Set the To domain based on To user 700@<DOMAIN>
[8] 20130716115832: Call state for call object 9467: idle
[7] 20130716115832: Call port 258: set_codecs for 28df04006923-51e524f0-3b03bc98-3b47eb28-2fd2c@127.0.0.1 codecs "18",>
[8] 20130716115832: Play audio_en/ex_enter_extension_number.wav, caching false
[8] 20130716115832: call port 258: state code from 0 to 183
[6] 20130716115832: Call-leg 258: Codec g729/8000 is chosen for call id 28df04006923-51e524f0-3b03bc98-3b47eb28-2fd2c@>
[5] 20130716115832: set codec: codec g729/8000 is set to call-leg 258
[8] 20130716115833: Play space20, caching false
[8] 20130716115833: call port 258: state code from 183 to 183
[8] 20130716115835: Play audio_en/ex_enter_extension_number.wav, caching false
[8] 20130716115835: call port 258: state code from 183 to 183
[8] 20130716115836: rtp_hangup: call port 254, too early to disconnect
[8] 20130716115836: rtp_hangup: call port 255, too early to disconnect
[8] 20130716115837: Play space20, caching false
[8] 20130716115837: call port 258: state code from 183 to 183
[8] 20130716115839: Play audio_en/ex_enter_extension_number.wav, caching false
[8] 20130716115839: call port 258: state code from 183 to 183
[8] 20130716115840: Play space20, caching false
[8] 20130716115840: call port 258: state code from 183 to 183
[8] 20130716115842: Play audio_en/ex_enter_extension_number.wav, caching false
[8] 20130716115842: call port 258: state code from 183 to 183
[8] 20130716115844: Play space20, caching false
[8] 20130716115844: call port 258: state code from 183 to 183
[8] 20130716115846: Play audio_en/ex_enter_extension_number.wav, caching false
[8] 20130716115846: call port 258: state code from 183 to 183
[8] 20130716115848: Play space20, caching false
[8] 20130716115848: call port 258: state code from 183 to 183
[8] 20130716115850: Play audio_en/ex_enter_extension_number.wav, caching false
[8] 20130716115850: call port 258: state code from 183 to 183
[8] 20130716115851: Play space20, caching false
[8] 20130716115851: call port 258: state code from 183 to 183

[Vodia PBX]

Yes. You can see that the PBX put the call always in 183 state. It should go to 200. Why it does that is a completely different question. My idea would be to take a look at the SIP packets going back and forth to your SIP service provider. Maybe that has a clue about what is going on.

[ndemou]

It doesn't have to do anything with the SIP service provider because I get the same behaviour when I call from a PBX extension (no trunk involved).

Here is the test I perform: I'm calling from an extension in the same domain as the calling card account and...

 

if I set "Callback: off" tcpdumps captures a "SIP/2.0 200 Ok." from the PBX and I get these lines in the logs:

[8] 20130717115501: Play audio_en/ex_enter_extension_number.wav, caching false
[8] 20130717115501: call port 400: state code from 0 to 200
[8] 20130717115503: Play space20, caching false

 

 

 

but if I set "Callback: on" tcpdumps captures a "SIP/2.0 183 Session Progress." from the PBX and I get these lines in the logs:

[8] 20130717115526: Play audio_en/ex_enter_extension_number.wav, caching false
[8] 20130717115526: call port 401: state code from 0 to 183
[8] 20130717115527: Play space20, caching false

no SIP message "200 Ok" will follow after this point. So the PBX for some reason wont answer the call with a "200 Ok" in the second case.

[Vodia PBX]

Oh. I think I get the point now.

 

When you are calling the PBX for a callback, you don't want to pay for this. Not even for the call that initiates the callback. That is why this call does not connect. However, during that time there is still media--early media. This is two way audio, including DTMF. Some airlines are using the same mechanism to keep costs away from their customers. Because the ringback phase is limited to a few seconds by most carriers, the financial damage for the carriers is limited. But a few seconds are enough to enter e.g. the PIN to start the callback. The 200 Ok has essentially the function to tell the carrier when to start the billing and to change the caller's display to "connected".

 

If your carrier does not transport the DTMF tones or even the media, he is definitively not SIP compliant. This is actually a pretty well-known test scenario. You can search for early media and SIP if your are interested in the technical background.

[ndemou]

is there any workaround? (because changing the carrier is not easy)

[Vodia PBX]

As far as I can see that is at the moment hard wired. A (dirty) workaround would be to send the call first to a dummy IVR node which always connects the call just to time out after a second and send the call to the callback service.