Нет голосового сообщения если телефон выключен

Question

Столкнулся со следующей ситуацией при подключении SIP номеров от одного из операторов. Астериск 1.6.2.16.1. В качестве телефонов - Zoiper. Кодек везде - alaw. Проблема в следующем. Допустим я отключаю свой сотовый, и при звонке на него логично получить сообщение о том что он выключен или находится вне зоны действия сети, после чего предлагается оставить голосовое сообщение на почту. В действительности, вместо приветствия о недоступности абонента я слышу "тишину", голос появляется только когда начинается приветствие голосовой почты, соответственно и тарификация начинается с этого момента. Дебаг в этом случае показывает "SIP/2.0 180 Ringing", тогда как у других операторов "SIP/2.0 183 Session Progress" и все слышно, на Zoiper даже статус вызова early media. Вопрос, как заставить Астериск воспроизводить начальное сообщение о недоступности абонента в таком случае? И как это должен обрабатывать оператор и выдавать мне, "SIP/2.0 180 Ringing" или "SIP/2.0 183 Session Progress", есть ли четкий регламент? Играл с "progressinband" и "prematuremedia", результата не принесло.

Answer 1

Астериск обычно в ответ на INVITE при progressinband=yes и prematuremedia=no шлет 180 Ringing, и потом уже 183 Progress, и некоторые софтоны, в частности тот же zoiper не проключают медиа при полученном 180 перед 183.

Попробуйте перед Dial вставить в диалплан

exten => bla-bla,1,Progress

Дабы от Астериска приходил сразу 183 Progress без предшествующего 180 Ringing.

Безрезультатно. Есть и хардфон, с него аналогично Ecuador ( 2011-02-03 10:21:08 +0400 )редактировать

Answer 2

0

<--- SIP read from UDP:10.101.64.25:5060 ---> 
SIP/2.0 180 Ringing 

<--- SIP read from UDP:10.101.64.25:5060 ---> 
SIP/2.0 183 Session Progress

Вот-с. Из дебага видим что от оператора пришел Progress, но где SDP??? Не вижу вообще Content-Type: application/sdp. Естественно, что будет тишина, ибо проключать медиа там незачем - нечего ловить. Пинайте оператора, спросите его - где SDP?

ссылка удалить спам редактировать

ответил 2011-02-03 10:40:21 +0400

mistral

370 ● 2 ● 5 ● 19

обновил 2011-02-03 10:43:07 +0400

Comments

Ты прав. Сравнил с нормальным звонком, там все присутствует. Нашел документ http://tools.ietf.org/id/draft-ietf-sip-183-00.txt, пункт 5.7.1.5, написано что SDP должен быть, но не обязательно для one way voice path. Значит ли это, что оператор должен соответствовать этим требованиям, и могу ли я ссылаться на этот документ доказывая свою правоту, что проблема не на моей стороне? Ecuador ( 2011-02-03 13:39:27 +0400 )редактировать

Ну, во-первых, как ты заметил - этот документ еще draft, т.е. ошибок в нем еще много, и он еще будет дорабатываться, поэтому для оператора он - не аргумент. Хотя бы потому что передача SIP 183 Progress без SDP сама по себе бессмысленна, ибо односторонний голосовой тракт просто не проключится, и ловить будет нечего. Во-вторых - у любого нормального SIP-оператора стык с сетью GSM обычно происходит по SS7/ISUP, следовательно, видим следующую картину - от тебя инвайт, оператор пересылает на SIP/ISUP MGW, и на GSM уже идет ISUP IAM, на что GSM-оператор отвечает ACM и иногда CPG, со включенным Progress indicator (PI=8), и Backward Indicator = Inband Early Media, который MGW и преобразует в SIP 183 Progress c SDP. Asterisk его получает, проключает тракт и пересылает его тебе (софтфону, хардфону etc.), в свою очередь ты проключаешь тракт и ловишь односторонний входящий RTP. Все понятно? А в твоем случае, т.к. SDP в Progress нету - то это уже кривые руки спецов оператора. mistral ( 2011-02-04 06:54:21 +0400 )редактировать

В этом документе глянь внимательнее п. 5.16.10, там описан процесс установки исходящего соединения с PSTN. Можешь спецов оператора ткнуть туда носом. mistral ( 2011-02-04 07:13:29 +0400 )редактировать

Ты прав, у УралСвязьИнформа и Эр-Телекома все именно так как в п.5.16.10. Специалист утверждает что ничего они не нарушают, и ссылается на http://www.vef-kvant.ru/sip.htm, 3.6.4 пункт. Могу выложить сюда, что мне ответил IgorG на этот вопрос, по почте, думаю многим будет интересно. На самом деле tcpdump показывает, что RTP на Астериск приходит, но подключить он его не может. Ecuador ( 2011-02-04 15:16:36 +0400 )редактировать

Выкладывай, если Игорь не против :) И RTP приходит, но после SIP/2.0 181 Call Is Being Forwarded. И что? Это сообщение не дает никому указания ни на генерацию КПВ, ни на передачу какой либо медиа-инфы в предответном состоянии, лишь указывает что прокси-сервер переслал вызов дальше, другому серверу, который, как видим, присылает 180 Ringing, и потом уже 183 Progress - это ИМХО неправильно (и зачем кстати в 181 нужен SDP - непонятно). Вы в Wireshark слушали этот RTP в дампе? есть голосовое соообщение от мобильщика в нем? А Гольдштейна пусть суппорт сам почитает внимательно, у меня эта книжка в бумажном варианте есть, так вот - глава 13, п.13.3.1, внимательно изучить рис. 13.9, и трейс под ним, где видно что после того как с ISUP в ответ на IAM приходит ACM, в SIP шлюз отдает уже сразу же - SIP 183 Progress, и ОБЯЗАТЕЛЬНО с SDP в теле сообщения;-) Никакого SIP 180 Ringing перед ним быть при этом не должно :) mistral ( 2011-02-04 17:40:08 +0400 )редактировать

Да, в WireSharke, сообщение есть, от оператора до моего сервера. К сожалению у меня этой книги нет, но такими темпами она скоро появится, так как некоторые вещи не очень понятны и приходится сравнивать, как та или иная ситуация отрабатывается на разных операторах. Ecuador ( 2011-02-04 18:33:16 +0400 )редактировать

Вот ответ уважаемого IgorG. Суть в том, что платформа синтеры при переадресации на автоответчик отправляет сообщение 181 Call Forwarded и в нем указывает SDP, это единственное отличие от обычного вызова. Астериском заголовок ответ 181 рассматривается так же как и 183. 183 без SDP рассматривается как 180 (тут и кроется ошибка астериска). Логика астериска: 1. При получении 183 UAS проигрывает какое-то сообщение, его нужно проиграть абоненту - читаем SDP, переходим с состояние передачи раннего аудио. 2. Получаем 180 без SDP, нужно переключиться в режим передачи КПВ. Так как нет SDP то КПВ должны генерировать мы. Ошибка Астериска: Не генерируется КПВ. Как правильно: Правильно было бы проверить, а продолжает ли передаваться RTP? (но это сложно сделать на мой взгляд). 3. Получаем 183 без SDP что трактуется как 180. Соответственно ничего не поменялось. На мой взгляд правильнее было бы проверить наличие RTP по прошлому SDP из 181. Это сделать на первый взгляд возможно. Ecuador ( 2011-02-04 18:38:03 +0400 )редактировать

Ну а я не вижу смысла слать 181 Call Forwarded, еще и с SDP, если достаточно для проигрывания сообщения в предответном состоянии послать 183 Progress c SDP. Нету логики в переадресации на информатор таким сообщением. А вообще - при 180 КПВ должен генерировать не Астериск, а UAC, Т.е. софтфон :) mistral ( 2011-02-04 19:14:15 +0400 )редактировать

Answer 3

0

Если я правильно понял, то надо проигрывать сообщение о недоступности пользователя, когда его IP телефон выключен. Это Playback without answer.

CLI> core show application playback

ссылка удалить спам редактировать

ответил 2011-02-03 03:10:04 +0400

litnimax
1453 ● 11 ● 8 ● 29
http://www.pbxware.ru/

Comments

Может я не правильно истолковал проблему, но в качестве вызываемого абонента выступает внешний абонент, в данном случае сотовый, и сообщение мне должен проиграть оператор этого абонента. То что вы предлагаете, это для случая когда я сам отслеживаю DIALSTATUS. Ecuador ( 2011-02-03 08:35:49 +0400 )редактировать

Answer 4

0

вы это никак не пофиксите. это должен сделать оператор. елси оператор поддерживает early media, он может послать 180+183 или 183, тут не сильно важно. но для того чтоб работало, надо чтоб пришел 183 с SDP частью. смотрите дебаг на сторону оператора. а вот елси 183 приходит, то смотрите в своем конфиге. в астериске 1.6 с этим вообще приколов дофига. надо искать комбинацию из progressinband=yes/no и (хз почему- но вот так жестко) еще prematuremedia=yes/no

ссылка удалить спам редактировать

ответил 2011-02-02 23:37:25 +0400

meral

23347 ● 24 ● 20 ● 177
http://pro-sip.net/

Comments

Оператор говорит что поддерживает early media, и проблема наблюдается только у меня. Какой должен прийти 183 с SDP частью, можно поподробнее? На самом деле 183 приходит, но через какое то время после 180, и после этого обрубает Ecuador ( 2011-02-03 08:43:53 +0400 )редактировать

проверте так. сделайте сначала Answer ы диалплане, а потом позвоните. таким образом вы исключите проблемы между астериском и софтфоном. сдп часть приходит точно такая же как при инвайте(ответе абонента) meral ( 2011-02-04 14:45:09 +0400 )редактировать

Answer 5

Вот кстати дебаг. 79082602633 - куда звоню. 3422017755 - откуда звоню. 10.101.64.25 - адрес сип сервера оператора. 10.105.66.10 - мой адрес.

INVITE sip:79082602633@10.101.64.25:5060 SIP/2.0
Via: SIP/2.0/UDP 10.105.66.10:5060;branch=z9hG4bK733b9e35;rport
Max-Forwards: 70
From: "50" sip:3422017755@10.105.66.10;tag=as4794b799
To: sip:79082602633@10.101.64.25:5060
Contact: sip:3422017755@10.105.66.10
Call-ID: 576d961a6e56e968227b8fa51a6e2240@10.105.66.10
CSeq: 102 INVITE
User-Agent: Asterisk PBX 1.6.2.16.1
Date: Thu, 03 Feb 2011 05:29:58 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 239

v=0
o=root 2059205215 2059205215 IN IP4 10.105.66.10
s=Asterisk PBX 1.6.2.16.1
c=IN IP4 10.105.66.10
t=0 0
m=audio 14764 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv

-- Called Sintera/79082602633

<--- SIP read from UDP:10.101.64.25:5060 --->
SIP/2.0 100 Trying
From: "50" sip:3422017755@10.105.66.10;tag=as4794b799
To: sip:79082602633@10.101.64.25:5060
Call-ID: 576d961a6e56e968227b8fa51a6e2240@10.105.66.10
CSeq: 102 INVITE
Via: SIP/2.0/UDP 10.105.66.10:5060;branch=z9hG4bK733b9e35;rport=5060
Content-Length: 0

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

<--- SIP read from UDP:10.101.64.25:5060 --->
SIP/2.0 181 Call Is Being Forwarded
From: "50" sip:3422017755@10.105.66.10;tag=as4794b799
To: sip:79082602633@10.101.64.25:5060;tag=695073d9-13c4-4d4a3d4b-1d7bc40e-766d7f02
Call-ID: 576d961a6e56e968227b8fa51a6e2240@10.105.66.10
CSeq: 102 INVITE
P-Asserted-Identity: sip:9028300008@10.105.1.33:5060;user=phone;transport=udp
Via: SIP/2.0/UDP 10.105.66.10:5060;branch=z9hG4bK733b9e35;rport=5060
Contact: sip:79082602633@10.101.64.25:5060;transport=udp
Content-Type: application/sdp
Content-Length: 114

v=0
o=- 537545762 0 IN IP4 10.101.64.25
s=-
c=IN IP4 10.101.64.25
t=0 0
m=audio 24280 RTP/AVP 8
a=ptime:20

<-------------> --- (10 headers 7 lines) ---
Found RTP audio format 8
Capabilities: us - 0x8 (alaw), peer - audio=0x8 (alaw)/video=0x0 (nothing)/text=0x0 (nothing), combined - 0x8 (alaw)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x0 (nothing), combined - 0x0 (nothing)
Peer audio RTP is at port 10.101.64.25:24280
-- SIP/Sintera-0000017b is making progress passing it to IAX2/50-1283

