Есть два астериска. Один обслуживает небольшой город N, второй - офис в этом городе. Весь межгород приходит через ростелекомовский ОКС. Офисный астериск зарегистрирован как клиент городского астериска. Если звонить из города в офис, то всё отлично. Если же звонить из другого города [звонок приходит из ростелекома] в офис в городе N и звонящий, недождавшись ответа, положит трубку, то офисный астериск не получит пакет CANCEL и звонок будет продолжаться до окончания таймаута.
Чтобы сразу исключить проблему с ОКС-7: если звонить не в офис, а на любой другой номер в городе N, то при аналогичной ситуации пакет CANCEL приходит и звонок прекращается.
Трафик проверялся дебагом на офисном астериске: sip set debug peer 000
А теперь собственно вопрос: в какую сторону смотреть и что проверять?
После того как положили трубку на транзитном астериске вот такое (UNITEL PBX - принимает ОКС от Ростелекома и конвертит в SIP):
<--- SIP read from UDP:172.17.160.11:5060 --->
INFO sip:27777@172.17.160.21:5060 SIP/2.0
Via: SIP/2.0/UDP 172.17.160.11:5060;branch=z9hG4bKxand100074696
From: "380446374329" <sip:380446374329@172.17.160.11>;tag=100074696
To: "380446374329" <sip:380446374329@172.17.160.11>;tag=100074696
Call-ID: 6-10007469zAndXOk@172.17.160.11
Contact: <sip:380446374329@172.17.160.11:5060>
CSeq: 3 INFO
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, INFO, NOTIFY
User-Agent: UNITEL PBX
Content-Length:23
Content-Type: application/dtmf-relay
Max-Forwards: 70
Signal=6
Duration=50
<------------->
--- (12 headers 2 lines) ---
<--- Transmitting (no NAT) to 172.17.160.11:5060 --->
SIP/2.0 481 Call leg/transaction does not exist
Via: SIP/2.0/UDP 172.17.160.11:5060;branch=z9hG4bKxand100074696;received=172.17.160.11
From: "380446374329" <sip:380446374329@172.17.160.11>;tag=100074696
To: "380446374329" <sip:380446374329@172.17.160.11>;tag=100074696
Call-ID: 6-10007469zAndXOk@172.17.160.11
CSeq: 3 INFO
Server: Asterisk PBX 10.2.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0
<--- SIP read from UDP:172.17.160.11:5060 --->
ACK sip:27777@172.17.160.21:5060 SIP/2.0
Via: SIP/2.0/UDP 172.17.160.11:5060;branch=z9hG4bKxand100074696
From: "380446374329" <sip:380446374329@172.17.160.11>;tag=100074696
To: "380446374329" <sip:380446374329@172.17.160.11>;tag=100074696
Call-ID: 6-10007469zAndXOk@172.17.160.11
CSeq: 3 ACK
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, INFO, NOTIFY
User-Agent: UNITEL PBX
Max-Forwards: 70
Content-Length:0
<------------->
--- (10 headers 0 lines) ---
<--- SIP read from UDP:172.17.160.11:5060 --->
INFO sip:27777@172.17.160.21:5060 SIP/2.0
Via: SIP/2.0/UDP 172.17.160.11:5060;branch=z9hG4bKxand100074696
From: "380446374329" <sip:380446374329@172.17.160.11>;tag=100074696
To: "380446374329" <sip:380446374329@172.17.160.11>;tag=100074696
Call-ID: 6-10007469zAndXOk@172.17.160.11
Contact: <sip:380446374329@172.17.160.11:5060>
CSeq: 4 INFO
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, INFO, NOTIFY
User-Agent: UNITEL PBX
Content-Length:23
Content-Type: application/dtmf-relay
Max-Forwards: 70
Signal=3
Duration=50
<------------->
--- (12 headers 2 lines) ---
<--- SIP read from UDP:172.17.160.11:5060 --->
ACK sip:27777@172.17.160.21:5060 SIP/2.0
Via: SIP/2.0/UDP 172.17.160.11:5060;branch=z9hG4bKxand100074696
From: "380446374329" <sip:380446374329@172.17.160.11>;tag=100074696
To: "380446374329" <sip:380446374329@172.17.160.11>;tag=100074696
Call-ID: 6-10007469zAndXOk@172.17.160.11
CSeq: 4 ACK
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, INFO, NOTIFY
User-Agent: UNITEL PBX
Max-Forwards: 70
Content-Length:0
То есть не приходит сигнал о том, что положили трубку. И вызывает сомнения эта фраза Call leg/transaction does not exist
последнии два сообщения не от этого диалога. SIP/2.0 481 Call leg/transaction does not exist это вот как раз openser/kamailio/opensip такой ефект дает. хотя тут надо еще смотреть соответвие Call-ID: и tag= во всем диалоге, но обычно это не астриск. оператор не будет ничего исправлять. используйте междгород через дургого или забейте.
meral ( 2012-04-27 18:05:27 +0400 )редактироватьНачните со снятия tcpdump на транзитном астериске для проблемного и для успешного случая. Без внятного трэйса ничего вы не найдете.
Спасибо за подсказку. Но есть проблема - успешных случаев нет на этого абонента. Будем сегодня заниматься полным дебагом.
sattellite ( 2012-04-28 09:25:24 +0400 )редактироватьесли вы шлете не напрямую а через межгород, то очевидно копать в сторону провайдера.
в частности так бывает когда стоит openser/kamailio на стороне провайдера и настраивали его по мануалам на сайте без реального опыта и не проверяли.
но вообще вы очень неправильно проверяете. надо отдельно проверять звонки с астриска на окс межгород и с астерсика на астериск. не мешать.
а если делаете как вы описали то надо посмотреть получает ли этот метод тарнзитный астриск. вобщем конкретно сказать ничего нельзя.
ответил большим комментом, сюда не влезло
А проверять отельными кусками тдм->астериск, а потом астериск->астериск не получится. выступает всё ж как транзитный.
но в начальном условии описано что звонок с астериска на астериск происходит удачно. из окс-астериск-клиент тоже нормально.
либо я вас не понял и написал что-то не то.
sattellite ( 2012-04-27 18:03:09 +0400 )редактироватьчтото не то написали. если окс-астерсик-клиент нормально. то что вас беспокоит то? версии астриска разные чтоли?
meral ( 2012-04-27 18:40:53 +0400 )редактироватьбеспокоит то, что клиентские шлюзы получают отбой, а вот клиенты в офисе через дополнительный астериск этого не получают. И версии астерисков разные: транзитный - 1.10, а офисный - 1.6
sattellite ( 2012-04-28 09:16:11 +0400 )редактироватьо. вот с этого надо было начинать. 1.10 меняем на 1.8 и ждем пока все в 1.10 поправят(полгода)
meral ( 2012-04-28 15:19:57 +0400 )редактироватьЗадан: 2012-04-27 17:10:15 +0400
Просмотрен: 1,066 раз
Обновлен: Apr 27 '12
Проект компании "АТС Дизайн"
Asterisk® и Digium® являются зарегистрированными торговыми марками компании
Digium, Inc., США.
IP АТС Asterisk распространяется под лицензией
GNU GPL.
