Toplink Express Asterisk Conf Issue - ToHeader activation

ansas · May 31, 2021, 9:33am

Hi alltogether,

I am struggling with an inbound routing of calls from “Toplink Xpress”.
Found great tips in this forum from Stewart1 regarding toplink
however - even with “sendrpid=pai” the inbound rules are not working (should call SIP 2001)
Only the Userdefinition is working as default (is calling SIP 2000)

The INVITE logs snipped are following shortly - thanks for the help in advance !

May 31 11:09:33 VERBOSE15459 chan_sip.c:
— SIP read from UDP:SOURCE_IPV6:5060 —
INVITE sip:P102_TOPLINK_USER AT TARGET_IPV6_ASTERISK:5060 SIP/2.0
Via: SIP/2.0/UDP SOURCE_IPV6:5060;branch=z9hG4bKac1706824423
Max-Forwards: 52
From: sip:+49172_SOURCE_MOBILE_PHONE AT PROVIDER;user=phone;id=TelNGN;tag=1c1297377107
To: sip:+4989_TARGET_FIXED_LINE_NR AT PROVIDER
Call-ID: 105970020315202110932 AT SOURCE_IPV6
CSeq: 1 INVITE
Contact: sip:+49172_SOURCE_MOBILE_PHONE AT SOURCE_IPV6:5060;line=sr-N6IAzBFwMJZLWJZfWmZfM.P-W.y6Mx1dCRsIH9WLOjZ6mjt-Pqs0.msek9YZ…pWOBWl.4eSWtpTRqfWOhq1KLssWquZM9W5pwIa.9rsW4uZk.p9NKp4K6fsN4uZCBpWkUI0.jpCp4uZahW-p6tMMueloFs.jjfAkUKuguKsTc**
Supported: from-change,100rel,timer,replaces,histinfo,sdp-anat
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, REFER, NOTIFY, SUBSCRIBE, UPDATE
P-Preferred-Identity: sip:+49172_SOURCE_MOBILE_PHONE AT PROVIDER
User-Agent: TELES-SBC
P-Asserted-Identity: sip:+49172_SOURCE_MOBILE_PHONE AT PROVIDER;user=phone
P-Charging-Vector: TARGET_IPV6_ASTERISK
Content-Type: application/sdp
Content-Length: 451
P-Early-Media: sendrecv
P-Ie-Display:

v=0
o=- 1831960063 1040775049 IN IP6 2001:4180:3:2:213:218:12:40
s=TELES-SBC
c=IN IP6 2001:4180:3:2:213:218:12:40
t=0 0
m=audio 12030 RTP/AVP 8 0 18 2 101
c=IN IP6 2001:4180:3:2:213:218:12:40
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=silenceSupp:on - - - -
a=rtcp:12031 IN IP6 2001:4180:3:2:213:218:12:40
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:2 G726-32/8000

May 31 11:09:33 VERBOSE15459 chan_sip.c: — (18 headers 17 lines) —
May 31 11:09:33 VERBOSE15459 chan_sip.c: Sending to SOURCE_IPV6:5060 (no NAT)
May 31 11:09:33 VERBOSE15459C-0000000b chan_sip.c: Sending to SOURCE_IPV6:5060 (no NAT)
May 31 11:09:33 VERBOSE15459C-0000000b chan_sip.c: Using INVITE request as basis request - 105970020315202110932 AT SOURCE_IPV6
May 31 11:09:33 VERBOSE15459C-0000000b chan_sip.c: Found peer ‘toplink1’ for ‘+49172_SOURCE_MOBILE_PHONE’ from SOURCE_IPV6:5060
May 31 11:09:33 VERBOSE15459C-0000000b chan_sip.c: Found RTP audio format 8
May 31 11:09:33 VERBOSE15459C-0000000b chan_sip.c: Found RTP audio format 0
May 31 11:09:33 VERBOSE15459C-0000000b chan_sip.c: Found RTP audio format 18
May 31 11:09:33 VERBOSE15459C-0000000b chan_sip.c: Found RTP audio format 2
May 31 11:09:33 VERBOSE15459C-0000000b chan_sip.c: Found RTP audio format 101
May 31 11:09:33 VERBOSE15459C-0000000b chan_sip.c: Found audio description format PCMA for ID 8
May 31 11:09:33 VERBOSE15459C-0000000b chan_sip.c: Found audio description format telephone-event for ID 101
May 31 11:09:33 VERBOSE15459C-0000000b chan_sip.c: Found audio description format PCMU for ID 0
May 31 11:09:33 VERBOSE15459C-0000000b chan_sip.c: Found audio description format G729 for ID 18
May 31 11:09:33 VERBOSE15459C-0000000b chan_sip.c: Found audio description format G726-32 for ID 2
May 31 11:09:33 VERBOSE15459C-0000000b chan_sip.c: Capabilities: us - (ulaw|alaw|gsm|h263), peer - audio=(ulaw|g726|alaw|g729)/video=(nothing)/text=(nothing), combined - (ulaw|alaw)
May 31 11:09:33 VERBOSE15459C-0000000b chan_sip.c: Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x1 (telephone-event|), combined - 0x1 (telephone-event|)
May 31 11:09:33 VERBOSE15459C-0000000b chan_sip.c: Peer audio RTP is at port 2001:4180:3:2:213:218:12:40:12030
May 31 11:09:33 VERBOSE15459C-0000000b chan_sip.c: Looking for P102_TOPLINK_USER in toplink-in (domain TARGET_IPV6_ASTERISK)
May 31 11:09:33 VERBOSE15459C-0000000b sip/route.c: sip_route_dump: route/path hop: sip:+49172_SOURCE_MOBILE_PHONE AT SOURCE_IPV6:5060;line=sr-N6IAzBFwMJZLWJZfWmZfM.P-W.y6Mx1dCRsIH9WLOjZ6mjt-Pqs0.msek9YZ…pWOBWl.4eSWtpTRqfWOhq1KLssWquZM9W5pwIa.9rsW4uZk.p9NKp4K6fsN4uZCBpWkUI0.jpCp4uZahW-p6tMMueloFs.jjfAkUKuguKsTc**
May 31 11:09:33 VERBOSE15459C-0000000b chan_sip.c:
— Transmitting (no NAT) to SOURCE_IPV6:5060 —
SIP/2.0 100 Trying
Via: SIP/2.0/UDP SOURCE_IPV6:5060;branch=z9hG4bKac1706824423;received=SOURCE_IPV6
From: sip:+49172_SOURCE_MOBILE_PHONE AT PROVIDER;user=phone;id=TelNGN;tag=1c1297377107
To: sip:+4989_TARGET_FIXED_LINE_NR AT PROVIDER
Call-ID: 105970020315202110932 AT SOURCE_IPV6
CSeq: 1 INVITE
Server: Asterisk PBX 16.2.1~dfsg-1+deb10u2
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Contact: sip:P102_TOPLINK_USER AT TARGET_IPV6_ASTERISK:5060
Content-Length: 0

