Элтекс

Почему не подменяется номер при безусл. переадресации?
Номер А звонит на номер Б(на номере Б установлена переадресация на сотовый номер С), получаем, что не подменяется номер А на номер Б при переадресации, в результате получаем неверную тарификацию. Как это можно исправить?

а моежете tcpdump прислать на techsupp@eltex.nsk.ru?
вообще при переадресации ТАУ отправляет сообщение 302, а билинг и т.п. выставляет сервер, я не думаю что на ТАУ проблема.. хотя может быть всякое.

подтверждаю, номер не заменяется
при переадресации дается 302, где в поле FROM стоит исходный номер А

будет ли корректным ставить там номер B - это вопрос, но очень хочется такую опцию иметь.
потому что биллинг циски например выдает исходящий вызов с номера А на тот номер на который стояла переадресация.
Обсчитать это без ухищрений сложно, да и в ряде случаев вызов такой не пройдет (если например проверяется номер А в переадресованном вызове).

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

давайте вместе пинать ELTEX
им галчку сделать - 15минут работы. но торговаться будут, как будто корову покупают - до последнего.

c TAU32(+SMG1016) аналогичная проблема (правдв там дается REDIRPDN, на который городская станция плюет ).

Ответ - так некорректно.

Давайте пинать тогда тех кто пишет RFC для SIP,
Внутри далога нельзя менять from и to поля, иначе тот же астерис откинет такое сообщение 302.
Если интерсно можете попробовать при помощи программки генерации SIP сообщений SIPP, сделать запрашиваемый Вами сценарий,
либо если есть другие шлюзы покажите что там именно так работает,
пока ответ нет,

> c TAU32(+SMG1016) аналогичная проблема (правдв там дается REDIRPDN, на который городская станция плюет )
ну и зря что плюет )
кстати SMG в таком случае корректно выставит билинг,
я, честно говоря, немного удивлен что циска этого не умеет, или может это дело настройки?

Женя писал(а):Давайте пинать тогда тех кто пишет RFC для SIP,
Внутри далога нельзя менять from и to поля, иначе тот же астерис откинет такое сообщение 302.

Вообще я подозревал такой результат. Только не знал как оперативно проверить.

Да не сочтут меня поборником циски, но проверять стандарты kexit по ней ну можно по какой нибудь Definity
а по asteriskу - это както вот странно проверять стандарты. Он конечно стал куда лучше, чем в ранних версиях, но сертификация никаких по прежнему вроде не имеет. По крайней мере в нашей стране в исходном виде.+
И если на циске работает (что вообще говоря вопрос), то галочка "подменять номер A при переадрсации" имела бы право на существование не смотря на RFC, Вам не кажется?

Женя писал(а):я, честно говоря, немного удивлен что циска этого не умеет, или может это дело настройки?

ну биллинг то несертифицированный и не родной цисковский. ну какой уж есть. В radius циска кидает много чего. Используется не все, возможно можно чтото гдето настроить. Поищу.
Но проблема то не только в биллинге. Часто провайдер проверяет соответствие исходящего CgPN выданному интервалу нумирации.
И это правильно - нефига давать подставлять левые CgPN.
Но переадресация в этом случае требует обязательной подмены номера A на номер B исходного вызова, иначе вызов просто не пройдет.

Опять же SMG (насколько я понимаю) не дает фильтровать исходящие вызовы по RedirPN (только по CgPN), что не дает возможности проверять корректность CgPN, приходящего от клиента если используется переадресация.
Или я не прав?

а билинг с циской по радиусу общаются?

> Опять же SMG (насколько я понимаю) не дает фильтровать исходящие вызовы по RedirPN (только по CgPN), что не дает возможности проверять корректность CgPN, приходящего от клиента если используется переадресация.
Или я не прав?

не понял вопрос.. что значит не дает возможности фильтровать?

Провел пару тестов.
В CDR * пишет при безусловной переадресации всегда номер А и номер С.
В CDR SMG пишет при безусловной переадресации:



- причем вместо 2748990 должен быть номер 2745755. Почему и откуда берется номер 2748990 непонятно.

В трассе пишет в конце следующее:

09:54:59.183662 [INFO] SIP. TX. Callref 0059. RLC-Release_Complete
[No optional params]
09:54:59.184396 [INFO] Port SIPT:0059. Process modifiers for CDR. ModTable: in [255:255], out [255:255]
09:54:59.184465 [INFO] Port SIPT:0059. Search Modifier at 'incoming CDR' for 'calling'. ModTable[255] Num <2745736> len [7].
09:54:59.184914 [INFO] Port SIPT:0059. Search Modifier at 'incoming CDR' for 'calling'. Result: modifier [-5]
09:54:59.184973 [INFO] Port SIPT:0059. Search Modifier at 'incoming CDR' for 'called'. ModTable[255] Num <89202969717> len [11].
09:54:59.185396 [INFO] Port SIPT:0059. Destroy Conn[102c].
09:54:59.185734 [INFO] Port SIPT:0059. Search Modifier at 'incoming CDR' for 'called'. Result: modifier [-5]
09:54:59.185804 [INFO] Port SIPT:0059. Search Modifier at 'outgoing CDR' for 'calling'. ModTable[255] Num <2745736> len [7].
09:54:59.186251 [INFO] Port SIPT:0059. Search Modifier at 'outgoing CDR' for 'calling'. Result: modifier [-5]
09:54:59.186311 [INFO] Port SIPT:0059. Search Modifier at 'outgoing CDR' for 'called'. ModTable[255] Num <89202969717> len [11].
09:54:59.186771 [INFO] Port SIPT:0059. Search Modifier at 'outgoing CDR' for 'called'. Result: modifier [-5]
09:54:59.186847 [INFO] Port SIPT:0059. Process modifiers for CDR. Redir and Origin. ModTable: in [255:255], out [255:255]
09:54:59.186909 [INFO] Port SIPT:0059. Search Modifier at 'incoming CDR' for 'calling'. ModTable[255] Num <> len [0]
09:54:59.187395 [INFO] Port SIPT:0059. Search Modifier at 'incoming CDR' for 'calling'. Result: modifier [-5]
09:54:59.187458 [INFO] Port SIPT:0059. Search Modifier at 'outgoing CDR' for 'calling'. ModTable[255] Num <2748990> len [7].
09:54:59.187903 [INFO] Port SIPT:0059. Search Modifier at 'outgoing CDR' for 'calling'. Result: modifier [-5]
09:54:59.187977 [INFO] Port SIPT:0059. CDR:
sign: ;
connect: 2014-04-03 09:54:59;
duration: 0;
disccode: 16;
discinfo: user called, but no-answer;
incoming: 192.168.xxx.x;trunk-SIP;TrunkGroupAsterisk;
calling: none;2748990;
outgoing: 0.0.0.0;trunk-Q931;TrunkGroup01;
called: 89202969717;89202969717;
setup: 2014-04-03 09:54:50;
disconn: 2014-04-03 09:54:59;
redir-mark: redirecting;
09:54:59.198531 [INFO] Q931. Line 00/00. Call 2DB6. RX 5
DUMP: 08.02.AD.B6.5A.
0x2DB6 (to orig), MSG=RELEASE COMPLETE:
---------------------------------
09:54:59.198640 [INFO] Q931. Line 00/00. Call 2DB6. Recv 'Release complete'
09:54:59.198703 [INFO] Port PRI:00:06. Release Complete, cause 'none', dcl '0', loc '0'
09:54:59.198768 [INFO] Port PRI:00:06. SormRelease in state 'Release'
09:54:59.198835 [INFO] Port PRI:00:06. Save CDR. enabled. [0x5]
09:54:59.198947 [INFO] Port PRI:00:06. Set state 'Ready'
09:54:59.199008 [INFO] Q931. Line 00/00. Call 2DB6. State 'Null'
SMG1016. Software Version: V.2.14.02.708. L. M. Build: Dec 4 2013 09:30:29
Log finished at: 9:55:00.873474

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

Я звонил с номера 2745736 на номер 2745755(на нем установлена безусловная переадресация на 89202969717). Трассу вышлю чуть позже.

и какое ПО стоит на SMG?
у меня вышло так:


470485 звонит на 100, который переадресует на 101
стоит флаг Сохранять Redirecting number?

Проблему локализовали,
она была в том, что на SMG приходил INVITE с полем
Diversion: "12345" <sip:12345@192.168.0.1>;reason=unconditional
Так вот проблема была в name-addr "12345", как только убрали его, все заработало.
На SMG обработка name-addr в Diversion будет поправлена в версии 15.2