<--- SIP read from UDP:10.101.64.25:5060 --->
SIP/2.0 180 Ringing
From: "50" sip:3422017755@10.105.66.10;tag=as4794b799
To: sip:79082602633@10.101.64.25:5060;tag=695073d9-13c4-4d4a3d4b-1d7bc40e-766d7f02
Call-ID: 576d961a6e56e968227b8fa51a6e2240@10.105.66.10
CSeq: 102 INVITE
Via: SIP/2.0/UDP 10.105.66.10:5060;branch=z9hG4bK733b9e35;rport=5060
Contact: sip:79082602633@10.101.64.25:5060;transport=udp
Content-Length: 0

<------------->
--- (8 headers 0 lines) ---
-- SIP/Sintera-0000017b is ringing

<--- SIP read from UDP:10.101.64.25:5060 --->
SIP/2.0 183 Session Progress
From: "50" sip:3422017755@10.105.66.10;tag=as4794b799
To: sip:79082602633@10.101.64.25:5060;tag=695073d9-13c4-4d4a3d4b-1d7bc40e-766d7f02
Call-ID: 576d961a6e56e968227b8fa51a6e2240@10.105.66.10
CSeq: 102 INVITE
Via: SIP/2.0/UDP 10.105.66.10:5060;branch=z9hG4bK733b9e35;rport=5060
Contact: sip:79082602633@10.101.64.25:5060;transport=udp
Content-Length: 0

<------------->
--- (8 headers 0 lines) ---
-- SIP/Sintera-0000017b is ringing

<--- SIP read from UDP:10.101.64.25:5060 --->
SIP/2.0 487 Transaction Cancelled
From: "50" sip:3422017755@10.105.66.10;tag=as4794b799
To: sip:79082602633@10.101.64.25:5060;tag=695073d9-13c4-4d4a3d4b-1d7bc40e-766d7f02
Call-ID: 576d961a6e56e968227b8fa51a6e2240@10.105.66.10
CSeq: 102 INVITE
Reason: Q.850 ;text="Normal call clearing";cause=16
Via: SIP/2.0/UDP 10.105.66.10:5060;branch=z9hG4bK733b9e35;rport=5060
Content-Length: 0

<------------->
--- (8 headers 0 lines) ---
Transmitting (no NAT) to 10.101.64.25:5060:
ACK sip:79082602633@10.101.64.25:5060 SIP/2.0
Via: SIP/2.0/UDP 10.105.66.10:5060;branch=z9hG4bK733b9e35;rport
Max-Forwards: 70
From: "50" sip:3422017755@10.105.66.10;tag=as4794b799
To: sip:79082602633@10.101.64.25:5060;tag=695073d9-13c4-4d4a3d4b-1d7bc40e-766d7f02
Contact: sip:3422017755@10.105.66.10
Call-ID: 576d961a6e56e968227b8fa51a6e2240@10.105.66.10
CSeq: 102 ACK
User-Agent: Asterisk PBX 1.6.2.16.1
Content-Length: 0

Answer 6

Добрый день, у меня похожая проблема. Поток E1 на шлюз Медиант 600, далее SIP транк на Asterisk. При звонке на мобильный или городской, вместо голосового сообщения о недоступности или блокировки вызываемого телефона, Asterisk генерит Ring(180), т.е. абонент на SIP телефоне слышит гудки, а не сообщение об отсутствии в сети или блокировки телефона. Может тоже кто нибудь, что-нибудь подскажет? С уважением, Николай

Answer 7

0

в команде Dial добавьте флаг R

ссылка удалить спам редактировать

ответил 2011-02-20 19:34:54 +0400

um2010
2056 ● 70 ● 13 ● 55

Answer 8

Поставить opensips вместе с mediaproxy. Там настроить правильное блокирование избыточных мессаг от прова и проксирование трафика уже на астер. Плюсом будет еще и защита извне от подбора аккаунтов абонентов. Еще заметил, что юзаете самый последний астер ветки 1.6.2, может дело в этом и стоит откатиться на что-либо стабильное.

Нет голосового сообщения если телефон выключен

8 Ответов

Comments

Comments

Comments

Comments

Ваш ответ

Закладки и информация

Статистика

Похожие вопросы: