Ошибка совершения звонка yealink forbidden - Решение и исправление самых разных ошибок на TopOshibok.ru

Outgoing calls fail — Forbidden — TotalNet — 03-31-2020 05:40 AM

My business is closed due to the national lockdown here in NZ and I’m trying to get my business phones working from my home office and it’s not going so well. Any help for a Yealink newcomer is gratefully appreciated!

Essentially, I believe my ISP/VoIP provider is blocking my outgoing calls from off-network, however, they have said no at 1st level support so I need some ammo to get through to level 4 ideally.

I have a W60B with 1 W56H and a T41S with the DD10 DECT adapter.

The line is registered and receives incoming calls on that line. When I attempt an outgoing call if fails quickly with «Forbidden».

There are other accounts registered on the W60B with a cloud PBX and my home ISP/VoIP working perfectly. I have set up the T41S for this account without the DECT adapter and get the same failure.

At the business office I use a CISCO ATA (SPA112) for this line and have used its settings for the registration on the W60B, with the intention of replacing it with the Yealink setup soon. This ATA device does not work from my home office either.

I have setup a syslog server to trace the call process and can attach here but the key entries I see are:

— a new call is established (call staus update [0]==>[2])
— a packet is successfully sent to the SIP server and a reply received
— a couple more exchanges of packets with the SIP server
— call status changes to 19 (call status update [2]==>[19])
— the call is released <<RELEASE-REASON>> (0xe2)

There is no SIP proxy involved, the connection is UDP only.

I’m sure there are many reasons behind a «forbidden» call failure (it’s often as much about what’s not in the log) so please let me know if there’s another area I can look at, perhaps it’s my network setup (NAT?) which is why the ATA I brought home doesn’t work either.

