OS7200 Одностороняя слышимость

[Butch3r]

Разбираюсь дальше

Изменил схему до первоначальной (тут IP телефон не сидит в одном влане с АТС, а регистрируется на АТС с домашнего интернета абонента, поэтом IP телефона другой). Опять же только роутинг, никаких НАТов.

когда внутренний абонент звонит мне на IP телефон, то в телнете карте MGI вижу следующее:

+----+-----------------+-------+-------+-------+-------+-------+-------+---------+-------+-------+
| ch | ip | oport | rport | codec | ctype | mobex | dtype | mfr | nat | vbd |
+----+-----------------+-------+-------+-------+-------+-------+-------+---------+-------+-------+
| 8 | 78.109.129.54 | 34164 | 34164 | 11 | UCAST | Off | rfc2833 | OFF |OFF | 0 |
+----+-----------------+-------+-------+-------+-------+-------+-------+---------+-------+-------+

А когда внешний абонент звонит на внешний номер и вызов уходит с АТС на мой IP телефон на MGI вижу следующее:

+----+-----------------+-------+-------+-------+-------+-------+-------+---------+-------+-------+
| ch | ip | oport | rport | codec | ctype | mobex | dtype | mfr | nat | vbd |
+----+-----------------+-------+-------+-------+-------+-------+-------+---------+-------+-------+
+----+-----------------+-------+-------+-------+-------+-------+-------+---------+-------+-------+

При этом в этот момент трубка снята, всё что я говорю в IP телефон слышно на удаленной стороне, а я в телефоне не слышу ничего.

Со станциями знаком поверхностно, в какую вообще сторону стоит копать?

[SergA]

Схему с NAT попробуйте.

[Butch3r]

Да вот проблема в том, что его сделать не на чём

[LionB]

Как так может быть, что адрес SIP Proxy 78.109.128.59, а на MP20 указан только локальный IP и Privat Only?
Естественно, в полях Contact и Media Channel Description АТС будет указываю SIP серверу свои локальные IP. И куда SIP сервер отвечать и слать RTP должен, в свою локальную сеть?
Раз SIP сервер не в локальной сетке, а висит на белом адресе, то по любому должен быть NAT и на нем должен для VoIP быть выделен белый IP, который и указывается, как Public IP в настройках LAN и MGI (на обоих должен стоять режим Private with Public). Соотетсвенно настраивается трансляция портов.

P.S. Для вызовов в VPN, надо задать список удаленных сетей в DM5.2.8, чтобы в обратных контактных данных оставались локальные IP.

[Butch3r]

Как так может быть, что адрес SIP Proxy 78.109.128.59, а на MP20 указан только локальный IP и Privat Only?
Естественно, в полях Contact и Media Channel Description АТС будет указываю SIP серверу свои локальные IP. И куда SIP сервер отвечать и слать RTP должен, в свою локальную сеть?
Раз SIP сервер не в локальной сетке, а висит на белом адресе, то по любому должен быть NAT и на нем должен для VoIP быть выделен белый IP, который и указывается, как Public IP в настройках LAN и MGI (на обоих должен стоять режим Private with Public). Соотетсвенно настраивается трансляция портов.

P.S. Для вызовов в VPN, надо задать список удаленных сетей в DM5.2.8, чтобы в обратных контактных данных оставались локальные IP.

Нет, не обязательно.

Мы провайдер и мы просто настроили маршутизацию и серая сеть 10.4.1.240/29 знает как ходить до IP 78.109.128.59 через свой основной шлюз 10.4.1.246 который и прописан на станции.

По-сути в данном случае понятие серой сети формально, так как у нас в сети по-сути это равнозначные адреса.

p.s. Если я меняю настройки на LAN с Private на Private with public то вообще всё перестает работать. Смена на MGI не дает никакого эффекта.

[SergA]

Лев, добрый день,
я согласен с коллегой из Барнаула, такая схема включения - вполне рабочая, в снифере виден вполне нормальный обмен АТС и софтсвича (Mera у них). Но пока 100% результата нет, конечно, нужно разбираться.

[LionB]

Я написал, как оно должно работать и работает 100% правильно.
Станция понимает только такие варианты:
1) Трафик идет в локалку (IP назначения достижим по маске).
2) Трафик идет на роутер в публичную сеть (IP не достижим по маске, в контактах указывается белый IP).
3) Трафик идет на роутер в VPN (IP не достижим по маске, в контактах указывается локальный IP).

Чисто комбинаторно остался еще вариант с указанием на MP20 и OAS типа Privat Only, но задать в DM5.2.8 адрес SIP Proxy 78.109.128.59

[Butch3r]

Я написал, как оно должно работать и работает 100% правильно.
Станция понимает только такие варианты:
1) Трафик идет в локалку (IP назначения достижим по маске).
2) Трафик идет на роутер в публичную сеть (IP не достижим по маске, в контактах указывается белый IP).
3) Трафик идет на роутер в VPN (IP не достижим по маске, в контактах указывается локальный IP).

Чисто комбинаторно остался еще вариант с указанием на MP20 и OAS типа Privat Only, но задать в DM5.2.8 адрес SIP Proxy 78.109.128.59

попробовал вариант с 5.2.8 - без изменений. голоса нет от телефона до АТС и в телнете MGI нет звонка.

[Butch3r]

В общем моя битва с самсунгом продолжается.
Вчера обновил ПО на станции, как и ожидалось ничего не заработало

