one way audio - no really !

Discussion in '3CX Phone System - General' started by regfixit, Nov 29, 2008.

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

    Joined:
    Mar 7, 2008
    Messages:
    35
    Likes Received:
    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:844114078@voiptalk.org:5060
    10:56:23.640 CallCtrl::eek:nLegConnected [CM503007]: Call(1): Device joined: sip:11@192.168.0.50: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:844114078@voiptalk.org: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:844114078@voiptalk.org:5060]
    10:56:17.765 CallCtrl::eek:nSelectRouteReq [CM503010]: Making route(s) to "889108"[sip:889108@192.168.0.12: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:889108@192.168.0.12:5060]
    10:56:17.750 CallLeg::eek:nNewCall [CM500002]: Info on incoming INVITE:INVITE sip:889108@192.168.0.12;transport=UDP SIP/2.0Via: SIP/2.0/UDP 192.168.0.50:5060;branch=z9hG4bK-33a581-c9be81d2-66cc2c2cMax-Forwards: 70Contact: [sip:11@192.168.0.50:5060;transport=UDP]To: "889108"[sip:889108@192.168.0.12:5060]From: "Dom desk"[sip:11@192.168.0.12:5060];tag=80ad3718-c0a80032-13c4-33a581-5fbdf1ae-33a581Call-ID: 80ad0ae8-c0a80032-13c4-33a581-c2a6d22-33a581@192.168.0.12CSeq: 2 INVITESession-Expires: 120Min-SE: 90Allow: INVITE, ACK, BYE, REFER, NOTIFY, CANCEL, OPTIONSProxy-Authorization: Digest username="11",realm="3CXPhoneSystem",nonce="12872429777:7ceddc750d634dbb1bfda59679e0c38d",uri="sip:889108@192.168.0.12;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
     
  2. regfixit

    Joined:
    Mar 7, 2008
    Messages:
    35
    Likes Received:
    0
    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 ?
     
  3. regfixit

    Joined:
    Mar 7, 2008
    Messages:
    35
    Likes Received:
    0
    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 ?
     
  4. regfixit

    Joined:
    Mar 7, 2008
    Messages:
    35
    Likes Received:
    0
    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 ?
     
  5. worksighted

    worksighted New Member

    Joined:
    Aug 19, 2008
    Messages:
    204
    Likes Received:
    0
    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
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  6. worksighted

    worksighted New Member

    Joined:
    Aug 19, 2008
    Messages:
    204
    Likes Received:
    0
    actually, I see you posted your wireshark stream and it appears to be using g711....hmmm.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  7. worksighted

    worksighted New Member

    Joined:
    Aug 19, 2008
    Messages:
    204
    Likes Received:
    0
    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
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  8. sharksfan

    Joined:
    Nov 7, 2008
    Messages:
    7
    Likes Received:
    0
    What operating system is 3cx installed on?
     
  9. regfixit

    Joined:
    Mar 7, 2008
    Messages:
    35
    Likes Received:
    0
    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.
     
  10. worksighted

    worksighted New Member

    Joined:
    Aug 19, 2008
    Messages:
    204
    Likes Received:
    0
    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
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  11. regfixit

    Joined:
    Mar 7, 2008
    Messages:
    35
    Likes Received:
    0
    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
     
  12. worksighted

    worksighted New Member

    Joined:
    Aug 19, 2008
    Messages:
    204
    Likes Received:
    0
    just for fun....move A-Law up to the top.

    Mike
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  13. ngunn

    Joined:
    Dec 5, 2008
    Messages:
    3
    Likes Received:
    0
    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
     
  14. worksighted

    worksighted New Member

    Joined:
    Aug 19, 2008
    Messages:
    204
    Likes Received:
    0
    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
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  15. regfixit

    Joined:
    Mar 7, 2008
    Messages:
    35
    Likes Received:
    0
    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)
     
  16. regfixit

    Joined:
    Mar 7, 2008
    Messages:
    35
    Likes Received:
    0
    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:CALL-80891223-01565889108@192.168.0.12: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:11@192.168.0.12: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.
     
  17. regfixit

    Joined:
    Mar 7, 2008
    Messages:
    35
    Likes Received:
    0
    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.
     
  18. worksighted

    worksighted New Member

    Joined:
    Aug 19, 2008
    Messages:
    204
    Likes Received:
    0
    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.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  19. regfixit

    Joined:
    Mar 7, 2008
    Messages:
    35
    Likes Received:
    0
    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:CALL-63527401-01565889108@77.240.48.208>

    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............
     
  20. worksighted

    worksighted New Member

    Joined:
    Aug 19, 2008
    Messages:
    204
    Likes Received:
    0
    No problem. Thats not an easy issue to troubleshoot. Especially since you have no control over how they implement their SIP conversations.

    Mike
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
Thread Status:
Not open for further replies.