да и проблема не во From, а в адресе с которого летит запрос

для адреса с которого прилетает есть пир. <--- SIP read from UDP:10.155.4.92:5060 —-> INVITE sip:74991247777@10.152.15.242:5060;user=phone SIP/2.0 Via: SIP/2.0/UDP 10.155.4.92:5060;branch=z9hG4bKi33vki00d88dve13n6s0.1 Call-ID: SDv3ap201-ba98c0d99368e2e35639e2d5d145a6d1-v3000i1 From: <sip:88126004014@10.79.47.196;user=phone;cpc-rus=1>;tag=SDv3ap201-qpynizzx-CC-29 To: <sip:74991247777@10.76.50.29;user=phone> CSeq: 1 INVITE Max-Forwards: 68 Contact: <sip:88126004014@10.155.4.92:5060;user=phone;transport=udp> Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,SUBSCRIBE,NOTIFY,UPDATE,MESSAGE,REFER User-Agent: Huawei SoftX3000 V300R010 Supported: 100rel Content-Length: 233 Content-Type: application/sdp v=0 o=- 1900907629 64181871 IN IP4 10.155.4.92 s=- c=IN IP4 10.155.4.92 t=0 0 m=audio 63972 RTP/AVP 8 18 100 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=rtpmap:100 telephone-event/8000 a=fmtp:100 0-15 a=fmtp:18 annexb=no <-------------> —- (13 headers 11 lines) —- Sending to 10.155.4.92:5060 (no NAT) Sending to 10.155.4.92:5060 (no NAT) Using INVITE request as basis request - SDv3ap201-ba98c0d99368e2e35639e2d5d145a6d1-v3000i1 [Dec 27 15:43:46] NOTICE[829][C-000000a5]: acl.c:748 ast_apply_acl: SIP Peer ACL: Rejecting '10.155.4.92' due to a failure to pass ACL '(BASELINE)' [Dec 27 15:43:46] NOTICE[829][C-000000a5]: chan_sip.c:25559 handle_request_invite: Failed to authenticate device <sip:88126004014@10.79.47.196;user=phone;cpc-rus=1>;tag=SDv3ap201-qpynizzx-CC-29

вот это <--- SIP read from UDP:10.155.4.92:5060 —-> откуда летит о чем и говорится ast_apply_acl: SIP Peer ACL: Rejecting '10.155.4.92' due to a failure to pass ACL '(BASELINE)'

для 10.155.4.92 енсть пир.

type=peer host=10.155.4.92 insecure=invite deny=0.0.0.0/0 permit=10.155.4.92/32

для 10.155.4.92 енсть пир.

Не верю (с) Станиславский

а если host dynamic и permit?

нет?

нет

dynamic только для регистрируемых на вас

Из методички:Формирование заголовка From Поле заголовка From содержит логический идентификатор инициатора со- общения, как правило, списочный адрес вызывающего пользователя. Так же, как поле To, оно содержит URI и, опционально, отображаемое имя (display name), что 32 Глава 2 удобно для вызываемого пользователя. Заголовок используется SIP-элементами для того, чтобы определить правила обработки, применимые к запросу (например, автоматическое отклонение вызова). Важно, чтобы URI в заголовке From не содер- жал IP-адреса или FQDN (Fully Qualified Domain Name) хоста, с которым работает UA, так как это не логические имена. Заголовок From предусматривает присутствие отображаемого имени (display name). Если данная информация отсутствует, UAC должен использовать отображаемое имя «Anonymous». Обычно поле заголовка From запросов, которые создает UA, заполняет- ся на основании значения, предварительно определенного пользователем или администратором локального домена. Если один UA используется несколькими пользователями, он может иметь переключаемые профили, которые содержат URI, соответствующие определенным пользователям. Получатели запросов могут аутентифицировать инициаторов запросов для того, чтобы убедиться, что они – те, кого представляют заголовки From этих запросов. Поле From должно содержать параметр «tag», созданный клиентом UA. Примеры: From: «Anton» <sips:anton@niits.ru> 9;tag=a48s From: sip:+79213434329@gateway.protei.ru;tag=887s From: Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8