Но в новой версии ПО появился раздел 6.7.1 где я получил вот такой лог звонка с односторонней слышимостью:

Код: Выделить всё

24843 12/13 10:26:17
24905[1af:#516]<SIPTRK t_idle   CONN_IN    00 78.109.128.59:22638[11,3,10,255,255](73852567420 <- 7
24905[1af:#516]<SIPTRK t_incom  ALERT_IN   00 0.0.0.0:0:0,0,0,0,0
24905[108:420 ]<call d_idle   szr_stn   1005
24905[108:420 ]>PRI d_idle   CONN_RQ    00 ( ->
)
24905[108:420 ]>SIPSTN d_idle   CONN_RQ    00 10.4.1.242:40104[11,3,10,255,255](73852567567 -> 420)
24905[1AF:#516]<call t_didstn szr_stn_r 1123
24905[1AF:#516]<call t_bri    state     1ade
24905[108:420 ]<SIPSTN d_idle   PROGRES_IN 00 0.0.0.0:0:0,0,0,0,0
24905[108:420 ]<LPM  d_idle   unknown   6600
24905[1AF:#516]<call t_bri    szr_stn_r 1100
24905[1AF:#516]<call t_brirbk bri_state 96ff
24905[108:420 ]<call d_brirng add_cbt   7dff
24905[108:420 ]<call d_brirng add_ringq 75ff
24905[108:420 ]<call d_brirng send_info 9805
24906[108:420 ]<SIPSTN d_brirng ALERT_IN   00 0.0.0.0:0:0,0,0,0,0
24906[108:420 ]<LPM  d_brirng unknown   6500
24906[1AF:#516]<call t_brirbk bri_state 96ff
24906[1af:#516]>SIPTRK t_brirbk ALERT_RQ   3F 10.4.1.242:45040:11,255,255,255,255
24930[108:420 ]<SIPSTN d_brirng CONN_CO    00 78.109.129.54:37816:11,255,255,255,255
24930[108:420 ]<LPM  d_brirng unknown   6200
24930[108:420 ]>PRI d_brirng CONN_ACK   00
24930[108:420 ]>PRI d_conv   UPDATE_RQ  00
24930[1AF:#516]<call t_brirbk opphof    1b00
24930[1AF:#516]<call t_brirbk imhof     71ff
24930[1AF:#516]<call t_brirbk bri_state 96ff
24930[108:420 ]<call d_conv   state     1a06
24930[108:420 ]<call d_conv   bri_state 96ff
24930[1AF:#516]<call t_conv   state     1a01
24930[1AF:#516]<call t_conv   state     1a00
24930[108:420 ]<call d_conv   call_dur  4c00
24930[108:420 ]<call d_conv   call_dur  4c00
24930[108:420 ]<call d_conv   k_vms_rec 32ff
24930[108:420 ]<call d_conv   k_vms_rec 32ff
24932[1af:#516]>SIPTRK t_conv   CONN_RS    3F 10.4.1.242:40106:11,255,255,255,255
24933[1af:#516]<SIPTRK t_conv   CONN_CO    00 78.109.128.59:22638:11,255,255,255,255
24933[108:420 ]>PRI d_conv   UPDATE_RQ  00
24933[108:420 ]>PRI d_conv   CONN_ACK   00
24933[108:420 ]>SIPSTN d_conv   CONN_ACK   00 255.255.255.255:65535:255,255,255,255,255
24933[108:420 ]>PRI d_conv   UPDATE_RQ  00
24933[108:420 ]<call d_conv   bri_state 96ff
24958[108:420 ]<SIPSTN d_conv   CLEAR_IN   00 16 456
24958[108:420 ]<LPM  d_conv   unknown   6300
24958[108:420 ]>PRI d_conv   CLEAR_RS   00
24958[108:420 ]>SIPSTN d_conv   CLEAR_RS   00 10
24958[108:420 ] CALL_CLEAR recv_voip_trunk_msg : 620 (0x1af,0x0)
24958[108:420 ]<LPM  d_conv   hook_on   0263
24958[1AF:#516]<call t_conv   autordl   3c01
24958[1AF:#516]<call t_conv   opphon    1cff
24958[1af:#516] CALL_CLEAR go_trk_rls_state : 480 (0x108,0x10)
24958[1af:#516]>SIPTRK t_conv   CLEAR_RQ   3F 16
24958[1AF:#516]<call t_rls    imhon     72ff
24958[108:420 ]<call d_rls    state     1a09
24958[108:420 ]<SIPSTN d_rls    CLEAR_CO   00 80813800
24958[108:420 ]<LPM  d_rls    unknown   6400
24958[108:420 ] CALL_CLEAR recv_voip_trunk_msg : 713 (0x1af,0x0)
24958[108:420 ]<LPM  d_rls    hook_on   0264
24958[1AF:#516]<call t_rls    get_ringq 77ff
24958[108:420 ]<call d_rls    get_rq_r  7801
24958[1af:#516]<SIPTRK t_rls    CLEAR_CO   00 2
24958[1af:#516] CALL_CLEAR recv_voip_trunk_msg : 721 (0x108,0x3f)
24958[1AF:#516]<LPM  t_rls    hook_on   0264

Кто-нибудь в этом понимает, тут всё ок?

[LionB]

Бесполезный в общем трэйс. В VoIP лучше смотреть в WireShark.
В любом случае, я описал 3 варианта, как должна и работает правильно АТС.