• V20: 3CX Re-engineered. Get V20 for increased security, better call management, a new admin console and Windows softphone. Learn More.

one way audio - no really !

Status
Not open for further replies.

regfixit

Joined
Mar 7, 2008
Messages
35
Reaction score
0
I know a lot of probs with one way audio due to firewall, but I really think mine is set up OK and am non-plussed. After recent upgrade to version 6.1 people can no longer hear me, but I can hear them. This is the set up:

3cx running on windows XP behind linksys wag325n router. ports 9000-9015 and 5060-5065 mapped to 3cx server pc.
voiptalk set up as voip provider
speedtouch 760wl used as analog ATA FXS with local ip 192.168.0.50
linkssys spa3102 used as FXO gateway to PSTN with locak ip 192.168.0.40

I can call between internal extensions no problem.
I can call via the linksys spa3102 no problem.

When I make a call over voiptalk I can hear remote party but they can't hear me.

I have tried using PBX delivers audio on the voiptalk line setting, but does not work either.

My Firewall test completes successfully.

From the logs it looks like call is set up OK, but I don't know what is then happening to the RTP streams.

Here is sample log of setting up a call:
10:56:41.187 Call::Terminate [CM503008]: Call(1): Call is terminated10:56:41.187 Call::Terminate [CM503008]: Call(1): Call is terminated
10:56:23.750 CallLeg::eek:nConfirmed Session 59 of leg C:1.1 is confirmed
10:56:23.640 CallCtrl::eek:nLegConnected [CM503007]: Call(1): Device joined: sip:[email protected]:5060
10:56:23.640 CallCtrl::eek:nLegConnected [CM503007]: Call(1): Device joined: sip:[email protected]:5060
10:56:23.640 MediaServerReporting::SetRemoteParty [MS210001] C:1.2:Answer received. RTP connection: 77.240.48.201:49030(49031)
10:56:23.640 CallLeg::setRemoteSdp Remote SDP is set for legC:1.2
10:56:20.546 MediaServerReporting::SetRemoteParty [MS210005] C:1.1:Answer provided. Connection(proxy mode):192.168.0.12:7100(7101)
10:56:20.546 MediaServerReporting::SetRemoteParty [MS210001] C:1.2:Answer received. RTP connection: 77.240.48.209:49030(49031)
10:56:20.546 CallLeg::setRemoteSdp Remote SDP is set for legC:1.2
10:56:20.546 Line::printEndpointInfo [CM505003]: Provider:[voiptalk] Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [] Transport: [sip:192.168.0.12:5060]
10:56:20.546 CallCtrl::eek:nAnsweredCall [CM503002]: Call(1): Alerting sip:[email protected]:5060
10:56:17.968 MediaServerReporting::SetRemoteParty [MS210004] C:1.2:Offer provided. Connection(proxy mode): 80.229.82.249:9000(9001)
10:56:17.796 CallCtrl::eek:nSelectRouteReq [CM503004]: Call(1): Calling: VoIPline:01565889108@(Ln.10001@voiptalk)@[Dev:sip:[email protected]:5060]
10:56:17.765 CallCtrl::eek:nSelectRouteReq [CM503010]: Making route(s) to "889108"[sip:[email protected]:5060]
10:56:17.765 MediaServerReporting::SetRemoteParty [MS210000] C:1.1:Offer received. RTP connection: 192.168.0.50:7302(7303)
10:56:17.765 CallLeg::setRemoteSdp Remote SDP is set for legC:1.1
10:56:17.765 Extension::printEndpointInfo [CM505001]: Ext.11: Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [SpeedTouch 780] Transport: [sip:192.168.0.12:5060]
10:56:17.750 CallCtrl::eek:nIncomingCall [CM503001]: Call(1): Incoming call from Ext.11 to "889108"[sip:[email protected]:5060]
10:56:17.750 CallLeg::eek:nNewCall [CM500002]: Info on incoming INVITE:INVITE sip:[email protected];transport=UDP SIP/2.0Via: SIP/2.0/UDP 192.168.0.50:5060;branch=z9hG4bK-33a581-c9be81d2-66cc2c2cMax-Forwards: 70Contact: [sip:[email protected]:5060;transport=UDP]To: "889108"[sip:[email protected]:5060]From: "Dom desk"[sip:[email protected]:5060];tag=80ad3718-c0a80032-13c4-33a581-5fbdf1ae-33a581Call-ID: [email protected]: 2 INVITESession-Expires: 120Min-SE: 90Allow: INVITE, ACK, BYE, REFER, NOTIFY, CANCEL, OPTIONSProxy-Authorization: Digest username="11",realm="3CXPhoneSystem",nonce="12872429777:7ceddc750d634dbb1bfda59679e0c38d",uri="sip:[email protected];transport=UDP",response="f00d6365215aa125129ef7f40500cb6d",algorithm=MD5Supported: replaces, 100rel, timerUser-Agent: SpeedTouch 780Content-Length: 0X-Serialnumber: CP0737JT3MK


and hear is media server trace:
10:56:17.750|.\MediaServer.cpp(533)|Trace5||??:EndPoint created: (destination=192.168.0.50)
EndPoint: ID=00000041@(LOCAL)
LOGID=C:1.1 Status: MSEP_LOCAL
RTP:192.168.0.12:7100
RTCP:192.168.0.12:7101
STUN RTP:0.0.0.0:0
STUN RTCP:0.0.0.0:0
Coder:
NOT SET
101:telephony-event
Party ptime:20
Party RTP:0.0.0.0:0
Party RTCP:0.0.0.0:0
Decoders:
<empty>

10:56:17.750|.\MediaServer.cpp(979)|Trace5||??:EP 00000041@ joined to call 1
10:56:17.750|.\MediaServer.cpp(988)|Trace5||??:starting send on new call 1
10:56:17.765|.\MediaServer.cpp(630)|Trace5||??:Set Party EP:C:1.1SDP:v=0
o=780 1227956602 1227956602 IN IP4 192.168.0.50
s=-
c=IN IP4 192.168.0.50
t=0 0
m=audio 7302 RTP/AVP 0 8 18 4
a=ptime:20
a=SilenceSupp:eek:ff

10:56:17.765|.\MSEndPoint.cpp(2441)|Trace5||??:New state00000041@ SILENCE
10:56:17.765|.\MSEndPoint.cpp(1457)|Log2||??:[MS210000] C:1.1:Offer received. RTP connection: 192.168.0.50:7302(7303)
10:56:17.968|.\MSEndPoint.cpp(824)|Trace5||??:Source ports: 9000 STUN RTP:80.229.82.249:9000 RTCP:80.229.82.249:9001 mapped to 80.229.82.249, ports 9000,9001
10:56:17.968|.\MediaServer.cpp(533)|Trace5||??:EndPoint created: (destination=voiptalk.org)
EndPoint: ID=00000042@(EXTERNAL)
LOGID=C:1.2 Status: MSEP_STUN
RTP:80.229.82.249:9000
RTCP:80.229.82.249:9001
STUN RTP:80.229.82.249:9000
STUN RTCP:80.229.82.249:9001
Coder:
NOT SET
101:telephony-event
Party ptime:20
Party RTP:0.0.0.0:0
Party RTCP:0.0.0.0:0
Decoders:
<empty>

10:56:17.968|.\MediaServer.cpp(979)|Trace5||??:EP 00000042@ joined to call 1
10:56:17.968|.\MediaServer.cpp(1024)|Trace5||??:EndPoint 00000042@ removed from call 1
10:56:17.968|.\MediaServer.cpp(979)|Trace5||??:EP 00000042@ joined to call 1
10:56:17.968|.\MSEndPoint.cpp(2441)|Trace5||??:New state00000042@ SILENCE
10:56:17.968|.\MSEndPoint.cpp(1180)|Log2||??:[MS210004] C:1.2:Offer provided. Connection(proxy mode): 80.229.82.249:9000(9001)
10:56:17.968|.\MediaServer.cpp(568)|Trace5||??:Get Local SDP. EP:C:1.2SDP:v=0
o=3cxPS 273082744832 139435442177 IN IP4 80.229.82.249
s=3cxPS Audio call
c=IN IP4 80.229.82.249
t=0 0
m=audio 9000 RTP/AVP 0 8 18 4
c=IN IP4 80.229.82.249
a=ptime:20
a=SilenceSupp:eek:ff

