Only sending 1 in 6 calls over the sip

[Gideon]

Hello
I have a problem , My 3CX system is only sending 1 in 6 calls over the sip trunk , the remaining 5 calls goes nowhere. can someone give me an idea on what i can do to fix this

1005 local 3CX extension dialing 9190 3rd party PBX system

Unsuccessful call log

02/20/2018 6 :13:03 PM - Call(C:127), Extn:1005 on exit: DlgInfo(127-1439/Terminated / I)
02/20/2018 6 :13:03 PM - Call(C:127), Extn:1005 on entry: DlgInfo(127-1439/Initial / I)
02/20/2018 6 :13:03 PM - Notify dialog-info: Extn:1005: sip:[email protected]:44080;transport=TCP, Call(C:127)
02/20/2018 6 :13:03 PM - L:127.1[Extn:1005] Sending: OnSendResp Send 200/CANCEL from 0.0.0.0:0 tid=48e6cc351f8f7a10 Call-ID=XAR4LRgNoAvE7ZOLxWYM1Q..:
SIP/2.0 200 OK
Via: SIP/2.0/TCP 196.c.c.c:44080;branch=z9hG4bK-524287-1---48e6cc351f8f7a10;received=10.b.b.b
Contact: <sip:9190>
To: <sip:[email protected];transport=TCP>;tag=d2527466
From: <sip:[email protected];transport=TCP>;tag=c32f7649
Call-ID: XAR4LRgNoAvE7ZOLxWYM1Q..
CSeq: 2 CANCEL
Content-Length: 0

02/20/2018 6 :13:03 PM - Call(C:127), Extn:1005 on entry: DlgInfo(127-1300/Initial / I)
02/20/2018 6 :13:03 PM - Notify dialog-info: Extn:1005: sip:[email protected]:44080;transport=TCP, Call(C:127)
02/20/2018 6 :12:48 PM - [CM503025]: Call(C:127): Calling T:Line:10000>>9190@[Dev:sip:[email protected]:5060] for L:127.1[Extn:1005]
02/20/2018 6 :12:48 PM - [Flow] Call(C:127): making call from L:127.1[Extn:1005] to T:Line:10000>>9190@[Dev:sip:[email protected]:5060]
02/20/2018 6 :12:48 PM - [CM503027]: Call(C:127): From: Extn:1005 (<sip:[email protected]:5060>) to T:Line:10000>>9190@[Dev:sip:[email protected]:5060]
02/20/2018 6 :12:48 PM - [CM503004]: Call(C:127): Route 5: from L:127.1[Extn:1005] to T:Line:10000>>9190@[Dev:sip:[email protected]:5060]
02/20/2018 6 :12:48 PM - [Flow] Call(C:127): making call from L:127.1[Extn:1005] to T:Line:10000>>9190@[Dev:sip:[email protected]:5060]
02/20/2018 6 :12:48 PM - [CM503027]: Call(C:127): From: Extn:1005 (<sip:[email protected]:5060>) to T:Line:10000>>9190@[Dev:sip:[email protected]:5060]
02/20/2018 6 :12:48 PM - [CM503004]: Call(C:127): Route 4: from L:127.1[Extn:1005] to T:Line:10000>>9190@[Dev:sip:[email protected]:5060]
02/20/2018 6 :12:48 PM - [Flow] Call(C:127): making call from L:127.1[Extn:1005] to T:Line:10000>>9190@[Dev:sip:[email protected]:5060]
02/20/2018 6 :12:48 PM - [CM503027]: Call(C:127): From: Extn:1005 (<sip:[email protected]:5060>) to T:Line:10000>>9190@[Dev:sip:[email protected]:5060]
02/20/2018 6 :12:48 PM - [CM503004]: Call(C:127): Route 3: from L:127.1[Extn:1005] to T:Line:10000>>9190@[Dev:sip:[email protected]:5060]
02/20/2018 6 :12:48 PM - [Flow] Call(C:127): making call from L:127.1[Extn:1005] to T:Line:10000>>9190@[Dev:sip:[email protected]:5060]
02/20/2018 6 :12:48 PM - [CM503027]: Call(C:127): From: Extn:1005 (<sip:[email protected]:5060>) to T:Line:10000>>9190@[Dev:sip:[email protected]:5060]
02/20/2018 6 :12:48 PM - [CM503004]: Call(C:127): Route 2: from L:127.1[Extn:1005] to T:Line:10000>>9190@[Dev:sip:[email protected]:5060]
02/20/2018 6 :12:48 PM - [Flow] Call(C:127): making call from L:127.1[Extn:1005] to T:Line:10000>>9190@[Dev:sip:[email protected]:5060]
02/20/2018 6 :12:48 PM - [CM503027]: Call(C:127): From: Extn:1005 (<sip:[email protected]:5060>) to T:Line:10000>>9190@[Dev:sip:[email protected]:5060]
02/20/2018 6 :12:48 PM - [CM503004]: Call(C:127): Route 1: from L:127.1[Extn:1005] to T:Line:10000>>9190@[Dev:sip:[email protected]:5060]
02/20/2018 6 :12:48 PM - Call(C:127): Call from Extn:1005 to 9190 matches outbound rule 'Avaya'
02/20/2018 6 :12:48 PM - [Flow] Call(C:127): has built target endpoint: Out#:>>Rule{Avaya}>>9190 for call from L:127.1[Extn:1005]
02/20/2018 6 :12:48 PM - [CM503010]: Call(C:127): Making route(s) from Extn:1005 to <sip:[email protected]:5060>
02/20/2018 6 :12:48 PM - Remote SDP is set for leg L:127.1[Extn:1005]
02/20/2018 6 :12:48 PM - [CM505001]: Endpoint Extn:1005: Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [Z 3.15.40006 rv2.8.20] PBX contact: [sip:[email protected]:5060;transport=TCP]
02/20/2018 6 :12:48 PM - [CM500002]: Call(C:127): Info on incoming INVITE from Extn:1005:
Invite-IN Recv Req INVITE from 10.b.b.b:63717 tid=48e6cc351f8f7a10 Call-ID=XAR4LRgNoAvE7ZOLxWYM1Q..:
INVITE sip:[email protected];transport=TCP SIP/2.0
Via: SIP/2.0/TCP 196.c.c.c:44080;branch=z9hG4bK-524287-1---48e6cc351f8f7a10;received=10.b.b.b
Max-Forwards: 70
Contact: <sip:[email protected]:44080;transport=TCP>
To: <sip:[email protected];transport=TCP>
From: <sip:[email protected];transport=TCP>;tag=c32f7649
Call-ID: XAR4LRgNoAvE7ZOLxWYM1Q..
CSeq: 2 INVITE
Content-Type: application/sdp
Proxy-Authorization: Digest username="1005",realm="3CXPhoneSystem",nonce="414d53595a8c490094:03bc5e75171f4fd41d44ff71a8a90fe8",uri="sip:[email protected];transport=TCP",response="901312da2637d7420adacc6fadeb7c35",algorithm=MD5
User-Agent: Z 3.15.40006 rv2.8.20
Allow-Events: presence, kpml, talk
Content-Length: 237

 

[eddv123]

Hi Gideon,

Can you explain your topology in a little more detail, in your logs we can see "matches outbound rule 'Avaya'" are you bridging to an Avaya or something like that ?

 

[leejor]

Could the other end, be "rejecting", or placing a limit, on the number of calls over the trunk group? That fact the one calls gets through, would suggest that your outbound rules are being applied, and that suggests that call failures may be the result of a condition at the destination . Is the destination (logs?) any help in diagnosing this? Have you considered using Wireshark to see the actual SIP messages exchanged?

 

[Gideon]

Hi Gideon,

Can you explain your topology in a little more detail, in your logs we can see "matches outbound rule 'Avaya'" are you bridging to an Avaya or something like that ?

Hello Eddv123
The "avaya" is the name of the link , and it is a Sip Trunk between the 3CX and an Avaya PBX . the extension 9190 is located on the Avaya

Could the other end, be "rejecting", or placing a limit, on the number of calls over the trunk group? That fact the one calls gets through, would suggest that your outbound rules are being applied, and that suggests that call failures may be the result of a condition at the destination . Is the destination (logs?) any help in diagnosing this? Have you considered using Wireshark to see the actual SIP messages exchanged?

Hello Leerjor
I dont have anything that is rejecting the calls on the other side , in-fact they dont even get to the Avaya system(i run a trace on the Avaya side and get no data on the trunk). as i said in the start only 1 in 6 calls works with the same config, as in the 6th call i have full 2 way speech. it is only a 10 channel trunk for now but i am the only one using it. i have not looked at Wireshark yet,

Calls from the Avaya to the 3CX works 100%

i have compared the logs from a successful call with those from an unsuccessful call , and the only thing i could see that the failed calls have the

CSeq: 2 CANCEL
Content-Length: 0

in them where is a the successful calls dont have it

 

[eddv123]

Hi Gideon,

I too have trunked a 3CX and an Avaya before (but wouldn't recommend it) I found it to be a bit of a faff, but did eventually get it working. One of the issues I did experience is something similar to what you are getting - sometimes the Avaya simply ignored requests coming from 3CX.

The Avaya does have a real-time logging capability which I found extremely useful for diagnosing the issue(s) I was getting however - you may want to take a look at this.

I did also write a guide on this - although it sounds like you have the bridge up and running it maybe of use to see if there are any settings that differ, let me know and I can PM across.

 

[Gideon]

i am just confused as to why this is happening on some of the calls and not all the calls

 

[eddv123]

Then I would try the real-time debugger (it will give you an output from the Avaya side for SIP messages etc) and compare a call that works and a call that fails.

Is this connection going across a VPN or direct ? direct could obviously incorporate firewall related issues also such as SIP ALG.

 

[Gideon]

The connections is direct , and there is no firewall between the 2 systems , they on the same vlan