Мегафон с его multifon-ом. Ну нету входящих.

[tol_iwan]

Подключил себе этот чудный мультифон. Устал искать решение самостоятельно, перерыл за два дня много топиков, решения не нашел, хотя все вроде стандартно как у всех. По крайней мере начало проблемы - "на софтфоне все работает, на asterisk нет".
Были косяки и с исходящими - решил. Потом не было вообще никакой реакции на входящие(не было INVITE), тоже решил - tcp в моем случае. А вот дальше не сдвинулся.
На firewall-е разрешены порты 5000-65535 tcp udp. iptables на asterisk выключен.

sip.conf такой:
в extension.conf указанный контекст с входящим номером существует.

PRIME_BBCODE_SPOILER_SHOW PRIME_BBCODE_SPOILER:

[general]
register => tcp://7920XXXXXXX@multifon.ru:PPPPPP:7920XXXXXXX@sbc.megafon.ru:5060/7920XXXXXXX
; Без tcp вообще не регистрируется
bindaddr=172.16.0.213:5060
tcpenable=yes
tcpbindaddr=172.16.0.213:5060

[7920XXXXXXX]
dtmfmode=inband
type=friend
host=sbc.megafon.ru
secret=PPPPPP
defaultuser=7920XXXXXXX
fromuser=7920XXXXXXX
fromdomain=multifon.ru
context=incoming_calls_megafon
nat=force_rport,comedia
directmedia=no
insecure=invite

Исходящие работают, входящие отбрасываются:
No matching peer for '7905YYYYYYY' from '193.201.229.35:16077'
SIP/2.0 401 Unauthorized
Авторизации на транке быть не должно(ну или это я так считаю)
7905YYYYYYY - с него звонок
172.16.0.213 - Asterisk
Вот sip set debug ip 193.201.229.35:

PRIME_BBCODE_SPOILER_SHOW PRIME_BBCODE_SPOILER:

<--- SIP read from TCP:193.201.229.35:16077 --->
INVITE sip:7920XXXXXXX@172.16.0.213:5060;transport=TCP SIP/2.0
Via: SIP/2.0/TCP 193.201.229.35:5060;branch=z9hG4bKacgjv900905g3onko270.1
Max-Forwards: 68
User-Agent: multifon.ru
Supported: 100rel,path,replaces,tdialog
Expires: 300
Content-Type: application/sdp
Content-Length: 295
From: sip:7905YYYYYYY@multifon.ru;tag=FAC3324631353641F6D0C000
To: sip:7920XXXXXXX@multifon.ru:5060
P-Asserted-Identity: sip:7905YYYYYYY@10.190.35.17:5060
Allow: PRACK,INVITE,BYE,REGISTER,ACK,OPTIONS,CANCEL,SUBSCRIBE,NOTIFY,INFO,REFER
Call-ID: 020597C8D28140000035B3AD@SFESIP3-id1-ext
CSeq: 1 INVITE
Contact: <sip:7905YYYYYYY@193.201.229.35:5060;transport=tcp>

v=0
o=Dialogic_SDP 142803515 0 IN IP4 193.201.229.35
s=Dialogic-SIP
c=IN IP4 193.201.229.35
t=0 0
m=audio 48926 RTP/AVP 8 0 18 4
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:4 G723/8000
a=fmtp:4 bitrate=6.3
a=silenceSupp:off - - - -
<------------->
--- (15 headers 13 lines) ---
Sending to 193.201.229.35:5060 (no NAT)
Sending to 193.201.229.35:5060 (no NAT)
Using INVITE request as basis request - 020597C8D28140000035B3AD@SFESIP3-id1-ext
No matching peer for '7905YYYYYYY' from '193.201.229.35:16077'

<--- Reliably Transmitting (no NAT) to 193.201.229.35:5060 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/TCP 193.201.229.35:5060;branch=z9hG4bKacgjv900905g3onko270.1;received=193.201.229.35
From: sip:7905YYYYYYY@multifon.ru;tag=FAC3324631353641F6D0C000
To: sip:7920XXXXXXX@multifon.ru:5060;tag=as7a3382af
Call-ID: 020597C8D28140000035B3AD@SFESIP3-id1-ext
CSeq: 1 INVITE
Server: pronto
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="522ba8ff"
Content-Length: 0


<------------>
Scheduling destruction of SIP dialog '020597C8D28140000035B3AD@SFESIP3-id1-ext' in 32000 ms (Method: INVITE)

<--- SIP read from TCP:193.201.229.35:16077 --->
ACK sip:7920XXXXXXX@172.16.0.213:5060;transport=TCP SIP/2.0
Via: SIP/2.0/TCP 193.201.229.35:5060;branch=z9hG4bKacgjv900905g3onko270.1
CSeq: 1 ACK
Max-Forwards: 68
From: sip:7905YYYYYYY@multifon.ru;tag=FAC3324631353641F6D0C000
To: <sip:7920XXXXXXX@multifon.ru:5060>;tag=as7a3382af
Call-ID: 020597C8D28140000035B3AD@SFESIP3-id1-ext
Content-Length: 0

<------------->
--- (8 headers 0 lines) ---

<--- SIP read from TCP:193.201.229.35:16077 --->
INVITE sip:7920XXXXXXX@172.16.0.213:5060;transport=TCP SIP/2.0
Via: SIP/2.0/TCP 193.201.229.35:5060;branch=z9hG4bKjsbgs700a8c0mjvn7730.1
Max-Forwards: 68
User-Agent: multifon.ru
Supported: 100rel,path,replaces,tdialog
Expires: 300
Content-Type: application/sdp
Content-Length: 295
From: sip:7905YYYYYYY@multifon.ru;tag=7EDE324631353641FDD0C000
To: sip:7920XXXXXXX@multifon.ru:5060
P-Asserted-Identity: sip:7905YYYYYYY@10.190.35.17:5060
Allow: PRACK,INVITE,BYE,REGISTER,ACK,OPTIONS,CANCEL,SUBSCRIBE,NOTIFY,INFO,REFER
Call-ID: 020597C8D28140000035B3B2@SFESIP3-id1-ext
CSeq: 1 INVITE
Contact: <sip:7905YYYYYYY@193.201.229.35:5060;transport=tcp>

v=0
o=Dialogic_SDP 142803515 0 IN IP4 193.201.229.35
s=Dialogic-SIP
c=IN IP4 193.201.229.35
t=0 0
m=audio 34492 RTP/AVP 8 0 18 4
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:4 G723/8000
a=fmtp:4 bitrate=6.3
a=silenceSupp:off - - - -
<------------->
--- (15 headers 13 lines) ---
Sending to 193.201.229.35:5060 (no NAT)
Sending to 193.201.229.35:5060 (no NAT)
Using INVITE request as basis request - 020597C8D28140000035B3B2@SFESIP3-id1-ext
No matching peer for '7905YYYYYYY' from '193.201.229.35:16077'

<--- Reliably Transmitting (no NAT) to 193.201.229.35:5060 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/TCP 193.201.229.35:5060;branch=z9hG4bKjsbgs700a8c0mjvn7730.1;received=193.201.229.35
From: sip:7905YYYYYYY@multifon.ru;tag=7EDE324631353641FDD0C000
To: sip:7920XXXXXXX@multifon.ru:5060;tag=as437d9d0c
Call-ID: 020597C8D28140000035B3B2@SFESIP3-id1-ext
CSeq: 1 INVITE
Server: pronto
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="55652094"
Content-Length: 0


<------------>
Scheduling destruction of SIP dialog '020597C8D28140000035B3B2@SFESIP3-id1-ext' in 32000 ms (Method: INVITE)

<--- SIP read from TCP:193.201.229.35:16077 --->
ACK sip:7920XXXXXXX@172.16.0.213:5060;transport=TCP SIP/2.0
Via: SIP/2.0/TCP 193.201.229.35:5060;branch=z9hG4bKjsbgs700a8c0mjvn7730.1
CSeq: 1 ACK
Max-Forwards: 68
From: sip:7905YYYYYYY@multifon.ru;tag=7EDE324631353641FDD0C000
To: <sip:7920XXXXXXX@multifon.ru:5060>;tag=as437d9d0c
Call-ID: 020597C8D28140000035B3B2@SFESIP3-id1-ext
Content-Length: 0

Смущает еще, что в debug нет реального IP, через который Asterisk выходит в свет. Но вызов-то приходит.

Голова гудит уже. Кажется некоторые вещи начинаю по второму разу проверять/пробовать. Куда капнуть пока желание не кончилось Заранее спасибо за помощь.

P.S. Транки с sipnet и ростелеком работают нормально и проблем особых не было.

P.S.S. ded и другие - честно пытался решить проблему без обращения на форум

[Paguk]

мои настройки для мультифона.
Входящие исходящие нормально приходят:
register => tcp://7937XXXXXXX@multifon.ru:мойпароль:7937XXXXXXX@sbc.megafon.ru/7937XXXXXXX

