Добрый день!
Имеется следующая проблема: 7090, настроенный на сипнет, при исходящих звонках в город, если вызывающий абонент кладет трубку - не отбивает звонок. Т.е. из мониторинга звонок пропадает, а у вызываемого абонента телефон продолжает звонить до тех пор, пока он не возьмет трубку. При этом в трубке, разумеется, тишина. При прямых звонках со шлюзов AddPac и с OpenPhone в город через сипнет такой проблемы нет. При звонках через 7090 - есть. Может, кто сталкивался?

Столкнулся с такой же проблемой и тоже пока не решил.
Если трубку вызываемый абонент не берет, то звонок идет порядка 2 минут и только потом сбрасывается. Бывает даже так, что сипнет начинает повторно вызывать абонента уже с другого номера, на 7090 в этот момент, конечно же, ничего не видно.

Есть возможность отсниферить трафик между 7090 и сипнетом?
Либо проверьте "SU Protocol" звонка, который не отбился на предмет наличия/отсутствия сообщения REL от DVX в сторону сипнета!

_________________
С уважением,
Инженер связи
Давыдов Андрей Андреевич

Было, да и есть все точно такоеже. настраивать тоны отбоя и снифить пакеты бесполезно. от д-линка не дождался помощи.
Решение , сделал роут на отбой вызова и у каждого пользователя прописал через 30 секунд не ответа посылать на этот роут.

Можно все таки "SU Protocol" звонка, который не отбился в студию.

_________________
С уважением,
Инженер связи
Давыдов Андрей Андреевич

Специально для dogmeat1982 привожу 2 звонка

1. Через сипнет был сделан вызов в 18.37.30 далее в 18.37.45 вызов был прерван (положил трубку) однако после этого на другом конце еще шли звонки от сипнета в течении 1 мин. 14 сек. (до 18.39.00)
Собственно ЛОГ

2009/06/21 18:37:30:INF:BaseClasses.cpp:8499:Sip Call created: 0x8b0cb20
2009/06/21 18:37:30:INF:dInterface.cpp:826:Opening incoming SIP leg c0b95300-eb01-0010-80b0-00900b0cc36b from=1015 to=6174957727672 fromIP=192.168.133.56:5063 toIP=192.168.133.55:5060 registrationID=151cba46-41a3-42b7-8122-44b32e7fdc9a
2009/06/21 18:37:30:INF:BaseClasses.cpp:8499:Sip Call created: 0x8b0d6ec
2009/06/21 18:37:30:INF:..//RtpFilters/RtpTransceiver.h:196:RTP channel created: 0x8ca4180 load=0
2009/06/21 18:37:30:INF:dInterface.cpp:826:Opening outgoing SIP leg 73fc1a3c-5e25-43c3-9324-6016dab2373a from=1015 to=74957727672 fromIP=192.168.133.55:5060 toIP=212.53.40.40:5060 registrationID=
2009/06/21 18:37:30:INF:..//RtpFilters/RtpTransceiver.h:196:RTP channel created: 0x8ce9ae8 load=0
2009/06/21 18:37:45:INF:..//RtpFilters/RtpTransceiver.h:167:RTP channel deleted: 0x8ce9ae8, nat = false, dst = 192.168.133.56:16460, sent = 736, recv = 491, sent RTCP = 1, recv RTCP = 0, sent T.38 = 0, recv T.38 = 0
2009/06/21 18:37:45:INF:BaseClasses.cpp:9468:Closing leg c0b95300-eb01-0010-80b0-00900b0cc36b cause= 200 codec= G729 (active conferences= 0)
2009/06/21 18:37:45:INF:..//RtpFilters/RtpTransceiver.h:167:RTP channel deleted: 0x8ca4180, nat = false, dst = 0.0.0.0:0, sent = 0, recv = 0, sent RTCP = 0, recv RTCP = 0, sent T.38 = 0, recv T.38 = 0
2009/06/21 18:37:45:INF:BaseClasses.cpp:9468:Closing leg 73fc1a3c-5e25-43c3-9324-6016dab2373a cause= 200 codec= G729 (active conferences= 0)
2009/06/21 18:37:55:INF:BaseClasses.cpp:8708:Sip Call deleted: 0x8b0cb20
2009/06/21 18:37:55:INF:BaseClasses.cpp:8708:Sip Call deleted: 0x8b0d6ec




2. Через еще одного провайдера был сделан вызов в 18.49.32 далее в 18.49.46 вызов был прерван (положил трубку) после этого на другом конце еще шли звонки в течении 4 сек!!! (до 18.49.50)

2009/06/21 18:49:32:INF:BaseClasses.cpp:8499:Sip Call created: 0x8b0cb20
2009/06/21 18:49:32:INF:dInterface.cpp:826:Opening incoming SIP leg 00540100-9007-0010-8100-00900b0cc36b from=1015 to=6074957727672 fromIP=192.168.133.56:5063 toIP=192.168.133.55:5060 registrationID=151cba46-41a3-42b7-8122-44b32e7fdc9a
2009/06/21 18:49:32:INF:BaseClasses.cpp:8499:Sip Call created: 0x8b0d6ec
2009/06/21 18:49:32:INF:..//RtpFilters/RtpTransceiver.h:196:RTP channel created: 0x8ca50e8 load=0
2009/06/21 18:49:32:INF:dInterface.cpp:826:Opening outgoing SIP leg b7f55549-16f0-4ed1-b073-3af6af3415f4 from=1015 to=74957727672 fromIP=192.168.133.55:5060 toIP=82.146.40.132:5060 registrationID=
2009/06/21 18:49:34:INF:..//RtpFilters/RtpTransceiver.h:196:RTP channel created: 0x8ce9a28 load=0
2009/06/21 18:49:46:INF:..//RtpFilters/RtpTransceiver.h:167:RTP channel deleted: 0x8ce9a28, nat = false, dst = 192.168.133.56:16462, sent = 554, recv = 369, sent RTCP = 1, recv RTCP = 0, sent T.38 = 0, recv T.38 = 0
2009/06/21 18:49:46:INF:BaseClasses.cpp:9468:Closing leg 00540100-9007-0010-8100-00900b0cc36b cause= 200 codec= PCMA (active conferences= 0)
2009/06/21 18:49:46:INF:..//RtpFilters/RtpTransceiver.h:167:RTP channel deleted: 0x8ca50e8, nat = false, dst = 0.0.0.0:0, sent = 0, recv = 0, sent RTCP = 0, recv RTCP = 0, sent T.38 = 0, recv T.38 = 0
2009/06/21 18:49:46:INF:BaseClasses.cpp:9468:Closing leg b7f55549-16f0-4ed1-b073-3af6af3415f4 cause= 200 codec= PCMA (active conferences= 0)
2009/06/21 18:49:56:INF:BaseClasses.cpp:8708:Sip Call deleted: 0x8b0cb20
2009/06/21 18:49:56:INF:BaseClasses.cpp:8708:Sip Call deleted: 0x8b0d6ec



ВСЕ настройки на 7090 для двух указанных гейтов одинаковые.
Да и еще у 7090 серый адрес возможно дело в этом.
Пишите если еще что-то будет нужно.

Для более полной картины в дополнение к вышеприведенным логам SU логам привожу CU протоколы для тех же звонков

2009/06/21 18:37:30.082 INF c0b95300eb01001080b000900b0cc36b Call: OnRegisterCall(): *******************************************************
2009/06/21 18:37:30.082 INF c0b95300eb01001080b000900b0cc36b Call: OnRegisterCall(): Incoming call src=1015 address=192.168.133.56 dst=6174957727672
2009/06/21 18:37:30.094 INF c0b95300eb01001080b000900b0cc36b Call: OnRegisterCall(): Incoming call capabilities = <capabilities></capabilities>
2009/06/21 18:37:30.149 INF e9917ab310a6441782d6b0e8502516da Conference: OnCapabilitiesCall(): incoming >>> Caps (DB): G.729/2, G.729A/2, G.723.1/1, PCMA/20, PCMU/20, GSMFR/7
2009/06/21 18:37:30.150 INF e9917ab310a6441782d6b0e8502516da Conference: OnCapabilitiesCall(): incoming >>> Caps (device): G.729/0, PCMU/0, G.723.1/0, PCMA/0
2009/06/21 18:37:30.151 INF e9917ab310a6441782d6b0e8502516da Conference: OnCapabilitiesCall(): Caps1: G.729/0, G.723.1/0, PCMA/0, PCMU/0, G.729/0
2009/06/21 18:37:30.153 INF c0b95300eb01001080b000900b0cc36b Rule: GetRoute(): Rule description: Outgoing calls sip 674
2009/06/21 18:37:30.154 INF c0b95300eb01001080b000900b0cc36b GwRoute: .ctor(): --->>> Follow to GATEWAY route src=1015, dst=74957727672, gw=169512c1-e3df-4c23-964f-bf9727840030
2009/06/21 18:37:30.160 INF c0b95300eb01001080b000900b0cc36b Conference: DialOutgoingTerminal(): DialUser: 1015 -> 52995674
2009/06/21 18:37:30.164 INF 73fc1a3c5e2543c393246016dab2373a Conference: CreateOutgoingCall(): Caps2: G.729/2, G.723.1/1, PCMA/20, PCMU/20, G.729/2, G.729A/2, GSMFR/1
2009/06/21 18:37:30.210 INF 73fc1a3c5e2543c393246016dab2373a Call: OnRegisterCall(): <<< outgoing src=1015 dst=74957727672
2009/06/21 18:37:30.769 INF e9917ab310a6441782d6b0e8502516da Conference: OnCapabilitiesCall(): outgoing <<< Caps (DB): G.729A/2, G.729/2, G.723.1/1, PCMA/20, PCMU/20, GSMFR/1
2009/06/21 18:37:30.770 INF e9917ab310a6441782d6b0e8502516da Conference: OnCapabilitiesCall(): outgoing <<< Caps (device): G.729/0
2009/06/21 18:37:30.771 INF e9917ab310a6441782d6b0e8502516da Conference: OnCapabilitiesCall(): outgoing <<< Confirming caps for the first leg: G.729/0, G.729/0
2009/06/21 18:37:30.772 INF 73fc1a3c5e2543c393246016dab2373a Conference: OnMediaStart(): outgoing <<< Call src=1015 dst=74957727672 caps_start: G.729/0,
2009/06/21 18:37:30.773 INF 73fc1a3c5e2543c393246016dab2373a Conference: OnAlertingCall(): outgoing <<< Call src=1015 dst=74957727672 alerted.
2009/06/21 18:37:30.817 INF c0b95300eb01001080b000900b0cc36b Conference: OnMediaStart(): incoming >>> Call src=1015 dst=6174957727672 caps_start: G.729/0,
2009/06/21 18:37:30.953 INF e9917ab310a6441782d6b0e8502516da Conference: OnPayloadTypeChangedCall(): incoming >>> callId=c0b95300-eb01-0010-80b0-00900b0cc36b
2009/06/21 18:37:45.539 INF c0b95300eb01001080b000900b0cc36b Conference: OnUnregisterCall() >>> incoming src=1015 dst=6174957727672 reasonCode=16 reason=Normal call termination
2009/06/21 18:37:45.598 INF 73fc1a3c5e2543c393246016dab2373a Conference: OnUnregisterCall() <<< outgoing src=1015 dst=74957727672 reasonCode=16 reason=Normal call termination

