cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5428
Views
0
Helpful
6
Replies

No audio on outgoing calls from Trixbox phones connecting through CME and SIP trunk

Hi, please assist with this problem adding Trixbox SIP phones to a CME setup.

We have had a  Cisco UC560 device with 20 phones or so, running fine for a couple of  years, connecting to the PSTN via a telco provided SIP trunk. A third  party supplier has now provided a Trixbox and some SIP phones, with  which we need to integrate with the current setup.

We got as far  as adding dial-peers for the extensions that are on the Trixbox phones,  and using a test set of dial-peers, managed to get internal Cisco to TB  phone calls functioning perfectly.  It is also possible dial in from the  PSTN to the TB phone, and the call proceeds perfectly.  However,  outgoing calls from the TB phone to the PSTN do not function correctly.   The call sets up fine, and remains active until one party ends it, but  there is no audio in either direction.

Using "debug voip rtp"  showed that indeed, the UC560 was receiving packets from both the  Trixbox (192.168.92.9) and the SIP trunk provider (83.245.6.8x), but was  not transmitting packets to either end point.

We are not sure  why the incoming calls function correctly, but the same "debug voip rtp"  trace reveals that as well as packets being sent to and from the end  points, they are sent to and from the local IP source address for the  CME (10.1.1.1) and the gateway address of the integrated service engine  on 10.1.10.2.

I have attached the two rtp debugs from the  successful incoming and failing outgoing traces. Will also post some  running config excerpts up shortly.

All suggestions gratefully received!

1 Accepted Solution

Accepted Solutions

The debug seems incomplete:

UC receives INVITE sip:907635782010@192.168.92.254 SIP/2.0

User-Agent: Asterisk PBX 1.6.0.26-FONCORE-r78

audio + video

but it doesn't send any sip messages to 192.168.92.9 or to SIP provider.

UC receives a TRYING, 183 session progess, 200 ok from SIP privider and send a finally ACK.

Can you add a complete debug with sent messages from UC?

Do you have already try to disable video capability in the TB?

Regards.

View solution in original post

6 Replies 6

Are trixbox behind NAT?

Can you add the output of debug ccsip messages?

Regards.

Thnak you for your reply - I will get the ccsip debugs tomorrow, as I am away right now.  There is no NAT between any of the devices, and the UC560 device has a public facing interface.

I am suspecting that the UC560 won't act as a gateway on the interface that the Trixxbox is connecting to, but not sure if I can configure this safely on this device while it is effectively a call manager box?

I have since added the below commands, and then found that the successful incoming calls were no longer going via the 10.1.x.x addresses.  Outgoing calls were still unaffected though.

voice service voip

  redirect ip2ip

Here is a CCSIP debug of one of the outgoing calls.  I did notice that it appears to be attempting to send video, which doesn't seem right! Also there are errors about direction attributes?

Hope this is of assistance  - let me know if any other debugs would be useful.

The debug seems incomplete:

UC receives INVITE sip:907635782010@192.168.92.254 SIP/2.0

User-Agent: Asterisk PBX 1.6.0.26-FONCORE-r78

audio + video

but it doesn't send any sip messages to 192.168.92.9 or to SIP provider.

UC receives a TRYING, 183 session progess, 200 ok from SIP privider and send a finally ACK.

Can you add a complete debug with sent messages from UC?

Do you have already try to disable video capability in the TB?

Regards.

That is strange, as I just pasted in the full sanitised debug.  Perhaps this is another symptom of the problem?  However, I can see the CME sending the message on behalf of the TB user here:

To: <07635782010>;tag=3546235261-114320

From: "John Smith" <2086321267>;tag=682BA15C-14F0

Call-ID: 65ECD6F3-9F3811E1-9410C09D-4678902D@202.167.54.2

CSeq: 101 INVITE

I have asked the administrator of the TB to remove the video stream, and will then re-test and collect the ccsip debug.

Thanks again for your assistance.

Hi Daniele,

We did manage to get this working in the end, although removing the video stream had no effect. We did receive some information indicating that the UC560 is not officially supported for CUBE, and so we then tried switching from SIP to H.323 for the TB to UC560 hop.  This solved the problem and calls then flowed in both directions.

Thanks for your help,

MM