Outbound routes на несколько городских потоков

[Роман Дровалев]

Добрый день.

Проблема такая, есть 2-а PRI  потока, кот. входят в шлюз
в одном потоке нумерация 5011хх, в другом 5022хх

При выходе с номера с outbound CollerID 5011xx через поток 5022хх  у набираемого абонента высвечивается входящий номер 502200,
верно и обратное.
Задача  распихивать исходящие звонки на город в соответствии с PRI потоками  чтобы определялись правильные CID.

В плане исходящей вызовов
condition - destination_number - ^(\d{6})$

Добавлял доп. condition  - CID - не срабатывает(

Как можно решить данный вопрос на freeswitch или может это делается на других уровнях?

Например у провайдера или на шлюзе?

[Serge S. Yuriev]

Добрый день,

Самое простое конечно это матчить на шлюзе по caller и нарисовать префикс.
Или на фрисвиче префикс добавить. На шлюзе префикс выловить и отправить
куда надо.

--
Serge S. Yuriev
Lead VoIP engineer

[Viktor awsswa]

Уточняйте что за оборудование - потому как на cisco и eltex это делается легко

пятница, 5 февраля 2016 г., 14:18:36 UTC+5 пользователь Роман Дровалев написал:

[Роман Дровалев]

Шлюз - Digium G800, поковырял его, нашёл только роутинг звонков по набираемому номеру, по исходящему вроде нет.

Остаётся только на freeswitch'е заруливать звонки в определённый гатевей на базе outbound "effective_caller_id_number", но пока ни как не получается.

Кто делал подобное на freeswitch'е, подскажите пожалуйста, как это на нём реализовывается или может я в Digium'е не разобрался?

Rак выглядит на Digium данная настройка во вложении

[Алик Трумкин]

Не проще ли CID менять перед тем как bridge делать?

[Роман Дровалев]

Вообщем сделал так:
1.Под каждый порт создал sip акаунт = гатевей, логины  соответственно  freeswitch1 и  freeswitch2
2.На freeswitche`е заруливаю в нужный гатевей Outbound routes. Делается либо по условию caller_id_number или toll allow
3.На Дигиуме создал правила sip акаунт - port,

И всё вроде работает какое-то время, а потом начинает всё отправлять в 1-ый порт и соотв. не работает как надо.
Дело явно в Дигиуме, потому что в логах на freeswitche`е правило уходит в нужный пункт Outbound routes.

Привет
Должен уйти в порт 2, а попадает на sip аккаунт freeswitch1 (
В дигиуме в логах
<135>asterisk[29651]: VERBOSE[29683]: chan_sip.c:16391 in check_peer_ok: Found peer 'freeswitch1' for '4842501141' from 192.168.8.156:5080
    192.168.8.31    11/02 08:17:50.035

Может кто знает, почему так происходит?

[ros tel]

добавить в шлюзы по параметру на нужный IP:port

<param name="outbound-proxy" value="IP:Port"/>

четверг, 11 февраля 2016 г., 14:16:17 UTC+5 пользователь Роман Дровалев написал:

[Роман Дровалев]

Я так понял в свойствах гатевей на freeswitch`e добавить данное правило?
в моём случае <param name="outbound-proxy" value="192.168.8.31:5080"/> , так?

Просто после добавления данной опции звонки вообще перестали ходить (
Уже и не знаю в какую сторону копать.

[Роман Дровалев]

Так, добавил на Дигиуме данный параметр(192.168.8.156:5080), в свойствах sip endpoints.
На функциональность ни как не повлияло (

Кстати sip endpoints у меня с регистрацией на стороне шлюза.

Так же, когда всё вроде работает, работает не сразу а минут через 10-15 "прочухивается".

[ros tel]

в параметрах шлюзов FS
IP и порт шлюза в мир

сильно сомневаюсь что оно слушает 5080

четверг, 11 февраля 2016 г., 16:17:27 UTC+5 пользователь Роман Дровалев написал:

[Роман Дровалев]

Исли взять из глобальных настроек SIP на шлюзе, то порт - 5060.
Поставил его, звонки не идут (

[Роман Дровалев]

Порт убрал, просто адрес оставил, тоже звонки не идут (

[ros tel]

тогда выкладывайте текущие конфиги

не знаю как умудряетесь сломать то что не работало

четверг, 11 февраля 2016 г., 19:03:47 UTC+5 пользователь Роман Дровалев написал:

[Роман Дровалев]

Да, смешно )
Мне не понятно сама логика работы. Если я в на FS указываю proxy - 192.168.8.31, потом мне для чего ещё указывать outbound proxy - 192.168.8.31?
Т.е. FS не понимает куда отправить обратный RTP поток? для указывать надо outbound proxy? или для чего то другого.

Схема такая
  FS_192.168.8.156 ---------- 192.168.8.31_Digium G800

Конфиги завтра все прикреплю

[Роман Дровалев]

Эксперементальным методом удалось установить, что проблема со стороны FS. Отключил первый GW, и всё пошло через второй GW и соответственно 2-ой порт.
Значит либо FS не правильно отрабатывает правила, либо не правильно они написаны. Повторюсь, хотя в логах вроде заруливает куда надо.


Логика:
С внутр. телефонов 4ххх,3xxx,2xxx должно уходить в 1-ый порт и на SIP_EP freeswitch1
С внутр. телефонов 1ххх должно уходить во 2-ой порт и на SIP_EP freeswitch2

Тест:
- Звоню с внутр 1010, с Outbound Caller ID Number  484270114x на 6-ти значный номер

Лог FS:
4b103d12-dd1b-4915-811c-4bbe092e2578 Dialplan: sofia/internal/10...@192.168.8.156:5060 Regex (FAIL) [Group_701168] destination_number(714901) =~ /^701168$/ break=on-false
4b103d12-dd1b-4915-811c-4bbe092e2578 Dialplan: sofia/internal/10...@192.168.8.156:5060 parsing [192.168.8.156->Group_701169] continue=false
4b103d12-dd1b-4915-811c-4bbe092e2578 Dialplan: sofia/internal/10...@192.168.8.156:5060 Regex (FAIL) [Group_701169] destination_number(714901) =~ /^701169$/ break=on-false
4b103d12-dd1b-4915-811c-4bbe092e2578 Dialplan: sofia/internal/10...@192.168.8.156:5060 parsing [192.168.8.156->Digium1.p1.d6] continue=false
4b103d12-dd1b-4915-811c-4bbe092e2578 Dialplan: sofia/internal/10...@192.168.8.156:5060 Regex (FAIL) [Digium1.p1.d6] caller_id_number(1010) =~ /^(4\d{3})|^(3\d{3})|^(2\d{3})$/ break=on-false
4b103d12-dd1b-4915-811c-4bbe092e2578 Dialplan: sofia/internal/10...@192.168.8.156:5060 parsing [192.168.8.156->Digium1.p2.8d10] continue=false
4b103d12-dd1b-4915-811c-4bbe092e2578 Dialplan: sofia/internal/10...@192.168.8.156:5060 Regex (PASS) [Digium1.p2.8d10] caller_id_number(1010) =~ /^(1\d{3})$/ break=on-false
4b103d12-dd1b-4915-811c-4bbe092e2578 Dialplan: sofia/internal/10...@192.168.8.156:5060 Regex (FAIL) [Digium1.p2.8d10] destination_number(714901) =~ /^(8\d{10})$/ break=on-false
4b103d12-dd1b-4915-811c-4bbe092e2578 Dialplan: sofia/internal/10...@192.168.8.156:5060 parsing [192.168.8.156->Digium1.p2.d6] continue=false
4b103d12-dd1b-4915-811c-4bbe092e2578 Dialplan: sofia/internal/10...@192.168.8.156:5060 Regex (PASS) [Digium1.p2.d6] destination_number(714901) =~ /^(\d{6})$/ break=on-false
4b103d12-dd1b-4915-811c-4bbe092e2578 Dialplan: sofia/internal/10...@192.168.8.156:5060 Action set(sip_h_X-accountcode=${accountcode})
4b103d12-dd1b-4915-811c-4bbe092e2578 Dialplan: sofia/internal/10...@192.168.8.156:5060 Action set(sip_h_X-Tag=)
4b103d12-dd1b-4915-811c-4bbe092e2578 Dialplan: sofia/internal/10...@192.168.8.156:5060 Action set(call_direction=outbound)
4b103d12-dd1b-4915-811c-4bbe092e2578 Dialplan: sofia/internal/10...@192.168.8.156:5060 Action set(hangup_after_bridge=true)
4b103d12-dd1b-4915-811c-4bbe092e2578 Dialplan: sofia/internal/10...@192.168.8.156:5060 Action set(effective_caller_id_name=${outbound_caller_id_name})
4b103d12-dd1b-4915-811c-4bbe092e2578 Dialplan: sofia/internal/10...@192.168.8.156:5060 Action set(effective_caller_id_number=${outbound_caller_id_number})
4b103d12-dd1b-4915-811c-4bbe092e2578 Dialplan: sofia/internal/10...@192.168.8.156:5060 Action set(inherit_codec=true)
4b103d12-dd1b-4915-811c-4bbe092e2578 Dialplan: sofia/internal/10...@192.168.8.156:5060 Action set(ignore_display_updates=true)
4b103d12-dd1b-4915-811c-4bbe092e2578 Dialplan: sofia/internal/10...@192.168.8.156:5060 Action set(callee_id_number=714901)
4b103d12-dd1b-4915-811c-4bbe092e2578 Dialplan: sofia/internal/10...@192.168.8.156:5060 Action set(continue_on_fail=true)
4b103d12-dd1b-4915-811c-4bbe092e2578 Dialplan: sofia/internal/10...@192.168.8.156:5060 Action bridge(sofia/gateway/93305098-287e-49b1-b196-c1f38907a8a2/714901)
4b103d12-dd1b-4915-811c-4bbe092e2578 2016-02-12 09:15:16.938663 [DEBUG] switch_core_state_machine.c:216 (sofia/internal/10...@192.168.8.156:5060) State Change CS_ROUTING -> CS_EXECUTE
4b103d12-dd1b-4915-811c-4bbe092e2578 2016-02-12 09:15:16.938663 [DEBUG] switch_core_state_machine.c:532 (sofia/internal/10...@192.168.8.156:5060) State ROUTING going to sleep
4b103d12-dd1b-4915-811c-4bbe092e2578 2016-02-12 09:15:16.938663 [DEBUG] switch_core_state_machine.c:473 (sofia/internal/10...@192.168.8.156:5060) Running State Change CS_EXECUTE
4b103d12-dd1b-4915-811c-4bbe092e2578 2016-02-12 09:15:16.938663 [DEBUG] switch_core_state_machine.c:539 (sofia/internal/10...@192.168.8.156:5060) State EXECUTE

Лог Digium:
<135>asterisk[29651]: VERBOSE[29683]: chan_sip.c:16391 in check_peer_ok: Found peer 'freeswitch1' for '484270114x' from 192.168.8.156:5080

    192.168.8.31    11/02 08:17:50.035

Судя по логу с Digium, по факту он определяет, что звонок идёт с первой sip учётки.

Настройки FS (Fusionpbx)

GW1 для port1 - "Digium1.p1"

Gateway    Digium1.p1
Username freeswitch1
Password    ***
From User   
From Domain   
Proxy    192.168.8.31
Realm   
Expire Seconds    3600
Register     
Retry Seconds    30
Distinct To     
Auth Username   
Extension   
Register Transport     
Register Proxy   
Outbound Proxy   
Caller ID In From    True     
Supress CNG     
Sip CID Type    none
Codec Preferences    PCMU,PCMA
Extension In Contact     
Ping   
Channels    0
Domain     
Context    public
Profile     external
Enabled     True
Description    Digium 1, port_1


GW2 для port2 - "Digium1.p2"

Gateway    Digium1.p2
Username freeswitch2
Password    ***
From User   
From Domain   
Proxy    192.168.8.31
Realm   
Expire Seconds    3600
Register     
Retry Seconds    30
Distinct To     
Auth Username   
Extension   
Register Transport     
Register Proxy   
Outbound Proxy   
Caller ID In From    True     
Supress CNG     
Sip CID Type    none
Codec Preferences    PCMU,PCMA
Extension In Contact     
Ping   
Channels    0
Domain     
Context    public
Profile     external
Enabled     True
Description    Digium 1, port_2

Outbound Routes
Name Digium1.p1.d6
Continue=False


Name Digium1.p2.d6
Continue=False


Что не так с FS, потому что он явно делает не то, что на нём нарисовано?

[Роман Дровалев]

Скриншоты снимал, когда настройки были стандартные изначательно, когда сняты были логи
Digium1.p1.d6



для Digium1.p2.d2

[ros tel]

asterisk внутри шлюза не способен различать с какого именно пира пришел вызов при идентичных настройках 

варианта два:

1. разнести в FS по разным sofia-профилям, повешенным на разные сигнальные порты
   
2. как и сказано выше использовать префиксы в номере назначения

пятница, 12 февраля 2016 г., 12:17:19 UTC+5 пользователь Роман Дровалев написал:

[Роман Дровалев]

Для полной картины, настройки Digium

extensions.conf

[general]
static=yes
writeprotect=no
clearglobalvars=no

[globals]
CONSOLE=Console/dsp

[SIP-to-E1_port1]
exten => _X.,1,Verbose(2,${EXTEN} matches Rule SIP-to-E1_port1)
exten => _X.,n,execif($["${TOLOWER(${CALLERID(name)})}" = "anonymous"]?Set(CALLERID(num-pres)=prohib))
exten => _X.,n,GoSub(sub-failover,s,1(${EXTEN},gtw/port1:0))
exten => _X.,n,Hangup()

[E1_port1-to-SIP]
exten => _X.,1,Verbose(2,${EXTEN} matches Rule E1_port1-to-SIP)
exten => _X.,n,Proceeding()
exten => _X.,n,Wait(1)
exten => _X.,n,GoSub(sub-failover,s,1(${EXTEN},SIP/freeswitch1:0))
exten => _X.,n,Hangup()

[E1_port2-to-SIP]
exten => _X.,1,Verbose(2,${EXTEN} matches Rule E1_port2-to-SIP)
exten => _X.,n,Proceeding()
exten => _X.,n,Wait(1)
exten => _X.,n,GoSub(sub-failover,s,1(${EXTEN},SIP/freeswitch2:0))
exten => _X.,n,Hangup()

[SIP-to-E1_port2]
exten => _X.,1,Verbose(2,${EXTEN} matches Rule SIP-to-E1_port2)
exten => _X.,n,execif($["${TOLOWER(${CALLERID(name)})}" = "anonymous"]?Set(CALLERID(num-pres)=prohib))
exten => _X.,n,GoSub(sub-failover,s,1(${EXTEN},gtw/port2:0))
exten => _X.,n,Hangup()

[freeswitch1]
include => SIP-to-E1_port1

[freeswitch2]
include => SIP-to-E1_port2

[port1]
include => E1_port1-to-SIP

[port2]
include => E1_port2-to-SIP

[sub-failover]
exten => s,1,Verbose(2,Beginning failover)
exten => s,n(tryagain),Set(TARGET=${SHIFT(ARG2,:)})
exten => s,n,Set(ISFXS=${SHIFT(ARG2,:)})
exten => s,n,Gotoif($["${ARG1}"=""]?dialstrnoexten)
exten => s,n,Gotoif($["${ARG1}"="s"]?dialstrnoexten)
exten => s,n,Gotoif($["${ISFXS}"="1"]?dialstrnoexten)
exten => s,n,Set(DIALSTR=${TARGET}/${ARG1})
exten => s,n,Goto(dial)
exten => s,n(dialstrnoexten),Set(DIALSTR=${TARGET})
exten => s,n(dial),Dial(${DIALSTR})
exten => s,n,NoOp(${HANGUPCAUSE})
exten => s,n,Gotoif($["${HANGUPCAUSE}"="34"]?evalstring)
exten => s,n,Gotoif($["${HANGUPCAUSE}"="38"]?evalstring)
exten => s,n,Gotoif($["${HANGUPCAUSE}"="41"]?evalstring)
exten => s,n,Gotoif($["${HANGUPCAUSE}"="42"]?evalstring)
exten => s,n,Gotoif($["${HANGUPCAUSE}"="44"]?evalstring)
exten => s,n,Gotoif($["${HANGUPCAUSE}"="27"]?evalstring)
exten => s,n,Gotoif($["${HANGUPCAUSE}"="111"]?evalstring)
exten => s,n,Gotoif($["${HANGUPCAUSE}"="20"]?evalstring)
exten => s,n,Gotoif($["${HANGUPCAUSE}"="0"]?evalstring)
exten => s,n,Goto(return,1)
exten => s,n(evalstring),Gotoif($[${LEN(ARG2)}>0]?tryagain:return,1)
exten => return,1,Return()

sip.conf

[general]
tcpbindaddr=0.0.0.0:5060
domainasrealm=no
tcpauthlimit=99
srvlookup=yes
sendrpid=no
registertimeout=20
maxexpiry=3600
tlsbindaddr=0.0.0.0
sdpsession=Digium Gateway
allowoverlap=yes
autodomain=no
minexpiry=60
allowexternaldomains=yes
pedantic=no
alwaysauthreject=no
externrefresh=180
tos_sip=cs3
tos_audio=ef
dtmfmode=rfc2833
dynamic_exclude_static=no
externtcpport=5060
jblog=no
match_auth_username=no
prematuremedia=yes
matchexternaddrlocally=no
tcpauthtimeout=30
useragent=Digium Gateway
udpbindaddr=0.0.0.0:5060
rtpend=10999
tcpenable=no
context=default
shrinkcallerid=yes
jbenable=yes
defaultexpiry=120
compactheaders=no
tlsenable=no
allowguest=no
jbforce=no
dnsrefreshinterval=300
sdpowner=root
auth_options_request=no

[authentication]

[freeswitch1]
qualify=no
nat=no
sendrpid=no
t38transport=udptl
usereqphone=no
timerb=32000
session-minse=90
allowoverlap=no
directmedia=no
insecure=port,invite
callingpres=allowed_not_screened
g726nonstandard=no
dtmfmode=auto
type=friend
use_q850_reason=no
rtpjittermode=static
rtp_engine=vocallo
session-refresher=uas
transport=udp
progressinband=never
timert1=500
t1min=500ms
session-timers=accept
allowtransfer=yes
disallow=all
context=freeswitch1
registertrying=no
rtpjitterdelay=50
trust_id_outbound=legacy
secret=***
trustrpid=no
host=dynamic
defaultuser=freeswitch1
promiscredir=no
preferred_codec_only=no
session-expires=1800
t38pt_udptl=no
max_forwards=70
allow=ulaw:20
allow=alaw:20
allow=g729:20
allow=g722:20
allow=gsm:20
allow=g726:20
requesturi_did=1

[freeswitch2]
qualify=no
nat=no
sendrpid=no
t38transport=udptl
usereqphone=no
timerb=32000
session-minse=90
allowoverlap=no
directmedia=no
insecure=port,invite
callingpres=allowed_not_screened
g726nonstandard=no
dtmfmode=rfc2833
type=friend
use_q850_reason=no
rtpjittermode=static
rtp_engine=vocallo
session-refresher=uas
transport=udp
progressinband=never
timert1=500
t1min=500ms
session-timers=accept
allowtransfer=yes
disallow=all
context=freeswitch2
registertrying=yes
rtpjitterdelay=50
trust_id_outbound=legacy
secret=***
trustrpid=no
host=dynamic
defaultuser=freeswitch2
promiscredir=no
preferred_codec_only=no
session-expires=1800
t38pt_udptl=no
max_forwards=70
allow=ulaw:20
allow=alaw:20
allow=g729:20
allow=g722:20
allow=gsm:20
allow=g726:20
requesturi_did=1

Кстати, делал  как рекомендовали - добывлял префикс и отлавливал его на Digium.
При звонке на 2-ой порт, вот что в логах Digium:

Thu Feb 11 21:07:09 2016;192.168.8.31; <135>asterisk[11814]: VERBOSE[11846]: chan_sip.c:23378 in handle_request_invite: Using INVITE request as basis request - 1c43bf81-4b8d-1234-d085-00215e3f4ecc
Thu Feb 11 21:07:09 2016;192.168.8.31; <135>asterisk[11814]: VERBOSE[11846]: chan_sip.c:16391 in check_peer_ok: Found peer 'freeswitch1' for '484270114х' from 192.168.8.156:5080
Thu Feb 11 21:07:09 2016;192.168.8.31; <135>asterisk[11814]: VERBOSE[11846]: chan_sip.c:9456 in process_sdp: Peer audio RTP is at port 172.16.12.16:65190
Thu Feb 11 21:07:09 2016;192.168.8.31; <135>asterisk[11814]: VERBOSE[11846]: chan_sip.c:15815 in get_destination: Looking for 92714901 in freeswitch1 (domain 192.168.8.31)
Thu Feb 11 21:07:09 2016;192.168.8.31; <135>asterisk[11814]: VERBOSE[11846]: chan_sip.c:4267 in send_response:  <--- Reliably Transmitting (no NAT) to 192.168.8.156:5080 ---> SIP/2.0 404 Not Found^M Via: SIP/2.0/UDP 192.168.8.156:5080;branch=z9hG4bKr090Dt24pj4UH;received=192.168.8.156;rport=5080^M From: "1010" <sip:484270114х@192.168.8.156>;tag=94r63ZtDe6Q2S^M To: <sip:9271...@192.168.8.31>;tag=as59982862^M Call-ID: 1c43bf81-4b8d-1234-d085-00215e3f4ecc^M CSeq: 87270951 INVITE^M Server: Digium Gateway^M Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH^M Supported: replaces, timer^M Content-Length: 0^M ^M  <------------>

Thu Feb 11 21:07:09 2016;192.168.8.31; <133>asterisk[11814]: NOTICE[11846]: chan_sip.c:23552 in handle_request_invite: Call from 'freeswitch1' (192.168.8.156:5080) to extension '92714901' rejected because extension not found in context 'freeswitch1'.

Thu Feb 11 21:07:09 2016;192.168.8.31; <135>asterisk[11814]: VERBOSE[11846]: chan_sip.c:4027 in sip_scheddestroy: Scheduling destruction of SIP dialog '1c43bf81-4b8d-1234-d085-00215e3f4ecc' in 32000 ms (Method: INVITE)

Получается, что с FS он выходит через 1-ый sip аккаунт! Потом он не идёт, потомучто в маршрутизации данный префикс отлавливался со второго аккаунта и естественно он не подпадал не под одно правило!!!

Или что то не так понимаю, тогда как делает Digium сопоставление Found peer 'freeswitch1' for '484270114х' from 192.168.8.156:5080 , если FS всё правильно отрабатывает и отправляет через 2-ю учётку

Вообщем для меня не понятно где проблема, может у кого будут какие-нибудь мысли?
Помогите пожалуйста разобраться в данной проблеме.

[ros tel]

вот теперь видно в чем проблема

удалите строку
insecure=port,invite
в обоих пирах freeswitch1, freeswitch2

кто вас вообще надоумил совать её в пир с типом type=friend

пятница, 12 февраля 2016 г., 13:13:46 UTC+5 пользователь Роман Дровалев написал:

[Роман Дровалев]

Спасибо за ответы, особенно Ros Tel и Сергею Юрьеву.

Не думал, что для такой железки ещё надо будет костыли городить в виде префиксов.

Тему считаю закрытой, всё работает.

Для тех, кто озадачится подобной проблемой, сделано так

Один гатевей, и несколько Outbound routes. В исх. правила загоняем по toll allow в extension или по условию соответствия caller_id_number  в исх. правиле.
+ добавляем префикс для определённого порта и на Digium его отлавливаем.