Asterisk Bandwidth.com configuration for incoming call

SIP trunk Provider: Bandwidth. com
SIP Phone:Zoiper
Both are configured with asterisk. Outgoing is working perfectly. We are not able to receive incoming call to our sip phone from skype(as bandwidth only supports US numbers).
and we have dialled the DID (in skype) which is assign`Prefed to us.

Below is the extensions. conf:

[incoming]
exten => s,1,Dial(SIP/1002)


Below is the sip. conf:

[general]
udpenable=yes
tcpenable=yes
preferred_codec_only=yes
disallow=all
allow=ulaw
allow=alaw
sipdebug=no
localnet=XXX.XXX.XX. XX 
externaddr=XXX.XXX.XX. XX 
udpbindaddr=0.0.0.0: 5060
realm=XXX.XXX.XX. XX ;replace with your Asterisk server public IP address or host
transport=udp

[siptrunk](!)
type=friend
context=incoming
dtmfmode=rfc2833
canreinivite=yes
qualify=yes
insecure=port,invite

[bandwidth](siptrunk)
host=216.82.224.202
tcpenable=no

[bandwidthincoming](siptrunk)
host=216.82.224.202

[office­phone](!)
type=friend
context=fromphones
host=dynamic
dtmfmode=auto
disallow=all
allow=ulaw

[1002](office­phone)
secret=test123

Kindy help us out.

Please provide SIP logging showing the call being offered to Asterisk and failing.

There are syntax errors in your externip and localnets, and there is really no need to redact the latter. There are stray spaces in both, and your localnets specifies a host, not a subnetwork, at the moment.

You have the typical obsolete and sub-optimal settings resulting from copying another configuration.

I don’t think you can set tcpenable on an individual peer.

Hi @david551 ,

We did not get any logs on asterisk side for incoming calls

Those spaces we have put because we were not able to post the question as it was saying new users cannot post more than 2 links so we have put a space in between

I think ‘tcpenable=no’ can be set, as Outgoing(‘bandwidth’ context) is working fine.Do you want us to check by removing tcpenable??

I think tcpenable is only working because it is the default.

If you mark the text as preformatted, the forum will not interpret things as links.

That doesn’t explain the lack of subnet mask.

Until you can provide logs showing Asterisk receiving the call, the presumption is that the fault lies somewhere before Asterisk is reached.