10:56:17.968|.\MediaServer.cpp(1024)|Trace5||??:EndPoint 00000042@ removed from call 1
10:56:20.546|.\MediaServer.cpp(979)|Trace5||??:EP 00000042@ joined to call 1
10:56:20.546|.\MediaServer.cpp(630)|Trace5||??:Set Party EP:C:1.2SDP:v=0
o=root 3842 3842 IN IP4 77.240.48.207
s=session
c=IN IP4 77.240.48.209
t=0 0
m=audio 49030 RTP/AVP 8 0 18 4
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:4 G723/8000
a=fmtp:4 annexa=no
a=silenceSupp:eek:ff - - - -
a=ptime:20
a=sendrecv
a=nortpproxy:yes

10:56:20.546|.\MSEndPoint.cpp(2441)|Trace5||??:New state00000042@ SILENCE
10:56:20.546|.\MSEndPoint.cpp(2441)|Trace5||??:New state00000042@ PASSTHROUGH
10:56:20.546|.\MSEndPoint.cpp(1462)|Log2||??:[MS210001] C:1.2:Answer received. RTP connection: 77.240.48.209:49030(49031)
10:56:20.546|.\MSEndPoint.cpp(2441)|Trace5||??:New state00000041@ PASSTHROUGH
10:56:20.546|.\MSEndPoint.cpp(1185)|Log2||??:[MS210005] C:1.1:Answer provided. Connection(proxy mode):192.168.0.12:7100(7101)
10:56:20.546|.\MediaServer.cpp(568)|Trace5||??:Get Local SDP. EP:C:1.1SDP:v=0
o=3cxPS 43989860352 346667614209 IN IP4 192.168.0.12
s=3cxPS Audio call
c=IN IP4 192.168.0.12
t=0 0
m=audio 7100 RTP/AVP 8 0 18 4
c=IN IP4 192.168.0.12
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:4 G723/8000
a=fmtp:4 annexa=no
a=silenceSupp:eek:ff - - - -
a=ptime:20
a=sendrecv
a=nortpproxy:yes

10:56:23.640|.\MediaServer.cpp(630)|Trace5||??:Set Party EP:C:1.2SDP:v=0
o=root 3842 3843 IN IP4 77.240.48.201
s=session
c=IN IP4 77.240.48.201
t=0 0
m=audio 49030 RTP/AVP 8 0 18 4
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:4 G723/8000
a=fmtp:4 annexa=no
a=silenceSupp:eek:ff - - - -
a=ptime:20
a=sendrecv
a=nortpproxy:yes

10:56:23.640|.\MSEndPoint.cpp(2441)|Trace5||??:New state00000042@ SILENCE
10:56:23.640|.\MSEndPoint.cpp(2441)|Trace5||??:New state00000042@ PASSTHROUGH
10:56:23.640|.\MSEndPoint.cpp(1462)|Log2||??:[MS210001] C:1.2:Answer received. RTP connection: 77.240.48.201:49030(49031)
10:56:41.171|.\MediaServer.cpp(1024)|Trace5||??:EndPoint 00000041@ removed from call 1
10:56:41.187|.\MediaServer.cpp(1024)|Trace5||??:EndPoint 00000042@ removed from call 1
10:56:41.187|.\MediaServer.cpp(783)|Trace5||??:references to EndPoint 00000041@ were removed
10:56:41.187|.\RTPReceiver.cpp(127)|Trace5||??:Endpoint for socket 924 is not found!
10:56:41.187|.\MSEndPoint.cpp(672)|Trace5||??:EndPoint 00000041@ destroyed
10:56:41.343|.\MediaServer.cpp(783)|Trace5||??:references to EndPoint 00000042@ were removed
10:56:41.343|.\RTPReceiver.cpp(127)|Trace5||??:Endpoint for socket 1004 is not found!
10:56:41.343|.\MSEndPoint.cpp(672)|Trace5||??:EndPoint 00000042@ destroyed
10:56:41.359|.\MediaServer.cpp(1102)|Trace5||??:references to call 1 were removed
10:56:41.359|.\MSCallConf.cpp(33)|Trace5||??:Call: 1 destroyed
 
Am trying to help myself as much as poss. but could someone confirm my understanding is right. Based on these logs:
10:56:17.765 C:1.1:Offer received. RTP connection: 192.168.0.50:7302(7303)
10:56:17.968 C:1.2:Offer provided. Connection(proxy mode): 80.229.82.249:9000(9001)
10:56:20.546 C:1.2:Answer received. RTP connection: 77.240.48.209:49030(49031)
10:56:20.546C:1.1:Answer provided. Connection(proxy mode):192.168.0.12:7100(7101)

Is it right to say:
1) My telephone adapter as told 3cx it will receive audio on port 7302
2) 3cx has told voiptalk it will receive audio on port 9000
3) voiptalk has told 3cx it will receive audo on port 49030
4) 3cx has told my telephone adapter it will receive audio on port 7100

Since I can hear the remote party I must assume (1) and (2) have not problem. Since I can make internal calls between extensions I would also assume that (4) must be OK (although not sure as internal calls would not be to 3cx but from ATA back to itself).

Is there a way to pick up the RTP packets on my network to check for example if my PC is actually sending RTP packets to port 49031 at voiptalk ?
 
OK I found something called Wireshark that seems to do the exact job. From what I can see on another call I analysed the RTP is flowing from TA to 3CX and Voiptalk and vice versa:
27 4.774090 192.168.0.50 192.168.0.12 RTP PT=ITU-T G.711 PCMA, SSRC=0x4A4B0BF1, Seq=10305, Time=1995069375
28 4.793994 192.168.0.50 192.168.0.12 RTP PT=ITU-T G.711 PCMA, SSRC=0x4A4B0BF1, Seq=10306, Time=1995069535
29 4.813824 192.168.0.50 192.168.0.12 RTP PT=ITU-T G.711 PCMA, SSRC=0x4A4B0BF1, Seq=10307, Time=1995069695
30 4.816332 77.240.48.209 192.168.0.12 RTP PT=ITU-T G.711 PCMA, SSRC=0x7D1C94B0, Seq=3880, Time=1023430920
31 4.825600 192.168.0.12 192.168.0.50 RTP PT=ITU-T G.711 PCMA, SSRC=0x7D1C94B0, Seq=3880, Time=1023430920
32 4.825678 192.168.0.12 77.240.48.209 RTP PT=ITU-T G.711 PCMA, SSRC=0x4A4B0BF1, Seq=10305, Time=1995069375
33 4.825709 192.168.0.12 77.240.48.209 RTP PT=ITU-T G.711 PCMA, SSRC=0x4A4B0BF1, Seq=10306, Time=1995069535
34 4.825738 192.168.0.12 77.240.48.209 RTP PT=ITU-T G.711 PCMA, SSRC=0x4A4B0BF1, Seq=10307, Time=1995069695

I would say first packets 27-29 from TA to 3cx; packet 30 is from voiptalk to 3cx; 31 is same packet from 3cx to TA; packets 32-34 are first three packets from 3cx to voiptalk

So given recipient cant hear me can I deduce that maybe:
a) my broadband router is dropping the outbound RTP traffic to voiptalk
or
b) my ISP is blocking the RTP packets to voiptalk
or
c) there is a problem at voiptalk that is causing it to reject the packets - could it be that the from address on the packet from 3cx to voiptalk is for some reason not my public IP address ?
 
Now I found some more packets called RTCP. I am seeing packets from my TA that say stuff like:
sent count = 154, highest sequence number received = 4030

and from voiptalk that say:
sent count = 224, highest sequence number received = 10524

so it seems like voiptalk IS receiving the RTP stream, just that it is silent.

Can't really understand this further. Anyone any ideas ?
 
Wow, lots of info hear.

Ok, you should not see your phone sending rtp traffic directly to voiptalk. Your pbx will automatically deliver the audio since its off network (proxy the audio).

You should see your phone sending rtp to 3cx on 7100 and 3cx sending audio to voiptalk on 49030. 3cx should be receiving audio from voiptalk on 9000.

Can you run a wireshark on your 3cx box and capturing the call setup info from voiptalk so we can see what codecs they are using?

Mike
 
actually, I see you posted your wireshark stream and it appears to be using g711....hmmm.
 
OK, do another wireshark capture on your 3cx box and post the SDP section of the SIP invite you get from voiptalk. I would like to see their codec preferences in order.

Mike
 
What operating system is 3cx installed on?
 
This is the SDP set up:
v=0
o=root 17232 17232 IN IP4 77.240.48.211
s=session
c=IN IP4 77.240.48.209
t=0 0
m=audio 53940 RTP/AVP 8 0 3 96
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:96 telephone-event/8000
a=fmtp:96 0-16
a=silenceSupp:eek:ff - - - -
a=ptime:20
a=sendrecv
a=nortpproxy:yes

I am using Windows XP service pack 2.
 
This looks to me liek they prefer g 711 a-law then u-law. What is your codec preference with the VoIP provider in 3cx?

Mike
 
The following is set in 3cx in this order for the line voiptalk:
G-711 U-law
G-711 A-law
GSM-FR

on my TA it is :
G711u
G711a
g723.1
g726_16
g726_24
g726_32
g726_40
g729
 
just for fun....move A-Law up to the top.

Mike
 
Hi,

Looks like I have the same problem.

I have an external extension which is going through a NAT (draytek) firewall to a 3CX server and out on a VoIP line. Audio is only in one direction. I'm using STUN to get around the NAT and I'm pretty sure I have all the necessary firewall ports open?

If I don't use STUN and connect direct - I can see that it's trying to set up an RTP to the internal LAN address:

[MS210000] C:45.1:Offer received. RTP connection: 192.168.1.56:10000(10001)

When I connect using STUN - I don't see this message - instead I see

[MS210002] C:48.2:Offer provided. Connection(transcoding mode): <external 3CX IP>:9000(9001)

The phone I'm using is a Linksys WIP330 with the latest firmware.

I've connected the phone via a different firewall (a Cisco ASA which I think is using PAT?) - all works fine without the need for a STUN server as the RTP connection uses the external interface of the firewall?

I too had differing Codecs - but have since aligned them up to match but still no joy..

Any ideas - this has been driving me nuts for a few days now!

Thanks,

Nick
 
The ASA will likely have fixup SIP enabled by default. This should remove the need for stun as it inspects the SIP payload and adjusts internal IPs to external IPs. Sort of like STUN but not exactly. It will adjust the IPs for your SIP and RTP streams and traverse the PAT like magic.

Im guessing your issues on the other firewall is RTP. STUN will let the phone register with its external IP but on some firewalls you need to forward your RTP range the phone uses from the outside interface of the firewall to the phone.

Is this as clear as mud?

Try seeing what RTP range your phoen is listening on and forward that range from teh firewall to the phone.

Mike
 
I managed to get calls working by changing my outbound proxy from nat.voiptalk.org:5065 to just voiptalk.org:5060 - the same as the registrar details.

Now call audio is working both ways, but outbound calls drop after 20 s. The remote party line goes dead and they hear the disconnect tone; on my side the line just goes quiet. Doesn't seem to be any disconnect message coming back to 3cx until I actually hang up my phone.

Calls into 3cx from outside (on the voiptalk line) don't have this problem and audio works fine in both directions with no disconnect.

In the call set up log I notice the call info seems to get sent twice by voiptalk - could it be that it is expecting some kind of acknowledgement back that is not arriving and so is assuming the call has not been set up ?

