Asterisk 1.8 игнорирует ACK?

[XBOCTATOE]

Добрый день. Имеется астер 1.8 и пристегнутый к нему NEC SL1000, пир с регистрацией, станция за натом. Проблема следующая: при включении авторизации вызовов (убираем insecure=port,invite) астер почему-то не воспринимает ACK от станции, делает 10 ретрансмитов и, ожидаемо, рвет соединение. Если insecure включен - то всё работает. Вопрос: что ему не нравится в ACK?

Чтобы не захламлять, иввайт уже с дайджестом

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

<--- SIP read from UDP:e.f.g.h:5060 --->
INVITE sip:8926*******@a.b.c.d SIP/2.0
From: "7495*******"<sip:7495*******@a.b.c.d>;tag=91A8324631353641000041C4
To: <sip:8926*******@a.b.c.d:5060>
Contact: <sip:7495*******@172.20.98.35:5060>
Content-Type: application/sdp
CSeq: 2 INVITE
Authorization: Digest username="7495*******",realm="asterisk",algorithm=MD5,nonce="685aa150",opaque="",uri="sip:8926*******@a.b.c.d",response="356571036e26a6b3ac66f9eb38f83142"
Allow: INVITE,ACK,BYE,CANCEL,PRACK,UPDATE
Supported: 100rel,timer
Expires: 180
Call-ID: 021004710A8140000000000D@172.20.98.35
Max-Forwards: 70
User-Agent: NEC-i SL Series 03.01
Via: SIP/2.0/UDP 172.20.98.35:5060;branch=z9hG4bK4A48CA2F8AA196DA
Content-Length: 300

v=0
o=- 0 0 IN IP4 172.20.98.35
s=T005
c=IN IP4 172.20.98.36
t=0 0
m=audio 10022 RTP/AVP 8 2 18 9 110
a=rtpmap:8 PCMA/8000
a=ptime:20
a=rtpmap:2 G726-32/8000
a=ptime:30
a=rtpmap:18 G729/8000
a=ptime:20
a=rtpmap:9 G722/8000
a=ptime:30
a=rtpmap:110 telephone-event/8000
a=fmtp:110 0-15
<------------->

Далее стандартные trying, ringing, call progress
И вот на этот ОК

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

<--- Reliably Transmitting (NAT) to e.f.g.h:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.20.98.35:5060;branch=z9hG4bK4A48CA2F8AA196DA;received=e.f.g.h;rport=5060
From: "7495*******"<sip:7495*******@a.b.c.d>;tag=91A8324631353641000041C4
To: <sip:8926*******@a.b.c.d:5060>;tag=as0deed44c
Call-ID: 021004710A8140000000000D@172.20.98.35
CSeq: 2 INVITE
Server: Asterisk PBX 1.8.20.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Contact: <sip:8926*******@a.b.c.d:5060>
Content-Type: application/sdp
Content-Length: 206

v=0
o=root 621531610 621531611 IN IP4 a.b.c.d
s=Asterisk PBX 1.8.20.0
c=IN IP4 a.b.c.d
t=0 0
m=audio 13426 RTP/AVP 8
a=rtpmap:8 PCMA/8000
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

<------------>

Мне приходит ACK, который почему-то не нравится астеру

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

<--- SIP read from UDP:e.f.g.h:5060 --->
ACK sip:8926*******@a.b.c.d:5060 SIP/2.0
CSeq: 2 ACK
To: <sip:8926*******@a.b.c.d:5060>;tag=as0deed44c
From: "7495*******"<sip:7495*******@a.b.c.d>;tag=91A8324631353641000041C4
Call-ID: 021004710A8140000000000D@172.20.98.35
Max-Forwards: 70
User-Agent: NEC-i SL Series 03.01
Via: SIP/2.0/UDP 172.20.98.35:5060;branch=z9hG4bKB52300503C5D743E
Content-Length: 0

<------------->

Ну и дальше ретрансмиты и всё заканчивается.
Есть примеры с другим UA, там в такой ситуации ACK отличается только наличием поля Contact. Но в RFC написано, что в ACK поле Contact не обязательно, если тело сообщения = 0. From, To, tags и Call-ID совпадают.

[sasa]

по rfc, invite транзакции закрываются либо по branchID в поле via
либо по callID если уже установлен диалог

Изучайте код chan_sip если ищете ошибки

А вообще переходите на новый астериск и pj_sip, старый chan_sip уже deprecated и не поддерживается дигиумом

[ded]

На примере диалога

видно, что после Trying & Session progress должен открыться RTP со стороны Астериска, на который уже прибежит ACK.

Ваш NEC имеет разные ИП адреса для сигнализации и для медиа?

o=- 0 0 IN IP4 172.20.98.35
c=IN IP4 172.20.98.36

Проблема осложняется тем, что у вас там оба устройства - Астериск и NEC - каждый за своим НАТом. И когда убираете insecure=port,invite, то соединение не устанавливается, потому что RTP прибегает с другим адресом/портом оригинатора.

Включить rtp set debug on - хоть что-то прибежит с аудиопорта?
Есть возможность снять дамп трафика с внешних ИП-адресов у обоих устройств?

[XBOCTATOE]

В том то и фишка, что с insecure все работает. Астер у меня не за натом, за натом только NEC. Более того, ртп поднимается и с выключенным insecure, после session progress. Только астер считает, что ACK не получил и рубит звонок после 6 секунд. Кстати, без insecure он также не воспринимает ОК от NEC-a в ответ на BYE. Также пытается его 10 раз послать. С другими железками или софтом этот пир также работает нормально. Просто уже реально интересно, кто виноват: астер или NEC

Забыл дописать: да, у NEC разные адреса для dsp платы и процессора с сигналлингом.

[ded]

В том то и фишка, что с insecure все работает.

Я так и написал.

А когда убираете insecure=port,invite, то соединение не устанавливается, потому что RTP прибегает с другим адресом/портом оригинатора.

Потому что разные адреса NEC для dsp платы и процессора с сигналлингом транслируются через одно НАТ устройство. Если бы Астериск и NEC были бы в одной подсети, то проблемы не было бы.
Вас это объяснение не удовлетворило?

Почему не нравится использование insecure=port,invite?

[Zavr2008]

ТС, а Вы не думали почему с insecure=port,invite работает?
Точнее почему в случае с авторизацией - нет (а ведь INVITE повторный идет следом уже для этого)..
Скорее всего дело в том устройстве что делает NAT там где стоит УАТС.. Смотреть SIP ALG и что он там творит в случае того что media с другого IP летит..
Как временное решение можно попробовать транспорт TCP поставить, тогда возможно этот костыль спасет.

Ну и Вы всегда можете решить вопрос кардинально - послать SIP фичи NEC далеко, поставить E1 шлюз и делать всё что захотите безболезненно.

[ded]

Zavr2008, там нет авторизации по дайджесту и повторного инвайта. Там медиа прибегает не с того порта, который фигурировал в инвайте, и поэтому игнорируется Астериском.
Пройдёт даже
insecure=port