Here’s a highlight of the syslog output (phone# replace with NN):

Code:

DCX <5+notice> 632.873.481:TX[0] HS 2 --> T[55597] {CC-INFO} P_IT(240) DCX <5+notice> 632.873.625: <<Calling Party Number>> (0x6c) DCX <5+notice> 632.873.769: Number type: DCX <5+notice> 632.873.910: Numbering plan: ISDN/telephony plan DCX <5+notice> 632.874.055: Presentation indicator: , Screening indicator: User-provided, not screened DCX <5+notice> 632.875.883: Number: 0xNN ("N") 0xNN ("N") 0xNN ("N") 0xNN ("N") 0xNN ("N") 0xNN ("N") 0xNN ("N") 0xNN ("N") 0xNN ("N") DCX <5+notice> 632.876.071: <<Calling Party Name>> (0x6d) DCX <5+notice> 632.876.227: "NNNNNNNNN DCX <5+notice> 632.876.373: <<Call information>> (0x7e) DCX <5+notice> 632.876.518: Call ID: 0x0 DCX <5+notice> 632.879.676: DCX <5+notice> 632.879.872: APP <5+notice> [SIP] SIP_C2S_CALL_NEW_OUTGOING, lid:0, cid:32795,callmask:0x00000000,callee:NNNNNNNNN CAL <5+notice> [000] call status update [0]==>[2] DLG <5+notice> [000] Sending Packet :to dest=119.224.142.182:5060 msglen = 929 DLG <5+notice> [000] End of Sending Packet :msglen = 929 NET <5+notice> [000] ===>>>> UDP socket 119.224.142.182:5060: send 929 bytes NET <5+notice> [255] <<<<=== UDP socket 119.224.142.182:5060: read 246 bytes DLG <5+notice> [000] Data Received :from src=119.224.142.182:5060 msglen = 246 DLG <5+notice> [000] End of Data Received :msglen = 246 NET <5+notice> [255] <<<<=== UDP socket 119.224.142.182:5060: read 277 bytes DLG <5+notice> [000] Data Received :from src=119.224.142.182:5060 msglen = 277 DLG <5+notice> [000] End of Data Received :msglen = 277 DLG <5+notice> [000] Sending Packet :to dest=119.224.142.182:5060 msglen = 318 DLG <5+notice> [000] End of Sending Packet :msglen = 318 NET <5+notice> [000] ===>>>> UDP socket 119.224.142.182:5060: send 318 bytes CAL <5+notice> [000] call status update [2]==>[19] SS7 <5+notice> 633.047.590:SS7_ReqRelExt instance=0x1003000e, reason=0x75,msg:(null) rel_msg_len=0 SS7 <5+notice> 633.048.034:service_SS7_ReqRel inst=0x1003000e,Reason=117,Call Id:0 APPC<5+notice> 633.048.266:appmedia_CallObjMediaStop inst:0xf,ChannelID:0 APPC<5+notice> 633.048.453:CallObjMediaSet inst:0xf,state:1 APPC<5+notice> 633.050.701:appcall_ReleaseCall CallId:0, Reason:0x75, RelMsgLen:0, CallIns:0xf, Hs:2 DCX <5+notice> 633.261.418: DCX <5+notice> 633.261.635:FTMLP_ID/0,3,8,0x0,0x0,0,<0> DCX <5+notice> 633.291.416: DCX <5+notice> 633.291.633:FTMLP_ID/0,3,7,0x4,0x0,4,<0> DCX <5+notice> 633.331.383: DCX <5+notice> 633.331.590:FTMLP_ID/0,3,7,0x5,0x0,5,<0> DCX <5+notice> 633.351.965: DCX <5+notice> 633.352.222:FTMLP_ID/0,3,7,0x6,0x0,6,<0> DCX <5+notice> 633.352.379: DCX <5+notice> 633.352.528:RX[0] HS 2 <-- T(55645) {CC-RELEASE-COM} [HS-2] P_IT(140) DCX <5+notice> 633.352.676: <<RELEASE-REASON>> (0xe2) DCX <5+notice> 633.352.819: Normal

Whether making a call or not I also get the occasional DESV<3+error > 792.450.786:get_ip failed ret= -1

I would port my phone number to the cloud PBX but I get an unbeatable package with unlimited free national and mobile calls on 2 lines Sad

Cheers for any assistance

Richard

RE: Outgoing calls fail — Forbidden — complex1 — 03-31-2020 08:14 AM

(03-31-2020 05:40 AM)TotalNet Wrote: My business is closed due to the national lockdown here in NZ and I’m trying to get my business phones working from my home office and it’s not going so well. Any help for a Yealink newcomer is gratefully appreciated!

Essentially, I believe my ISP/VoIP provider is blocking my outgoing calls from off-network, however, they have said no at 1st level support so I need some ammo to get through to level 4 ideally.

I have a W60B with 1 W56H and a T41S with the DD10 DECT adapter.

The line is registered and receives incoming calls on that line. When I attempt an outgoing call if fails quickly with «Forbidden».

There are other accounts registered on the W60B with a cloud PBX and my home ISP/VoIP working perfectly. I have set up the T41S for this account without the DECT adapter and get the same failure.

At the business office I use a CISCO ATA (SPA112) for this line and have used its settings for the registration on the W60B, with the intention of replacing it with the Yealink setup soon. This ATA device does not work from my home office either.

I have setup a syslog server to trace the call process and can attach here but the key entries I see are:

— a new call is established (call staus update [0]==>[2])
— a packet is successfully sent to the SIP server and a reply received
— a couple more exchanges of packets with the SIP server
— call status changes to 19 (call status update [2]==>[19])
— the call is released <<RELEASE-REASON>> (0xe2)

There is no SIP proxy involved, the connection is UDP only.

I’m sure there are many reasons behind a «forbidden» call failure (it’s often as much about what’s not in the log) so please let me know if there’s another area I can look at, perhaps it’s my network setup (NAT?) which is why the ATA I brought home doesn’t work either.

Here’s a highlight of the syslog output (phone# replace with NN):

Code:

DCX <5+notice> 632.873.481:TX[0] HS 2 --> T[55597] {CC-INFO} P_IT(240) DCX <5+notice> 632.873.625: <<Calling Party Number>> (0x6c) DCX <5+notice> 632.873.769: Number type: DCX <5+notice> 632.873.910: Numbering plan: ISDN/telephony plan DCX <5+notice> 632.874.055: Presentation indicator: , Screening indicator: User-provided, not screened DCX <5+notice> 632.875.883: Number: 0xNN ("N") 0xNN ("N") 0xNN ("N") 0xNN ("N") 0xNN ("N") 0xNN ("N") 0xNN ("N") 0xNN ("N") 0xNN ("N") DCX <5+notice> 632.876.071: <<Calling Party Name>> (0x6d) DCX <5+notice> 632.876.227: "NNNNNNNNN DCX <5+notice> 632.876.373: <<Call information>> (0x7e) DCX <5+notice> 632.876.518: Call ID: 0x0 DCX <5+notice> 632.879.676: DCX <5+notice> 632.879.872: APP <5+notice> [SIP] SIP_C2S_CALL_NEW_OUTGOING, lid:0, cid:32795,callmask:0x00000000,callee:NNNNNNNNN CAL <5+notice> [000] call status update [0]==>[2] DLG <5+notice> [000] Sending Packet :to dest=119.224.142.182:5060 msglen = 929 DLG <5+notice> [000] End of Sending Packet :msglen = 929 NET <5+notice> [000] ===>>>> UDP socket 119.224.142.182:5060: send 929 bytes NET <5+notice> [255] <<<<=== UDP socket 119.224.142.182:5060: read 246 bytes DLG <5+notice> [000] Data Received :from src=119.224.142.182:5060 msglen = 246 DLG <5+notice> [000] End of Data Received :msglen = 246 NET <5+notice> [255] <<<<=== UDP socket 119.224.142.182:5060: read 277 bytes DLG <5+notice> [000] Data Received :from src=119.224.142.182:5060 msglen = 277 DLG <5+notice> [000] End of Data Received :msglen = 277 DLG <5+notice> [000] Sending Packet :to dest=119.224.142.182:5060 msglen = 318 DLG <5+notice> [000] End of Sending Packet :msglen = 318 NET <5+notice> [000] ===>>>> UDP socket 119.224.142.182:5060: send 318 bytes CAL <5+notice> [000] call status update [2]==>[19] SS7 <5+notice> 633.047.590:SS7_ReqRelExt instance=0x1003000e, reason=0x75,msg:(null) rel_msg_len=0 SS7 <5+notice> 633.048.034:service_SS7_ReqRel inst=0x1003000e,Reason=117,Call Id:0 APPC<5+notice> 633.048.266:appmedia_CallObjMediaStop inst:0xf,ChannelID:0 APPC<5+notice> 633.048.453:CallObjMediaSet inst:0xf,state:1 APPC<5+notice> 633.050.701:appcall_ReleaseCall CallId:0, Reason:0x75, RelMsgLen:0, CallIns:0xf, Hs:2 DCX <5+notice> 633.261.418: DCX <5+notice> 633.261.635:FTMLP_ID/0,3,8,0x0,0x0,0,<0> DCX <5+notice> 633.291.416: DCX <5+notice> 633.291.633:FTMLP_ID/0,3,7,0x4,0x0,4,<0> DCX <5+notice> 633.331.383: DCX <5+notice> 633.331.590:FTMLP_ID/0,3,7,0x5,0x0,5,<0> DCX <5+notice> 633.351.965: DCX <5+notice> 633.352.222:FTMLP_ID/0,3,7,0x6,0x0,6,<0> DCX <5+notice> 633.352.379: DCX <5+notice> 633.352.528:RX[0] HS 2 <-- T(55645) {CC-RELEASE-COM} [HS-2] P_IT(140) DCX <5+notice> 633.352.676: <<RELEASE-REASON>> (0xe2) DCX <5+notice> 633.352.819: Normal

Whether making a call or not I also get the occasional DESV<3+error > 792.450.786:get_ip failed ret= -1

I would port my phone number to the cloud PBX but I get an unbeatable package with unlimited free national and mobile calls on 2 lines

Cheers for any assistance

Richard

Hi Richard,

Let me sum it up if I understand your issue.
At your business office you use a W60B with two accounts, 1 business and 1 private.
The W56H and T41S are both connected to the W60B.
All work well, no issues.

Because of the lockdown you must work at home, so you take the W60B, W56H and T41S with you and place it in your home office.

Now you have issues… and only with outbound business calls.
No issues with incoming calls, business or private, at all.

I do not think there are issues with you modem/router or other network component at your home, but you can always check if the SIP ALG feature in your modem/router is disabled.
SIP ALG should be a SIP helper but it create more issues than it is doing good.
Also check the port (forward) setting of your business and home router if they are setup different.
Why: SPA112 at the office don’t work… different LAN IP-address and that’s why it cannot communicate with your business VoIP provider?

It is a nasty issue.

RE: Outgoing calls fail — Forbidden — TotalNet — 03-31-2020 11:32 AM

(03-31-2020 08:14 AM)complex1 Wrote: Let me sum it up if I understand your issue.
At your business office you use a W60B with two accounts, 1 business and 1 private.
The W56H and T41S are both connected to the W60B.
All work well, no issues.

Not quite. The Yealink setup is new and not yet deployed so I am trying to get it working from home by registering the main business phone number on the W60B to make/take business calls at home. The Cisco ATA was working at the office and I have brought it home, I can’t make calls from home on this either. Both register and can receive calls with audio working in both directions, they just can’t initiate calls.

I have 4 other personal SIP accounts with 3 different providers that do work at home on the Yealink setup.

Thanks for the tip on SIP ALG, I have disabled this on the Unifi USG in the controller. This hasn’t made a difference yet but I will reboot everything in the morning to see if that changes. This also gives me something to discuss with tech support at my ISP but I don’t expect much, on a business package they set me up with a consumer grade Router/WiFi/modem/Firewall (that got hacked within 2 days of going online) and if you’re not using that then support kind of halts!

RE: Outgoing calls fail — Forbidden — complex1 — 03-31-2020 12:18 PM

(03-31-2020 11:32 AM)TotalNet Wrote: The Yealink setup is new and not yet deployed so I am trying to get it working from home by registering the main business phone number on the W60B to make/take business calls at home. The Cisco ATA was working at the office and I have brought it home, I can’t make calls from home on this either. Both register and can receive calls with audio working in both directions, they just can’t initiate calls.

I guess your provider is blocking unknown IP-addresses to avoid unauthorized calls.
They only validated your main office IP-address.

SOLVED: Outgoing calls fail — Forbidden — TotalNet — 05-07-2020 08:30 PM

(03-31-2020 12:18 PM)complex1 Wrote:

(03-31-2020 11:32 AM)TotalNet Wrote: The Yealink setup is new and not yet deployed so I am trying to get it working from home by registering the main business phone number on the W60B to make/take business calls at home. The Cisco ATA was working at the office and I have brought it home, I can’t make calls from home on this either. Both register and can receive calls with audio working in both directions, they just can’t initiate calls.

I guess your provider is blocking unknown IP-addresses to avoid unauthorized calls.
They only validated your main office IP-address.

Turns out this is the most likely case, the Yealink phones are now in the office with the only change being the internal IP address and working well.

I was hoping the syslog output of the W60B would include more detail on the response from the SIP proxy like a response code, is that encrypted in the packet received from the proxy or does the proxy even give detail?

There’s no support article here to indicate what call status 19 actual means or if it’s just a generic response for call failure.

My home ISP is part of the same group of companies as the office ISP and tech support said it shouldn’t be a problem. The evidence suggests otherwise — that my home connection is considered off-network.

Thanks for all the replies. Disappointed that my ISP couldn’t assist during an event like this but so far liking the Yealink products.

<— SIP read from UDP:195.5.0.83:5060 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.10.10.110:5060;received=195.88.113.188;branch=z9hG4bK43d6f2c9;rport=60638
From: <sip:380892506511@sip.ukrtel.net>;tag=as4b83d39a
To: <sip:380892506511@195.5.0.83>;tag=aprqcvrsqu2-p2r94110000u6
Call-ID: 7fae610b155ea1e37031b9577cd780e1@127.0.1.1
CSeq: 111 REGISTER
Contact: <sip:380892506511@195.5.0.83>;expires=30

<————->
— (7 headers 0 lines) —
Scheduling destruction of SIP dialog ‘7fae610b155ea1e37031b9577cd780e1@127.0.1.1’ in 32000 ms (Method: REGISTER)
[Jul 30 15:05:31] NOTICE[1767]: chan_sip.c:18399 handle_response_register: Outbound Registration: Expiry for sip.ukrtel.net is 120 sec (Scheduling reregistration in 105 s)
== Using SIP RTP CoS mark 5
— Executing [90800506800@phones:1] Verbose(«SIP/101-00000028», «########## call from the SIP_ALL_OUT ###########») in new stack
########## call from the SIP_ALL_OUT ###########
— Executing [90800506800@phones:2] Dial(«SIP/101-00000028», «SIP/ukrtelecom/0800506800,120») in new stack
== Using SIP RTP CoS mark 5
Audio is at 10.10.10.110 port 15890
Adding codec 0x4 (ulaw) to SDP
Adding codec 0x8 (alaw) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
Reliably Transmitting (NAT) to 195.5.0.83:5060:
INVITE sip:0800506800@sip.ukrtel.net SIP/2.0
Via: SIP/2.0/UDP 10.10.10.110:5060;branch=z9hG4bK671ecf1e;rport
Max-Forwards: 70
From: «101» <sip:380892506511@sip.ukrtel.net>;tag=as6f72688f
To: <sip:0800506800@sip.ukrtel.net>
Contact: <sip:380892506511@10.10.10.110>
Call-ID:

12d9dcd953de7a8f514a05ee6a480ebb@sip.ukrtel.net

CSeq: 102 INVITE
User-Agent: Asterisk PBX 1.6.2.9-2+squeeze6
Date: Mon, 30 Jul 2012 12:05:39 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 271

v=0
o=root 1856866922 1856866922 IN IP4 10.10.10.110
s=Asterisk PBX 1.6.2.9-2+squeeze6
c=IN IP4 10.10.10.110
t=0 0
m=audio 15890 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv

—
— Called ukrtelecom/0800506800

<— SIP read from UDP:195.5.0.83:5060 —>
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.10.10.110:5060;received=195.88.113.188;branch=z9hG4bK671ecf1e;rport=60638
From: «101» <sip:380892506511@sip.ukrtel.net>;tag=as6f72688f
To: <sip:0800506800@195.5.0.83>
Call-ID:

12d9dcd953de7a8f514a05ee6a480ebb@sip.ukrtel.net

CSeq: 102 INVITE

<————->
— (6 headers 0 lines) —

<— SIP read from UDP:195.5.0.83:5060 —>
SIP/2.0 407 Proxy authentication required
Via: SIP/2.0/UDP 10.10.10.110:5060;received=195.88.113.188;branch=z9hG4bK671ecf1e;rport=60638
From: «101» <sip:380892506511@sip.ukrtel.net>;tag=as6f72688f
To: <sip:0800506800@195.5.0.83>;tag=896FD33D68B66E113617ECF08AC04D4013436499839011779
Call-ID:

12d9dcd953de7a8f514a05ee6a480ebb@sip.ukrtel.net

CSeq: 102 INVITE
Content-Length: 0
Proxy-Authenticate: Digest realm=»sip.ukrtel.net»,domain=»sip.ukrtel.net»,nonce=»MTM0MzY0OTk4MzpTREZTZXJ2ZXJTZWNyZXRLZXk6MTM2NDM0OTE0Mg==»,algorithm=MD5
Organization: Ukrtelecom

<————->
— (9 headers 0 lines) —
Transmitting (NAT) to 195.5.0.83:5060:
ACK sip:0800506800@sip.ukrtel.net SIP/2.0
Via: SIP/2.0/UDP 10.10.10.110:5060;branch=z9hG4bK671ecf1e;rport
Max-Forwards: 70
From: «101» <sip:380892506511@sip.ukrtel.net>;tag=as6f72688f
To: <sip:0800506800@sip.ukrtel.net>;tag=896FD33D68B66E113617ECF08AC04D4013436499839011779
Contact: <sip:380892506511@10.10.10.110>
Call-ID:

12d9dcd953de7a8f514a05ee6a480ebb@sip.ukrtel.net

CSeq: 102 ACK
User-Agent: Asterisk PBX 1.6.2.9-2+squeeze6
Content-Length: 0

—
Audio is at 10.10.10.110 port 15890
Adding codec 0x4 (ulaw) to SDP
Adding codec 0x8 (alaw) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
Reliably Transmitting (NAT) to 195.5.0.83:5060:
INVITE sip:0800506800@sip.ukrtel.net SIP/2.0
Via: SIP/2.0/UDP 10.10.10.110:5060;branch=z9hG4bK69060425;rport
Max-Forwards: 70
From: «101» <sip:380892506511@sip.ukrtel.net>;tag=as6f72688f
To: <sip:0800506800@sip.ukrtel.net>
Contact: <sip:380892506511@10.10.10.110>
Call-ID:

12d9dcd953de7a8f514a05ee6a480ebb@sip.ukrtel.net

CSeq: 103 INVITE
User-Agent: Asterisk PBX 1.6.2.9-2+squeeze6
Proxy-Authorization: Digest username=»380892506511″, realm=»sip.ukrtel.net», algorithm=MD5, uri=»sip.ukrtel.net», nonce=»MTM0MzY0OTk4MzpTREZTZXJ2ZXJTZWNyZXRLZXk6MTM2NDM0OTE0Mg==», response=»ba9ce3cbc3d573ec0fb047860c6b1091″
Date: Mon, 30 Jul 2012 12:05:39 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 271

v=0
o=root 1856866922 1856866923 IN IP4 10.10.10.110
s=Asterisk PBX 1.6.2.9-2+squeeze6
c=IN IP4 10.10.10.110
t=0 0
m=audio 15890 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv

—

<— SIP read from UDP:195.5.0.83:5060 —>
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.10.10.110:5060;received=195.88.113.188;branch=z9hG4bK69060425;rport=60638
From: «101» <sip:380892506511@sip.ukrtel.net>;tag=as6f72688f
To: <sip:0800506800@195.5.0.83>
Call-ID:

12d9dcd953de7a8f514a05ee6a480ebb@sip.ukrtel.net

CSeq: 103 INVITE

<————->
— (6 headers 0 lines) —

<— SIP read from UDP:195.5.0.83:5060 —>
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 10.10.10.110:5060;received=195.88.113.188;branch=z9hG4bK69060425;rport=60638
From: «101» <sip:380892506511@sip.ukrtel.net>;tag=as6f72688f
To: <sip:0800506800@195.5.0.83>;tag=113265522
Call-ID:

12d9dcd953de7a8f514a05ee6a480ebb@sip.ukrtel.net

CSeq: 103 INVITE
Contact: <sip:0800506800@195.5.0.83:5060;transport=udp>
Allow: INVITE
Allow: ACK
Allow: PRACK
Allow: SUBSCRIBE
Allow: BYE
Allow: CANCEL
Allow: NOTIFY
Allow: INFO
Allow: REFER
Allow: UPDATE
Content-Type: application/sdp
Content-Length: 151

v=0
o=- 1 2 IN IP4 195.5.0.83
s=-
c=IN IP4 195.5.0.83
t=0 0
m=audio 20854 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000

<————->
— (19 headers 8 lines) —
Found RTP audio format 8
Found RTP audio format 101
Found audio description format PCMA for ID 8
Found audio description format telephone-event for ID 101
Capabilities: us — 0xc (ulaw|alaw), peer — audio=0x8 (alaw)/video=0x0 (nothing)/text=0x0 (nothing), combined — 0x8 (alaw)
Non-codec capabilities (dtmf): us — 0x1 (telephone-event), peer — 0x1 (telephone-event), combined — 0x1 (telephone-event)
Peer audio RTP is at port 195.5.0.83:20854
— SIP/ukrtelecom-00000029 is ringing
— SIP/ukrtelecom-00000029 is making progress passing it to SIP/101-00000028

12d9dcd953de7a8f514a05ee6a480ebb@sip.ukrtel.net

CSeq: 103 INVITE
Contact: «Main800506800» <sip:0800506800@195.5.0.83:5060;transport=udp>
Allow: INVITE
Allow: ACK
Allow: PRACK
Allow: SUBSCRIBE
Allow: BYE
Allow: CANCEL
Allow: NOTIFY
Allow: INFO
Allow: REFER
Allow: UPDATE
P-Asserted-Identity: «Main800506800» <sip:380892222600@corp.ukrtelecom.loc:5061>
Content-Type: application/sdp
Content-Length: 151

v=0
o=- 1 2 IN IP4 195.5.0.83
s=-
c=IN IP4 195.5.0.83
t=0 0
m=audio 20854 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000

<————->
— (20 headers 8 lines) —
— SIP/ukrtelecom-00000029 is ringing
— SIP/ukrtelecom-00000029 is making progress passing it to SIP/101-00000028

<— SIP read from UDP:195.5.0.83:5060 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.10.10.110:5060;received=195.88.113.188;branch=z9hG4bK69060425;rport=60638
From: «101» <sip:380892506511@sip.ukrtel.net>;tag=as6f72688f
To: <sip:0800506800@195.5.0.83>;tag=113265522
Call-ID:

12d9dcd953de7a8f514a05ee6a480ebb@sip.ukrtel.net

CSeq: 103 INVITE
Contact: «AIC Route to VP» <sip:0800506800@195.5.0.83:5060;transport=udp>
P-Asserted-Identity: «AIC Route to VP» <sip:380892222201@corp.ukrtelecom.loc:5061>
Allow: INVITE
Allow: ACK
Allow: PRACK
Allow: SUBSCRIBE
Allow: BYE
Allow: CANCEL
Allow: NOTIFY
Allow: INFO
Allow: REFER
Allow: UPDATE
Content-Type: application/sdp
Content-Length: 151

v=0
o=- 1 2 IN IP4 195.5.0.83
s=-
c=IN IP4 195.5.0.83
t=0 0
m=audio 20854 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000

<————->
— (20 headers 8 lines) —
list_route: hop: <sip:0800506800@195.5.0.83:5060;transport=udp>
set_destination: Parsing <sip:0800506800@195.5.0.83:5060;transport=udp> for address/port to send to
set_destination: set destination to 195.5.0.83, port 5060
Transmitting (NAT) to 195.5.0.83:5060:
ACK sip:0800506800@195.5.0.83:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 10.10.10.110:5060;branch=z9hG4bK551d3960;rport
Max-Forwards: 70
From: «101» <sip:380892506511@sip.ukrtel.net>;tag=as6f72688f
To: <sip:0800506800@sip.ukrtel.net>;tag=113265522
Contact: <sip:380892506511@10.10.10.110>
Call-ID:

12d9dcd953de7a8f514a05ee6a480ebb@sip.ukrtel.net

CSeq: 103 ACK
User-Agent: Asterisk PBX 1.6.2.9-2+squeeze6
Content-Length: 0

—
— SIP/ukrtelecom-00000029 answered SIP/101-00000028

<— SIP read from UDP:195.5.0.83:5060 —>
UPDATE sip:380892506511@10.10.10.110 SIP/2.0
Via: SIP/2.0/UDP 195.5.0.83:5060;branch=z9hG4bKoqqhfo2088nh8fk4j5k0sm0000g00.1
Call-ID:

12d9dcd953de7a8f514a05ee6a480ebb@sip.ukrtel.net

CSeq: 1 UPDATE
From: <sip:0800506800@sip.ukrtel.net>;tag=113265522
To: «101» <sip:380892506511@195.5.0.83>;tag=as6f72688f
Content-Length: 0
Contact: «AIC Route to VP» <sip:0800506800@195.5.0.83:5060;transport=udp>
Max-Forwards: 8
Session-Expires: 1800
Supported: timer
P-Asserted-Identity: «Main800506800» <sip:892506511@10.254.10.17;user=phone>

<————->
— (12 headers 0 lines) —

<— Transmitting (NAT) to 195.5.0.83:5060 —>
SIP/2.0 501 Method Not Implemented
Via: SIP/2.0/UDP 195.5.0.83:5060;branch=z9hG4bKoqqhfo2088nh8fk4j5k0sm0000g00.1;received=195.5.0.83
From: <sip:0800506800@sip.ukrtel.net>;tag=113265522
To: «101» <sip:380892506511@195.5.0.83>;tag=as6f72688f
Call-ID:

12d9dcd953de7a8f514a05ee6a480ebb@sip.ukrtel.net

CSeq: 1 UPDATE
Server: Asterisk PBX 1.6.2.9-2+squeeze6
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Accept: application/sdp
Content-Length: 0

<————>
[Jul 30 15:05:48] NOTICE[1767]: chan_sip.c:22000 handle_incoming: Unknown SIP command ‘UPDATE’ from ‘195.5.0.83’

<— SIP read from UDP:195.5.0.83:5060 —>
UPDATE sip:380892506511@10.10.10.110 SIP/2.0
Via: SIP/2.0/UDP 195.5.0.83:5060;branch=z9hG4bKoqqhfo2088nh8fk4j5k0sm0000010.1
Call-ID:

12d9dcd953de7a8f514a05ee6a480ebb@sip.ukrtel.net

CSeq: 2 UPDATE
From: <sip:0800506800@sip.ukrtel.net>;tag=113265522
To: «101» <sip:380892506511@195.5.0.83>;tag=as6f72688f
Content-Length: 0
Contact: «AIC Route to VP» <sip:0800506800@195.5.0.83:5060;transport=udp>
Max-Forwards: 8
Session-Expires: 1800
Supported: timer
P-Asserted-Identity: «VP0159» <sip:892506511@10.254.10.17;user=phone>

<————->
— (12 headers 0 lines) —

<— Transmitting (NAT) to 195.5.0.83:5060 —>
SIP/2.0 501 Method Not Implemented
Via: SIP/2.0/UDP 195.5.0.83:5060;branch=z9hG4bKoqqhfo2088nh8fk4j5k0sm0000010.1;received=195.5.0.83
From: <sip:0800506800@sip.ukrtel.net>;tag=113265522
To: «101» <sip:380892506511@195.5.0.83>;tag=as6f72688f
Call-ID:

12d9dcd953de7a8f514a05ee6a480ebb@sip.ukrtel.net

CSeq: 2 UPDATE
Server: Asterisk PBX 1.6.2.9-2+squeeze6
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Accept: application/sdp
Content-Length: 0

<————>
[Jul 30 15:05:48] NOTICE[1767]: chan_sip.c:22000 handle_incoming: Unknown SIP command ‘UPDATE’ from ‘195.5.0.83’
Scheduling destruction of SIP dialog ’12d9dcd953de7a8f514a05ee6a480ebb@sip.ukrtel.net’ in 6400 ms (Method: UPDATE)
set_destination: Parsing <sip:0800506800@195.5.0.83:5060;transport=udp> for address/port to send to
set_destination: set destination to 195.5.0.83, port 5060
Reliably Transmitting (NAT) to 195.5.0.83:5060:
BYE sip:0800506800@195.5.0.83:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 10.10.10.110:5060;branch=z9hG4bK46c7a376;rport
Max-Forwards: 70
From: «101» <sip:380892506511@sip.ukrtel.net>;tag=as6f72688f
To: <sip:0800506800@sip.ukrtel.net>;tag=113265522
Call-ID:

12d9dcd953de7a8f514a05ee6a480ebb@sip.ukrtel.net

CSeq: 104 BYE
User-Agent: Asterisk PBX 1.6.2.9-2+squeeze6
Proxy-Authorization: Digest username=»380892506511″, realm=»sip.ukrtel.net», algorithm=MD5, uri=»sip.ukrtel.net», nonce=»MTM0MzY0OTk4MzpTREZTZXJ2ZXJTZWNyZXRLZXk6MTM2NDM0OTE0Mg==», response=»49cd1e38a8fe27f4a910af7c1b757cc0″
X-Asterisk-HangupCause: Normal Clearing
X-Asterisk-HangupCauseCode: 16
Content-Length: 0

—
== Spawn extension (phones, 90800506800, 2) exited non-zero on ‘SIP/101-00000028’
Retransmitting #1 (NAT) to 195.5.0.83:5060:
BYE sip:0800506800@195.5.0.83:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 10.10.10.110:5060;branch=z9hG4bK46c7a376;rport
Max-Forwards: 70
From: «101» <sip:380892506511@sip.ukrtel.net>;tag=as6f72688f
To: <sip:0800506800@sip.ukrtel.net>;tag=113265522
Call-ID:

12d9dcd953de7a8f514a05ee6a480ebb@sip.ukrtel.net

—
Retransmitting #2 (NAT) to 195.5.0.83:5060:
BYE sip:0800506800@195.5.0.83:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 10.10.10.110:5060;branch=z9hG4bK46c7a376;rport
Max-Forwards: 70
From: «101» <sip:380892506511@sip.ukrtel.net>;tag=as6f72688f
To: <sip:0800506800@sip.ukrtel.net>;tag=113265522
Call-ID:

12d9dcd953de7a8f514a05ee6a480ebb@sip.ukrtel.net

—

<— SIP read from UDP:195.5.0.83:5060 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.10.10.110:5060;received=195.88.113.188;branch=z9hG4bK46c7a376;rport=60638
From: «101» <sip:380892506511@sip.ukrtel.net>;tag=as6f72688f
To: <sip:0800506800@195.5.0.83>;tag=113265522
Call-ID:

12d9dcd953de7a8f514a05ee6a480ebb@sip.ukrtel.net

CSeq: 104 BYE
Content-Length: 0

<————->
— (7 headers 0 lines) —
Really destroying SIP dialog ’12d9dcd953de7a8f514a05ee6a480ebb@sip.ukrtel.net’ Method: UPDATE

12d9dcd953de7a8f514a05ee6a480ebb@sip.ukrtel.net

CSeq: 104 BYE
Content-Length: 0

<————->
— (7 headers 0 lines) —

12d9dcd953de7a8f514a05ee6a480ebb@sip.ukrtel.net

CSeq: 104 BYE
Content-Length: 0

<————->
— (7 headers 0 lines) —
energotourserver*CLI>

Источник

Outgoing calls fail — Forbidden — TotalNet — 03-31-2020 05:40 AM

Essentially, I believe my ISP/VoIP provider is blocking my outgoing calls from off-network, however, they have said no at 1st level support so I need some ammo to get through to level 4 ideally.

I have a W60B with 1 W56H and a T41S with the DD10 DECT adapter.

The line is registered and receives incoming calls on that line. When I attempt an outgoing call if fails quickly with «Forbidden».

There are other accounts registered on the W60B with a cloud PBX and my home ISP/VoIP working perfectly. I have set up the T41S for this account without the DECT adapter and get the same failure.

I have setup a syslog server to trace the call process and can attach here but the key entries I see are:

There is no SIP proxy involved, the connection is UDP only.

Here’s a highlight of the syslog output (phone# replace with NN):

Code:

Whether making a call or not I also get the occasional DESV<3+error > 792.450.786:get_ip failed ret= -1

I would port my phone number to the cloud PBX but I get an unbeatable package with unlimited free national and mobile calls on 2 lines Sad

Cheers for any assistance

Richard

RE: Outgoing calls fail — Forbidden — complex1 — 03-31-2020 08:14 AM

(03-31-2020 05:40 AM)TotalNet Wrote: My business is closed due to the national lockdown here in NZ and I’m trying to get my business phones working from my home office and it’s not going so well. Any help for a Yealink newcomer is gratefully appreciated!

Essentially, I believe my ISP/VoIP provider is blocking my outgoing calls from off-network, however, they have said no at 1st level support so I need some ammo to get through to level 4 ideally.

I have a W60B with 1 W56H and a T41S with the DD10 DECT adapter.

The line is registered and receives incoming calls on that line. When I attempt an outgoing call if fails quickly with «Forbidden».

There are other accounts registered on the W60B with a cloud PBX and my home ISP/VoIP working perfectly. I have set up the T41S for this account without the DECT adapter and get the same failure.

At the business office I use a CISCO ATA (SPA112) for this line and have used its settings for the registration on the W60B, with the intention of replacing it with the Yealink setup soon. This ATA device does not work from my home office either.

I have setup a syslog server to trace the call process and can attach here but the key entries I see are:

— a new call is established (call staus update [0]==>[2])
— a packet is successfully sent to the SIP server and a reply received
— a couple more exchanges of packets with the SIP server
— call status changes to 19 (call status update [2]==>[19])
— the call is released <<RELEASE-REASON>> (0xe2)

There is no SIP proxy involved, the connection is UDP only.

I’m sure there are many reasons behind a «forbidden» call failure (it’s often as much about what’s not in the log) so please let me know if there’s another area I can look at, perhaps it’s my network setup (NAT?) which is why the ATA I brought home doesn’t work either.

Here’s a highlight of the syslog output (phone# replace with NN):

Code:

DCX <5+notice> 632.873.481:TX[0] HS 2 --> T[55597] {CC-INFO} P_IT(240) DCX <5+notice> 632.873.625: <<Calling Party Number>> (0x6c) DCX <5+notice> 632.873.769: Number type: DCX <5+notice> 632.873.910: Numbering plan: ISDN/telephony plan DCX <5+notice> 632.874.055: Presentation indicator: , Screening indicator: User-provided, not screened DCX <5+notice> 632.875.883: Number: 0xNN ("N") 0xNN ("N") 0xNN ("N") 0xNN ("N") 0xNN ("N") 0xNN ("N") 0xNN ("N") 0xNN ("N") 0xNN ("N") DCX <5+notice> 632.876.071: <<Calling Party Name>> (0x6d) DCX <5+notice> 632.876.227: "NNNNNNNNN DCX <5+notice> 632.876.373: <<Call information>> (0x7e) DCX <5+notice> 632.876.518: Call ID: 0x0 DCX <5+notice> 632.879.676: DCX <5+notice> 632.879.872: APP <5+notice> [SIP] SIP_C2S_CALL_NEW_OUTGOING, lid:0, cid:32795,callmask:0x00000000,callee:NNNNNNNNN CAL <5+notice> [000] call status update [0]==>[2] DLG <5+notice> [000] Sending Packet :to dest=119.224.142.182:5060 msglen = 929 DLG <5+notice> [000] End of Sending Packet :msglen = 929 NET <5+notice> [000] ===>>>> UDP socket 119.224.142.182:5060: send 929 bytes NET <5+notice> [255] <<<<=== UDP socket 119.224.142.182:5060: read 246 bytes DLG <5+notice> [000] Data Received :from src=119.224.142.182:5060 msglen = 246 DLG <5+notice> [000] End of Data Received :msglen = 246 NET <5+notice> [255] <<<<=== UDP socket 119.224.142.182:5060: read 277 bytes DLG <5+notice> [000] Data Received :from src=119.224.142.182:5060 msglen = 277 DLG <5+notice> [000] End of Data Received :msglen = 277 DLG <5+notice> [000] Sending Packet :to dest=119.224.142.182:5060 msglen = 318 DLG <5+notice> [000] End of Sending Packet :msglen = 318 NET <5+notice> [000] ===>>>> UDP socket 119.224.142.182:5060: send 318 bytes CAL <5+notice> [000] call status update [2]==>[19] SS7 <5+notice> 633.047.590:SS7_ReqRelExt instance=0x1003000e, reason=0x75,msg:(null) rel_msg_len=0 SS7 <5+notice> 633.048.034:service_SS7_ReqRel inst=0x1003000e,Reason=117,Call Id:0 APPC<5+notice> 633.048.266:appmedia_CallObjMediaStop inst:0xf,ChannelID:0 APPC<5+notice> 633.048.453:CallObjMediaSet inst:0xf,state:1 APPC<5+notice> 633.050.701:appcall_ReleaseCall CallId:0, Reason:0x75, RelMsgLen:0, CallIns:0xf, Hs:2 DCX <5+notice> 633.261.418: DCX <5+notice> 633.261.635:FTMLP_ID/0,3,8,0x0,0x0,0,<0> DCX <5+notice> 633.291.416: DCX <5+notice> 633.291.633:FTMLP_ID/0,3,7,0x4,0x0,4,<0> DCX <5+notice> 633.331.383: DCX <5+notice> 633.331.590:FTMLP_ID/0,3,7,0x5,0x0,5,<0> DCX <5+notice> 633.351.965: DCX <5+notice> 633.352.222:FTMLP_ID/0,3,7,0x6,0x0,6,<0> DCX <5+notice> 633.352.379: DCX <5+notice> 633.352.528:RX[0] HS 2 <-- T(55645) {CC-RELEASE-COM} [HS-2] P_IT(140) DCX <5+notice> 633.352.676: <<RELEASE-REASON>> (0xe2) DCX <5+notice> 633.352.819: Normal

Whether making a call or not I also get the occasional DESV<3+error > 792.450.786:get_ip failed ret= -1

I would port my phone number to the cloud PBX but I get an unbeatable package with unlimited free national and mobile calls on 2 lines

Cheers for any assistance

Richard

Hi Richard,

Because of the lockdown you must work at home, so you take the W60B, W56H and T41S with you and place it in your home office.

Now you have issues… and only with outbound business calls.
No issues with incoming calls, business or private, at all.

It is a nasty issue.

RE: Outgoing calls fail — Forbidden — TotalNet — 03-31-2020 11:32 AM

(03-31-2020 08:14 AM)complex1 Wrote: Let me sum it up if I understand your issue.
At your business office you use a W60B with two accounts, 1 business and 1 private.
The W56H and T41S are both connected to the W60B.
All work well, no issues.

I have 4 other personal SIP accounts with 3 different providers that do work at home on the Yealink setup.

RE: Outgoing calls fail — Forbidden — complex1 — 03-31-2020 12:18 PM

(03-31-2020 11:32 AM)TotalNet Wrote: The Yealink setup is new and not yet deployed so I am trying to get it working from home by registering the main business phone number on the W60B to make/take business calls at home. The Cisco ATA was working at the office and I have brought it home, I can’t make calls from home on this either. Both register and can receive calls with audio working in both directions, they just can’t initiate calls.

I guess your provider is blocking unknown IP-addresses to avoid unauthorized calls.
They only validated your main office IP-address.

SOLVED: Outgoing calls fail — Forbidden — TotalNet — 05-07-2020 08:30 PM

(03-31-2020 12:18 PM)complex1 Wrote:

(03-31-2020 11:32 AM)TotalNet Wrote: The Yealink setup is new and not yet deployed so I am trying to get it working from home by registering the main business phone number on the W60B to make/take business calls at home. The Cisco ATA was working at the office and I have brought it home, I can’t make calls from home on this either. Both register and can receive calls with audio working in both directions, they just can’t initiate calls.

I guess your provider is blocking unknown IP-addresses to avoid unauthorized calls.
They only validated your main office IP-address.

Turns out this is the most likely case, the Yealink phones are now in the office with the only change being the internal IP address and working well.

There’s no support article here to indicate what call status 19 actual means or if it’s just a generic response for call failure.

Thanks for all the replies. Disappointed that my ISP couldn’t assist during an event like this but so far liking the Yealink products.

12d9dcd953de7a8f514a05ee6a480ebb@sip.ukrtel.net

—
— Called ukrtelecom/0800506800

12d9dcd953de7a8f514a05ee6a480ebb@sip.ukrtel.net

CSeq: 102 INVITE

<————->
— (6 headers 0 lines) —

12d9dcd953de7a8f514a05ee6a480ebb@sip.ukrtel.net

CSeq: 102 ACK
User-Agent: Asterisk PBX 1.6.2.9-2+squeeze6
Content-Length: 0

12d9dcd953de7a8f514a05ee6a480ebb@sip.ukrtel.net

—

12d9dcd953de7a8f514a05ee6a480ebb@sip.ukrtel.net

CSeq: 103 INVITE

<————->
— (6 headers 0 lines) —

12d9dcd953de7a8f514a05ee6a480ebb@sip.ukrtel.net

v=0
o=- 1 2 IN IP4 195.5.0.83
s=-
c=IN IP4 195.5.0.83
t=0 0
m=audio 20854 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000

12d9dcd953de7a8f514a05ee6a480ebb@sip.ukrtel.net

v=0
o=- 1 2 IN IP4 195.5.0.83
s=-
c=IN IP4 195.5.0.83
t=0 0
m=audio 20854 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000

<————->
— (20 headers 8 lines) —
— SIP/ukrtelecom-00000029 is ringing
— SIP/ukrtelecom-00000029 is making progress passing it to SIP/101-00000028

12d9dcd953de7a8f514a05ee6a480ebb@sip.ukrtel.net

v=0
o=- 1 2 IN IP4 195.5.0.83
s=-
c=IN IP4 195.5.0.83
t=0 0
m=audio 20854 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000

12d9dcd953de7a8f514a05ee6a480ebb@sip.ukrtel.net

CSeq: 103 ACK
User-Agent: Asterisk PBX 1.6.2.9-2+squeeze6
Content-Length: 0

—
— SIP/ukrtelecom-00000029 answered SIP/101-00000028

<— SIP read from UDP:195.5.0.83:5060 —>
UPDATE sip:380892506511@10.10.10.110 SIP/2.0
Via: SIP/2.0/UDP 195.5.0.83:5060;branch=z9hG4bKoqqhfo2088nh8fk4j5k0sm0000g00.1
Call-ID:

12d9dcd953de7a8f514a05ee6a480ebb@sip.ukrtel.net

<————->
— (12 headers 0 lines) —

12d9dcd953de7a8f514a05ee6a480ebb@sip.ukrtel.net

CSeq: 1 UPDATE
Server: Asterisk PBX 1.6.2.9-2+squeeze6
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Accept: application/sdp
Content-Length: 0

<————>
[Jul 30 15:05:48] NOTICE[1767]: chan_sip.c:22000 handle_incoming: Unknown SIP command ‘UPDATE’ from ‘195.5.0.83’

<— SIP read from UDP:195.5.0.83:5060 —>
UPDATE sip:380892506511@10.10.10.110 SIP/2.0
Via: SIP/2.0/UDP 195.5.0.83:5060;branch=z9hG4bKoqqhfo2088nh8fk4j5k0sm0000010.1
Call-ID:

12d9dcd953de7a8f514a05ee6a480ebb@sip.ukrtel.net

<————->
— (12 headers 0 lines) —

12d9dcd953de7a8f514a05ee6a480ebb@sip.ukrtel.net

CSeq: 2 UPDATE
Server: Asterisk PBX 1.6.2.9-2+squeeze6
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Accept: application/sdp
Content-Length: 0

12d9dcd953de7a8f514a05ee6a480ebb@sip.ukrtel.net

—

12d9dcd953de7a8f514a05ee6a480ebb@sip.ukrtel.net

CSeq: 104 BYE
Content-Length: 0

<————->
— (7 headers 0 lines) —
Really destroying SIP dialog ’12d9dcd953de7a8f514a05ee6a480ebb@sip.ukrtel.net’ Method: UPDATE

12d9dcd953de7a8f514a05ee6a480ebb@sip.ukrtel.net

CSeq: 104 BYE
Content-Length: 0

<————->
— (7 headers 0 lines) —

12d9dcd953de7a8f514a05ee6a480ebb@sip.ukrtel.net

CSeq: 104 BYE
Content-Length: 0

<————->
— (7 headers 0 lines) —
energotourserver*CLI>

Источник

You’re currently viewing a stripped down version of our content. View the full version with proper formatting.

Hi, I’ve installed one W60B + 2 W56H on my office using my Spanish ISP SIP settings. The issue I’ve found is that, it does register properly (apparently), and sometimes (only sometimes), it can receive and send calls, nevertheless, almost every other time, one of the call attempts says «forbidden» on the screen of the phone. Then, after 30″ or 1′ approximately, if I ty it again, it seems to work.

I’ve downloaded the logs from the W60B and I can see it full of messages like this:
<131>Aug 26 14:08:15 sua [1423.1781]: REG <3+error > [000] <AEM> code=0x04000009, rid=4, reason=-3,’wrong state’.
<131>Aug 26 14:08:15 sua [1423.1781]: REG <3+error > [000] <AEM> code=0x04000009, rid=4, reason=-3,’wrong state’.
<131>Aug 26 14:08:15 sua [1423.1781]: REG <3+error > [000] <AEM> code=0x04000009, rid=4, reason=-3,’wrong state’.
<131>Aug 26 14:08:15 sua [1423.1781]: REG <3+error > [000] <AEM> code=0x04000009, rid=4, reason=-3,’wrong state’.
<131>Aug 26 14:08:15 sua [1423.1781]: REG <3+error > [000] <AEM> code=0x04000009, rid=4, reason=-3,’wrong state’.
<131>Aug 26 14:08:15 sua [1423.1781]: REG <3+error > [000] <AEM> code=0x04000009, rid=4, reason=-3,’wrong state’.

Relevant Data:

— My provider is Movistar Spain, whose SIP parameters are well known:

Proxy/registrar: 10.31.255.134:5070
Domain/realm: telefonica.net
STUN: [empty]
Username: [#TELEPHONE-NUMBER]
Password: [#TELEPHONE-NUMBER]

— Both Handsets (w56H) as well as the Base (W60B) are on their latest available firmware today.
— Base HW version is: 77.0.0.48.0.0.0

— If I configure those parameters on a desktop application (phoner Lite), it does work flawlesly

Any help will be much appreciated,

Thanks in advance

Best

(08-30-2021 05:03 AM)w60B-Spain Wrote: [ -> ]Hi, I’ve installed one W60B + 2 W56H on my office using my Spanish ISP SIP settings. The issue I’ve found is that, it does register properly (apparently), and sometimes (only sometimes), it can receive and send calls, nevertheless, almost every other time, one of the call attempts says «forbidden» on the screen of the phone. Then, after 30″ or 1′ approximately, if I ty it again, it seems to work.

I’ve downloaded the logs from the W60B and I can see it full of messages like this:
<131>Aug 26 14:08:15 sua [1423.1781]: REG <3+error > [000] <AEM> code=0x04000009, rid=4, reason=-3,’wrong state’.
<131>Aug 26 14:08:15 sua [1423.1781]: REG <3+error > [000] <AEM> code=0x04000009, rid=4, reason=-3,’wrong state’.
<131>Aug 26 14:08:15 sua [1423.1781]: REG <3+error > [000] <AEM> code=0x04000009, rid=4, reason=-3,’wrong state’.
<131>Aug 26 14:08:15 sua [1423.1781]: REG <3+error > [000] <AEM> code=0x04000009, rid=4, reason=-3,’wrong state’.
<131>Aug 26 14:08:15 sua [1423.1781]: REG <3+error > [000] <AEM> code=0x04000009, rid=4, reason=-3,’wrong state’.
<131>Aug 26 14:08:15 sua [1423.1781]: REG <3+error > [000] <AEM> code=0x04000009, rid=4, reason=-3,’wrong state’.

Relevant Data:

— My provider is Movistar Spain, whose SIP parameters are well known:

Proxy/registrar: 10.31.255.134:5070
Domain/realm: telefonica.net
STUN: [empty]
Username: [#TELEPHONE-NUMBER]
Password: [#TELEPHONE-NUMBER]

— Both Handsets (w56H) as well as the Base (W60B) are on their latest available firmware today.
— Base HW version is: 77.0.0.48.0.0.0

— If I configure those parameters on a desktop application (phoner Lite), it does work flawlesly

Any help will be much appreciated,

Thanks in advance

Best

Hi,

This issue sounds like typical router problems.
Check if the SIP ALG function is disabled, the correct ports are open and forwarded to the W60B.
You might also consider using STUN.

Hope this will help.

Hi, Thanks a lot for the suggestion complex1,

Indeed one of the first thing I tried was disabling any SIP ALG functionality from the router (Edgerouter from Unifi), but sadly it did not change anything, the behaviour was still the same. The router itself is almost blank in terms of configuration, there are no firewall rules applied for either in or out of the interface, nor there is anything else but ports redirection for 5060-5070 UDP ports as well as some RTP ports used on teh configuration. Despite those 2 things, the rest is pretty much basic stuff.

Any other ideas? Is there any other part of the log I could look into to gather more information to trace it?

Thanks in advance!

Best

(08-30-2021 08:18 PM)complex1 Wrote: [ -> ]

(08-30-2021 05:03 AM)w60B-Spain Wrote: [ -> ]Hi, I’ve installed one W60B + 2 W56H on my office using my Spanish ISP SIP settings. The issue I’ve found is that, it does register properly (apparently), and sometimes (only sometimes), it can receive and send calls, nevertheless, almost every other time, one of the call attempts says «forbidden» on the screen of the phone. Then, after 30″ or 1′ approximately, if I ty it again, it seems to work.

I’ve downloaded the logs from the W60B and I can see it full of messages like this:
<131>Aug 26 14:08:15 sua [1423.1781]: REG <3+error > [000] <AEM> code=0x04000009, rid=4, reason=-3,’wrong state’.
<131>Aug 26 14:08:15 sua [1423.1781]: REG <3+error > [000] <AEM> code=0x04000009, rid=4, reason=-3,’wrong state’.
<131>Aug 26 14:08:15 sua [1423.1781]: REG <3+error > [000] <AEM> code=0x04000009, rid=4, reason=-3,’wrong state’.
<131>Aug 26 14:08:15 sua [1423.1781]: REG <3+error > [000] <AEM> code=0x04000009, rid=4, reason=-3,’wrong state’.
<131>Aug 26 14:08:15 sua [1423.1781]: REG <3+error > [000] <AEM> code=0x04000009, rid=4, reason=-3,’wrong state’.
<131>Aug 26 14:08:15 sua [1423.1781]: REG <3+error > [000] <AEM> code=0x04000009, rid=4, reason=-3,’wrong state’.

Relevant Data:

— My provider is Movistar Spain, whose SIP parameters are well known:

Proxy/registrar: 10.31.255.134:5070
Domain/realm: telefonica.net
STUN: [empty]
Username: [#TELEPHONE-NUMBER]
Password: [#TELEPHONE-NUMBER]

— Both Handsets (w56H) as well as the Base (W60B) are on their latest available firmware today.
— Base HW version is: 77.0.0.48.0.0.0

— If I configure those parameters on a desktop application (phoner Lite), it does work flawlesly

Any help will be much appreciated,

Thanks in advance

Best

Hi,

This issue sounds like typical router problems.
Check if the SIP ALG function is disabled, the correct ports are open and forwarded to the W60B.
You might also consider using STUN.

Hope this will help.

(08-31-2021 03:53 PM)w60B-Spain Wrote: [ -> ]Hi, Thanks a lot for the suggestion complex1,

Indeed one of the first thing I tried was disabling any SIP ALG functionality from the router (Edgerouter from Unifi), but sadly it did not change anything, the behaviour was still the same. The router itself is almost blank in terms of configuration, there are no firewall rules applied for either in or out of the interface, nor there is anything else but ports redirection for 5060-5070 UDP ports as well as some RTP ports used on teh configuration. Despite those 2 things, the rest is pretty much basic stuff.

Any other ideas? Is there any other part of the log I could look into to gather more information to trace it?

Thanks in advance!

Best

Hi,

Please try using STUN.

Network > NAT > STUN
Active: Enable
STUN Server: stun.sipgate.net
STUN Port: 3478

Thanks for the suggestion @complex1

I tried with STUN Enabled and the parameters you suggested but the results are the same , I still get a «Forbidden» message every other call…

This is driving me crazy

(08-31-2021 05:53 PM)complex1 Wrote: [ -> ]

(08-31-2021 03:53 PM)w60B-Spain Wrote: [ -> ]Hi, Thanks a lot for the suggestion complex1,

Indeed one of the first thing I tried was disabling any SIP ALG functionality from the router (Edgerouter from Unifi), but sadly it did not change anything, the behaviour was still the same. The router itself is almost blank in terms of configuration, there are no firewall rules applied for either in or out of the interface, nor there is anything else but ports redirection for 5060-5070 UDP ports as well as some RTP ports used on teh configuration. Despite those 2 things, the rest is pretty much basic stuff.

Any other ideas? Is there any other part of the log I could look into to gather more information to trace it?

Thanks in advance!

Best

Hi,

Please try using STUN.

Network > NAT > STUN
Active: Enable
STUN Server: stun.sipgate.net
STUN Port: 3478

(08-31-2021 11:30 PM)w60B-Spain Wrote: [ -> ]Thanks for the suggestion @complex1

I tried with STUN Enabled and the parameters you suggested but the results are the same , I still get a «Forbidden» message every other call…

This is driving me crazy

(08-31-2021 05:53 PM)complex1 Wrote: [ -> ]

(08-31-2021 03:53 PM)w60B-Spain Wrote: [ -> ]Hi, Thanks a lot for the suggestion complex1,

Indeed one of the first thing I tried was disabling any SIP ALG functionality from the router (Edgerouter from Unifi), but sadly it did not change anything, the behaviour was still the same. The router itself is almost blank in terms of configuration, there are no firewall rules applied for either in or out of the interface, nor there is anything else but ports redirection for 5060-5070 UDP ports as well as some RTP ports used on teh configuration. Despite those 2 things, the rest is pretty much basic stuff.

Any other ideas? Is there any other part of the log I could look into to gather more information to trace it?

Thanks in advance!

Best

Hi,

Please try using STUN.

Network > NAT > STUN
Active: Enable
STUN Server: stun.sipgate.net
STUN Port: 3478

Hi,

I think you did everything you could have done.
I suggest you contact your VoIP provider and ask them to assist you. Maybe they know a solution to this problem?

I think I found the issue , at least «partially» (so far, I haven’t had any more errors on the log).

The issue seems to come from the ONT device that connects to the Fiber Optics and that routes to the VoIP Vlan. Within the same ONT configuration there is a section that enables or disables the internal SIP client that is later on attached to the POTS interface (RHJ11) of the same ONT. I think that, given that the ONT was already registered on the SIP server, when I tried to also register the W60B with the same configuration, there was some sort of «overlap» on the registration, which allowed the base to beregistered, but that in the end, seemed to generate some sort of conflict…

Having said so, the other Issue I’ve realised is that the «end call» functionality doesn’t seem to work very good, as when I reject one call (on my mobile) that goes my office to my mobile, on the Yealink device I still can hear perfectly the tone of the ongoing call request… Nevertheless I’ll open a new thread for that, as this one is solved

Thanks a lot for your support @complex1

Best

(09-01-2021 01:16 AM)complex1 Wrote: [ -> ]

(08-31-2021 11:30 PM)w60B-Spain Wrote: [ -> ]Thanks for the suggestion @complex1

I tried with STUN Enabled and the parameters you suggested but the results are the same , I still get a «Forbidden» message every other call…

This is driving me crazy

(08-31-2021 05:53 PM)complex1 Wrote: [ -> ]

(08-31-2021 03:53 PM)w60B-Spain Wrote: [ -> ]Hi, Thanks a lot for the suggestion complex1,

Indeed one of the first thing I tried was disabling any SIP ALG functionality from the router (Edgerouter from Unifi), but sadly it did not change anything, the behaviour was still the same. The router itself is almost blank in terms of configuration, there are no firewall rules applied for either in or out of the interface, nor there is anything else but ports redirection for 5060-5070 UDP ports as well as some RTP ports used on teh configuration. Despite those 2 things, the rest is pretty much basic stuff.

Any other ideas? Is there any other part of the log I could look into to gather more information to trace it?

Thanks in advance!

Best

Hi,

Please try using STUN.

Network > NAT > STUN
Active: Enable
STUN Server: stun.sipgate.net
STUN Port: 3478

Hi,

I think you did everything you could have done.
I suggest you contact your VoIP provider and ask them to assist you. Maybe they know a solution to this problem?

Источник

Modified on: Wed, 25 Jan, 2023 at 12:29 AM

Q: My VoIP phone line isn’t working when I try to make a call. The message «line forbidden» is written on the screen so I cannot make or receive calls.

A: Reboot the Yealink base unit as at present the phone line is off line and so not getting an internet connection.

By rebooting this should re-establish a connection and the phone should be back online ready to make and receive calls.

Did you find it helpful?
Yes
No

Send feedback

Sorry we couldn’t be helpful. Help us improve this article with your feedback.

Источник

Hi,

We have a 3CX system with Yealink phones, one T48S and five W56H. One of the W56H phones was having troubles so we sent it back under warranty and got a new one in place.
This new one is now having troubles making outgoing calls, saying they are «invalid» or «forbidden».
When we try to dial that extension from any of the other phones it just diverts to the mobile set up for voicemails.
We cannot get incoming calls from other numbers on that phone either, it says the same thing about being «invalid».
I have had a look in our Phone System Management Console and the settings are the same for all 5 W56H phones.
I have run an auto provision on the phone as well.

Any ideas?

Thanks!

cobaltit

Platinum Partner

Advanced Certified

Is that extension showing as registered? The W56H is just a DECT handset. The actual SIP registration happens on the base. If you did everything you said then all you should need to do is pair the handset with the base again and match it up to the extension.

What, exactly, is the Activity Log showing?

Saqqara

Bronze Partner

Intermediate Cert.

Last edited: Aug 13, 2019

cobaltit, We are trying to pair them, we tried pressing the button on the base and it sends out a signal to all W56H phones but doesn’t show anything to press on the phone itself.

leejor, the Activity Log on the 3CX dashboard? That isn’t showing anything.

Saqqara, we only have one base station. At the moment none of the phones are showing up as registered as it seems to have reverted back to factory settings. All of them are red on the extensions page of the Phone System Management Console.

Looks like we might have to start from scratch again.

Hi all,

Sorry for the delay. This issue has been solved now. It turned out we had to remove both the old and the new phones from the system and reset the new phone to the old extension.

Thank you all for your help.

Источник

Related Articles

cobaltit

Saqqara