I have two endpoints in different local networks communicating with each other through VCS Expressway.
The issue is that I have two-way video but no audio.
After looking at the logs I see that one of the endpoints is communicating different ports for audio and video in SDP than the ports it actually uses.
Even though the ports are different the video sets up but the audio doesn't.
What might be causing this issue?
Which protocol do you use, sip unencryped? interworking to h323 used, ice/turn/stun?
Golden rule: open the right ports in the firewall (chek on the vcs https://
and double check that no l3 aware device is in between (firewall, alg, inspection, nat helper, ...)
This is a SIP to SIP call using TLS between a C-series codec in one location and Jabber Video in another, ICE is not used.
Since TLS is used no ALG should be affecting the communication.
The RTP streams actually flow to the correct ports on VCS Expressway but with different source port numbers than the ones negotiated in SDP (from the location of Jabber, the C-series is ok).
And what is strange video works, audio doesn't.
So can I assume right that you did a debug session on the VCSs/Jabber (jabber or JabberVideo?)/C-Series?
If not there is a high chance that you should not see the SDP otherwise.
That you will see different source ports will most likely be ok, If the client is behind nat, the NAT
might change the source ports of the client, the VCS should send an answer back to the same
Did you check if its not something as simple as a wrong audio device setting? :-)
i would check if the call is flowing somewhere where it should not (like looping through some other box like a vcsc)
and if the call is really all the way sip-tls (have also never seen an alg causing issues on sip-tls, but who knows
when the first alg has a default sip-man-in-the-middle inspection :-)
Do you do anything fancy on the rtp ports, like limiting it to a to low number of ports=
Then check if you can pinpoint the issue by testing with other working components, like is the c not receiving
audio or the jabber not sending and so on, ...
Try to isolate the issue.
If you need more help, I guess its time to make a drawing and a overview of the used components and call flow
and post the traces you made.
In general such a simple call should work fine!
Thanks for the comments Martin.
Yes, I've run a netlog 2 and tcpdump on VCS-E.
The device settings where the first thing to check and although I didn't do it myself I assume the configuration is ok
This is a really simple call as on the diagram below with default port configurations. I don't have any control over the firewalls.
Below is the call flow as seen on the VCS (just included the audio ports). I'm not sure why there are two 200 OK's.
When looking at the tcpdump UDP flow is coming from C20 on port 2408 to port 51746 (as negotiated in SDP).
But for Movi, the UDP flow is coming from port 1468 to port 51816 (the negotiated ports were 21138 and 51816).
The same is for video (+2 to the port number) but somehow video works and audio doesn't.
You never specified which audio is gone, both, receiving on the c20 or receiving on the jabber video client.
Never assume that the device is ok, especially if you have movi where it can be a muted mic or the c20
where somebody might have used an external mic which does not work or a sound system which is not turned on,
sometimes its the easy things in life :-)
Espeically if you would see (audio+video)+rtcp packets, also interesting could be the packet statistics when
the call is up. Also check the codecs which are used.
Like I said its most likely that you will not see the src of the movi client as being the one mentioned in the RTP
if you use nat which is at least in our scenarios most often the case for internal/home networks.
But thats what the VCS-E is good for and it will simply answer and reply the rtp to the ports it received it from.
Thats a often used way to handle nat and rtp.
How many seconds after the first OK do you see the second one? If it is the same seq number?
There is no audio both ways.
I only assumed that the device is ok because I was able to sit at the device for a moment when the test took place
The first OK arrived at 09:46:40,667 and the second at 09:46:41,168 so 0,5 s. This is the same CSeq and Call-ID and the content is exactly the same.
Also in the tcpdump I've noticed several ICMP destination unreachable packets but it happens for different port numbers so maybe this is no indication of a problem.