Receiving no Calling number via SIP Trunk

Asterisk Asterisk SIP
1 
We've a SIP Trunk and we're receiving 994X digits. The calls establish successfully, but the calling arrives in the destination as "unknown".

The result of the trace:

<--- SIP read from UDP:10.192.4.188:5060 --->
INVITE sip:9940@10.192.230.231:5060 SIP/2.0
Via: SIP/2.0/UDP 10.192.4.178;branch=z9hG4bK766a.5a652c6ff1dcbe13d2a9d2a59b38caf9.0
Via: SIP/2.0/UDP 192.168.111.250:5080;branch=z9hG4bK15fe7331;rport=5080
Max-Forwards: 69
From: "Rui Santos" <sip:1432@gt.ipphone.molde.pt>;tag=as261eb33b
To: <sip:9940@10.192.230.231:5060>
Contact: <sip:1432@10.192.4.178:5060>
Call-ID: 594384fc2fd8eeac4d61d52e4353f718@gt.ipphone.socem.pt
CSeq: 102 INVITE
User-Agent: IPBrick
Date: Tue, 27 Nov 2018 17:40:49 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
P-Asserted-Identity: <sip:1432@10.192.230.231>
Content-Type: application/sdp
Content-Length: 247

In my extensions.conf:

exten => _9XXX,1,Ringing()
exten => _9XXX,2,Dial({TRUNKSAGRES}/{EXTEN},180,tT)
exten => _9XXX,3,Hangup()

I’ve changed it without success to the following:

exten => _9XXX,1,Ringing()
exten => _9XXX,2,Set(CALLERID(num)={SIP_HEADER(P-Asserted-Identity)}) exten => _9XXX,3,SipAddHeader(P-Asserted-Identity: {CALLERID(num)})
exten => _9XXX,4,Dial({TRUNKSAGRES}/{EXTEN},180,tT)
exten => _9XXX,5,Hangup()

I do not know what to do to pass the calling number … :frowning:

2

Please do not try to manipulate this header directly. Simply use trustrpid=yes to have it read, and sendrpid=pai to have it written.

Also, please mark dialplan as preformatted text, on the forum.

3 
[quote="david551, post:2, topic:77346"]
sendrpid=pai
[/quote]

Hi David, thanks for your reply. I didn't undestand very well your suggestion. I've tried the following:

Incoming Trunk:

[TRUNKSIP-MOLDES]
type=peer
host=10.192.4.178
context=incoming-moldes
disallow=all
allow = ulaw
dtmfmode=rfc2833
faxdetect=yes
t38pt_udptl=yes,redundancy,maxdatagram=400
canreinvite=no
qualify=8000
trustrpid=yes
sendrpid=yes
;sendrpid=pai
nat=no
deny=0.0.0.0/0.0.0.0
permit=10.192.4.178/255.255.255.255

Outgoing Trunk:

[TRUNKSIP-SAGRES]
type=peer
host=10.192.124.101
context=incoming-tlm
;disallow=all
allow = all
dtmfmode=inband
directmedia=no
qualify=yes
;sendrpid=pai 
sendrpid=yes
trust_id_outbound = yes
nat=no
deny=0.0.0.0/0.0.0.0
permit=10.192.124.101/255.255.255.255

And:

[TRUNKSIP-MOLDES]
type=peer
host=10.192.4.178
context=incoming-moldes
disallow=all
allow = ulaw
dtmfmode=rfc2833
faxdetect=yes
t38pt_udptl=yes,redundancy,maxdatagram=400
canreinvite=no
qualify=8000
trustrpid=yes
;sendrpid=yes
sendrpid=pai
nat=no
deny=0.0.0.0/0.0.0.0
permit=10.192.4.178/255.255.255.255

Outgoing Trunk:

[TRUNKSIP-SAGRES]
type=peer
host=10.192.124.101
context=incoming-tlm
;disallow=all
allow = all
dtmfmode=inband
directmedia=no
qualify=yes
;sendrpid=pai 
sendrpid=yes
trust_id_outbound = yes
nat=no
deny=0.0.0.0/0.0.0.0
permit=10.192.124.101/255.255.255.255

In both cases the call didn't went to the outgoing trunk and the caller gets the following information in his VoIP Terminal -> 403 - forbidden.

