SIP Trunk | UNREACHABLE | 404 Not Found

Asterisk Asterisk Support
1

Hi, all

I configured a SIP Trunk between my (Asterisk) and (Ribbon Microsft Teams) and it works with calls in both directions.

After some days, the trunk change the state from “ok” to “UNREACHABLE” withou make any changes in both servers.

The both servers can ping witch other.

[My Asterisk version is ]# asterisk -V
Asterisk 1.4.30

The log’s said that my Asterisk response with 404 Not Found like you can see in the image and in logs abouve

SIP_flow_tcpdump (2)
SIP_flow_tcpdump (2)1020×706 62.7 KB

SIP Debugging Enabled for IP: 10.194.230.41:5060
Reliably Transmitting (no NAT) to 10.194.230.41:5060:
OPTIONS sip:10.194.230.41 SIP/2.0
Via: SIP/2.0/UDP 10.252.0.10:5060;branch=z9hG4bK28c49995;rport
From: “asterisk” <sip: asterisk@ 10.252.0.10>;tag=as1cfbbee1
To: <sip:10.194.230. 41>
Contact: <sip:asterisk @10.252.0.10>
Call-ID: 415ef41e758ed2633cfe1cae50781f04 @ 10.252.0.10
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX
Max-Forwards: 70
Date: Fri, 01 Apr 2022 16:31:09 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Content-Length: 0

Retransmitting #1 (no NAT) to 10.194.230.41:5060:
OPTIONS sip:10.194.230.41 SIP/2.0
Via: SIP/2.0/UDP 10.252.0.10:5060;branch=z9hG4bK28c49995;rport
From: “asterisk” <sip:asterisk @10.252.0.10>;tag=as1cfbbee1
To: <sip:10.194.230. 41>
Contact: <sip:asterisk @10.252.0.10>
Call-ID: 415ef41e758ed2633cfe1cae50781f04 @ 10.252.0.10
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX
Max-Forwards: 70
Date: Fri, 01 Apr 2022 16:31:09 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Content-Length: 0

Retransmitting #2 (no NAT) to 10.194.230.41:5060:
OPTIONS sip:10.194.230.41 SIP/2.0
Via: SIP/2.0/UDP 10.252.0.10:5060;branch=z9hG4bK28c49995;rport
From: “asterisk” <sip:asterisk @10.252.0.10>;tag=as1cfbbee1
To: <sip:10.194.230. 41>
Contact: <sip:asterisk @10.252.0.10>
Call-ID: 415ef41e758ed2633cfe1cae50781f04 @ 10.252.0.10
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX
Max-Forwards: 70
Date: Fri, 01 Apr 2022 16:31:09 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Content-Length: 0

Retransmitting #3 (no NAT) to 10.194.230.41:5060:
OPTIONS sip:10.194.230.41 SIP/2.0
Via: SIP/2.0/UDP 10.252.0.10:5060;branch=z9hG4bK28c49995;rport
From: “asterisk” <sip:asterisk @10.252.0.10>;tag=as1cfbbee1
To: <sip:10.194.230. 41>
Contact: <sip:asterisk @ 10.252.0.10>
Call-ID: 415ef41e758ed2633cfe1cae50781f04@ 10.252.0.10
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX
Max-Forwards: 70
Date: Fri, 01 Apr 2022 16:31:09 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Content-Length: 0

Retransmitting #4 (no NAT) to 10.194.230.41:5060:
OPTIONS sip:10.194.230.41 SIP/2.0
Via: SIP/2.0/UDP 10.252.0.10:5060;branch=z9hG4bK28c49995;rport
From: “asterisk” <sip:asterisk@ 10.252.0.10>;tag=as1cfbbee1
To: <sip: 10.194.230.41>
Contact: <sip:asterisk@ 10.252.0.10>
Call-ID: 415ef41e758ed2633cfe1cae50781f04@ 10.252.0.10
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX
Max-Forwards: 70
Date: Fri, 01 Apr 2022 16:31:09 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Content-Length: 0

Really destroying SIP dialog ‘415ef41e758ed2633cfe1cae50781f04@10.252.0.10’ Method: OPTIONS
Reliably Transmitting (no NAT) to 10.194.230.41:5060:
OPTIONS sip:10.194.230.41 SIP/2.0
Via: SIP/2.0/UDP 10.252.0.10:5060;branch=z9hG4bK1639e994;rport
From: “asterisk” <sip:asterisk@ 10.252.0.10>;tag=as0967858b
To: <sip: 10.194.230.41>
Contact: <sip:asterisk@ 10.252.0.10>
Call-ID: 61cfdc19067dbb4d64b213e54d8f3711@ 10.252.0.10
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX
Max-Forwards: 70
Date: Fri, 01 Apr 2022 16:31:13 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Content-Length: 0

Retransmitting #1 (no NAT) to 10.194.230.41:5060:
OPTIONS sip:10.194.230.41 SIP/2.0
Via: SIP/2.0/UDP 10.252.0.10:5060;branch=z9hG4bK1639e994;rport
From: “asterisk” <sip:asterisk@ 10.252.0.10>;tag=as0967858b
To: <sip: 10.194.230.41>
Contact: <sip:asterisk@ 10.252.0.10>
Call-ID: 61cfdc19067dbb4d64b213e54d8f3711@ 10.252.0.10
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX
Max-Forwards: 70
Date: Fri, 01 Apr 2022 16:31:13 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Content-Length: 0

;#########################
;#######RIBBON###Trunk###
;#########################

[RIBBON]
type=friend
host=10.194.230.41
insecure=port,invite
disallow=all
allow=ulaw
allow=alaw
dtmfmode=rfc2833
nat=no
canreinvite=no
qualify=yes

I have more trunks with other servers with same configuration and never get down

How can I see the configuration or in log the reason for it’s happen?

Thanks for your attention

2

This is not a problem.

Your problem is that total lack of responses in the other direction.

Except that the problem doesn’t seem to be with Asterisk, at all, I’d say stop here. Asterisk 1.4 is less than three week short of a decade beyond final end of life! Normally I’d say you should not be using chan_sip, but this version dates back to before chan_pjsip was introduced!

3

I have the same thought, but the suport team from Ribbon said that the problem is from Asterisk because Ribbon receive 4xx an sent 2xx as you can see in the image

image
image1920×947 143 KB

4

The options transactions in the two directions are independent. Any 2xx they sent was a reaction to OPTIONS, not to the 404. OPTIONS is being used to test the “connection” and any response should be acceptable.

I’m not completely sure, but I think if you define an extension s, for traffic from them, that will change the status, so you can debunk their theory. OPTIONS should be handled the same as an INVITE, as far as status codes are concerned, and s is the placeholder for when there is no user part in the request.

5

It is possible to know what kind of response that Asterisk are wainting from Ribbon?

Any debug detailed that I can do it to send to Ribbon support?

6

Asterisk is expecting ANY SIP response to the SIP OPTIONS request it has sent.

7

How can understand this?

The SIP Trunk communication is the sam as SIP call?

image
image1260×1245 24.7 KB

8

I was simplifying a bit. The precise wording is:

The response to an OPTIONS is constructed using the standard rules for a SIP response as discussed in Section 8.2.6. The response code chosen MUST be the same that would have been chosen had the request been an INVITE. That is, a 200 (OK) would be returned if the UAS is ready to accept a call, a 486 (Busy Here) would be returned if the UAS is busy, etc. This allows an OPTIONS request to be used to determine the basic state of a UAS, which can be an indication of whether the UAS will accept an INVITE request.

In your diagram, you used SIP Server in a way that is not compatible with the proper meaning, albeit that misuse is rather common. The only thing that is definitely a SIP Server (UAS)) in the diagram, is the casually dressed head without the headset.

In particular, looking at the BYE handling, you seem to be showing a stateless, combined media and signalling, proxy, that sets Record Route to keep itself in the signalling path. (I’m not sure if a stateless proxy can proxy media, though, but a stateful proxy wouldn’t wait for the A side ACK before ACKing the B side.)

Asterisk is a back to back user agent, so the middle lines is actually a server line and client line, with an internal message passing mechanism between them, In particular, Asterisk immediately returns 200 to the incoming BYE, even though the outgoing BYE may actually happen much later, or come from the other direction.

Trying and Ringing are optional, although I think Asterisk always sends Trying. Many dialplans send OK before the B side INVITE has been sent.

9

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.