Cisco SPA502G - Transfers failing

darran.hamer · ‎05-15-2012

Hello,

I'm using a hosted Asterisk-based solution. Everything works fine for around a week, and then, when attempting a transfer, the handsests display "Transfer Failed" even though the call has actually gone through. If I leave it a bit longer, transfers stop working entirely (attended and blind transfers). Rebooting the asterisk server temporarily solves the issue.

I provided traces for the software provider and they have recommended asking here as the traces are showing strange results. Here is a quote from my support ticket with them, discussing the trace that I provided:.

(The calling number is 07578875601, which goes through to telephone line 0000004 (SPA502G). The transfer is then attempted to 0000003.)

This is a confusing trace! As I see it, the call flow is:

1. There's some extraneous packets from a previous call.

2. A new call comes in from the PSTN with callid D7BFB565-984B11E1-AF83D619-7FCEA6F7@213.166.5.166.

3. We send the call to 0000004 with callid 03ef059a33797f1010947a3c37243a32@88.198.46.25:5070.

4. 0000004 answers.

5. 0000004 makes a new call to 0000003 with callid c2bab806-1212a911@10.0.0.224.

6. We send the call to 0000003 with callid 661df5b01f60d67b320da6d61eb29413@88.198.46.25:5070.

7. 0000003 answers.

8. There's all this RTP junk. I don't know what this means:

[May 8 14:52:16] DEBUG[4071] res_rtp_asterisk.c: No remote address on RTP instance '0x2ac4f804ea68' so dropping frame

[May 8 14:52:16] DEBUG[4114] res_rtp_asterisk.c: Setting RTCP address on RTP instance '0x2ac4f8002f98'

[May 8 14:52:16] DEBUG[4114] res_rtp_asterisk.c: RTP NAT: Got audio from other end. Now sending to address 81.143.10.241:38549

[May 8 14:52:16] DEBUG[4138] res_rtp_asterisk.c: Ooh, format changed from unknown to g722

[May 8 14:52:16] DEBUG[4138] res_rtp_asterisk.c: Created smoother: format: g722 ms: 20 len: 160

[May 8 14:52:16] DEBUG[4071] res_rtp_asterisk.c: No remote address on RTP instance '0x2ac4f804ea68' so dropping frame

9. 0000004 send a BYE to hang up the call to 0000003 at line 2889 in the trace. I don't know it does this. Perhaps because it hasn't received any RTP for the previous 3 seconds due to the above RTP warnings? I can't imagine a phone timing out after such a short time (I've had drop-outs longer than 3 seconds many times on calls over bad internet connections), so I suspect its something else. The logs on the phone may show.

10. 0000004 then sends a REFER to connect its inbound call with the call to 0000003. This is absolutely crazy as it has already hung up the call to 0000003.

11. Asterisk accepts the REFER, but then starts producing errors about "No target channel" (because the call is hung up), and then sends a 603 Declined to 0000004.

12. The rest of the trace is tidying up the mess.

So the questions raised by this trace are therefore:

A. Why does 0000004 hang up the call to 0000003?

B. Why does it send a refer after hanging up the call?

The provider suggested asking here, as maybe someone could "Tell me what we need to change in the SIP packets we send to the handset."

Any help would be very greatly appreciated.

Thanks.

testeven · ‎05-15-2012

Hi Darran,

I googled the error messages they see as RTP junk and I found they are expected whenever

you enable the debugging. It sounds like an asterisk issue to me and I found a similar

issue on the Asterisk forums where the user downgraded to a different version.

http://forums.digium.com/viewtopic.php?p=126667&sid=2e2d31e0176ed15a51dd332b9fed0ece

Regards,

Tere.

If you find this post helpful, please rate!

Regards, Tere. If you find this post helpful, please rate! :)

darran.hamer · ‎05-16-2012

I appreciate your reply Tere.

We already downgraded the Asterisk server to a more widely used version in attempt to solve this, but unfortunately it hasn't got us anywhere.

Thanks.

paolo bevilacqua · ‎05-16-2012

Wrong forum, try "small business voice - SPA phones". You can move you post using the Actions panel on the right.