форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Маршрутизаторы CISCO и др. оборудование. (VoIP)
Изначальное сообщение		[ Отслеживать ]

"Перенаправление звонков Cisco -> SIP-шлюз"	+/–
Сообщение от vigogne (ok) on 14-Окт-13, 15:27
Добрый день! Всю голову сломал, рассудите плиз, знатоки: Есть включенная в VoIP-сеть Cisco IOS Software, 2800 Software (C2800NM-ADVENTERPRISEK9_IVS-M), Version 12.4(24)T5, RELEASE SOFTWARE (fc3) Есть SIP-шлюз Diamond GateWay, с зарегистрированным sip-фоном. Есть ЦАТС, подключенная к циске по Е1. Проблема заключается в невозможности перенаправления звонка из VoIP-сети в сип-фон, не заводя трафик в ЦАТС (хотя это реально, ЦАТС напрямую соединена с SIP-шлюзом) Для примера: звонит человек из другого региона (у него есть диалпир только на мою циску) на номер сип-фона. Он набирает 8045 (региональный префикс циски) 6701 (номер сип-фона) и получает отлуп с ошибкой %VOICE_IEC-3-GW: CCAPI: Internal Error (Inbound dialpeer blocked): IEC=1.1.181.1.30.0 on callID 0. на циске имею три диалпира: !POTS-пир, для передачи в Е1 dial-peer voice 8045 pots voice cut-through alert destination-pattern ^8045[0,2,3,5-6,9][^7]T direct-inward-dial port 0/0/0:15 ! !Основной входящий пир для внутренних телефонов ЦАТС dial-peer voice 8045000 voip permission orig huntstop preference 2 voice-class codec 1 incoming called-number ^8045[0,2,3,5-6,9][^7]T ! !Пир перевода звонков на SIP-шлюз (нумерация 67хх) dial-peer voice 80456700 voip permission term description DGW huntstop preference 1 destination-pattern ^804567.. voice-class codec 1 session protocol sipv2 session target ipv4:10.45.129.254 incoming called-number ^804567.. При всем этом, если направить звонок с ЦАТС на циску, то она нормально переводит звонок на сип-фон. т.е. если позвонить с внутреннего телефона ЦАТС на номер 80456701, то прекрасно дозванивается... Понимаю, что очень сумбурно написал, кто имеет желание помочь и знания в данном вопросе, скажите, что еще скинуть.
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Перенаправление звонков Cisco -> SIP-шлюз"	+1 +/–
Сообщение от mdenisov (ok) on 14-Окт-13, 17:33
Все просто - вы не попадаете во входящий пир 8045000 т. к. 80456701 не попадает в incoming called-number (семерка запрещена перед T). Вызов попадает в пир 80456700 и отбивается т. к. permission term.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "Перенаправление звонков Cisco -> SIP-шлюз"	+/–
	Сообщение от vigogne (ok) on 14-Окт-13, 20:05
	> Все просто - вы не попадаете во входящий пир 8045000 т. к. > 80456701 не попадает в incoming called-number (семерка запрещена перед T). Вызов > попадает в пир 80456700 и отбивается т. к. permission term. Так, т.о. term - только для входящих звонков, а orig для исходящих? Поэтому если изменить в пире 80456700 значение permission на orig или на both то должно заработать? Я правильно это понял? Тогда непонятно, почему проходят звонки именно на этот пир со стороны абонентов Е1?
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	3. "Перенаправление звонков Cisco -> SIP-шлюз"	+1 +/–
	Сообщение от mdenisov (ok) on 15-Окт-13, 13:39
	> Так, т.о. term - только для входящих звонков, а orig для исходящих? Да, но нет. В смысле наоборот. > Поэтому если изменить в пире 80456700 значение permission на orig или на > both то должно заработать? Я правильно это понял? По идее должно, только мне кажется в первом воипном пире 7 как-то не логично закрыто. Зачем это сделано? > Тогда непонятно, почему проходят звонки именно на этот пир со стороны абонентов > Е1? В вашем случае вызовы с VoIP отбиваются т. к. запрещен входящий пир. При звонках с потока используется входящий pots пир.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	4. "Перенаправление звонков Cisco -> SIP-шлюз"	+/–
	Сообщение от vigogne (ok) on 15-Окт-13, 20:07
	>> Так, т.о. term - только для входящих звонков, а orig для исходящих? > Да, но нет. В смысле наоборот. Понятно. >> Поэтому если изменить в пире 80456700 значение permission на orig или на >> both то должно заработать? Я правильно это понял? > По идее должно, только мне кажется в первом воипном пире 7 как-то > не логично закрыто. Зачем это сделано? Это сделано, потому что, если выбирается именно этот пир, то звонок проходит, но проходит через ЦАТС. Т.е. практически, звонки проходили через раз, пока я в первом пире не убрал 7. Я же ставил данный эксперимент ради перенаправления звонка на другой шлюз, не включая в процесс АТС. >> Тогда непонятно, почему проходят звонки именно на этот пир со стороны абонентов >> Е1? > В вашем случае вызовы с VoIP отбиваются т. к. запрещен входящий пир. > При звонках с потока используется входящий pots пир. Да, поменял в пире 80456700 значение permission на both, звонки стали проходить, но пока только сигнализация, когда абонент 6701 берет трубку, связь отбивается, и пока только посредством протокола H323, на SIP почему-то совсем тишина. К сожалению, сегодня весь день был в другом подразделении, и успел только сменить значение а пире и сделать пару звонков... Завтра продолжу. Спасибо Вам огромное, Ваши советы всегда "в кассу"!
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	5. "Перенаправление звонков Cisco -> SIP-шлюз"	+1 +/–
	Сообщение от mdenisov (ok) on 16-Окт-13, 18:22
	> Это сделано, потому что, если выбирается именно этот пир, то звонок проходит, > но проходит через ЦАТС. Т.е. практически, звонки проходили через раз, пока > я в первом пире не убрал 7. > Я же ставил данный эксперимент ради перенаправления звонка на другой шлюз, не > включая в процесс АТС. За то как уйдет вызов отвечает исходящий пир, зачем же на входящем ограничивать? > Да, поменял в пире 80456700 значение permission на both, звонки стали проходить, > но пока только сигнализация, когда абонент 6701 берет трубку, связь отбивается, > и пока только посредством протокола H323, на SIP почему-то совсем тишина. А вот тут все зависит от конечных устройств. CUBE конечно штука мощная в плане исправления косяков сигнализации, но не всемогущая. Странно что работает H.323 а не SIP, т. к. SIP более стандартизирован. Кстати, проверьте allow connection в voice service voip.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	6. "Перенаправление звонков Cisco -> SIP-шлюз"	+/–
	Сообщение от vigogne (ok) on 17-Окт-13, 07:03
	>> Это сделано, потому что, если выбирается именно этот пир, то звонок проходит, >> но проходит через ЦАТС. Т.е. практически, звонки проходили через раз, пока >> я в первом пире не убрал 7. >> Я же ставил данный эксперимент ради перенаправления звонка на другой шлюз, не >> включая в процесс АТС. > За то как уйдет вызов отвечает исходящий пир, зачем же на входящем > ограничивать? Так, я видимо совсем запутался... Если не сложно, укажите пожалуйста, как поправить мои диалпиры, для данной задачи? dial-peer voice 8045 pots voice cut-through alert destination-pattern ^8045[0,2,3,5-6,9][^7]T progress_ind setup enable 3 progress_ind progress enable 8 progress_ind connect enable 8 progress_ind disconnect enable 8 fax rate voice direct-inward-dial port 0/0/0:15 supported-language ru ! dial-peer voice 8045000 voip !Основной входящий permission orig huntstop voice-class codec 1 incoming called-number ^8045..T ! dial-peer voice 8045200 voip !Пир для пока еще тестового астериска. Работать должен по той же схеме, с передачей звонка. Нумерация 2хх voice cut-through alert description POS huntstop destination-pattern 80452.. translate-outgoing called 8045 voice-class codec 1 session protocol sipv2 session target ipv4:10.45.5.254 ! dial-peer voice 80456700 voip description DGW huntstop destination-pattern ^804567.. voice-class codec 1 session target ipv4:10.45.129.254 incoming called-number ^804567.. dtmf-relay h245-alphanumeric fax rate 14400 fax protocol t38 ls-redundancy 5 hs-redundancy 2 fallback pass-through g711alaw ip qos dscp cs5 media ip qos dscp cs5 signaling >> Да, поменял в пире 80456700 значение permission на both, звонки стали проходить, >> но пока только сигнализация, когда абонент 6701 берет трубку, связь отбивается, >> и пока только посредством протокола H323, на SIP почему-то совсем тишина. > А вот тут все зависит от конечных устройств. CUBE конечно штука мощная > в плане исправления косяков сигнализации, но не всемогущая. Странно что работает > H.323 а не SIP, т. к. SIP более стандартизирован. > Кстати, проверьте allow connection в voice service voip. Вот моя секция voice service voip voice service voip allow-connections h323 to h323 allow-connections h323 to sip allow-connections sip to h323 allow-connections sip to sip redirect ip2ip fax protocol t38 ls-redundancy 5 hs-redundancy 2 fallback pass-through g711alaw h323   no call service stop   call start slow modem passthrough nse codec g711ulaw sip   bind control source-interface FastEthernet0/0   bind media source-interface FastEthernet0/0   registrar server expires max 3600 min 3600   no call service stop
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	7. "Перенаправление звонков Cisco -> SIP-шлюз"	+/–
	Сообщение от vigogne (ok) on 23-Окт-13, 11:07
	Уважаемый Максим Денисов! Понимаю, что наглею, но у меня самого видимо не хватает знаний для этого. Если не затруднит, не могли бы Вы ответить, как, все-таки, правильно нужно создать эти диалпиры? И правильно ли сделаны настройки в voice service voip?
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	8. "Перенаправление звонков Cisco -> SIP-шлюз"	+/–
	Сообщение от mdenisov (ok) on 23-Окт-13, 16:04
	Так у вас же вызовы начали ходить, осталась проблема с односторонним RTP и отсутствием SIP. Это другая проблема, пиры тут врятли виноваты. Нужно смотреть трейсы, попробуйте поднять SIP как более простой для человеческого понимания и снимите debug ccsip messages для одного проблемного вызова.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	9. "Перенаправление звонков Cisco -> SIP-шлюз"	+/–
	Сообщение от vigogne (ok) on 24-Окт-13, 10:01
	> Так у вас же вызовы начали ходить, осталась проблема с односторонним RTP > и отсутствием SIP. > Это другая проблема, пиры тут врятли виноваты. Нужно смотреть трейсы, попробуйте поднять > SIP как более простой для человеческого понимания и снимите debug ccsip > messages для одного проблемного вызова. Вот дебаг звонка с астериска по SIP: Oct 24 11:46:07.712: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Received: INVITE sip:80456701@10.45.15.205 SIP/2.0 Via: SIP/2.0/UDP 10.169.2.222:5060;branch=z9hG4bK7b450b98;rport Max-Forwards: 70 From: <sip:81691690@10.169.2.222>;tag=as47c1192d To: <sip:80456701@10.45.15.205> Contact: <sip:81691690@10.169.2.222:5060> Call-ID: 19b3352f3ba363557f4f6fde368e18ba@10.169.2.222:5060 CSeq: 102 INVITE User-Agent: -2.11.0beta2(11.5.1) Date: Thu, 24 Oct 2013 05:45:18 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH Supported: replaces, timer Content-Type: application/sdp Content-Length: 745 v=0 o=root 1129937424 1129937424 IN IP4 10.169.2.222 s=Asterisk PBX 11.5.1 c=IN IP4 10.169.2.222 b=CT:384 t=0 0 m=audio 15516 RTP/AVP 18 4 9 8 0 10 101 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:4 G723/8000 a=fmtp:4 annexa=no a=rtpmap:9 G722/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:10 L16/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=sendrecv m=video 17050 RTP/AVP 34 98 99 31 a=rtpmap:34 H263/90000 a=fmtp:34 F=0;I=0;J=0;T=0;K=0;N=0;BPP=0;HRD=0 a=rtpmap:98 h263-1998/90000 a=fmtp:98 F=0;I=0;J=0;T=0;K=0;N=0;BPP=0;HRD=0 a=rtpmap:99 H264/90000 a=fmtp:99 redundant-pic-cap=0;parameter-add=0;packetization-mode=0;level-asymmetry-allowed=0 a=rtpmap:31 H261/90000 a=sendrecv Oct 24 11:46:07.752: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Sent: SIP/2.0 100 Trying Via: SIP/2.0/UDP 10.169.2.222:5060;branch=z9hG4bK7b450b98;rport From: <sip:81691690@10.169.2.222>;tag=as47c1192d To: <sip:80456701@10.45.15.205> Date: Thu, 24 Oct 2013 05:46:07 GMT Call-ID: 19b3352f3ba363557f4f6fde368e18ba@10.169.2.222:5060 CSeq: 102 INVITE Allow-Events: telephone-event Server: Cisco-SIPGateway/IOS-12.x Content-Length: 0 Oct 24 11:46:07.756: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Sent: INVITE sip:80456701@10.45.129.254:5060 SIP/2.0 Via: SIP/2.0/UDP 10.45.15.205:5060;branch=z9hG4bK34317E1 Remote-Party-ID: <sip:81691690@10.45.15.205>;party=calling;screen=no;privacy=off From: <sip:81691690@10.45.15.205>;tag=8EE35584-13CB To: <sip:80456701@10.45.129.254> Date: Thu, 24 Oct 2013 05:46:07 GMT Call-ID: 69D5F764-3BA611E3-846CECB2-B4A0A393@10.45.15.205 Supported: 100rel,timer,resource-priority,replaces,sdp-anat Min-SE:  1800 Cisco-Guid: 1775310219-1000739299-2221337778-3030426515 User-Agent: Cisco-SIPGateway/IOS-12.x Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER CSeq: 101 INVITE Timestamp: 1382593567 Contact: <sip:81691690@10.45.15.205:5060> Expires: 180 Allow-Events: telephone-event Max-Forwards: 69 Content-Type: application/sdp Content-Disposition: session;handling=required Content-Length: 574 v=0 o=CiscoSystemsSIP-GW-UserAgent 15 2066 IN IP4 10.45.15.205 s=SIP Call c=IN IP4 10.45.15.205 t=0 0 m=audio 17950 RTP/AVP 18 4 8 0 100 19 c=IN IP4 10.45.15.205 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:4 G723/8000 a=fmtp:4 bitrate=6.3;annexa=no a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:100 X-NSE/8000 a=fmtp:100 192-194 a=rtpmap:19 CN/8000 m=video 17528 RTP/AVP 34 99 c=IN IP4 10.45.15.205 b=TIAS:85000 a=rtpmap:34 H263/90000 a=fmtp:34 CIF=1;MAXBR=850 a=rtpmap:99 H264/90000 a=fmtp:99 profile-level-id=000000;packetization-mode=0 Oct 24 11:46:07.780: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Received: SIP/2.0 100 Trying Via: SIP/2.0/UDP 10.45.15.205:5060;branch=z9hG4bK34317E1;received=10.45.15.205 From: <sip:81691690@10.45.15.205>;tag=8EE35584-13CB To: <sip:80456701@10.45.129.254> Call-ID: 69D5F764-3BA611E3-846CECB2-B4A0A393@10.45.15.205 CSeq: 101 INVITE Content-Length: 0 Oct 24 11:46:07.792: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Received: SIP/2.0 183 Session Progress Via: SIP/2.0/UDP 10.45.15.205:5060;branch=z9hG4bK34317E1;received=10.45.15.205 From: <sip:81691690@10.45.15.205>;tag=8EE35584-13CB To: <sip:80456701@10.45.129.254>;tag=58f7391a Call-ID: 69D5F764-3BA611E3-846CECB2-B4A0A393@10.45.15.205 CSeq: 101 INVITE Contact: <sip:80456701@10.45.129.254:5060> Content-Type: application/sdp Content-Length: 152 v=0 o=proton 1382593564 1382593564 IN IP4 10.45.129.254 s=SDP session c=IN IP4 10.45.129.254 t=0 0 m=audio 7570 RTP/AVP 18 a=rtpmap:18 G729/8000 Oct 24 11:46:07.796: %VOICE_IEC-3-GW: SIP: Internal Error (183, codec mismatch): IEC=1.1.278.7.105.0 on callID 123685 GUID=69D1158B3BA611E38466ECB2B4A0A393 c2811-45-voip# c2811-45-voip# c2811-45-voip# c2811-45-voip# Oct 24 11:46:07.800: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Sent: CANCEL sip:80456701@10.45.129.254:5060 SIP/2.0 Via: SIP/2.0/UDP 10.45.15.205:5060;branch=z9hG4bK34317E1 From: <sip:81691690@10.45.15.205>;tag=8EE35584-13CB To: <sip:80456701@10.45.129.254> Date: Thu, 24 Oct 2013 05:46:07 GMT Call-ID: 69D5F764-3BA611E3-846CECB2-B4A0A393@10.45.15.205 CSeq: 101 CANCEL Max-Forwards: 70 Timestamp: 1382593567 Reason: Q.850;cause=65 Content-Length: 0 Oct 24 11:46:07.812: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Received: SIP/2.0 408 Request Timeout Via: SIP/2.0/UDP 10.45.15.205:5060;branch=z9hG4bK34317E1;received=10.45.15.205 From: <sip:81691690@10.45.15.205>;tag=8EE35584-13CB To: <sip:80456701@10.45.129.254>;tag=58f7391a;tag=30c59eb7 Call-ID: 69D5F764-3BA611E3-846CECB2-B4A0A393@10.45.15.205 CSeq: 101 INVITE Contact: <sip:80456701@10.45.129.254:5060> Content-Length: 0 Oct 24 11:46:07.824: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Sent: ACK sip:80456701@10.45.129.254:5060 SIP/2.0 Via: SIP/2.0/UDP 10.45.15.205:5060;branch=z9hG4bK34317E1 From: <sip:81691690@10.45.15.205>;tag=8EE35584-13CB To: <sip:80456701@10.45.129.254>;tag=58f7391a;tag=30c59eb7 Date: Thu, 24 Oct 2013 05:46:07 GMT Call-ID: 69D5F764-3BA611E3-846CECB2-B4A0A393@10.45.15.205 Max-Forwards: 70 CSeq: 101 ACK Allow-Events: telephone-event Reason: Q.850;cause=65 Content-Length: 0 Oct 24 11:46:07.824: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Sent: SIP/2.0 501 Not Implemented Via: SIP/2.0/UDP 10.169.2.222:5060;branch=z9hG4bK7b450b98;rport From: <sip:81691690@10.169.2.222>;tag=as47c1192d To: <sip:80456701@10.45.15.205>;tag=8EE355CC-1586 Date: Thu, 24 Oct 2013 05:46:07 GMT Call-ID: 19b3352f3ba363557f4f6fde368e18ba@10.169.2.222:5060 CSeq: 102 INVITE Allow-Events: telephone-event Server: Cisco-SIPGateway/IOS-12.x Reason: Q.850;cause=65 Content-Length: 0 Oct 24 11:46:07.828: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Received: SIP/2.0 200 OK Via: SIP/2.0/UDP 10.45.15.205:5060;branch=z9hG4bK34317E1;received=10.45.15.205 From: <sip:81691690@10.45.15.205>;tag=8EE35584-13CB To: <sip:80456701@10.45.129.254> Call-ID: 69D5F764-3BA611E3-846CECB2-B4A0A393@10.45.15.205 CSeq: 101 CANCEL Content-Length: 0 Oct 24 11:46:07.876: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Received: c2811-45-voip#ACK sip:80456701@10.45.15.205 SIP/2.0 Via: SIP/2.0/UDP 10.169.2.222:5060;branch=z9hG4bK7b450b98;rport Max-Forwards: 70 From: <sip:81691690@10.169.2.222>;tag=as47c1192d To: <sip:80456701@10.45.15.205>;tag=8EE355CC-1586 Contact: <sip:81691690@10.169.2.222:5060> Call-ID: 19b3352f3ba363557f4f6fde368e18ba@10.169.2.222:5060 CSeq: 102 ACK User-Agent: -2.11.0beta2(11.5.1) Content-Length: 0 Oct 24 11:46:09.556: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Received: OPTIONS sip:10.45.15.205 SIP/2.0 Via: SIP/2.0/UDP 10.169.2.222:5060;branch=z9hG4bK6659352e;rport Max-Forwards: 70 From: "Unknown" <sip:Unknown@10.169.2.222>;tag=as0644d677 To: <sip:10.45.15.205> Contact: <sip:Unknown@10.169.2.222:5060> Call-ID: 0dab5dac266072254980629f521c4fa2@10.169.2.222:5060 CSeq: 102 OPTIONS User-Agent: -2.11.0beta2(11.5.1) Date: Thu, 24 Oct 2013 05:45:20 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH Supported: replaces, timer Content-Length: 0 Oct 24 11:46:09.564: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Sent: SIP/2.0 200 OK Via: SIP/2.0/UDP 10.169.2.222:5060;branch=z9hG4bK6659352e;rport From: "Unknown" <sip:Unknown@10.169.2.222>;tag=as0644d677 To: <sip:10.45.15.205>;tag=8EE35C94-7D Date: Thu, 24 Oct 2013 05:46:09 GMT Call-ID: 0dab5dac266072254980629f521c4fa2@10.169.2.222:5060 Server: Cisco-SIPGateway/IOS-12.x CSeq: 102 OPTIONS Supported: 100rel,resource-priority,replaces,sdp-anat Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER Allow-Events: telephone-ev c2811-45-voip#ent Accept: application/sdp Content-Type: application/sdp Content-Length: 452 v=0 o=CiscoSystemsSIP-GW-UserAgent 6266 9402 IN IP4 10.45.15.205 s=SIP Call c=IN IP4 10.45.15.205 t=0 0 m=audio 0 RTP/AVP 18 0 8 9 4 2 15 3 c=IN IP4 10.45.15.205 m=image 0 udptl t38 c=IN IP4 10.45.15.205 a=T38FaxVersion:0 a=T38MaxBitRate:9600 a=T38FaxFillBitRemoval:0 a=T38FaxTranscodingMMR:0 a=T38FaxTranscodingJBIG:0 a=T38FaxRateManagement:transferredTCF a=T38FaxMaxBuffer:200 a=T38FaxMaxDatagram:180 a=T38FaxUdpEC:t38UDPRedundancy Какой-то непонятный набор ошибок. Как я понял, астериск с циской договорились нормально, а вот циска с DGW уже не может ни о чем договориться? Причем видно, что сама сигнализация прошла и один звонок на телефоне был, абонент же сразу получил отбой. Вот в истории звонков: 123701 ORG     T0     g729r8      VOIP        P80456701          0.0.0.0:0       D41   123700 ANS     T0     g729r8      VOIP        P81691690     10.169.2.222:11738   D41
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	10. "Перенаправление звонков Cisco -> SIP-шлюз"	+/–
	Сообщение от vigogne (ok) on 24-Окт-13, 11:08
	Так, кажется начинает вырисовываться картина. При жестком указании кодека G711Alaw в диалпире 80456700 звонки начинают нормально осуществляться. И даже если я создаю voice class codec с кодеками по-порядку g711alaw, g729r8, g723ar53, в общем с теми, которые указаны в DGW, все равно сразу картина меняется на ту, что в дебаге. Самое плохое, что почти в каждом регионе на наше (да и на другие) направления жестко указан g729br8. Как быть с ними, не представляю. Вроде в этом должен помочь транскодинг, но, насколько я понял, он осуществим только на модуле NM-HDV2, у меня же голые PVDM2-32. В некоторых регионах создан voice class codec с набором кодеков, в которых есть и g711alaw, так те нормально дозваниваются (во всяком случае один дозвонился, потом остальные проверим).
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	11. "Перенаправление звонков Cisco -> SIP-шлюз"	+/–
	Сообщение от crash (ok) on 25-Окт-13, 06:57
	> Вроде в этом должен помочь транскодинг, но, насколько я понял, он > осуществим только на модуле NM-HDV2, у меня же голые PVDM2-32. настраивал на простом pvdm, транскодинг работает.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	12. "Перенаправление звонков Cisco -> SIP-шлюз"	+/–
	Сообщение от vigogne (ok) on 25-Окт-13, 07:26
	>> Вроде в этом должен помочь транскодинг, но, насколько я понял, он >> осуществим только на модуле NM-HDV2, у меня же голые PVDM2-32. > настраивал на простом pvdm, транскодинг работает. А не могли бы Вы привести пример Ваших настроек транскодинга?
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема