СвязьПроект http://old.xdsl.ru/svpro/ |
|
gs1002c: 2 gsm одновременно http://old.xdsl.ru/svpro/viewtopic.php?f=4&t=5404 |
Страница 1 из 1 |
Автор: | vipclass [ 22 апр 2015, 19:11 ] |
Заголовок сообщения: | gs1002c: 2 gsm одновременно |
Подскажите, пожалуйста по такому вопросу. Используется связка gs1002c+asterisk На аддпаке connection plar 1234 на обоих портах 0/0 и 0/1 gsm. В астериске транк без авторизации с ip аддпака и соотв. inbound route 1234 на IVR, а также outbound route с фильтром на номерА оператора симок. Соль в чем. Предположим, совершается звонок на карту в порту 0/0. он проходит на 1234, затем звонящий через ivr выбирает абонента(555) которого к примеру сейчас нет, но у него стоит переадресация на его мобильный по не ответу. Далее звонок уходит обратно на аддпак, т.к. новый набираемый мобильный проходит по правилам набора для оператора карточки 0/1 и всё, глухая тишина в трубке. У меня идеи кончились, если честно. Спасайте. Вот кусок когда звонок уходит на аддпак. Код: ExecIf("SIP/gsm1-00000011", "0?Set(CONNECTEDLINE(num,i)=%555_MOBILE_NUM%)") in new stack
-- Executing [s@macro-dialout-trunk:20] ExecIf("SIP/gsm1-00000011", "0?Set(CONNECTEDLINE(name,i)=CID:%SIM_0/1_NUM%)") in new stack -- Executing [s@macro-dialout-trunk:21] GotoIf("SIP/gsm1-00000011", "0?customtrunk") in new stack -- Executing [s@macro-dialout-trunk:22] Dial("SIP/gsm1-00000011", "SIP/gsm2/%555_MOBILE_NUM%,300,Tt") in new stack == Using SIP RTP TOS bits 184 == Using SIP RTP CoS mark 5 Audio is at 13256 Adding codec 100004 (alaw) to SDP Adding codec 100003 (ulaw) to SDP Adding codec 100008 (g729) to SDP Adding non-codec 0x1 (telephone-event) to SDP Reliably Transmitting (no NAT) to %IP_ADDPAC%:5060: INVITE sip:%555_MOBILE_NUM%@%IP_ADDPAC% SIP/2.0 Via: SIP/2.0/UDP %IP_ASTERISK%:5060;branch=z9hG4bK5602fe43 Max-Forwards: 70 From: <sip:%SIM_0/1_NUM%@%IP_ASTERISK%>;tag=as3d92e677 To: <sip:%555_MOBILE_NUM%@%IP_ADDPAC%> Contact: <sip:%SIM_0/1_NUM%@%IP_ASTERISK%:5060> Call-ID: 5039aa543a38568a1c52a772320be256@%IP_ASTERISK%:5060 CSeq: 102 INVITE User-Agent: FPBX-2.11.0(11.14.2) Date: Wed, 22 Apr 2015 17:05:39 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer Content-Type: application/sdp Content-Length: 307 v=0 o=root 118522779 118522779 IN IP4 %IP_ASTERISK% s=Asterisk PBX 11.14.2 c=IN IP4 %IP_ASTERISK% t=0 0 m=audio 13256 RTP/AVP 8 0 18 101 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=sendrecv --- -- Called SIP/gsm2/%555_MOBILE_NUM% <--- SIP read from UDP:%IP_ADDPAC%:5060 ---> SIP/2.0 100 Trying Via: SIP/2.0/UDP %IP_ASTERISK%:5060;branch=z9hG4bK5602fe43 From: <sip:%SIM_0/1_NUM%@%IP_ASTERISK%>;tag=as3d92e677 To: <sip:%555_MOBILE_NUM%@%IP_ADDPAC%> Call-ID: 5039aa543a38568a1c52a772320be256@%IP_ASTERISK%:5060 CSeq: 102 INVITE User-Agent: AddPac SIP Gateway Content-Length: 0 <-------------> --- (8 headers 0 lines) --- <--- SIP read from UDP:%IP_ADDPAC%:5060 ---> SIP/2.0 183 Session Progress Via: SIP/2.0/UDP %IP_ASTERISK%:5060;branch=z9hG4bK5602fe43 From: <sip:%SIM_0/1_NUM%@%IP_ASTERISK%>;tag=as3d92e677 To: <sip:%555_MOBILE_NUM%@%IP_ADDPAC%>;tag=e355d50aa4 Call-ID: 5039aa543a38568a1c52a772320be256@%IP_ASTERISK%:5060 CSeq: 102 INVITE Supported: timer, replaces, early-session User-Agent: AddPac SIP Gateway Contact: sip:%555_MOBILE_NUM%@%IP_ADDPAC% Content-Type: application/sdp Content-Length: 252 v=0 o=%555_MOBILE_NUM% 1429722339 1429722339 IN IP4 %IP_ADDPAC% s=AddPac Gateway SDP c=IN IP4 %IP_ADDPAC% t=1429722339 0 m=audio 23006 RTP/AVP 8 101 a=ptime:20 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv <-------------> --- (11 headers 11 lines) --- list_route: hop: <sip:%555_MOBILE_NUM%@%IP_ADDPAC%> Found RTP audio format 8 Found RTP audio format 101 Found audio description format PCMA for ID 8 Found audio description format telephone-event for ID 101 Capabilities: us - (ulaw|alaw|g729), peer - audio=(alaw)/video=(nothing)/text=(nothing), combined - (alaw) Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x1 (telephone-event|), combined - 0x1 (telephone-event|) Peer audio RTP is at port %IP_ADDPAC%:23006 -- SIP/gsm2-00000012 is making progress passing it to SIP/gsm1-00000011 |
Автор: | awsswa [ 23 апр 2015, 09:19 ] |
Заголовок сообщения: | Re: gs1002c: 2 gsm одновременно |
а зачем вы пускаете по тому же каналу - настройке как peer с двумя каналами и исходящий звонок будет идти по свободному http://awsswa.livejournal.com/24962.html |
Автор: | vipclass [ 05 май 2015, 15:34 ] |
Заголовок сообщения: | Re: gs1002c: 2 gsm одновременно |
Спасибо за совет. Пробовал. В моем случае ничего не поменяло. Да и не в этом дело. Я нашел причину, но не знаю как это убрать. У меня в конфиге addpac'a стоит параметр: dial-peer hunt 5 где 5—Specifies least recent use, explicit preference, longest match in phone number. (т.е. предпочтение выбора наименьшее недавнее использование, приоритет, набольшее совпадение в номере. ) Напоминаю мою желаемую схему звонка: Абонент gsm (?) --- addpac 0/(0...1) --- asterisk (1234/IVR) --- call_local_user(5678) --- answer_time_out --- dial_5678's_mobile] --- addpac 0/(1...0) --- Мобильный абонента 5678. Предположим, звонок поступил на порт 0/0 и он корректно ушел на 0/1 - все окей. Но следующий звонок на 0/0 он пытается пропихнуть в 0/0 по приоритету наименьшего использования. И тут случается Великий Затык. Такое ощущение, что шлюз сам не понимает, что у него эта линия уже занята, и остается в этом состоянии навечно, видимо, ждать пока линия не освободится. Как шлюзу объяснить, чтобы в таком случае у него было определение, что порт уже занят, и звонить надо в соседний, а не ждать? Это я что-то недонастроил, или это баг прошивки? Я сейчас временно выставил dial-peer hunt 3—Specifies explicit preference, longest match in phone number, least recent use.(т.е. приоритетность у него будет первым критерием), и назначил в dial-peer voice pots соответственно порту 0/0 preference 2 а порту 0/1 - preference 1, и тогда оно будет отрабатывать, но не совсем корректно, т.к. что бы ни пришло на набор исходящего gsm, первый приоритет будет у порта 0/1. Это реально костыль. Ведь я тогда теряю балансировку нагрузки по карточкам, чего весьма не хотелось бы, да и тут же вляпываюсь в ту же проблему, если позвонят на карточку в порту 0/1 и вызов будет переадресован обратно на аддпак в gsm. А если только подумать о том, что еще и второй gsm порт может тоже оказаться занят чьим-то еще исходящим, или, того хуже, входящим вызовом, получается полная каша. Т.е. в конечном итоге мне надо, чтобы: а) при входящих звонках, поступивших на gsm 0/0, вторые звонки, исходящие, корректно аддпаком обрабатывались, т.е. он, видя что по 0/0 у нас уже есть входящий вызов (т.е. линия занята) пихал второй поступивший ему исходящий вызов в gsm 0/1, а если и он занят тоже, то отбивал по congestion / busy, чтобы я мог астериском перекинуть этот вызов в какой-нибудь еще транк (интернет телефонию, ну или в городской с донабором кода). б) аналогичная ситуация, только порты наоборот в) при запросе на набор мобильных, аддпаком попеременно использовались карты в gsm 0/0 и gsm 0/1.(к примеру звонки исходящие бесплатные 50 мин/день/номер, а так я получаю порядка 100мин - профит!) г) обе городские линии 0/2 и 0/3, которые у меня тоже подключены, также попеременно использовались (по той же причине: лимит бесплатный на город предположим 15000сек/номер/месяц, а так я получаю что-то чуть меньше 30000сек - профит!) Подскажите пожалуйста, как это корректно реализовать? Единственная мысль, которая мне пришла в голову - поменять конфигурацию на аддпаке - сделать e164 регистрацию пиров каждого порта на астериске и рулить распределением уже оттуда. |
Страница 1 из 1 | Часовой пояс: UTC |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |