Посылка SIP 183 Progress без предшествующего SIP 180 Ringing

[Lonely_Ghost]

Всем привет.

Есть схема: Asterisk 1.6.2.17.3 <-SIP-> Iskratel Si2000v5 <-SS7/ISUP-> TDM

Со стороны TDM приходит вызов - нет КПВ. Причина - в ответ на входящий IAM сишка шлет как полагается, инвайт астериску, астериск отвечает 100 Trying, 180 Ringing и 183 Session Progress, в результате Si2000 пересылает в ISUP ACM Alerting, и далее CPG Progress, что в корне неправильно, ибо Alerting означает что вызываемый абонент найден и вызывается. Естетственно что TDM АТС, получая Progress после Alerting - затыкается.

Но тут, так как вызов транзитный, то астериск должен был ответить только с 183 Session Progress c SDP, чтобы станция послала в сторону TDM ACM c Progress Indicator=Inband early media, что подразумевает собой проключение тракта в предответном и начало передачи раннего аудио (КПВ, музычка, или голосовое сообщение).

Как заставить Астериск отвечать на инвайт только 183 Progress без 180 ?

[Lonely_Ghost]

ddkprog, и? 180 все равно отсылается, пробовали уже играться с progressinband и prematuremedia.
и как протокол SIP работает, и как должен работать согласно рекомендациям IETF - тоже знаем, так что гугль тут не помощник.

[Lonely_Ghost]

изучили давно вдоль и поперек.
и пришли к выводу что ошибка в астериске. И ошбика заключается в отсылке лишнего 180 перед 183.
и сам искрател тут ни при чем. он передает что ему дает астериск.

я понимаю что si2000 в плане настройки SIP достаточно убогий, но аргумент - он сертифицирован для присоединения по ОКС-7 к Укртелекому.

[Lonely_Ghost]

гляди какие умные слова - багрепорт

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

Подумайте 100 раз, прежде чем в гугль кого-то посылать. Вопрос тут явно не из нубских.

[ded]

я понимаю что si2000 в плане настройки SIP достаточно убогий, но аргумент - он сертифицирован для присоединения по ОКС-7 к Укртелекому.

Я бы заострил внимание на сертифицирован для присоединения по ОКС-7. Потому что Укртелеком вряд ли интересовался сертификацией присоединения по SIP вообще и Искрател - в частности. Вы же именно о SIP сообщениях спорите?

[Lonely_Ghost]

ded, речь шла об интерконнекте между сетями операторов. Укртелеком отказался присоединять по SIP, только ОКС-7. Si2000 была выбрана в конфигурации SS7/ISUP-SIP медиашлюза. И вот в ходе эксплуатации и возникла трабла корректной передачи раннего аудио в предответном.

[ded]

Я весь топик прочитал с самого начала, эти пояснения лишь дублируют всё сказанное выше.
Предответное состояние описано в RFC 3960, 3261 http://tools.ietf.org/rfc/rfc3960.txt
Там про обязательность 183 ничего не сказано. А локальное полиси для 180 описано так:

For example, a POTS ("Plain Old Telephone
Service")-like SIP User Agent (UA) could implement the following
local policy:

1. Unless a 180 (Ringing) response is received, never generate
local ringing.

2. If a 180 (Ringing) has been received but there are no incoming
media packets, generate local ringing.

3. If a 180 (Ringing) has been received and there are incoming
media packets, play them and do not generate local ringing.

Note that a 180 (Ringing) response means that the callee is
being alerted, and a UAS should send such a response if the
callee is being alerted, regardless of the status of the early
media session.

И разбираются разные модели поведения для Gateway и для Application Server. Хрен знает кем выступает Искрател в этой связке.
А для 183 посылать SDP не обязательно.

21.1.5 183 Session Progress

The 183 (Session Progress) response is used to convey information
about the progress of the call that is not otherwise classified. The
Reason-Phrase, header fields, or message body MAY be used to convey
more details about the call progress.

А в Астериске нет поддержки корректной передачи сообщений ISUP в SIP и обратно (SIP-T, SIP-I)
И он не транзитный софтсвич (4-го класса), коим предписано такое поведение, а 5-го.


А может всё это бред и актуально изучать RFC 5009 http://www.armware.dk/RFC/rfc/rfc5009.html

[ded]

Щас Lonely_Ghost нас будет распинать...
Потом обжимать по 5-й категории.

[tma]

Мы тут с ddkprog уже разбирали ситуацию с 180 и 183 (проблема была в другом, но варианты разобрали по полной)...
Я тогда уже писал, что asterisk получив 180 сам генерирует 183 (Quintum шлет 180 с SDP без 183):

Session Progress добавляет уже сам asterisk...
Причем вырезает из Ringing SDP и вставляет его в Session Progress..

Для конечных устройств подходит.
asterisk это все-таки PBX. Полезайте в исходники и меняйте поведение, если нет стандартного решения.

P.S. Я не разбирался можно ли отключить подобное поведение в asterisk'е, т.к. мне это не нужно было...

[gofer_k]

В плане asterisk я конечно новичёк, но имеется очень большой опыт работы с телефонными станциями различных производителей отправка сначала 180 а потом 183 это нормальное явление и насколько я понимаю как бы так оно и должно быть.Буквально на днях стыковал АТС Samsung на которой в принципе можно сделать чтобы отправлялось сразу 183 с оператором ТТК по sip,так одним из требований оператора было как раз чтобы сначала приходил 180 .Да и от оператора я не раз замечал такую же картину особенно при звонке по межгороду сначала 180 затем 183.
Так что наверно все таки дело было не в бобине.