Problem With Yealink as External Extension

[star1]

We're testing out Yealink as external extensions and are having a problem at one location. We followed the config exactly and enabled rport as well as set the other settings as indicated in the support article. The sip side is working fine and the call setup is working but the RTP is not and we have no audio in either direction.

Below is the log from the server activity:

14:29:41.315  [MS105000] C:38.1: No RTP packets were received:remoteAddr=192.168.10.128:11780,extAddr=0.0.0.0:0,localAddr=65.11.85.55:10008
14:29:40.611  [CM503008]: Call(38): Call is terminated
14:29:28.252  Session 70793 of leg C:38.1 is confirmed
14:29:27.487  [CM503007]: Call(38): Device joined: sip:[email protected]:40600;rinstance=780b7734bc687747
14:29:27.487  [CM503007]: Call(38): Device joined: sip:[email protected]:5062
14:29:27.487  [MS210005] C:38.1:Answer provided. Connection(proxy mode):65.161.85.55:10008(10009)
14:29:27.471  [MS210001] C:38.2:Answer received. RTP connection[unsecure]: 127.0.0.1:40654(40655)
14:29:27.471  Remote SDP is set for legC:38.2
14:29:27.471  [CM505001]: Ext.9999: Device info: Device Identified: [Man: 3CX Ltd.;Mod: Voice Mail Menu;Rev: General] Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [3CX Voice Mail Menu] PBX contact: [sip:[email protected]:5060]
14:29:27.471  [CM503002]: Call(38): Alerting sip:[email protected]:40600;rinstance=780b7734bc687747
14:29:27.315  [CM503025]: Call(38): Calling Ext:Ext.9999@[Dev:sip:[email protected]:40600;rinstance=780b7734bc687747]
14:29:27.315  [MS210004] C:38.2:Offer provided. Connection(proxy mode): 127.0.0.1:7096(7097)
14:29:27.284  [CM503004]: Call(38): Route 1: Ext:Ext.9999@[Dev:sip:[email protected]:40600;rinstance=780b7734bc687747]
14:29:27.284  [CM503010]: Making route(s) to <sip:[email protected]>
14:29:27.268  [MS210000] C:38.1:Offer received. RTP connection: 192.168.10.128:11780(11781)
14:29:27.268  Remote SDP is set for legC:38.1
14:29:27.268  [CM505001]: Ext.6711: Device info: Device Identified: [Man: Yealink;Mod: T28;Rev: General] Capabilities:[reinvite, no-replaces, unable-no-sdp, no-recvonly] UserAgent: [Yealink SIP-T28P 2.60.0.60] PBX contact: [sip:[email protected]:5060]
14:29:27.268  [CM503001]: Call(38): Incoming call from Ext.6711 to <sip:[email protected]>
14:29:27.268  [CM500002]: Info on incoming INVITE:
  INVITE sip:[email protected] SIP/2.0
  Via: SIP/2.0/UDP 79.17.185.106:5062;rport=5062;branch=z9hG4bK1607880766
  Max-Forwards: 70
  Contact: <sip:[email protected]:5062>
  To: <sip:[email protected]>
  From: "Eric Mandel"<sip:[email protected]>;tag=238181627
  Call-ID: [email protected]
  CSeq: 2 INVITE
  Allow: INVITE, INFO, PRACK, ACK, BYE, CANCEL, OPTIONS, NOTIFY, REGISTER, SUBSCRIBE, REFER, PUBLISH, UPDATE, MESSAGE
  Proxy-Authorization: Digest username="6711",realm="3CXPhoneSystem",nonce="414d535c03282895:baa46e3e1b9dff113e0bf029de45",uri="sip:[email protected]",response="030e44a9fc7e8ad50a5c446680cff",algorithm=MD5
  Supported: replaces
  User-Agent: Yealink SIP-T28P 2.60.0.60
  Allow-Events: talk, hold, conference, refer, check-sync
  Content-Length: 0

The problem that catches my eye seems to be that the extAddr=0.0.0.0 as if it's not seeing the external address of the remote Yealink. In a packet capture, I can see that the sip packets are addressed correctly to the public IP, but the RTP packets are being sent to the private IP.

Any help or clues are appreciated.

Thanks,
Eric

 

[leejor]

Couple of things...if you are configuring a number of these sets, does this particular set work at one of the other locations? If not, and other sets do, then it is a set configuration issue. If it does work elsewhere, then check the router at the location where you are having problems, it may be blocking some ports/packets or incompatible with SIP as it stands.

Make sure that STUN is enabled and working (can the set connect to a DNS server?) on the set.

 

[SY]

Hi,

The problem that catches my eye seems to be that the extAddr=0.0.0.0 as if it's not seeing the external address of the remote Yealink

The problem is that in the request, received from the phone, PBX sees only address

4:29:27.268 [MS210000] C:38.1:Offer received. RTP connection: 192.168.10.128:11780(11781)

the strange thing is why PBX doesn't receive traffic from the phone...

14:29:41.315 [MS105000] C:38.1: No RTP packets were received:remoteAddr=192.168.10.128:11780,extAddr=0.0.0.0:0,localAddr=65.11.85.55:10008

Could you please specify network topology and describe how PBX host is conneted to local network and internet?

Thanks

 

[star1]

Hi Stepan,

Network Setup is as follows:

3CX server IP 10.1.10.118 connected to NAT firewall with statis IP and all necessary ports forwarded including the 9000 range and sip ports. Remote extensions work from other locations.

This problem extension is on a different network on the internet with an ip 192.168.10.125 (was 128 in the post above). It's behind a nat router with a dynamic IP.

Phone has stun enabled and the log from the Yealink shows it's obtaining the STUN info.

I ran some packet captures and the remote phone is sending RTP correctly to the UDP port negotiatiated and to the correct public IP of the server. The capture on the server shows the correct PORT being used to send the RTP traffic, but it's sending it to the private IP of the remote phone. So what happens is that it's receiving the RTP traffic from the phone which doesn't match a session and it's disregarding it. It's trying to send traffic to the phone but using the private IP.

Do we have a starting place to look?
Here's the info from the mediaserver log showing the RTP offer with the private IP:

05:59:52.605|.\MSEndPoint.cpp(1124)|Trace5||??:Source ports: 9014 STUN RTP:65.161.85.55:9014 RTCP:65.161.85.55:9015 mapped to 65.161.85.55, ports 9014,9015
05:59:52.605|.\MediaServer.cpp(847)|Trace5||??:EndPoint created: (destination=79.178.184.5)
EndPoint: ID=0000000F@(EXTERNAL)
  LOGID=C:8.1  Status: MSEP_STUN
  RTP:65.161.85.55:9014
  RTCP:65.161.85.55:9015
  STUN RTP:65.161.85.55:9014
  STUN RTCP:65.161.85.55:9015
  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>

05:59:52.605|.\MediaServer.cpp(1292)|Trace5||??:EP 0000000F@ joined to call 8
05:59:52.605|.\MediaServer.cpp(1301)|Trace5||??:starting send on new call 8
05:59:52.605|.\MediaServer.cpp(944)|Trace5||??:Set Party EP:C:8.1SDP:v=0
o=- 20003 20003 IN IP4 192.168.10.125
s=SDP data
c=IN IP4 192.168.10.125
t=0 0
m=audio 17000 RTP/AVP 0 8 18 9 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:9 G722/8000
a=fmtp:101 0-15
a=rtpmap:101 telephone-event/8000
a=sendrecv

05:59:52.605|.\MSEndPoint.cpp(3627)|Trace5||??:New state0000000F@ SILENCE
05:59:52.605|.\MSEndPoint.cpp(1975)|Trace5||??:partyAddrRTP_ is set to 192.168.10.125:17000
05:59:52.605|.\MSEndPoint.cpp(1976)|Trace5||??:partyAddrRTCP_ is set to 192.168.10.125:17001
05:59:52.605|.\MSEndPoint.cpp(2228)|Log2||??:[MS210000] C:8.1:Offer received. RTP connection: 192.168.10.125:17000(17001)

Should the c= in the SDP from the Yealink be the public address? Is that where 3cx is determining the RTP address to use?

Let me know what other info you have.

Thanks.
Eric

 

[SY]

If we will not change 65.11.85.55:100xx to something like 65.161.85.55:90xx
and will not change 192.168.10.128:11xxx to something like 192.168.10.125:17xxx

Then we will start to talk about same things

Should the c= in the SDP from the Yealink be the public address? Is that where 3cx is determining the RTP address to use?

It is the place wherefrom any system (not only 3cx ) is determining the RTP address to use...

Thanks

P.S. Sorry for the question. What is the device you are trying to debug?

 

[star1]

Sorry if there was confusion. We made some RTP port changes between my first and 2nd post which is why you see different ranges of RTP ports. We were trying to rule out firewall problems and conflicts. The remote station is a Yealink T28

 

[SY]

Sorry if there was confusion. We made some RTP port changes between my first and 2nd post which is why you see different ranges of RTP ports. We were trying to rule out firewall problems and conflicts. The remote station is a Yealink T28

Ok, it is not a problem.

It still unclear why

14:29:41.315 [MS105000] C:38.1: No RTP packets were received:remoteAddr=192.168.10.128:11780,extAddr=0.0.0.0:0,localAddr=65.11.85.55:10008

who blocks incoming traffic to PBX?

 

[star1]

Getting Close. After some further testing I narrowed one of the problems to the Yealink firmware. The T28 was running the newest 2.60 since the phone is brand new. We just located 2.50.0.50 and downgraded. The SDP is now including the correct public IP in the SDP packet. We now have one way audio. The remote extension can't hear anything, but can trasnmit audio to the other end.

3cx is sitting behind a PFsense firewall. I'm going to troubleshoot the one way audio a bit, but at least we ironed out the most strage problem.

How do we go about notifying Yealink of this bug?

 

[SY]

Getting Close. After some further testing I narrowed one of the problems to the Yealink firmware. The T28 was running the newest 2.60 since the phone is brand new. We just located 2.50.0.50 and downgraded. The SDP is now including the correct public IP in the SDP packet. We now have one way audio. The remote extension can't hear anything, but can trasnmit audio to the other end.

3cx is sitting behind a PFsense firewall. I'm going to troubleshoot the one way audio a bit, but at least we ironed out the most strage problem.

How do we go about notifying Yealink of this bug?

there are two problems.
1. why sending to "local" address has blocked receiving on the 3CX side? (question to PFsense)
2. ALLOWSOURCEASOUTBOUND=1 (see release notes of v9 SP5) should resolve problems in case of .50 firmware.

Regards

 

[star1]

Thanks a lot Stepan. I changed the ALLOWSOURCEASOUTBOUND to 1 and the audio is working now.

I'm not sure what you mean by #1. The "local" address it was having an error with is a private/non-routable IP on a different network. Server is 10.1.10.118 and phone is on a totally different NAT network with an IP of 192.168.10.125.

On a side note, I read the release notes about the ALLOWSOURCEASOUTBOUND parameter and I was wondering if there's a way in the future to maybe have the setting apply to only extensions and not voip providers to minimze the problems we may experience. Just a though.

Thanks a lot for your help.

-Eric

 

[SY]

Thanks a lot Stepan. I changed the ALLOWSOURCEASOUTBOUND to 1 and the audio is working now.

I'm not sure what you mean by #1. The "local" address it was having an error with is a private/non-routable IP on a different network. Server is 10.1.10.118 and phone is on a totally different NAT network with an IP of 192.168.10.125.

On a side note, I read the release notes about the ALLOWSOURCEASOUTBOUND parameter and I was wondering if there's a way in the future to maybe have the setting apply to only extensions and not voip providers to minimze the problems we may experience. Just a though.

Thanks a lot for your help.

-Eric

Eric,

#1 is the message to PFsence to improve the service...

 

[star1]

Oh. I understand your point. I don't think it's a pfsense issue. I think 3cx is disregarding it (as it should be) because it's receiving RTP packets from a source (public IP) it doesn't have a RTP session with. It thinks the RTP session is with the private IP. I'm attaching 2 packets captured during the exchange. The first is the server sending to the phone's private IP. The second is the phone's public IP sending to the server.

267	5.124386	10.1.10.118	192.168.10.125	RTP	PT=ITU-T G.711 PCMU, SSRC=0x4DB7, Seq=19828, Time=38132 
268	5.127720	79.178.184.5	10.1.10.118	UDP	Source port: 17002  Destination port: 9018