flynumber.com Inbound DID

[zando101]

Hi,

I've purchased a DID from flynumber.com but am not able to get inbound number to route to the IN_GROUP.

I am able to get it to route direct to a soft phone but this is not what I need.

I think the extension is not correct. There is a config sample at their site, the extension is:

extensions.conf:
[from-fly]
exten=> 2125551111,1,Dial(SIP/100)

2125551111 is the DID number and I think the Dial() part is what's stopping the call going into vicidial's
in group and to a SIP phone direcit.

Configs are at http://www.flynumber.com/asterisk-pbx-configuration

Can anyone adivse how I can make to route into vicidials ingroup and not a sip phone direct?

I have setup the DID number and INGROUP as detailed in the managers manual.



VERSION: 2.4-361a | BUILD: 120221-1647 | Single Server | No Digium/Sangoma Hardware | No Extra Software After Installation | Intel(R) Core(TM)2 Duo CPU | ViciBox_Redux.x86_64-3.1.15.preload.iso

[zando101]

Some further details on this .. when I call the DID number this is from the log =>

[Jun 18 17:12:15] -- Executing [66600035123@from-fly:1] Dial("SIP/46.19.209.14-00000008", "SIP/100") in new stack
[Jun 18 17:12:15] WARNING[9268]: chan_sip.c:3225 create_addr: No such host: 100
[Jun 18 17:12:15] WARNING[9268]: app_dial.c:1310 dial_exec_full: Unable to create channel of type 'SIP' (cause 20 - Unknown)
[Jun 18 17:12:15] == Everyone is busy/congested at this time (1:0/0/1)
[Jun 18 17:12:15] == Auto fallthrough, channel 'SIP/46.19.209.14-00000008' status is 'CHANUNAVAIL'


It wants to sent to the SIP phone id 100 not going into the vicidial ingroup.

[zando101]

context=trunkinbound is the change needed to make this work.

Next issue is the inbound call lasts only 15 seconds or so before dropping out.

I guess that's a separate issue.

[mcargile]

Can you post the asterisk output from when the call drops?

[GaD]

There are a few things I would check. On the trunk configuration you need to find out where the trunk 'from flynumber' lands in (do you have an options like 'context=from<whatever>?. If you don't Vici will assume context is trunkinbound).

If the context is the default (trunkinbound), I would make sure the system has a route called 100 that knows it needs to send the call to extension 100. Same thing for any other context.

Also 'SIP/100' will assume that you have a peer IN THAT SAME CONTEXT called 100, which may not be the case. If the extension is registered in that same box I would recommend using something like " Dial(Local/100@default/n,,)" (notice that the DEFAULT is the context where the extension 100 is located in.

Try it out and post back your results....

[zando101]

Can you post the asterisk output from when the call drops?

Hi,

I have been trying for days to fix an "inbound dropped call after 15 seconds" issue without success.

Outbound calls work fine with no issues at all.

There is lots of references to this problem on the internet from current to many years past.
Strangely though there's no clear solution to the problem.

I'm pretty sure it's iptables firewall related - SIP connection tracking.

I've come to a grinding halt on figuring this out so am posting this question to the boards
in the hopes it makes sense to someone who knows the solution.

Here are the details =>

I have setup a Thailand inbound DID with flynumber.com and also a US inbound DID with Xcast.
They both connect and start to work (call) OK.

After about 15 seconds the call consisantly hangs up with this error message:

[Jun 21 17:31:08] WARNING[3188]: chan_sip.c:2058 retrans_pkt: Maximum retries exceeded on transmission
cd2fac175fe7cdc1d7ad2c63f7c41b61-66591@38.108.120.49 for seqno 501 (Critical Response) -- See doc/sip-retransmit.txt.

[Jun 21 17:31:08] WARNING[3188]: chan_sip.c:2080 retrans_pkt: Hanging up call
cd2fac175fe7cdc1d7ad2c63f7c41b61-66591@38.108.120.49 - no reply to our critical packet (see doc/sip-retransmit.txt).

[Jun 21 17:31:08] -- User hung up


The vicidial box is behind a Ubuntu gateway server running an iptables firewall.

Somehow the firewall is preventing asterisk to maintain the call.

Here is the Account Entry from vicidial for both the US and Thai DIDs


[xcast-in-USA-DID]
type=friend
context=trunkinbound
usecallerid=yes
trustrpid=yes
sendrpid=yes
host=38.102.250.60
qualify=yes
insecure=port,invite
disallow=all
allow=g729
dtmfmode=rfc2833
nat=yes

[46.19.209.14-Thai-DID]
host=46.19.209.14
dtmfmode=rfc2833
dtmf=rfc2833
type=peer
context=trunkinbound
insecure=very
nat=never
allow=all


Here's a break down of the firewall rules:

# Enable forwarding for all traffic
# eth0 is the WAN
# eth3 is the LAN
#
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i eth3 -j ACCEPT


This next part is specific to vicidial (asterisk)

# Forward SIP and RTP traffic to vicidial on IP 192.168.2.3

iptables -t nat -A PREROUTING -i eth0 -p udp -m udp --dport 10000:20000 -j DNAT --to-destination 192.168.2.3
iptables -t nat -A PREROUTING -i eth0 -p udp -m udp --dport 5060 -j DNAT --to-destination 192.168.2.3
iptables -t nat -A PREROUTING -i eth0 -p tcp -m tcp --dport 5060 -j DNAT --to-destination 192.168.2.3

iptables -A FORWARD -p udp -d 192.168.2.3 --dport 10000:20000 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -p udp -d 192.168.2.3 --dport 5060 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT


It's all pretty straight forward stuff and is found standard when google'ing.

There is something missing though .. something that causes "Maximum retries exceeded on transmission".

Can anyone see anything wrong with my Account Entry or Firewall rules?

Any conntracking issue?

Thanks!

VERSION: 2.4-361a | BUILD: 120221-1647 | Single Server | No Digium/Sangoma Hardware | No Extra Software After Installation | Intel(R) Core(TM)2 Duo CPU | ViciBox_Redux.x86_64-3.1.15.preload.iso

[zando101]

Hrm .. after days of trying all sorts of variations on configuration and firewall rules .. the 15 second cut out seems fixed on my system here.

The iptables firewall rules are unchanged as posted in my previous thread.

For the USA DID using Xcast all I did was to add "canreinvite=yes" and it works.

What a huge sigh of relief! Back to happy days again.

Adding this poses no real risk or anything does it?

[FlyNumber]

For the USA DID using Xcast all I did was to add "canreinvite=yes" and it works.

..a little late to the party but did you end up getting it to work with the Thai number as well?