username=7937XXXXXXX
type=peer
transport=tcp
secret=мойпароль
qualify=yes
nat=yes
insecure=invite,port
host=sbc.megafon.ru
fromuser=7937XXXXXXX
fromdomain=multifon.ru
dtmfmode=inband
disallow=all
context=мойконтекст
allow=alaw,ulaw

[awsswa]

У него нету входящего маршрута, только транк

[tol_iwan]

Пробовал я и такую конфигурацию...

[tol_iwan]

У него нету входящего маршрута, только транк

а что подразумевается под входящим маршрутом?
register => tcp://7920XXXXXXX@multifon.ru:PPPPPP:7920XXXXXXX@sbc.megafon.ru:5060/7920XXXXXXX
7920XXXXXXX - это же callbackextention, т.е. на него в контексте [incoming_calls_megafon](в моем случае) и идут входящие(должны идти), как я понимаю.

[tol_iwan]

за рабочий конфиг спасибо.
transport=tcp в транке помогло - вызовы ходят в обе стороны.
Я ставил этот параметр видимо совместно с callbackextention=7920XXXXXXX, убирая при этом строку регистрации. Но тогда при sip reload:
ERROR[12688]: chan_sip.c:5968 create_addr_from_peer: 'UDP' is not a valid transport for '79208466306'. we only use 'TCP'! ending call.
WARNING[12688]: chan_sip.c:15310 transmit_register: Probably a DNS error for registration to 79208466306@sbc.megafon.ru, trying REGISTER again (after 20 seconds)
почему он ругается на UDP, если прописан TCP? Понимаю, что это не с конфига берется, но откуда тогда?

Как заставить работать без строки регистрации с параметром callbackextention?

[virus_net]

No matching peer for '7905YYYYYYY' from '193.201.229.35:16077'
SIP/2.0 401 Unauthorized

Это говорит о двух вещах:

• 1. В соответствии с allowguest=no в sip.conf Aster пытается авторизовать этот вызов
  2. Пир в sip.conf не найден и судя по выложенному кофигу это реально так и есть

Не найден потому что не попадает под [7920XXXXXXX]
Asterisk sip insecure

Считаю что лучше разделить IN и OUT на два пира type=peer, а не один с type=friend

PRIME_BBCODE_SPOILER_SHOW PRIME_BBCODE_SPOILER:

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

register => 79261112233@multifon.ru:password:79261112233@sbc.megafon.ru/79261112233

[multifon-out]
type=peer
username=79261112233
callerid=79261112233
secret=password
fromdomain=multifon.ru
fromuser=79261112233
host=193.201.229.35
dtmfmode=inband
transport=tcp
insecure=invite
disallow=all
allow = ulaw
canreinvite=no

[79261112233]
context=мойконтекст
type=peer
host=193.201.229.35
dtmfmode=inband
insecure=invite
disallow=all
allow = ulaw
canreinvite=no

[Paguk]

у меня только на приём используется.

[tol_iwan]

Блин - из головы вылетело, что peer заменял на friend.
А почему тогда при проставленном transport=tcp вызов пришел? Нашел же куда. И еще одно - убрал сейчас transport=tcp, а результат остался. Выгрузил/загрузил chan_sip все-равно работает. Для меня непонятное поведение.
Сейчас установлено:

PRIME_BBCODE_SPOILER_SHOW PRIME_BBCODE_SPOILER:

register => tcp://
7920XXXXXXX@multifon.ru:PPPPPP:7920XXXXXXX@sbc.megafon.ru:5060/7920XXXXXXX

[7920XXXXXXX]
dtmfmode=inband
type=peer
host=sbc.megafon.ru
secret=PPPPPP
defaultuser=7920XXXXXXX
fromuser=7920XXXXXXX
fromdomain=multifon.ru
context=incoming_calls_megafon
nat=force_rport,comedia
directmedia=no
insecure=invite,port
;callbackextension=7920XXXXXXX

и работает. Причем работало и с type=friend. Не понимаю как влияет добавление/удаление transport=tcp. Есть шанс, что опять отвалится?
И все же как заставить работать без строки регистрации? Ростелеком без нее работает: callbackextension= достаточно.
Предыдущая ошибка отпала про UDP/TCP после смены type=peer. Но без строки регистрации входящих нет, даже в sip debug пустой.

у меня только на приём используется.

У меня основная задача как раз на выход, но:
1. Полюбому кто-то перезвонит.2
2. Использую, не использую - работать должно.

[tol_iwan]

Считаю что лучше разделить IN и OUT на два пира type=peer, а не один с type=friend

А почему не один type=peer?