Asterisk crashes on Transfer function with tel: URL

Asterisk Asterisk SIP
1

Hi,

I’m trying to setup a call forward to a twilio number. My asterisk installation crashes on execution of the transfer command and restarts.

My setup:
Asterisk 20.9.2 built by root @ e4b08db6ee4e on a x86_64 running Linux on 2024-08-09 10:43:08 UTC

File extensions_custom.conf

[external-transfer-out]
exten => s,1,transfer(tel:+4961037899999)

Log output:

2024-09-16 20:27:09] VERBOSE[1484][C-00000001] pbx.c: Executing [1001@ext-local:5] GotoIf("PJSIP/anonymous-00000000", "0?external-transfer-out,s,1") in new stack

[2024-09-16 20:27:09] VERBOSE[1484][C-00000001] pbx.c: Executing [1001@ext-local:6] GotoIf("PJSIP/anonymous-00000000", "0?external-transfer-out,s,1") in new stack

[2024-09-16 20:27:09] VERBOSE[1484][C-00000001] pbx.c: Executing [1001@ext-local:7] GotoIf("PJSIP/anonymous-00000000", "1?external-transfer-out,s,1") in new stack

[2024-09-16 20:27:09] VERBOSE[1484][C-00000001] pbx_builtins.c: Goto (external-transfer-out,s,1)

[2024-09-16 20:27:09] VERBOSE[1484][C-00000001] pbx.c: Executing [s@external-transfer-out:1] Transfer("PJSIP/anonymous-00000000", "tel:+496103789999") in new stack

[2024-09-16 20:27:11] Asterisk 20.9.2 built by root @ e4b08db6ee4e on a x86_64 running Linux on 2024-08-09 10:43:08 UTC

[2024-09-16 20:27:11] VERBOSE[1603] pbx.c: Asterisk PBX Core Initializing

[2024-09-16 20:27:11] VERBOSE[1603] loader.c: Asterisk Dynamic Loader Starting:
[2024-09-16 20:27:11] NOTICE[1603] loader.c: 335 modules will be loaded.

any help or hint appretiated

2

We shouldn’t crash there, but regardless it is not supported there either. Support would need to be added.

3

@jcolp thanks for quick reply. Means tel-schema is not supported in transfer command?

4

It is not.

5

From my understanding twilio expects a SIP REFER for a call forward/transfer.

Asterisk’s transfer command seems to do that, but I do not have a SIP phone number. Any idea/hint how to invoke that SIP REFER with Asterisk?

6

Use Transfer, with a SIP: URI, after the call is answered.

Note this is the first I’ve heard this of Twilio. Other providers use redirection headers to indicate that an outgoing leg is the result of an incoming leg, so should have had its CLI forwarded. However I have no personal experience of doing this.

I actually thought it was uncommon for providers to support REFER>

7

Cant use sip:URI schema, because the number I want to forward to is not behind sip.

from twilio docu:

Call Transfer to the PSTN

In order to transfer a call to the PSTN you must include your Trunking Termination Domain for example sip:+14152908007@{my-trunk}.pstn.twilio.com or alternatively use a Tel-URI for example tel:+14152909007 in the Refer-To header.

so, thats the reason, why I’m trying to use tel schema here, because the number I’m trying to forward to is not under sip…

8

Yes it is. And this is the form of the SIP URI required:

9

@david551, thanks

just for understanding
I have a number on sip trunk, where the originating call is coming
asterisk receives that call and because nobody can answer that call should be transfered to another number.

you say, that that another number should be on a sip trunk in twilio. If so, twilio will send it to asterisk again and I’ll end in a infinite loop.

10

Twilio would only send it to Asterisk again, possibly, if you tell it to redirect the call to a number that is routed to Asterisk. If you SIP REFER to a number that is not yours, then Twilio would presumably just send the call within their infrastructure and you would have no further knowledge of it.

11

I know, it is not a twilio support, but

What I experience here is:

  1. call is coming from external caller to a sip trunk on twilio 496103XXX107
  2. call is processed by asterisk on my side (there is no active extension)
  3. call is forwarded to another number via schema suggested above with the url for as under 1) +496103789XXXX@amXXXdeadsink.pstn.frankfurt.twilio.com
  4. call is processed by asterisk again, but the DID is not the configured one, so asterisk answers with a message “the number you are calling is not in use”.

I desperatly trying to configure reliable call forward, but I dont know anymore where to look.

my custom extension configuration looks like this:

[external-transfer-out]
exten => s,1,transfer(sip:+496103789XXXX@amXXXdeadsink.pstn.frankfurt.twilio.com)

in the log I see following on transfer execution

Goto (external-transfer-out,s,1)
    -- Executing [s@external-transfer-out:1] Transfer("PJSIP/anonymous-00000004", "sip:+496103789XXXX@amXXXdeadsink.pstn.frankfurt.twilio.com") in new stack
<--- Transmitting SIP response (836 bytes) to UDP:35.156.191.130:5060 --->
SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/UDP 35.156.191.130:5060;rport=5060;received=35.156.191.130;branch=z9hG4bKf32b.c71958721b021d1bd6fe5ace7fe7ed20.0
Via: SIP/2.0/UDP 172.21.3.226:5060;rport=5060;branch=z9hG4bK97ecb7db-4b93-4cf1-9125-f1d9452ff396_c3356d0b_574-2396459263288941071
Record-Route: <sip:35.156.191.130;lr>
Call-ID: 41039e3ef02abe1364808882d982f4f6@0.0.0.0
From: <sip:+49176XXXX80@amXXXsipzentrale.pstn.twilio.com>;tag=23467067_c3356d0b_97ecb7db-4b93-4cf1-9125-f1d9452ff396
To: <sip:+496103XXX107@194.XXX.XX.143>;tag=8e331e54-54cf-4bc9-a377-527f2d0831f8
CSeq: 45109 INVITE
Server: FPBX-16.0.40.8(20.9.2)
Contact: <sip:+496103789XXXX@194.XXX.XX.143>
Reason: Q.850;cause=0
Supported: histinfo
Diversion: <sip:+496103XXX107@amXXXsipzentrale.pstn.twilio.com>;reason=unconditional
Content-Length:  0

what I observe here, is, the asterisk replies with 302 Moved Temporary, instead of SIP REFER and uses Contact the number I want, BUT always with the IP from the asterisk server.

any further hint?

12

302 is because the call has not been answered. REFER can only be used for answered calls. Other people seem to be asking questions based on wanting to use 302 with Twilio.

I’m surprised that the domain name is being resolved. That looks wrong to me.

You haven’t said what 194.XXX.XX.143 represents and you have obfuscated both domain and IP sufficiently that I can’t work that out by doing DNS lookups.

I wonder if you have rewrite_contact and there is a bug causing it to rewrite every contact, not just those it should overwrite. If so note that none of the NAT hacks (rewrite_contact, force_rport, and symmetric_media) should be needed when using a competent provider. They should only be needed when accessing phones which can’t be properly configured for use behind NAT. Normal providers should only be outside NAT, not behind it.

13

302 is because the call has not been answered. REFER can only be used for answered calls.

I saw that on Transfer documentation. The call cannot be answered, because nobody can do that. THerefore the call should be forwarded.

Any possibility to tweak that behaviour via dialplan configuration?
I’m trying here and there, but nothing works.

The Adress 194.XXX.XX.143 represents the server IP where asterisk is running.

Regarding wrong contact field I’ve found this discussion from last year: Problem to transfer call with pjsip

14

and similar question regarding contact field just a moment ago, with your reference to documentation for redirect method: Asterisk not redirecting calls properly

thats all is somehow connected…

15

I think that Twilio will be happy with 302, if they accept redirects, at all. Strangely, you answer the call by calling Answer(), or as a side effect of some other applications, but note that answering will start the billing clock, for the caller, if the call is chargeable.

The other thread is about incoming redirects, not outgoing ones, unless I read it wrongly. My answer was about incoming ones. Incoming redirect => outgoing call.

16

I’ve run the wireshark on the other thread and it is definitely an incoming (302) redirection, so my answer, on that one, stands. Also note on that one that the unexpected IP address is not that of Asterisk.

You didn’t answer the implied question as to whether you had rewrite contact set. As noted, this should not be required for competent ITSPs.

17

It occurs to me that, if Asterisk is inappropriately applying rewrite_contact to the Contact header in 302 responses, that could explain, although not justify, the original crash, as it could mishandle the missing “@” in the tel: URI, and try to replace a domain that didn’t exist, in the first place.

If that is the case going through the proper crash reporting process (including backtraces from a non-optimised build) might show the crash to be in the rewrit_contact code, although sometimes such errors produce a delayed crash.

18

The rewrite_contact option is not applied in that scenario, and it has protection against non-SIP/SIPS based URIs. It would be the external_signaling_address option on transport that would be applied, and it also has protection. There is also an issue where external_signaling_address is applied to the Contact on requests/responses it shouldn’t be, specifically when using Transfer().

An issue can certainly be filed with a backtrace, but there’s no guarantee of if/when it would be looked at and resolved.

19

Is that issue on Github? I couldn’t find it. It could mean that the OP has to answer the call, until it is fixed.

20

I wasn’t able to find it quickly either, I may have told someone to report it and they never did.