Which configuration shoud I have please?

The versions of Asterisks are 13.10.
4 
Even with the following configuration, the result is the same:

Incoming Trunk:

[TRUNKSIP-MOLDES]
type=peer
host=10.192.4.178
context=incoming-moldes
disallow=all
allow = ulaw
dtmfmode=rfc2833
faxdetect=yes
t38pt_udptl=yes,redundancy,maxdatagram=400
canreinvite=no
qualify=8000
nat=no
deny=0.0.0.0/0.0.0.0
permit=10.192.4.178/255.255.255.255

Outgoing Trunk:

[TRUNKSIP-SAGRES]
type=peer
host=10.192.124.101
context=incoming-tlm
;disallow=all
allow = all
dtmfmode=inband
directmedia=no
qualify=yes
sendrpid=pai 
trustrpid=yes
nat=no
deny=0.0.0.0/0.0.0.0
permit=10.192.124.101/255.255.255.255

 It appear 403 forbidden in the terminal of the caller and it didn't went to outgoing trunk (Sagres). The error i logging: 

-- Executing [9942@incoming-moldes:1] Ringing("SIP/TRUNKSIP-MOLDES-000002b3", "") in new stack
    -- Auto fallthrough, channel 'SIP/TRUNKSIP-MOLDES-000002b3' status is 'UNKNOWN'
  == Using SIP RTP CoS mark

5

5

And this what We get from the client in our Asterisk:


<--- SIP read from UDP:10.192.4.178:5060 --->
INVITE sip:9940@10.192.230.231:5060 SIP/2.0
Via: SIP/2.0/UDP 10.192.4.178;branch=z9hG4bK766a.5a652c6ff1dcbe13d2a9d2a59b38caf9.0
Via: SIP/2.0/UDP 192.168.111.250:5080;branch=z9hG4bK15fe7331;rport=5080
Max-Forwards: 69
From: "Rui Santos" <sip:1432@gt.ipphone.moldes.pt>;tag=as261eb33b
To: <sip:9940@10.192.230.231:5060>
Contact: <sip:1432@10.192.4.178:5060>
Call-ID: 594384fc2fd8eeac4d61d52e4353f718@gt.ipphone.socem.pt
CSeq: 102 INVITE
User-Agent: IPBrick
Date: Tue, 27 Nov 2018 17:40:49 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
P-Asserted-Identity: <sip:1432@10.192.230.231>
Content-Type: application/sdp
Content-Length: 247
6

The goal is to send 1432 to the outgoing SIP trunk (Sagres).

7

That’s what you are now doing… If the other end of the trunk doesn’t honour this you need to talk to the people that maintain that.

I am assuming that both trunks actually use P-Asserted-Identity.

Note these look like tie trunks, but trunks to the PSTN would not normally honour caller-ID, unless, possibly you had proved you controlled the number in use.

Also, please note that canreinvite has been deprecated since about Asterisk 6.

8 
We've a SIP Trunk with a Client (IPPbrick), and the call comes from the incoming Trunk referred above (Moldes), and then our Asterisk must route that call to another Asterisk (mine) via outgoing Trunk (Sagres). So what Can I must do please? (sorry I didn't understand your explanation)

And if canreinvite is deprecated I can suppress both lines in both trunks right?
9

And if the client is sending the caller ID correctly as shown below why Our Asterisk doesn’t forward that Caller ID information to my another Asterisk?

From: “Rui Santos” <sip:1432@gt.ipphone.moldes.pt>;tag=as261eb33b To: <sip:9940@10.192.230.231:5060>
[/quote]

10 
Now, in my Asterisk Viriato I've:

Incoming Trunk to Cliente (IPBrick PBX)

[TRUNKSIP-MOLDES]
type=peer
host=10.192.4.178
context=incoming-socem
disallow=all
allow = ulaw
dtmfmode=rfc2833
faxdetect=yes
t38pt_udptl=yes,redundancy,maxdatagram=400
canreinvite=no
qualify=yes
;trustrpid=yes
;sendrpid=yes
;sendrpid=pai
nat=no
deny=0.0.0.0/0.0.0.0
permit=10.192.4.178/255.255.255.255

Outgoing Trunk to My Asterisk Sagres:

[TRUNKSIP-SAGRES]
type=peer
host=10.192.124.101
context=incoming-tlm
;disallow=all
allow = all
dtmfmode=inband
directmedia=no
qualify=yes
trustrpid=yes
;sendrpid=yes
sendrpid=pai
nat=no
deny=0.0.0.0/0.0.0.0
permit=10.192.124.101/255.255.255.255

And in My Asterisk Sagres:

[TRUNKSIP-VIRIATO]
type=peer
host=10.192.230.231
context=and_int
;disallow=all
allow = all
dtmfmode=inband
directmedia=no
qualify=yes
nat=comedia
trustrpid=yes
sendrpid=pai
deny=0.0.0.0/0.0.0.0
permit=10.192.230.231/255.255.255.255

What we get in Asterisk Viriato:

 Executing [9942@incoming-socem:1] Ringing("SIP/TRUNKSIP-SOCEM-00000483", "") in new stack
    -- Auto fallthrough, channel 'SIP/TRUNKSIP-SOCEM-00000483' status is 'UNKNOWN'
11

In Sagres Asterisk we got nothing.

12

Sorry, I thought you had actually provided the outgoing SIP request, as well. You need to do that. You need to provide the full text, not just a few lines, as the From header can be influenced by

Please note that Asterisk has no concept of trunks and certainly no concept of outgoing an incoming trunks, so, if you have two sip.conf entries for the same peer, you may find that incoming calls are actually matched to the one you consider outgoing.

Also please note that full support for PAI started in Asterisk 1.8, so if you are using an obsolete version, sendrpid and trustrpid may not work as expected.

canreinvite is not relevant to your problem, and saying it was deprecated was a hint to read the documentation. It has been replaced by directmedia. Currently canreinvite is treated as an alternative name for directmedia, but is a good indication that someone has cut and pasted a configuration without understanding it.

13

I would also suggest providing the current dialplan logic for that particular context again, because it seems as though it is incorrect and the channel is falling through and hanging up.

14

And please mark everything quoted as pre-formatted, as missing characters and lines run together make it difficult to read.

15 
I've fixed the dialplan. Thanks jcolp!

I've maintained the configuration of SIP.conf files of my Asterisks (Viriato and Sagres) as referred above. The problem still remains. The destination doesn't see 1432 but "Unknown"...

The trace received in Viriato:

<--- SIP read from UDP:10.192.4.178:5060 --->
INVITE sip:9940@10.192.230.231:5060 SIP/2.0
Via: SIP/2.0/UDP 10.192.4.178;branch=z9hG4bK766a.5a652c6ff1dcbe13d2a9d2a59b38caf9.0
Via: SIP/2.0/UDP 192.168.111.250:5080;branch=z9hG4bK15fe7331;rport=5080
Max-Forwards: 69
From: "Rui Santos" <sip:1432@gt.ipphone.socem.pt>;tag=as261eb33b
To: <sip:9940@10.192.230.231:5060>
Contact: <sip:1432@10.192.4.178:5060>
Call-ID: 594384fc2fd8eeac4d61d52e4353f718@gt.ipphone.socem.pt
CSeq: 102 INVITE
User-Agent: IPBrick
Date: Tue, 27 Nov 2018 17:40:49 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
P-Asserted-Identity: <sip:1432@10.192.230.231>
Content-Type: application/sdp
Content-Length: 247

And now? (Asterisk Version 13.10 for both)

Regarding formatting text I’m selecting all the text and then select </> Isn’t it the right procedure?

16

You still haven’t provided the complete outgoing request, and you did not use </> on the partial quote that you provided earlier.

17 
David,

The integral SIP trace obtained from the Asterisk Viriato (Calling 1431 and Called 9941) and in Sagres Asterisk attached.
```<a class="attachment" href="/uploads/default/original/2X/f/f0589ff0a4d2343144c4b86b023c18b10e152946.txt">Trace_moldes_Sagres.txt</a> (70.8 KB)
 <a class="attachment" href="/uploads/default/original/2X/6/67aea4cc62226846b9866d7539cc664e99508b5a.txt">Trace_Modes_Viriato.txt</a> (77.4 KB)