PDA

View Full Version : No audio after Transfer.



threebit
06-22-2006, 12:56 PM
Hi,



When we transfer a call from one extension to another there is no audio
after the transfer, when the original call is via an IP PSTN trunk.



We have problems when the call scenario is as follow:

- Extension 1 (IP or FXS) makes external call via our IP-PSTN trunk.

- Extension 1 (IP or FXS) transfers call to Extension 2 (IP or FXS)

- Caller or Callee get not audio.



Also

- External caller rings our IP-PSTN number.

- Extension 1 receives call

- Extension 1 transfers call to Extension 2

- Caller or Callee get not audio.



If the original call uses an FXO PSTN trunk then there is no problem.



Is this a codec problem or something else?



Thanks.
Edited by: threebit

artur_barkhudaryan
06-22-2006, 02:56 PM
Hello,




Is this a codec problem or something else?



I would guess something else smileys/smiley1.gif

Does the "Call statistics" page show a reasonable amount of received/transmitted packets for the transferred call ?

threebit
06-22-2006, 03:38 PM
There is nothing listed in Network Details for these calls.
External calls from our IP Lines through the IP PSTN never have Network Details listed for them - which is a pain, because I am trying to test different codecs.

If I transfer the call to FXS line, then Network Details read:
Codec: PCMU, N/A
Trasmitted/Received Packets shows 0

artur_barkhudaryan
06-22-2006, 04:59 PM
Does an FXS->FXS transfer work ?
If no, what does the Network Details show ?

threebit
06-22-2006, 05:25 PM
FXS -> FXS does work.

souren
06-22-2006, 10:19 PM
Hello,

I suggest you to submit a ticket for this.

Thanks,
Souren

cgaunt
06-23-2006, 06:44 PM
I found this to be due to the ADSL Router/Firewall. Look at your Firewall DOS settings.

threebit
06-27-2006, 12:55 PM
We gave the Quadro unit a public IP and put it in our DMZ, turned off firewalling to it and still having the same issue.
Will look to submit a ticket.

threebit
09-07-2006, 08:06 AM
Hi Again,
Its quite a few weeks later, and we still have this problem.
We are unable to submit a ticket directly as we source our Quadro's from an Australian distributor.
When we mentioned the problem to the Australian company they followed it up with Epygi and the ITSP.

The conclusion they came to, was that the ITSP is changing the RTP when it receives the transfer message (ReInvite??) and this is confusing the Quadro.

We have had no luck getting the ITSP to do anything about this (as you might expect). Is there any configuration we can make in the Quadro that might help with this problem?

Thanks.

threebit
09-21-2006, 10:21 AM
I have since been told by the ITSP that their service was setup to be
stateless and features like call transfers will not work for this
reason.



Previously, when we were using Asterisk (shudder!) we had no such
problem. Calls would transfer without problem, which makes this problem
even more frustrating.

lebenton
09-21-2006, 01:52 PM
threebit, which ITSP are you using?

megatron
09-24-2006, 09:09 PM
Try turning on RTP proxy in call routing smileys/smiley4.gif

davrays
09-25-2006, 02:27 AM
Yes, for me it is also very interesting, which ITSP is that.


I remember a request from Alloy about similar problem, but our resolution was exactly the opposite to what threebit is telling.




The conclusion they came to, was that the ITSP is changing the RTP when it receives the transfer message (ReInvite??) and this is confusing the Quadro.



actually Quadro is changing the RTP port during transfers sending re-INVITE and this may confuse ITSP if their SIP implementation is not mature.

threebit
09-25-2006, 09:52 AM
Hi,
The ITSP is iTalk, and Alloy were taking the issue up with Epygi on our behalf.

And davrays, you are right about the RTP port changing, it is being done by the Quadro not the ITSP. I had that a little confused.

I managed to contact the italk product manager about this issue. After discussing the issue with his engineers he came back to me saying their service is "stateless" and therefore not designed to to handle functions like call transfers.

I have been trialling a workaround (hack) that uses Asterisk as a sort of proxy. Which solves the transfer issue, but is not ideal because Asterisk tries to handle the hold music, aswell as a number of other reasons including degradation of audio quality.

Thanks.

hrant221
09-25-2006, 11:52 PM
Please enable the developer logs on your Quadro (to do that enter the "systemlogs.cgi" in your browser's Address field after the IP address of Quadro, select "System Logs Settings" andenable "Enable developer logging". Then run please the same test again with failed transfer, download the logsand sendthat to the following mail address along withtestdescription:


hrant.vardanyan@epygiarm.am

davrays
09-26-2006, 10:21 PM
Wehave looked into these logs and ...


...I see no good resolution to this problem, other than to change the ITSP. Quadro is changing RTP port during transfer and there is no configuration options, which could change that behaviour.


The way Quadro is operating is fully in accordance to RFC, and SIP implementation on ITSP side should support that. Changing a port during re-negotiations isNOTa very advanced thing, and it cannot confuse normal SIP stack.


Asterisk doesn't change theport (and so doesn't have problem with that ITSP), most probably because itdoes the transfer internally. This may add an unnecessaryload to the device.


The implementation in the Quadro was considered as optimal, and we cannot change that because of possiblesideeffects, unless wehavestatistics, which shows thata lot of ITSPs don't support port change during re-negotiation. Up to now we have seen that behaviour only from iTalk server.


Regards,


DVREdited by: davrays

threebit
09-27-2006, 06:19 AM
Thanks for investigating the issue.
A new ITSP has launched this month which might be an alternative option for us. But up until now italk has been our only option.
Thanks again.

Edited by: threebit