13:39:43.031|.\MSEndPoint.cpp(1457)|Log2||??:[MS210000] C:3.1:Offer received. RTP connection: 192.168.0.50:18894(18895)
13:39:43.218|.\MSEndPoint.cpp(1180)|Log2||??:[MS210004] C:3.2:Offer provided. Connection(proxy mode): 80.229.82.249:9002(9003)
13:39:45.640|.\MSEndPoint.cpp(1462)|Log2||??:[MS210001] C:3.2:Answer received. RTP connection: 77.240.48.206:14266(14267)
13:39:45.656|.\MSEndPoint.cpp(1185)|Log2||??:[MS210005] C:3.1:Answer provided. Connection(proxy mode):192.168.0.12:7002(7003)
13:39:48.000|.\MSEndPoint.cpp(1462)|Log2||??:[MS210001] C:3.2:Answer received. RTP connection: 77.240.48.206:14266(14267)
 
Just looked in Wireshark and I think there is some issue with things not getting sent back.

I see these messages:
480 5.095750 77.240.48.94 192.168.0.12 SIP/SDP Status: 200 OK, with session description
501 5.198655 192.168.0.12 77.240.48.94 SIP Request: ACK sip:[email protected]:5060
502 5.198725 192.168.0.12 192.168.0.50 SIP/SDP Status: 200 OK, with session description
507 5.216054 192.168.0.50 192.168.0.12 SIP Request: ACK sip:[email protected]:5060
687 6.064770 77.240.48.94 192.168.0.12 SIP/SDP Status: 200 OK, with session description

Now packet 687 has in status line part "Resent packet: True", suspected resend of frame 480.
I then see further packets like 687 until the call ends.

My guess is that packet 480 is saying "call has been answered" and is wanting a message back to say "OK" but is not recognising it coming back.
 
Have now read some of RFC3261 and think the issue is the ACK message, but not sure if this is fault of 3cx, voiptalk or my network config. I look at the wireshark exchanges between 3cx and voiptalk and see like this:

3cx sends INVITE to voiptalk:
via = internal IP of 3cx, port 5060
contact = voiptalkID @ my public IP address
to = dailed number @ voiptalk.org:5060
from = voiptalk ID @ voiptalk.org:5060
callid = xyz (there is no @ part to the callID)

voiptalk replies 100 trying, then 407 Proxy authorisation required

3cx replies with ACK message (which I believe terminates this INVITE session).

3cx sends another INVITE all same info as before, but with proxy authorisation response included

voiptalk replies with 100 trying, 100 giving a try, 183 session in progress then eventually 200 OK. It is the 200 OK which seems strange a bit. The contact field looks odd.
Record route: SIP 77.240.48.94
From = voiptalk ID @ voiptalk.org:5060
to = dialled number @ voiptalk.org:5060
contact = sip:CALL-80891223-<dialled number>@internal ip address of 3cx:5060

3cx then sends an ACK with
request line: ACK sip:CALL-80891223-<dialled number>@internal ip address of 3cx:5060
contact = voiptalkID @ my public IP address
to = dialled number @ voiptalk.org:5060
From = voiptalk ID @ voiptalk.org:5060

voiptalk then resends it's 200 OK message, 3cx replies with and ACK and this repeats several times, then the call disconnects at the remote party's end. So it looks like voiptalk is not recognising the ACK.
 
Yeah, if thats the case you may need to either open a support ticket with 3CX (requires a support contract with them) or discuss with voiptalk or possibly switch providers.
 
Thanks MIke.
I changed the outbound proxy back to nat.voiptalk.org and now it is all working OK with no disconnects.
Basically everything is now set up as it was before I tried to fix the issue and it is working.
I COULD SCREAM !!!

What I think is voiptalk must have had some probs with their proxy server that are now fixed. For info now the 200 OK message looks like this:
Contact: <sip:[email protected]>

where the last ip address is one of theirs rather than my 192.168.0.12

Thanks for reading this and helping me anyway and at least I now know more about SIP and where to start looking for problems next time............
 
No problem. Thats not an easy issue to troubleshoot. Especially since you have no control over how they implement their SIP conversations.

Mike
 
Status
Not open for further replies.
Get 3CX - Absolutely Free!

Link up your team and customers Phone System Live Chat Video Conferencing

Hosted or Self-managed. Up to 10 users free forever. No credit card. Try risk free.

3CX
A 3CX Account with that email already exists. You will be redirected to the Customer Portal to sign in or reset your password if you've forgotten it.