2009/06/21 18:49:32.564 INF 0054010090070010810000900b0cc36b Call: OnRegisterCall(): *******************************************************
2009/06/21 18:49:32.565 INF 0054010090070010810000900b0cc36b Call: OnRegisterCall(): Incoming call src=1015 address=192.168.133.56 dst=6074957727672
2009/06/21 18:49:32.576 INF 0054010090070010810000900b0cc36b Call: OnRegisterCall(): Incoming call capabilities = <capabilities></capabilities>
2009/06/21 18:49:32.619 INF 09aeee0090db4843ab42b3e27f49ae7c Conference: OnCapabilitiesCall(): incoming >>> Caps (DB): G.729/2, G.729A/2, G.723.1/1, PCMA/20, PCMU/20, GSMFR/7
2009/06/21 18:49:32.620 INF 09aeee0090db4843ab42b3e27f49ae7c Conference: OnCapabilitiesCall(): incoming >>> Caps (device): G.729/0, PCMU/0, G.723.1/0, PCMA/0
2009/06/21 18:49:32.621 INF 09aeee0090db4843ab42b3e27f49ae7c Conference: OnCapabilitiesCall(): Caps1: G.729/0, G.723.1/0, PCMA/0, PCMU/0, G.729/0
2009/06/21 18:49:32.624 INF 0054010090070010810000900b0cc36b Rule: GetRoute(): Rule description: Outgoing calls sity 742 Clone
2009/06/21 18:49:32.624 INF 0054010090070010810000900b0cc36b GwRoute: .ctor(): --->>> Follow to GATEWAY route src=1015, dst=74957727672, gw=3a6c0158-d5a2-4c12-a749-9b30aa06eac1
2009/06/21 18:49:32.631 INF 0054010090070010810000900b0cc36b Conference: DialOutgoingTerminal(): DialUser: 1015 -> 52001742
2009/06/21 18:49:32.634 INF b7f5554916f04ed1b0733af6af3415f4 Conference: CreateOutgoingCall(): Caps2: G.729/2, G.723.1/1, PCMA/20, PCMU/20, G.729/2, G.729A/2, GSMFR/1
2009/06/21 18:49:32.680 INF b7f5554916f04ed1b0733af6af3415f4 Call: OnRegisterCall(): <<< outgoing src=1015 dst=74957727672
2009/06/21 18:49:34.897 INF 09aeee0090db4843ab42b3e27f49ae7c Conference: OnCapabilitiesCall(): outgoing <<< Caps (DB): G.729A/2, G.729/2, G.723.1/1, PCMA/20, PCMU/20, GSMFR/1
2009/06/21 18:49:34.899 INF 09aeee0090db4843ab42b3e27f49ae7c Conference: OnCapabilitiesCall(): outgoing <<< Caps (device): PCMA/0
2009/06/21 18:49:34.901 INF 09aeee0090db4843ab42b3e27f49ae7c Conference: OnCapabilitiesCall(): outgoing <<< Confirming caps for the first leg: PCMA/0
2009/06/21 18:49:34.902 INF b7f5554916f04ed1b0733af6af3415f4 Conference: OnMediaStart(): outgoing <<< Call src=1015 dst=74957727672 caps_start: PCMA/0,
2009/06/21 18:49:34.903 INF b7f5554916f04ed1b0733af6af3415f4 Conference: OnAlertingCall(): outgoing <<< Call src=1015 dst=74957727672 alerted.
2009/06/21 18:49:34.947 INF 0054010090070010810000900b0cc36b Conference: OnMediaStart(): incoming >>> Call src=1015 dst=6074957727672 caps_start: PCMA/0,
2009/06/21 18:49:35.069 INF 09aeee0090db4843ab42b3e27f49ae7c Conference: OnPayloadTypeChangedCall(): incoming >>> callId=00540100-9007-0010-8100-00900b0cc36b
2009/06/21 18:49:46.015 INF 0054010090070010810000900b0cc36b Conference: OnUnregisterCall() >>> incoming src=1015 dst=6074957727672 reasonCode=16 reason=Normal call termination
2009/06/21 18:49:46.061 INF b7f5554916f04ed1b0733af6af3415f4 Conference: OnUnregisterCall() <<< outgoing src=1015 dst=74957727672 reasonCode=16 reason=Normal call termination

1. Раз у нас DVX за NAT, то в настройках Gateway галку "Proxy" желательно поставить в "Force Proxy". Если она у Вас так и выставлена, тогда непонятно почему в логе при формировании RTP-канала пишется "nat = false, dst = 0.0.0.0:0";
2. Если есть возможность, то поппробуйте посадить DVX с белым ипом в сеть и рядом с ним IP-телефон или софтфон. Т.е. максимально упростие ситуацию с точки зрения прохождения VoIP-трафика, а потом постепенно усложняйте до требуемой и смотрите в какой момент проявится проблема;
3. Версия ПО на DVX у Вас какая?

_________________
С уважением,
Инженер связи
Давыдов Андрей Андреевич

Спасибо за советы
Результаты пока отрицательные
1 у меня по умолчанию стояла галка NAT detect поставил forced никаких изменений.
2 посадить DVX с белым IP пока нет возможности, возможно попробую не раньше следующего месяца.
3. версия ПО на DVX скорее всего самая последняя App2008-12-27_6480_2.dat , если нет напишите какая стоит у вас.

NAT сервер к сожалению администрирую не я, но я могу что либо узнать или попросить прописать.

Позвоните если у вас есть новые идеи и возможность мой номер в сипнете ID 3037388 всегда доступен.