Дано:
Подсеть 192.168.0.0/24 офис Москва
Подсеть 192.168.10.0/24 офис Самара
Между подсетями VPN (Fairwall/NAT все настроено)
Развернутый MS Lync сервер с ролью Mediation ip 192.168.0.38 внутренние номера 100-999
Развернутый Freepbx ip 192.168.0.21 внутренние номера 1000-1999
В Freepbx созданы 2 транка, 1 к провайдеру, 1 к Lync.
Настройки транка к Lync:
host=192.168.0.38
transport=tcp,udp
port=5060
insecure=very
type=friend
context=from-internal
promiscredir=yes
qualify=yes
conreivite=yes
В Outbound Routes созданы правила набора звонков на внутренние Lync 2013
[78]XXXXXXXXXX
0[1-9]XXXXXXXXX
49[589]XXXXXXX
итд
Настройки в Lync 2013
В самой консоли Lync указал маршрутам с правилами набора на внешние номера звонить через транк Freepbx.
Проблема: звонки из Freepbx идут на внутренние Lync, обратно нет. Отрывок лога : звоню с Lync на внутренний номер 1001 из самарской подсети.
[2017-05-14 15:19:29] VERBOSE[1887] chan_sip.c: --- (10 headers 0 lines) ---
[2017-05-14 15:19:29] NOTICE[1887] chan_sip.c: Outbound Registration: Expiry for login.mtt.ru is 120 sec (Scheduling reregistration in 105 s)
[2017-05-14 15:19:29] VERBOSE[1887] chan_sip.c: Really destroying SIP dialog '5f673eb22cfdfb0d0fc4fd1a72b614a9@[::1]' Method: REGISTER
[2017-05-14 15:20:00] VERBOSE[1887] chan_sip.c: Reliably Transmitting (no NAT) to 192.168.10.254:5060:
OPTIONS sip:1001@192.168.10.254:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.21:5060;branch=z9hG4bK4d88a27a
Max-Forwards: 70
From: "Unknown" <sip:Unknown@192.168.0.21>;tag=as62cc41b9
To: <sip:1001@192.168.10.254:5060>
Contact: <sip:Unknown@192.168.0.21:5060>
Call-ID: 4a16432036fe821b172eeb827ec68a3f@192.168.0.21:5060
CSeq: 102 OPTIONS
User-Agent: FPBX-13.0.191.11(13.12.1)
Date: Sun, 14 May 2017 12:20:00 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0
---
[2017-05-14 15:20:00] VERBOSE[1887] chan_sip.c:
<--- SIP read from UDP:192.168.10.254:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.0.21:5060;branch=z9hG4bK4d88a27a
From: "Unknown" <sip:Unknown@192.168.0.21>;tag=as62cc41b9
To: <sip:1001@192.168.10.254:5060>;tag=001887510d37e7119b0b300d26636dd8
Call-ID: 4a16432036fe821b172eeb827ec68a3f@192.168.0.21:5060
CSeq: 102 OPTIONS
Contact: <sip:1001@192.168.10.254:5060>
Allow: INVITE, ACK, BYE, CANCEL, INFO, MESSAGE, NOTIFY, OPTIONS, REFER, UPDATE
Server: SIPPER for PhonerLite
Content-Length: 0
<------------->
[2017-05-14 15:20:00] VERBOSE[1887] chan_sip.c: --- (10 headers 0 lines) ---
[2017-05-14 15:20:00] VERBOSE[1887] chan_sip.c: Really destroying SIP dialog '4a16432036fe821b172eeb827ec68a3f@192.168.0.21:5060' Method: OPTIONS
[2017-05-14 15:20:12] VERBOSE[1887] chan_sip.c: Reliably Transmitting (no NAT) to 192.168.0.38:5060:
OPTIONS sip:192.168.0.38 SIP/2.0
Via: SIP/2.0/TCP 192.168.0.21:5160;branch=z9hG4bK7ed2d06c
Max-Forwards: 70
From: "Unknown" <sip:Unknown@192.168.0.21:5160>;tag=as6736ec5e
To: <sip:192.168.0.38>
Contact: <sip:Unknown@192.168.0.21:5160;transport=TCP>
Call-ID: 2450bdce3e5b9c366826b38f28c164ca@192.168.0.21:5160
CSeq: 102 OPTIONS
User-Agent: FPBX-13.0.191.11(13.12.1)
Date: Sun, 14 May 2017 12:20:12 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0
---
[2017-05-14 15:20:12] VERBOSE[35331] chan_sip.c:
<--- SIP read from TCP:192.168.0.38:5060 --->
SIP/2.0 200 OK
FROM: "Unknown"<sip:Unknown@192.168.0.21:5160>;tag=as6736ec5e
TO: <sip:192.168.0.38>;tag=5310367843
CSEQ: 102 OPTIONS
CALL-ID: 2450bdce3e5b9c366826b38f28c164ca@192.168.0.21:5160
VIA: SIP/2.0/TCP 192.168.0.21:5160;branch=z9hG4bK7ed2d06c
ACCEPT: application/sdp
CONTENT-LENGTH: 0
ACCEPT-ENCODING: gzip
ACCEPT-LANGUAGE: en
ALLOW: NOTIFY
ALLOW: BENOTIFY
SERVER: RTCC/5.0.0.0 MediationServer
<img src="https://habrastorage.org/web/2aa/9ea/204/2aa9ea2044314be6bdc8965789ca10a3.png" alt="image"/>
В Freepbx в настройках Chan Sip Setting настройка NAT=no, transport=tcp, tcpenable=yes, Bind port=5060.
Может дело в маршрутах Lync? Для звонка на сотовые стоят такие
Ну и лог Lync
Не удается связаться с кэширующим узлом магистрали. Сервер-посредник будет продолжать попытки, но новые ошибки не будут заноситься в журнал.
Кэширующий узел магистрали 192.168.0.21;trunk=192.168.0.21 не отвечает на запросы OPTIONS, отправленные службой сервера-посредника.
Ошибка разрешения DNS: False
Исключение: Microsoft.Rtc.Signaling.ConnectionFailureException:Unable to establish a connection. ---> System.Net.Sockets.SocketException (0x80004005): No connection could be made because the target machine actively refused it 192.168.0.21:5060
at System.Net.Sockets.Socket.EndConnect(IAsyncResult asyncResult)
at Microsoft.Rtc.Internal.Sip.TcpTransport.OnConnected(Object arg)
--- End of inner exception stack trace ---
at Microsoft.Rtc.Signaling.SipAsyncResult2`1.ThrowIfFailed()
at Microsoft.Rtc.Signaling.SipAsyncResultBase2.EndAsyncOperation[TResult](Object owner, IAsyncResult result)
at Microsoft.RTC.MediationServerCore.PeriodicOptionsSender.FinishSendOptionMessage(IAsyncResult ar)
Detected at System.Environment.GetStackTrace(Exception e, Boolean needFileInfo)
at System.Environment.get_StackTrace()
at Microsoft.Rtc.Signaling.RealTimeException..ctor(String message, Exception innerException)
at Microsoft.Rtc.Signaling.ExceptionUtilities.TryMapS4Exception(Exception s4Exception, SecurityAssociationContext securityContext, Boolean isSipEndpoint, String traceId, Object parentObject, Object childObject, RealTimeException& ex)
at Microsoft.Rtc.Signaling.SipTransactionAsyncResult`1.ConnectionConnectCompleted(IAsyncResult result)
at Microsoft.Rtc.Signaling.SipAsyncResult2`1.MakeCallback()
at Microsoft.Rtc.Signaling.SipAsyncResult2`1.Complete(TEx ex, Boolean synchronousCompletion)
at Microsoft.Rtc.Signaling.RealTimeConnection.CompletePendingConnects(IEnumerable`1 results, RealTimeException exception)
at Microsoft.Rtc.Signaling.RealTimeConnection.<.ctor>b__1(SipConnection sender, Object reason)
at Microsoft.Rtc.Internal.Sip.SipConnection.FireDisconnectedEvent(Object reason)
at Microsoft.Rtc.Internal.Sip.SingleThreadedDispatcherQueue.DispatcherCallback(Object queue)
at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
at System.Threading.ThreadPoolWorkQueue.Dispatch()
Причина: служба сервера-посредника не может обмениваться данными со службой кэширующего узла магистрали через SIP из-за проблем с сетевым подключением.
Решение:
для правильной работы службы сервера-посредника проверьте сетевое подключение и доступность кэширующего узла магистрали
Второй лог
В службе сервера-посредника возникла серьезная проблема с подключением к этим кэширующим узлам магистрали.
Проблема связана со следующими кластерами службы магистрали ТСОП:
192.168.0.21;trunk=192.168.0.21
Причина: ошибка MEDIATIONSERVER_GATEWAY_OPTIONS_FAILED (идентификатор события: 25051) записана 5 раз. Дополнительные сведения см. в оповещениях MOM. MEDIATIONSERVER_GATEWAY_IP_NOT_AVAILABLE (идентификатор события: 25036) и MEDIATIONSERVER_GATEWAY_TLS_NEGOTIATION_FAILED (идентификатор события: 25040) — примеры событий, которые указывают на наличие ошибок подключения к кэширующему узлу магистрали.
Решение:
в случае ошибки MEDIATIONSERVER_GATEWAY_IP_NOT_AVAILABLE (идентификатор события: 25036) убедитесь в том, что в хранилище управления в объекте магистрали ТСОП указаны правильный IP-адрес и порт прослушивания для магистрали, а магистраль работает и способна принимать входящие подключения от сервера-посредника. В случае ошибки MEDIATIONSERVER_GATEWAY_TLS_NEGOTIATION_FAILED (идентификатор события: 25040) убедитесь в том, что для TLS настроены сервер-посредник и магистраль, ЦС для сертификата магистрали является доверенным путем сертификата на сервере-посреднике, а ЦС для сертификата сервера-посредника является доверенным путем сертификата на магистрали.