May 31 11:09:33 VERBOSE15594C-0000000b chan_sip.c: Audio is at 17042
May 31 11:09:33 VERBOSE15594C-0000000b chan_sip.c: Adding codec ulaw to SDP
May 31 11:09:33 VERBOSE15594C-0000000b chan_sip.c: Adding codec alaw to SDP
May 31 11:09:33 VERBOSE15594C-0000000b chan_sip.c: Adding codec gsm to SDP
May 31 11:09:33 VERBOSE15594C-0000000b chan_sip.c: Adding non-codec 0x1 (telephone-event) to SDP
May 31 11:09:33 VERBOSE15594C-0000000b chan_sip.c: Reliably Transmitting (no NAT) to 2001:a61:258e:be00:2e3a:fdff:febe:917b:5060:
INVITE sip:2000 AT 2001:a61:258e:be00:2e3a:fdff:febe:917b;uniq=926EAB31F80FE98695AF7ED4E317A SIP/2.0
Via: SIP/2.0/UDP TARGET_IPV6_ASTERISK:5060;branch=z9hG4bK07d8f320
Max-Forwards: 70
From: sip:+49172_SOURCE_MOBILE_PHONE AT TARGET_IPV6_ASTERISK;tag=as33071bc5
To: sip:2000 AT 2001:a61:258e:be00:2e3a:fdff:febe:917b;uniq=926EAB31F80FE98695AF7ED4E317A
Contact: sip:+49172_SOURCE_MOBILE_PHONE AT TARGET_IPV6_ASTERISK:5060
Call-ID: 04998a2a1a93a99c06732bd707f13d41 AT TARGET_IPV6_ASTERISK:5060
CSeq: 102 INVITE
User-Agent: Asterisk PBX 16.2.1~dfsg-1+deb10u2
Date: Mon, 31 May 2021 09:09:33 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
P-Asserted-Identity: “+49172_SOURCE_MOBILE_PHONE” sip:+49172_SOURCE_MOBILE_PHONE AT TARGET_IPV6_ASTERISK
Content-Type: application/sdp
Content-Length: 347

ansas · May 31, 2021, 9:54am

sorry - there the configs:

sip_conf
[toplink1]
context=toplink-in
fromuser = P102…
username = P102…
fromdomain = sip_toplink-xpress_de
host= sip_toplink-xpress_de
secret = verygoodpasswordindeed
type = peer
qualify = yes
insecure = port,invite
sendrpid=pai

extensions_conf
[toplink-in]
exten => _85mainline,1,Dial(SIP/2000)
exten => _919other number,1,Dial(SIP/2001)

david55 · May 31, 2021, 11:06am

The log looks like part of a successful call.

You haven’t enabled sufficient verbosity to see how it is being handled by he dialplan.

You have redacted the request URI, so one cannot see how it would have been handled by the dialplan you have provided.

You seem to have completely bypassed FreePBX by directing the call into a context not managed by FreePBX. Extracting the “DID” from the To header is something that is done by the FreePBX code, which you have bypassed.

sendrpid is completely irrelevant to this, and won’t have an effect until further down the log you provided.

Do you really need insecure=port, or is this just a mechanical translation of insecure=very? This just causes a minor compromise to security.

ansas · May 31, 2021, 11:56am

The “insecure” setting is a recommendation by the carrier:
https://www_toplink-xpress_de/wie-kann-ich-meinen-ip-anschluss-an-einer-asterisk-basierten-anlage-einrichten/
I’ll give it a try to remove “port”.

The “sendrpid” is according to another thread - and seemed to have helped:
https://community_freepbx_org/t/toplink-xpress-sip-trunk/62210/2

I reduced the URI as I mistakenly hardshortened it as I cannot post links.
What specific line to you need ?
In generally the call itself succeeds - just ringing on the wrong number.

Currenty I am testing on a “bare” asterisk as I am unsure where the problem relates from.
Other PBX distributions failed on other requirements - CallerID outgoing ect.

Thank you !

david55 · May 31, 2021, 12:08pm

DID processing is part of the added value from FreePBX. Bare Asterisk won’t do it it unless you explicitly add dialplan to do it. In this case you would need to invoke SIPGetHeader, as you are using the, legacy, chan_sip driver, and then parse the DID out of the result and route on it.

Carriers are rarely a good source. They tend to provide things which work, but include deprecated values and are not as secure as they could be. In the case of insecure, making the system as insecure as possible means it is less likely that there will be authorisation failures, and therefore followup calls to the provider, but is not best practice.

ansas · May 31, 2021, 12:26pm

The dialplan is given in extensions…
So I’ll put this config into a freepbx instance and will give it a try. Updates will (hopefully not) follow.

Nice comment on carriers Thanks a lot !

system · July 1, 2021, 12:26pm

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