LLamadas se cortan a a los 28 segundos


(México) #1

Hola tengo problema con la llamadas entre una extensión remota y una local, entre ellas las llamadas se caen en 28 segundos, Para conectarse la extensión remota tuve que abrir los puerto y crear reglas en mi fortigate. Agrego captura de log en de las llamadas :
[2021-06-25 11:48:01] VERBOSE[1943][C-00004de8] app_dial.c: PJSIP/604-00004df8 is ringing
[2021-06-25 11:48:01] VERBOSE[1943][C-00004de8] app_dial.c: PJSIP/604-00004df8 is ringing
[2021-06-25 11:48:07] VERBOSE[1943][C-00004de8] app_dial.c: PJSIP/604-00004df8 answered PJSIP/800-00004df7
[2021-06-25 11:48:07] VERBOSE[2022][C-00004de8] bridge_channel.c: Channel PJSIP/604-00004df8 joined ‘simple_bridge’ basic-bridge <426cc166-6e23-4880-b9f5-4e1ebbe550e4>
[2021-06-25 11:48:07] VERBOSE[1943][C-00004de8] bridge_channel.c: Channel PJSIP/800-00004df7 joined ‘simple_bridge’ basic-bridge <426cc166-6e23-4880-b9f5-4e1ebbe550e4>
[2021-06-25 11:48:39] VERBOSE[1943][C-00004de8] bridge_channel.c: Channel PJSIP/800-00004df7 left ‘simple_bridge’ basic-bridge <426cc166-6e23-4880-b9f5-4e1ebbe550e4>
[2021-06-25 11:48:39] VERBOSE[1943][C-00004de8] app_macro.c: Spawn extension (macro-dial-one, s, 56) exited non-zero on ‘PJSIP/800-00004df7’ in macro ‘dial-one’
[2021-06-25 11:48:39] VERBOSE[1943][C-00004de8] app_macro.c: Spawn extension (macro-exten-vm, s, 26) exited non-zero on ‘PJSIP/800-00004df7’ in macro ‘exten-vm’
[2021-06-25 11:48:39] VERBOSE[1943][C-00004de8] pbx.c: Spawn extension (ext-local, 604, 3) exited non-zero on ‘PJSIP/800-00004df7’
[2021-06-25 11:48:39] VERBOSE[1943][C-00004de8] pbx.c: Executing [[email protected]:1] Macro(“PJSIP/800-00004df7”, “hangupcall,”) in new stack
[2021-06-25 11:48:39] VERBOSE[1943][C-00004de8] pbx.c: Executing [[email protected]:1] GotoIf(“PJSIP/800-00004df7”, “1?theend”) in new stack
[2021-06-25 11:48:39] VERBOSE[1943][C-00004de8] pbx_builtins.c: Goto (macro-hangupcall,s,3)
[2021-06-25 11:48:39] VERBOSE[2022][C-00004de8] bridge_channel.c: Channel PJSIP/604-00004df8 left ‘simple_bridge’ basic-bridge <426cc166-6e23-4880-b9f5-4e1ebbe550e4>
[2021-06-25 11:48:39] VERBOSE[1943][C-00004de8] pbx.c: Executing [[email protected]:3] ExecIf(“PJSIP/800-00004df7”, “0?Set(CDR(recordingfile)=)”) in new stack
[2021-06-25 11:48:39] VERBOSE[1943][C-00004de8] pbx.c: Executing [[email protected]:4] NoOp(“PJSIP/800-00004df7”, "PJSIP/604-00004df8 montior file= ") in new stack
[2021-06-25 11:48:39] VERBOSE[1943][C-00004de8] pbx.c: Executing [[email protected]:5] GotoIf(“PJSIP/800-00004df7”, “1?skipagi”) in new stack
[2021-06-25 11:48:39] VERBOSE[1943][C-00004de8] pbx_builtins.c: Goto (macro-hangupcall,s,7)
[2021-06-25 11:48:39] VERBOSE[1943][C-00004de8] pbx.c: Executing [[email protected]:7] Hangup(“PJSIP/800-00004df7”, “”) in new stack
[2021-06-25 11:48:39] VERBOSE[1943][C-00004de8] app_macro.c: Spawn extension (macro-hangupcall, s, 7) exited non-zero on ‘PJSIP/800-00004df7’ in macro ‘hangupcall’
[2021-06-25 11:48:39] VERBOSE[1943][C-00004de8] pbx.c: Spawn extension (ext-local, h, 1) exited non-zero on ‘PJSIP/800-00004df7’


(David55) #2

Please provide the output from “pjsip set logger on”, from first INVITE to the OK for the BYE.

A disconnect after ~28 seconds is typically the result of failing to set correct external addresses when you are inside NAT and the extension (or trunk) is outside.


(México) #3

No puedeo ejecutar el pjsip set logger on desde la consola, “pjsip no se encontro la orden”


#4

Give the command at the Asterisk command prompt.
From a shell prompt, type
asterisk -r
then type
pjsip set logger on
you should see
PJSIP Logging enabled
then make your test call. Paste the Asterisk log for the complete call at pastebin.freepbx.org and post the link here.


(México) #5

Esta es lo que me muestra durante la llamada https://pastebin.freepbx.org/view/9013e60d. gracias


(David55) #6

The problem is on the incoming (8000) side.

Is 201.139.107.66:5060 a valid address to reach your Asterisk from the caller?

Asterisk has made multiple attempts to send 200 OK to the caller, but the caller has never replied with ACK. The caller should send the ACK to the above address.


#7

Edit: this post is incorrect. Thanks to @dicko for calling attention to my mistake. A corrected version appears later in this thread. The information below is wrong, but I am leaving it in place so the history of the thread can be followed. My apology.

The problem is that in your Fortigate, you are forwarding external TCP port 9756 to internal port 5060. This is not supported by FreePBX (though it is by Asterisk).

Some options:

  1. Forward external port 5060 to internal port 5060, and change the external extensions to connect to port 5060. Unfortunately, you will get quite a bit of malicious traffic sent to port 5060, so you will need to set up the Fortigate and/or FreePBX firewall to accept traffic only from authorized IP addresses.

  2. Forward external port 9756 to internal port 9756, and change Port to Listen on for pjsip transport 0.0.0.0 (tcp) to 9756, then restart Asterisk. This requires you to change any internal extensions using TCP to also connect to port 9756. With luck, you don’t have any (the internal extension in your example uses UDP).

  3. Add to (or create) the file /etc/asterisk/pjsip.transports_custom_post.conf with these contents:
    [0.0.0.0-tcp](+type=transport)
    external_signaling_port=9756
    then restart Asterisk. I’m not sure this will work correctly, but is worth a try if neither (1) nor (2) are feasible.


(David55) #8

Whilst that problem looks, likely, I’m not sure how Asterisk would cope with it. I believe that, to be valid SIP:

  • There would have to a VIa header for the TCP hop;
  • There would have had to be a Record-Route, header, including the TCP hop; and
  • The Contact header would have had to be the TCP address.

I was just looking at those headers and the last hop source address, which looked consistent with what Asterisk was doing.


#9

Is the transport layer being used here UDP or TCP ?

(it makes a big difference)


#10

TCP on the external extension, UDP on the internal one. AFAICT the problem is purely on the external side.


#11

And although my Spanish is poor, I don’t see that the phones or the PBX are actually set to use that transport


#12

You are absolutely right. My bad. I was confused by the ‘transport=TCP’ in the headers. Thanks for the update.

Here is a corrected version of my erroneous post:

The problem is that in your Fortigate, you are forwarding external UDP port 9756 to internal port 5060. This is not supported by FreePBX (though it is by Asterisk).

Some options:

  1. Forward external port 5060 to internal port 5060, and change the external extensions to connect to port 5060. Unfortunately, you will get quite a bit of malicious traffic sent to port 5060, so you will need to set up the Fortigate and/or FreePBX firewall to accept traffic only from authorized IP addresses.
  2. Forward external port 9756 to internal port 9756, and change Port to Listen On for pjsip transport 0.0.0.0 (udp) to 9756, then restart Asterisk. This requires you to change all of your internal extensions using UDP to also connect to port 9756.
  3. Add to (or create) the file /etc/asterisk/pjsip.transports_custom_post.conf with these contents:
    [0.0.0.0-udp](+type=transport)
    external_signaling_port=9756
    then restart Asterisk. I’m not sure this will work correctly, but is worth a try if neither (1) nor (2) are feasible.

(México) #13

Gracias ya provee la primera opción y funciono. Muchas gracias


(system) closed #14

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