Problem With Yealink as External Extension

Discussion in '3CX Phone System - General' started by star1, Dec 26, 2010.

Thread Status:
Not open for further replies.
  1. star1

    Joined:
    Apr 7, 2010
    Messages:
    40
    Likes Received:
    0
    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:

    Code:
    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:9999@127.0.0.1:40600;rinstance=780b7734bc687747
    14:29:27.487  [CM503007]: Call(38): Device joined: sip:6711@79.17.185.106: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:9999@127.0.0.1:5060]
    14:29:27.471  [CM503002]: Call(38): Alerting sip:9999@127.0.0.1:40600;rinstance=780b7734bc687747
    14:29:27.315  [CM503025]: Call(38): Calling Ext:Ext.9999@[Dev:sip:9999@127.0.0.1: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:9999@127.0.0.1:40600;rinstance=780b7734bc687747]
    14:29:27.284  [CM503010]: Making route(s) to <sip:9999@65.11.85.55>
    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:6711@65.11.85.55:5060]
    14:29:27.268  [CM503001]: Call(38): Incoming call from Ext.6711 to <sip:9999@65.11.85.55>
    14:29:27.268  [CM500002]: Info on incoming INVITE:
      INVITE sip:9999@65.11.85.55 SIP/2.0
      Via: SIP/2.0/UDP 79.17.185.106:5062;rport=5062;branch=z9hG4bK1607880766
      Max-Forwards: 70
      Contact: <sip:6711@79.17.185.106:5062>
      To: <sip:9999@65.11.85.55>
      From: "Eric Mandel"<sip:6711@65.11.85.55>;tag=238181627
      Call-ID: 1785745027@192.168.10.128
      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:9999@65.11.85.55",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
     
  2. leejor

    leejor Well-Known Member

    Joined:
    Jan 22, 2008
    Messages:
    10,356
    Likes Received:
    224
    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.
     
  3. SY

    SY Well-Known Member
    3CX Support

    Joined:
    Jan 26, 2007
    Messages:
    1,825
    Likes Received:
    2
    Hi,

    The problem is that in the request, received from the phone, PBX sees only address
    the strange thing is why PBX doesn't receive traffic from the phone...
    Could you please specify network topology and describe how PBX host is conneted to local network and internet?

    Thanks
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  4. star1

    Joined:
    Apr 7, 2010
    Messages:
    40
    Likes Received:
    0
    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:
    Code:
    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
     
  5. SY

    SY Well-Known Member
    3CX Support

    Joined:
    Jan 26, 2007
    Messages:
    1,825
    Likes Received:
    2
    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 :)

    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?
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  6. star1

    Joined:
    Apr 7, 2010
    Messages:
    40
    Likes Received:
    0
    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
     
  7. SY

    SY Well-Known Member
    3CX Support

    Joined:
    Jan 26, 2007
    Messages:
    1,825
    Likes Received:
    2
    Ok, it is not a problem.

    It still unclear why
    who blocks incoming traffic to PBX?
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  8. star1

    Joined:
    Apr 7, 2010
    Messages:
    40
    Likes Received:
    0
    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?
     
  9. SY

    SY Well-Known Member
    3CX Support

    Joined:
    Jan 26, 2007
    Messages:
    1,825
    Likes Received:
    2
    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
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  10. star1

    Joined:
    Apr 7, 2010
    Messages:
    40
    Likes Received:
    0
    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
     
  11. SY

    SY Well-Known Member
    3CX Support

    Joined:
    Jan 26, 2007
    Messages:
    1,825
    Likes Received:
    2
    Eric,

    #1 is the message to PFsence to improve the service...
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  12. star1

    Joined:
    Apr 7, 2010
    Messages:
    40
    Likes Received:
    0
    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.

    Code:
    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
     
Thread Status:
Not open for further replies.