Help setting up Asterisk 11.6

Asterisk Asterisk Support
1

I am setting up a very simple 11.6 system with two SIP providers and a single ATA. Flowroute is used for out calling only and works fine. My extensions.conf is:
[globals]

[general]
autofallthrough = yes

[default]

[inbound]
exten => s,1,Dial(SIP/obi_110) ;Incoming calls from Anveo should ring the Obi
exten => s,n,Hangup()

[outbound]
exten => *97,1,Dial(SIP/anveo/*97) ;listen to voice mail from Anveo
exten => *97,n,Hangup()
exten => _NXXXXXX,1,SipAddHeader(P-Asserted-Identity:tel:+11234567890)
exten => _NXXXXXX,n,Dial(SIP/flowroute/1217${EXTEN})
exten => _NXXXXXX,n,Hangup()
exten => _1NXXNXXXXXX,1,SipAddHeader(P-Asserted-Identity:tel:+11234567890)
exten => _1NXXNXXXXXX,n,Dial(SIP/flowroute/${EXTEN})
exten => _1NXXNXXXXXX,n,Hangup()

Out dialing from the Obi works fine except for calling Anveo for voice mail. Inbound from Anveo does not work. “sip show registry” says Anveo is registered. My question is about setting up sip.conf. The manual says that it is best to use a separate “user” and “peer” section instead of “friend”. I believe the section with “context=inbound” will be the one that goes to extension ‘s’? But I can’t figure out whether the context= line belongs in [Anveo] or [Anveo2] and which one should be the peer? Can I get some assistance on this? Thanks in advance.

2

You haven’t provided your sip.conf. You also haven’t provided verbose, or even more detailed. logs.

In many cases you only need a peer. You only need a user if the remote side identifies by From header, and in that case, the section name needs to match that header. (Certain ITSPs need additional inbound peers.)

context is only meaningful inbound.

Note that Asterisk normally manages P-Asserted-Identity (sendrpid=pai), and you should set CALLERID. Without sendrpid AddHeader may well work, but it is a work round for pre-1.8 Asterisk’s.

With autofallthrough (default) you don’t need Hangup.

3

Thank you. I tried callerid but don’t think I had sendrpid set. I’ll try again. Do I still need Hangup at the end of the section or leave it out completely?
[general]
context=default
localnet=198.0.0.0/255.255.255.224 ;This is a dummy
disallow=all
allow=ulaw
;allow=alaw
allow=g729
registertimeout=30
srvlookup=yes
allowguest=no
;jbenable=yes
;jbmaxsize=200
;jbimpl=adaptive
transport=udp
recordonfeature=
recordofffeature=
register => 1234:123456789.@sip.anveo.com:5010~160 ;seems to be registering Ok
;mwi => 1234:secret.@sip.anveo.com:5010/7000 ;turned off for debugging
allowoverlap=no
allowtransfer=no
alwaysauthreject = no ;for debugging
allowexternaldomains=yes ;not sure if this is required ???

[authentication]

[obi_110]
type=friend
context=outbound
host=dynamic
defaultip=bla.bl.bl.bl
canreinvite=yes
nat=no
qualify=no
port=5060
mailbox=7000@SIP_Remote
secret=AnyPassword

[anveo]
type=peer
context=inbound
host=dynamic
canreinvite=nonat
nat=force_rport,comedia
defaultuser=1234 ;not sure which is needed??
fromuser=1234 ;or both ???
port=5010
secret=supersecret ;not sure which is needed??
remotesecret=supersecret ;or both ???
qualify=no
insecure=port,invite

[flowroute]
type=peer
host=sip.flowroute.com
remotesecret=WorksFine
defaultuser=5678
qualify=yes
port=5060
nat=force_rport,comedia
canreinvite=nonat

extensions

[globals]

[general]
autofallthrough = yes

[default]
exten => s,1,NoOp(Made it to the default section!)
exten => s,n,Dial(SIP/obi_110)
exten => s,n,Hangup()

[inbound]
exten => s,1,NoOp(Made it to the inbound section!)
exten => s,n,Dial(SIP/obi_110)
exten => s,n,Hangup()

[outbound]
exten => *97,1,Dial(SIP/anveo/*97) ;Listen to voice mail
exten => *97,n,Hangup()
exten => _X.,1,NoOp(Made it to the outbound section!)
exten => _NXXXXXX,n,SipAddHeader(P-Asserted-Identity:tel:+18475319242)
exten => _NXXXXXX,n,Dial(SIP/flowroute/1217${EXTEN})
exten => _NXXXXXX,n,Hangup()
exten => _1NXXNXXXXXX,1,SipAddHeader(P-Asserted-Identity:tel:+18475319242)
exten => _1NXXNXXXXXX,n,Dial(SIP/flowroute/${EXTEN})
exten => _1NXXNXXXXXX,n,Hangup()

debug

<— SIP read from UDP:72.9.149.69:5010 —>
OPTIONS sip:75.23.112.123:5060 SIP/2.0
Via: SIP/2.0/UDP 72.9.149.69:5010;branch=0
From: sip:ping@noname.com;tag=c0e09145
To: sip:75.23.112.123:5060
Call-ID: 7d9dd2b-a095dd72-aea1a82@72.9.149.69
CSeq: 1 OPTIONS
Content-Length: 0

<------------->
— (7 headers 0 lines) —
Sending to 72.9.149.69:5010 (no NAT)
Looking for s in default (domain 75.23.112.123)

<— Transmitting (no NAT) to 72.9.149.69:5010 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 72.9.149.69:5010;branch=0;received=72.9.149.69
From: sip:ping@noname.com;tag=c0e09145
To: sip:75.23.112.123:5060;tag=as27a84442
Call-ID: 7d9dd2b-a095dd72-aea1a82@72.9.149.69
CSeq: 1 OPTIONS
Server: Asterisk PBX 11.6-cert2
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Contact: sip:172.16.20.22:5060
Accept: application/sdp
Content-Length: 0

<------------>
Scheduling destruction of SIP dialog ‘7d9dd2b-a095dd72-aea1a82@72.9.149.69’ in 32000 ms (Method: OPTIONS)

<— SIP read from UDP:172.16.20.29:5060 —>
INVITE sip:*97@172.16.20.22:5060 SIP/2.0
Call-ID: 73776008@172.16.20.29
Content-Length: 255
CSeq: 8001 INVITE
From: sip:obi_110@172.16.20.22;tag=SP1601d25f41827f0e2
Max-Forwards: 70
To: sip:*97@172.16.20.22
Via: SIP/2.0/UDP 172.16.20.29:5060;branch=z9hG4bK-4fd6b6ce;rport
User-Agent: OBIHAI/OBi110-1.3.0.2824
Contact: sip:obi_110@172.16.20.29:5060
Expires: 60
Supported: replaces
Allow: ACK,BYE,CANCEL,INFO,INVITE,NOTIFY,OPTIONS,REFER,UPDATE
Remote-Party-ID: sip:obi_110@172.16.20.22;party=calling;privacy=off
Content-Type: application/sdp

v=0
o=- 178092 1 IN IP4 172.16.20.29
s=-
c=IN IP4 172.16.20.29
t=0 0
m=audio 16608 RTP/AVP 0 18 101
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=ptime:20
a=xg726bitorder:big-endian
<------------->
— (15 headers 13 lines) —
Sending to 172.16.20.29:5060 (no NAT)
Sending to 172.16.20.29:5060 (no NAT)
Using INVITE request as basis request - 73776008@172.16.20.29
Found peer ‘obi_110’ for ‘obi_110’ from 172.16.20.29:5060

<— Reliably Transmitting (no NAT) to 172.16.20.29:5060 —>
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 172.16.20.29:5060;branch=z9hG4bK-4fd6b6ce;received=172.16.20.29;rport=5060
From: sip:obi_110@172.16.20.22;tag=SP1601d25f41827f0e2
To: sip:*97@172.16.20.22;tag=as67b87259
Call-ID: 73776008@172.16.20.29
CSeq: 8001 INVITE
Server: Asterisk PBX 11.6-cert2
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm=“asterisk”, nonce="7ea415bb"
Content-Length: 0

<------------>
Scheduling destruction of SIP dialog ‘73776008@172.16.20.29’ in 32000 ms (Method: INVITE)

<— SIP read from UDP:172.16.20.29:5060 —>
ACK sip:*97@172.16.20.22:5060 SIP/2.0
Call-ID: 73776008@172.16.20.29
Content-Length: 0
CSeq: 8001 ACK
From: sip:obi_110@172.16.20.22;tag=SP1601d25f41827f0e2
Max-Forwards: 70
To: sip:*97@172.16.20.22;tag=as67b87259
Via: SIP/2.0/UDP 172.16.20.29:5060;branch=z9hG4bK-4fd6b6ce;rport
User-Agent: OBIHAI/OBi110-1.3.0.2824

<------------->
— (9 headers 0 lines) —

<— SIP read from UDP:172.16.20.29:5060 —>
INVITE sip:*97@172.16.20.22:5060 SIP/2.0
Call-ID: 73776008@172.16.20.29
Content-Length: 255
CSeq: 8002 INVITE
From: sip:obi_110@172.16.20.22;tag=SP1601d25f41827f0e2
Max-Forwards: 70
To: sip:*97@172.16.20.22
Via: SIP/2.0/UDP 172.16.20.29:5060;branch=z9hG4bK-489dd3e7;rport
Authorization: DIGEST algorithm=MD5,nonce=“7ea415bb”,realm=“asterisk”,response=“cf0aefecfb6a195552f7f34c03b4d92a”,uri=“sip:*97@172.16.20.22:5060”,username="obi_110"
User-Agent: OBIHAI/OBi110-1.3.0.2824
Contact: sip:obi_110@172.16.20.29:5060
Expires: 60
Supported: replaces
Allow: ACK,BYE,CANCEL,INFO,INVITE,NOTIFY,OPTIONS,REFER,UPDATE
Remote-Party-ID: sip:obi_110@172.16.20.22;party=calling;privacy=off
Content-Type: application/sdp

v=0
o=- 178092 1 IN IP4 172.16.20.29
s=-
c=IN IP4 172.16.20.29
t=0 0
m=audio 16608 RTP/AVP 0 18 101
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=ptime:20
a=xg726bitorder:big-endian
<------------->
— (16 headers 13 lines) —
Sending to 172.16.20.29:5060 (no NAT)
Using INVITE request as basis request - 73776008@172.16.20.29
Found peer ‘obi_110’ for ‘obi_110’ from 172.16.20.29:5060
== Using SIP RTP CoS mark 5
Found RTP audio format 0
Found RTP audio format 18
Found RTP audio format 101
Found audio description format PCMU for ID 0
Found audio description format G729 for ID 18
Found audio description format telephone-event for ID 101
Capabilities: us - (ulaw|g729), peer - audio=(ulaw|g729)/video=(nothing)/text=(nothing), combined - (ulaw|g729)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x1 (telephone-event|), combined - 0x1 (telephone-event|)
Peer audio RTP is at port 172.16.20.29:16608
Looking for *97 in outbound (domain 172.16.20.22)
list_route: hop: sip:obi_110@172.16.20.29:5060

<— Transmitting (no NAT) to 172.16.20.29:5060 —>
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 172.16.20.29:5060;branch=z9hG4bK-489dd3e7;received=172.16.20.29;rport=5060
From: sip:obi_110@172.16.20.22;tag=SP1601d25f41827f0e2
To: sip:*97@172.16.20.22
Call-ID: 73776008@172.16.20.29
CSeq: 8002 INVITE
Server: Asterisk PBX 11.6-cert2
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Contact: sip:*97@172.16.20.22:5060
Content-Length: 0

<------------>
– Executing [*97@outbound:1] Dial(“SIP/obi_110-0000000a”, “SIP/anveo_p/*97”) in new stack
Really destroying SIP dialog ‘7c170a277e834b1b4f681888788c071e@172.16.20.22:5060’ Method: INVITE
[Jun 3 12:35:36] WARNING[1326][C-00000010]: app_dial.c:2437 dial_exec_full: Unable to create channel of type ‘SIP’ (cause 20 - Subscriber absent)
== Everyone is busy/congested at this time (1:0/0/1)
– Executing [*97@outbound:2] Hangup(“SIP/obi_110-0000000a”, “”) in new stack
== Spawn extension (outbound, *97, 2) exited non-zero on 'SIP/obi_110-0000000a’
Scheduling destruction of SIP dialog ‘73776008@172.16.20.29’ in 32000 ms (Method: INVITE)

<— Reliably Transmitting (no NAT) to 172.16.20.29:5060 —>
SIP/2.0 480 Temporarily unavailable
Via: SIP/2.0/UDP 172.16.20.29:5060;branch=z9hG4bK-489dd3e7;received=172.16.20.29;rport=5060
From: sip:obi_110@172.16.20.22;tag=SP1601d25f41827f0e2
To: sip:*97@172.16.20.22;tag=as18fcdb58
Call-ID: 73776008@172.16.20.29
CSeq: 8002 INVITE
Server: Asterisk PBX 11.6-cert2
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0

<------------>

<— SIP read from UDP:172.16.20.29:5060 —>
ACK sip:*97@172.16.20.22:5060 SIP/2.0
Call-ID: 73776008@172.16.20.29
Content-Length: 0
CSeq: 8002 ACK
From: sip:obi_110@172.16.20.22;tag=SP1601d25f41827f0e2
Max-Forwards: 70
To: sip:*97@172.16.20.22;tag=as18fcdb58
Via: SIP/2.0/UDP 172.16.20.29:5060;branch=z9hG4bK-489dd3e7;rport
Authorization: DIGEST algorithm=MD5,nonce=“7ea415bb”,realm=“asterisk”,response=“cf0aefecfb6a195552f7f34c03b4d92a”,uri=“sip:*97@172.16.20.22:5060”,username="obi_110"
User-Agent: OBIHAI/OBi110-1.3.0.2824

<------------->
— (10 headers 0 lines) —
Really destroying SIP dialog ‘7d9dd2b-04e3dd72-cca1a82@72.9.149.69’ Method: OPTIONS
Really destroying SIP dialog ‘c99a2788@172.16.20.29’ Method: REGISTER

<— SIP read from UDP:72.9.149.69:5010 —>
INVITE sip:s@172.16.20.22:5060 SIP/2.0
Record-Route: sip:72.9.149.69:5010;lr=on;nat=yes
Via: SIP/2.0/UDP 72.9.149.69:5010;branch=z9hG4bKff9.b7db6156bf3029a424a3826d4e90bd75.0
Via: SIP/2.0/UDP 10.1.1.10;branch=z9hG4bKVe-25uhCDFfXmZj4MWgdDFfcNrQdtlfd6l1cH8QcHR2Ntbl7AUwU0kyVYd3sA3J78a5UlpDU6UvXL8JztR-aLZ-ot5JXH8J
From: “2172311920” sip:2172311920@72.9.149.69:9119;tag=as3663f84a
To: sip:2656419520@sip.anveo.com:5010
Contact: sip:10.1.1.10;anveohash=enc-aKu.c6FQdDFDXH8JX6iWdDFfcNrQdtlfd6l1cH8Qch**
Call-ID: 4c5fdc2a289cdb39202f860c27e8726e@72.9.149.69
CSeq: 102 INVITE
User-Agent: Anveo Server v10.3
Max-Forwards: 69
Date: Tue, 03 Jun 2014 17:35:52 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces
Content-Type: application/sdp
Content-Length: 250

v=0
o=root 6573 6573 IN IP4 72.9.149.69
s=session
c=IN IP4 72.9.149.69
t=0 0
m=audio 44248 RTP/AVP 0 3 101
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv
a=nortpproxy:yes
<------------->
— (16 headers 13 lines) —
Sending to 72.9.149.69:5010 (no NAT)
Sending to 72.9.149.69:5010 (no NAT)
Using INVITE request as basis request - 4c5fdc2a289cdb39202f860c27e8726e@72.9.149.69
No matching peer for ‘2172311920’ from ‘72.9.149.69:5010’

<— Reliably Transmitting (no NAT) to 72.9.149.69:5010 —>
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 72.9.149.69:5010;branch=z9hG4bKff9.b7db6156bf3029a424a3826d4e90bd75.0;received=72.9.149.69
Via: SIP/2.0/UDP 10.1.1.10;branch=z9hG4bKVe-25uhCDFfXmZj4MWgdDFfcNrQdtlfd6l1cH8QcHR2Ntbl7AUwU0kyVYd3sA3J78a5UlpDU6UvXL8JztR-aLZ-ot5JXH8J
From: “2172311920” sip:2172311920@72.9.149.69:9119;tag=as3663f84a
To: sip:2656419520@sip.anveo.com:5010;tag=as3ab29dbc
Call-ID: 4c5fdc2a289cdb39202f860c27e8726e@72.9.149.69
CSeq: 102 INVITE
Server: Asterisk PBX 11.6-cert2
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm=“asterisk”, nonce="00b7c6af"
Content-Length: 0

<------------>
Scheduling destruction of SIP dialog ‘4c5fdc2a289cdb39202f860c27e8726e@72.9.149.69’ in 32000 ms (Method: INVITE)

<— SIP read from UDP:72.9.149.69:5010 —>
ACK sip:s@172.16.20.22:5060 SIP/2.0
Via: SIP/2.0/UDP 72.9.149.69:5010;branch=z9hG4bKff9.b7db6156bf3029a424a3826d4e90bd75.0
From: “2172311920” sip:2172311920@72.9.149.69:9119;tag=as3663f84a
To: sip:2656419520@sip.anveo.com:5010;tag=as3ab29dbc
Call-ID: 4c5fdc2a289cdb39202f860c27e8726e@72.9.149.69
CSeq: 102 ACK
Max-Forwards: 69
Content-Length: 0

4

Please add cod or quote blocks round your configuration; it will make navigating this thread a lot easier.

Hangup will never be executed for successful calls and will be inferred for failed calls. It is redundant but harmless.

You have workarounds for NAT problems but your configuration is for a system with all addresses public. Why did you include them?

Having register and host=dynamic for the same peer is almost certainly wrong. Most ITSP must be specified as host=address.

Most ITSPs will not authenticate themselves to you. Also specifying insecure=invite pretty much invalidates the use of both secret and remotesecret (it might authenticate the registers, but the peer can make calls without specifying a password. Specifying both remotesecret and secret with the same secret doesn’t make sense as it is equivalent to just specifying secret.

canreinvite is deprecated or removed. If it is still recognized, canreinvite=nonat is the same canreinvite=yes, in a system like this, which is not configured to use NAT.

fromuser and defaultuser will depend on what anveo requires.

The call is failing because the destination hasn’t registered with you (see above). show registry shows who you register with not who registers with you, but, as I said, such mutual host=dynamic’s are usually wrong, as one side needs to know the real address to get things started.

5

Thanks for looking. I got everything working. I’m not sure it was service affecting but I didn’t have the syntax of the mwi => line correct. It looks like it may have been confusing Anveo and they kept losing registration. The biggest issue was a mis-setting between my ATA and Asterisk that was preventing inbound calls from being processed by the ATA. Can’t remember what was keeping *97 from working. I’m not sure I understand your comment about ‘configuration is for a system with all addresses public’. Both the Asterisk and my ATA are behind my NAT firewall but of course the two ITSP’s are not. So what I was trying to set up is a “direct” connection [no NAT] between the ATA and Asterisk. Does this make sense? Thanks again.

6

You generally need an externhost or externip line in such a configuration.