Из методички:Формирование заголовка From Поле заголовка From содержит логический идентификатор инициатора со- общения, как правило, списочный адрес вызывающего пользователя. Так же, как поле To, оно содержит URI и, опционально, отображаемое имя (display name), что 32 Глава 2 удобно для вызываемого пользователя. Заголовок используется SIP-элементами для того, чтобы определить правила обработки, применимые к запросу (например, автоматическое отклонение вызова). Важно, чтобы URI в заголовке From не содер- жал IP-адреса или FQDN (Fully Qualified Domain Name) хоста, с которым работает UA, так как это не логические имена. Заголовок From предусматривает присутствие отображаемого имени (display name). Если данная информация отсутствует, UAC должен использовать отображаемое имя «Anonymous». Обычно поле заголовка From запросов, которые создает UA, заполняет- ся на основании значения, предварительно определенного пользователем или администратором локального домена. Если один UA используется несколькими пользователями, он может иметь переключаемые профили, которые содержат URI, соответствующие определенным пользователям. Получатели запросов могут аутентифицировать инициаторов запросов для того, чтобы убедиться, что они – те, кого представляют заголовки From этих запросов. Поле From должно содержать параметр «tag», созданный клиентом UA. Примеры: From: «Anton» <sips:anton@niits.ru> 9;tag=a48s From: sip:+79213434329@gateway.protei.ru;tag=887s From: Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8

очень похоже на перевод rfc, это я плохо гуглил или перевод никто не выкладывал?

Увы!Это единственный вменяемый справочник по сип на русском, Гольштейн есть такой, 2005 года 2014 переиздание.То что выложено в инете только 2-3 главы, полная книжка или на литресе за 300р в pdf или на бумаге.

Увы!Это единственный вменяемый справочник по сип на русском, Гольштейн есть такой, 2005 года 2014 переиздание.То что выложено в инете только 2-3 главы, полная книжка или на литресе за 300р в pdf или на бумаге.

спасибо за наводку, закажу в бумаге.

Ага, я тоже полистал и понял что надо иметь под рукой

Но их нет на бумаге-бесполезно.Есть возможность написать в институт они вроде рассылают, попробую после праздников

УДК 621.395 Г63 ББК 32.88 Б.С. Гольдштейн, А.А. Зарубин, В.В. Саморезов Протокол SIP: Справочник. – СПб.: БХВ-Петербург, 2014. – 456 с.: ил. ISBN 5-8206-0123-8 Приводятся сведения о принципах организации и функционирования протокола SIP (Session Initiation Protocol), широко используемого сегодня в IP-телефонии и являющегося наиболее вероятным кандидатом на ведущую роль в сетях связи следующего поколения NGN. Описываются сообщения SIP, процедуры управления соединениями в IP-сети и между сетями IP и ТфОП, процедуры аутентификации, защиты информации, обеспечения безопасности. Рассматриваются расширения SIP, обеспечивающие взаимодействие сети IP с телефонной сетью при создании и поддержке сеансов связи ТфОП-IP-ТфОП, ТфОП-IP и IP-ТфОП. Излагаются задачи преобразования сигнализации SIP при взаимодействии с дру- гими протоколами сетей NGN. Освещаются вопросы тестирования SIP и пути реализации на базе этого протокола ряда известных и новых инфокоммуникационных услуг. Справочник ISBN 5-8206-0123-8

http://niits.ru/public/order.php

Коллеги а в заголовке cpc-rus=1 некритично?Шлют всякие что попало

http://niits.ru/public/order.php

мне написали что со мной свяжутся...

Аналогично

2 или 3 недели написано.Ну ладно, классика же, куда спешить:)

Автор наверняка море баек знает из телекома, но он почти как Ленин :)

Внезапно. Мгтс покрутил свой хуавей и теперь в поле фром только их адрес и збс, робит...

SIP CPC-RUS – категория вызывающего абонента передается в параметре “cpc-rus” поля “From” в сигнальныхсообщенияхпротокола SIP/SIP-T

http://xa0t3k.me/files/mvts/Rtu-Mtt-1.5.3-100.-Admin-Guide-Rus.pdf

Нашел внезапно здесь

Система РТУ МТТ – комплексная система управления вызовами, сочетающая в себе функции гибкого программного коммутатора 4 класса (softswitch class 4) и пограничного контроллера соединений (session border controller). Основная задача Системы – концентрация и коммутация VoIP-потоков, обеспечение ихпередачи между сетями с разнородной сигнализацией (SIP, H.323 и ITU ISUP/ISUP-R)

РТУ МТТ - отличная вещь

Провайдерская штука?

Попробовать нереально?Вроде как SBC тоже есть функционал

ПОпробовать только если варез где найти

провадйерский транзитный коммутатор, да

Это же мера?

в пршлом да

живые есть?

првиет

есть

перепись ?

на коленке нахерачил такую дрянь для fxo шлюза

exten => _XXX,1,DIAL(LOCAL/${CALLERID(number):2},120,M(senddtmf,${EXTEN}#)) exten => _9XXXXXX,1,DIAL(LOCAL/${CALLERID(number):2},120,M(senddtmf1,${EXTEN:1}#)) exten => _9XXXXXXXXXXX,1,DIAL(LOCAL/${CALLERID(number):2},120,M(senddtmf1,${EXTEN:1}#)) [macro-senddtmf] exten => s,1,Set(DTMFSTR=${ARG1}) exten => s,n,Wait(0.5) exten => s,n,SendDTMF(${DTMFSTR},500,500) exten => s,n,Wait(0.5) [macro-senddtmf1] exten => s,1,Set(DTMFSTR=${ARG1}) exten => s,n,Wait(0.5) exten => s,n,SendDTMF(9,500,500) exten => s,n,Wait(2) exten => s,n,SendDTMF(${DTMFSTR},500,500) exten => s,n,Wait(1)

есть способ без макроса это сделать?

идеи типа DIAL(SIP/XXX,,D(XXX))

не пашут

как и www

может я с тупняка чего не понимаю

это здец что за шлюз такой, который не может набрать сам? Dial(SIP/XXX/${EXTEN:1})

fxo

и?

ну hotline причем тут

все с fxo тогут точно

что он сам будет набирать то?

hotline ни при чем

что сказали ему то и наберет

поднимается линия далее набираю нужный номер в fxo

d-link dvg

расскажи может я туп

я сними лет 7 не работал уж

по сути конвергенция аналога и цифры

на порту шлюза каждый порт внутренний номер

была такая схема не мной сделала порты на шлюзе зареганы на астере под XXX

ип телефоны с номерам NNXXX

где XXX совпадает, конечно, и у них была траба чтобы позвонить на внутренний номер аналоговый пользователь брал трубку набирал свой внутренний без префикса NN затем слышал гудок и набирал нужный номер

ко мне обратились убрать этот маразм... ну я накатал и понимаю что это костыль

дабы не чего не мудрить я не придумал не чего умнее как накатать макрос для эмуляции сего процесса...

то есть шлюз сможет выпускать в зависимости от внутреннго номера с нужного порта?

сам поднимать линию и набирать номер что на него пришел?

ERROR: S client not available

то что описано характерно для FXS <-> CO АТС вот после него надо иногда донабирать

чтоб через DISA или IVR пробиться

да тут ахтунг

FXO <-> внутренняя линия АТС требуется донабор только со стороны АТС со стороны VoIP шлюх набирает сам

по сути есть панас большой какой т0... есть удаленные места, берется jack панас кросируются в fxo шлюз получается на шлюзе на порту внутренний номер

ща...

смотри есть номер например 111 находится на панасе

если я звоню а астера чтобы выйти именно с нужного порта шлюза (это важно!) надо сначала поднять этот порт потом при поднятом порте набрать 111

если я сделаю группу они будут выходить с портов по кругу что нельзя

по сути если на шлюзе можно задать конфиг, что если пришло с такого то номера, поднимать такой то порт и звонить то да проблема решенна

http://lynks.ru/images/324.png

эти галки стоят?

ожидание коллера после поднятия

хз сейчас полезу гляну

я на шлюз не лазил

стоят

exten => _XXX,1,DIAL(SIP/${EXTEN}@ip_шлюза)

И7

и попробовать

я пойду с номера NNXXX

шлюз меня с какого порта плюнет?

как мне 9 эмулировать при этом способе

exten => _9XXX,1,DIAL(SIP/peer_любой_линии/${CALLERID(number):2}${EXTEN:1}) префиксы забить в шлюзе для каждой линии

ну вот

могем )

exten => _XXX,1,DIAL(SIP/${CALLERID(number):2}/${EXTEN},,)

вот так в общем пашет

осталось с 9 понять

это гораздо круче моего костыля

выше с 9 написал

нихера

там задержка тупа