SPA8000 is unable to use different IP for RTP

[jonas.thomsen]

Hi,

I have been using an SPA8000 for some years now, running three VOIP lines. Now, my provider has changed their servers resulting in SIP and RTP running on different IPs. Unfortunately I cannot get the SPA8000 to work in this scenario. Based on packet inspection I have noticed that the SPA8000 seems to ignore the "Connection Information" sent in the SDP packet; it sees the "Media Description" and then starts communicating with the "Owner/Creator" IP address on the port in "Media Description". This results in no voice data being transferred.

Anyone having suggestions on how to solve this?

Kind regards,

Jonas Thomsen

[Daniele Giordano]

I've the same scenario:

SPA8000 <====> SIP Signaling gateway

||===========> RTP Media gateway

But all works right.

Whst is the firmware version of the SPA?

Do you use SIP over TCP or UDP?

Can you add the SPA syslog?

Regards.

[jonas.thomsen]

I am running 6.1.10(001) firmware, which I think is the latest. I use SIP over UDP.

Since my previous post I have looked deeper into the problem. When I receive calls, the SPA is able to transmit media from the other end to my phones, but the media going out is being sent to a wrong IP. If I initiate the call, I do not receive any media from the other end and my outgoing media is sent to the wrong IP.

Just to sketch my setup, I have a Linux-computer acting as firewall/route connected directly to the Internet. The SPA is behind this Linux-box, where I NAT all relevant SIP-port to it. It all worked perfectly for years until the provider change their setup. I actually think that they useded TCP previously and now only use UDP, but this has not been confirmed by a network traffic dump.

Just now I have discovered some lines in the firewall log showing traffik from the other (media) address being rejected. I will have to investigate that further to make sure that this isn't the problem.

- Jonas

[jonas.thomsen]

The rejected packets in the firewall did not solve the problem. The SPA still connects to a wrong IP-address.

- Jonas

[Daniele Giordano]

Can you collect a trace of the call direct on the firewall using tcpdump?

Regards.

[jonas.thomsen]

I have attached two traces, in both cases I have removed all unrelated packages and taken most of the actual media data out as well. I have, however, left sufficient packages to see the trend.

The trace for an incoming call results in no audio in any direction. The trace for an outgoing call results in incoming audio but no outgoing audio.

- Jonas

[Daniele Giordano]

I've looked your traces. My scenario is different from your.

In the Sonus SDP message in the "o" and "c" field there are two different IP address.

SONUS SDP:

Owner/Creator, Session Id (o): Sonus_UAC 28617 19895 IN IP4 94.18.72.13

Connection Information (c): IN IP4 94.18.72.12

Usually are the same.

I've noted also a different ptime between Sonus and your SPA.

SONUS:

Media Attribute (a): maxptime:20

SPA:

Media Attribute (a): ptime:30

Try to set the SPA ptime to 20 msec.

Use the "RTP Packet Size" field under VOICE - SIP menu.

Let me know the result.

Regards.

[jonas.thomsen]

Now you have concluded what I wrote initially :-). It seems like the SPA communicates with the Owner/Creater (o) address and not the one in Connection (c). I have now changed the time/packet size and the result is the same. The fundamental problem is the wrong IP-address.

- Jonas

[jonas.thomsen]

So can we conclude that the SPA8000 has a software bug in handling SDP's with different o and c IP-address?

Is there any chance that Cisco will fix this bug and how can it be repported to the right people?

- Jonas

[Daniele Giordano]

I suggest you to contact the Cisco Small Business support center via telephone, explain the problem already detailed in the forum and ask to open a case.

I succesfully opened some cases and I got some bug fixed firmware but not rapidly.

Regards.

[jonas.thomsen]

Does someone have an SPA8000 purchased recently or under a service contract? Mine is out of warranty so Cisco won't open a ticket for this problem even though it is a problem with all the devices. They did, however, promise to forward this thread to someone relevant, but no answer so far.

If we could find a device within warranty, we could use that serial number to open a ticket.

- Jonas