История изменений [назад]

1. Устанавливаем TON и NPI Дело в том, что это 1 байт, в котором хранятся 2 величины. Таким образом, 0-15, TON - 0 (Unknown) , 16-31 - TON -1 (International), 32+ - TON - 2 (National) В моем случае TON - national (2) , NPI - E.164/E.163 (1) , Прибавляем к 32 1 и получаем

Set(REDIRECTING(from-num-plan,i)=33)

1. Причина переадресации. Вопрос творческий, но желательно все же, чтобы удаленная сеть не терялась. Ставим "нет ответа"

Set(REDIRECTING(reason,i)=2)

1. Самое сложное - установить Presentation. Необходимо получить величину Allowed, User provided, Verified. Значение этого байта для такой композиции должно быть 00100001 И тут начинается самое интересное. Попытка установить этот байт с помощью десятичной 33 проваливается. Мануалы говорят, что при не работает корректно с данной функцией. Вот что пишет про это pri.c

sr->redirecting.from.number.presentation = pres & (PRIPRESRESTRICTION | PRIPRESNUMBER_TYPE);

Чисто теоретически int 33 должна превращаться в нужный байт. Но этого по факту не происходит.
К великому сожалению, решение этой проблемы видится лишь в модификации исходного кода libpri. К слову, Presentaion для Caller id устанавливается в нужное значение, если равна 1.

1. Устанавливаем TON и NPI Дело в том, что это 1 байт, в котором хранятся 2 величины. Таким образом, 0-15, TON - 0 (Unknown) , 16-31 - TON -1 (International), 32+ - TON - 2 (National) В моем случае TON - national (2) , NPI - E.164/E.163 (1) , Прибавляем к 32 1 и получаем

Set(REDIRECTING(from-num-plan,i)=33)

1. Причина переадресации. Вопрос творческий, но желательно все же, чтобы удаленная сеть не терялась. Ставим "нет ответа"

Set(REDIRECTING(reason,i)=2)

1. Самое сложное - установить Presentation. Необходимо получить величину Allowed, User provided, Verified. Значение этого байта для такой композиции должно быть 00100001 И тут начинается самое интересное. Попытка установить этот байт с помощью десятичной 33 проваливается. Мануалы говорят, что при libpri не работает корректно с данной функцией. функцией (REDIRECTING(from-num-pres)). Вот что пишет про это pri.c

sr->redirecting.from.number.presentation = pres & (PRIPRESRESTRICTION | PRIPRESNUMBER_TYPE);

Чисто теоретически int 33 должна превращаться в нужный байт. Но этого по факту не происходит.
К великому сожалению, решение этой проблемы видится лишь в модификации исходного кода libpri. К слову, Presentaion для Caller id устанавливается в нужное значение, если равна 1.

1. -- Устанавливаем TON и NPI Дело в том, что это 1 байт, в котором хранятся 2 величины. Таким образом, 0-15, TON - 0 (Unknown) , 16-31 - TON -1 (International), 32+ - TON - 2 (National) В моем случае TON - national (2) , NPI - E.164/E.163 (1) , Прибавляем к 32 1 и получаем

Set(REDIRECTING(from-num-plan,i)=33)

1. -- Причина переадресации. Вопрос творческий, но желательно все же, чтобы удаленная сеть не терялась. Ставим "нет ответа"

Set(REDIRECTING(reason,i)=2)

1. -- Самое сложное - установить Presentation. Необходимо получить величину Allowed, User provided, Verified. Значение этого байта для такой композиции должно быть 00100001 И тут начинается самое интересное. Попытка установить этот байт с помощью десятичной 33 проваливается. Мануалы говорят, что libpri не работает корректно с данной функцией (REDIRECTING(from-num-pres)). Вот что пишет про это pri.c

sr->redirecting.from.number.presentation = pres & (PRIPRESRESTRICTION | PRIPRESNUMBER_TYPE);

Чисто теоретически int 33 должна превращаться в нужный байт. Но этого по факту не происходит.
К великому сожалению, решение этой проблемы видится лишь в модификации исходного кода libpri. К слову, Presentaion для Caller id устанавливается в нужное значение, если равна 1.

1. В итоге, максимум что удалось REDIRECTING(from-num-pres,i)=1 Дает Allowed, User provided, not screened.

-- О полноте изысканий. В первую очередь, стоит ответить немногочисленный характер этих вопросов и скудность материалов. Во вторую очередь, их противоречивость.
Конечно же, я перепробовал практически все возможные комбинации настроек с тем, чтобы получить нужный результат.
Но обо всем по порядку.
https://wiki.asterisk.org/wiki/display/AST/Function_REDIRECTING
Тут существует список возможных данных функции REDIRECTING.
К слову сказать, все что начинается с orig- - не распознается. Подозреваю, эта часть относится к SS7, где существует original called number.
Далее - сухое, для галочки информирование о наличии такой функции
http://www.voip-info.org/wiki/view/Asterisk+func+REDIRECTING
В обоих случаях, скудно представлен набор возможных данных и совершенно нет никакого описания. Единственное, что полезно - datatype,i означает инструкцию каналу не оверрайдить заданные значения. Впрочем, в моем случае работало и без ,i.
В одном из описаний REDIRECTING прямо сказано, что libpri некорректно работает с этой функцией. Или наоборот.
Грязные хаки вроде коррекции заголовочного файла libpri.h ни к чему не привели.
Вывод таков: для libpri это разные байты. Или что-то в самой библиотеке корректирует значение этого байта в момент инициации вызова. В любом случае, положительного эффекта достичь не представляется возможным на данный момент.

-- Устанавливаем TON и NPI Дело в том, что это 1 байт, в котором хранятся 2 величины. Таким образом, 0-15, TON - 0 (Unknown) , 16-31 - TON -1 (International), 32+ - TON - 2 (National) В моем случае TON - national (2) , NPI - E.164/E.163 (1) , Прибавляем к 32 1 и получаем

Set(REDIRECTING(from-num-plan,i)=33)

-- Причина переадресации. Вопрос творческий, но желательно все же, чтобы удаленная сеть не терялась. Ставим "нет ответа"

Set(REDIRECTING(reason,i)=2)

-- Самое сложное - установить Presentation. Необходимо получить величину Allowed, User provided, Verified. Значение этого байта для такой композиции должно быть 00100001 И тут начинается самое интересное. Попытка установить этот байт с помощью десятичной 33 проваливается. Мануалы говорят, что libpri не работает корректно с данной функцией (REDIRECTING(from-num-pres)). Вот что пишет про это pri.c

sr->redirecting.from.number.presentation = pres & (PRIPRESRESTRICTION | PRIPRESNUMBER_TYPE);

Чисто теоретически int 33 должна превращаться в нужный байт. Но этого по факту не происходит. происходит.
В то же время, изучение libpri.h показывает, что
PRIPRESALLOWED 0x00 - что соответствует 000XXXXX
PRIPRESRESTRICTED 0x20 - соответственно 001XXXXX
Неувязочка получается.
К великому сожалению, решение этой проблемы видится лишь в модификации исходного кода libpri. К слову, Presentaion для Caller id устанавливается в нужное значение, если равна 1. равно 1.
В итоге, максимум что удалось REDIRECTING(from-num-pres,i)=1 Дает дает Allowed, User provided, not screened.

-- О полноте изысканий. В первую очередь, стоит ответить немногочисленный характер этих вопросов и скудность материалов. Во вторую очередь, их противоречивость.
Конечно же, я перепробовал практически все возможные комбинации настроек с тем, чтобы получить нужный результат.
Но обо всем по порядку.
https://wiki.asterisk.org/wiki/display/AST/Function_REDIRECTING
Тут существует список возможных данных функции REDIRECTING.
К слову сказать, все что начинается с orig- - не распознается. Подозреваю, эта часть относится к SS7, где существует original called number.
Далее - сухое, для галочки информирование о наличии такой функции
http://www.voip-info.org/wiki/view/Asterisk+func+REDIRECTING
В обоих случаях, скудно представлен набор возможных данных и совершенно нет никакого описания. Единственное, что полезно - datatype,i означает инструкцию каналу не оверрайдить заданные значения. Впрочем, в моем случае работало и без ,i.
В одном из описаний REDIRECTING прямо сказано, что libpri некорректно работает с этой функцией. Или наоборот.
Грязные хаки вроде коррекции заголовочного файла libpri.h ни к чему не привели.
Вывод таков: для libpri это разные байты. Или что-то в самой библиотеке корректирует значение этого байта в момент инициации вызова. В любом случае, положительного эффекта достичь не представляется возможным на данный момент.

-- Устанавливаем TON и NPI Дело в том, что это 1 байт, в котором хранятся 2 величины. Таким образом, 0-15, TON - 0 (Unknown) , 16-31 - TON -1 (International), 32+ - TON - 2 (National) В моем случае TON - national (2) , NPI - E.164/E.163 (1) , Прибавляем к 32 1 и получаем

Set(REDIRECTING(from-num-plan,i)=33)

-- Причина переадресации. Вопрос творческий, но желательно все же, чтобы удаленная сеть не терялась. Ставим "нет ответа"

Set(REDIRECTING(reason,i)=2)

-- Самое сложное - установить Presentation. Необходимо получить величину Allowed, User provided, Verified. Значение этого байта для такой композиции должно быть 00100001 И тут начинается самое интересное. Попытка установить этот байт с помощью десятичной 33 проваливается. Мануалы говорят, что libpri не работает корректно с данной функцией (REDIRECTING(from-num-pres)). Вот что пишет про это pri.c

sr->redirecting.from.number.presentation = pres & (PRIPRESRESTRICTION | PRIPRESNUMBER_TYPE);

Чисто теоретически int 33 1 должна превращаться в нужный байт. Но этого по факту не происходит.
В то же время, изучение Изучение libpri.h показывает, что
PRIPRESALLOWED 0x00 - что соответствует 000XXXXX
PRIPRESRESTRICTED 0x20 - соответственно 001XXXXX
Неувязочка получается.
К великому сожалению, решение этой проблемы видится лишь в модификации исходного кода libpri. К слову, Presentaion для Caller id устанавливается в нужное значение, если равно 1.
В итоге, максимум что удалось REDIRECTING(from-num-pres,i)=1 дает Allowed, User provided, not screened.

screened.
Источник информации тут.
http://www.voip-info.org/wiki/view/Asterisk+cmd+CallingPres
-- О полноте изысканий. В первую очередь, стоит ответить немногочисленный характер этих вопросов и скудность материалов. Во вторую очередь, их противоречивость.
Конечно же, я перепробовал практически все возможные комбинации настроек с тем, чтобы получить нужный результат.
Но обо всем по порядку.
https://wiki.asterisk.org/wiki/display/AST/Function_REDIRECTING
Тут существует список возможных данных функции REDIRECTING.
К слову сказать, все что начинается с orig- - не распознается. Подозреваю, эта часть относится к SS7, где существует original called number.
Далее - сухое, для галочки информирование о наличии такой функции
http://www.voip-info.org/wiki/view/Asterisk+func+REDIRECTING
В обоих случаях, скудно представлен набор возможных данных и совершенно нет никакого описания. Единственное, что полезно - datatype,i означает инструкцию каналу не оверрайдить заданные значения. Впрочем, в моем случае работало и без ,i.
В одном из описаний REDIRECTING прямо сказано, что libpri некорректно работает с этой функцией. Или наоборот.
Грязные хаки вроде коррекции заголовочного файла libpri.h ни к чему не привели.
Вывод таков: для libpri это разные байты. Или что-то в самой библиотеке корректирует значение этого байта в момент инициации вызова. В любом случае, положительного эффекта достичь не представляется возможным на данный момент.

-- Устанавливаем TON и NPI Дело в том, что это 1 байт, в котором хранятся 2 величины. Таким образом, 0-15, TON - 0 (Unknown) , 16-31 - TON -1 (International), 32+ - TON - 2 (National) В моем случае TON - national (2) , NPI - E.164/E.163 (1) , Прибавляем к 32 1 и получаем

Set(REDIRECTING(from-num-plan,i)=33)

-- Причина переадресации. Вопрос творческий, но желательно все же, чтобы удаленная сеть не терялась. Ставим "нет ответа"

Set(REDIRECTING(reason,i)=2)

-- Самое сложное - установить Presentation. Необходимо получить величину Allowed, User provided, Verified. Значение этого байта для такой композиции должно быть 00100001 00000001 И тут начинается самое интересное. Попытка установить этот байт с помощью десятичной 33 проваливается. цифры больше 1 проваливается (отображается в дебаге как 32). Мануалы говорят, что libpri не работает корректно с данной функцией (REDIRECTING(from-num-pres)). Вот что пишет про это pri.c

sr->redirecting.from.number.presentation = pres & (PRIPRESRESTRICTION | PRIPRESNUMBER_TYPE);

Чисто теоретически int 1 должна превращаться в нужный байт. Но этого по факту не происходит.
Изучение libpri.h показывает, что
PRIPRESALLOWED 0x00 - что соответствует 000XXXXX
PRIPRESRESTRICTED 0x20 - соответственно 001XXXXX
К великому сожалению, решение этой проблемы видится лишь в модификации исходного кода libpri. К слову, Presentaion для Caller id устанавливается в нужное значение, если равно 1.
В итоге, максимум что удалось REDIRECTING(from-num-pres,i)=1 дает Allowed, User provided, not screened.
Источник информации тут.
http://www.voip-info.org/wiki/view/Asterisk+cmd+CallingPres
-- О полноте изысканий. В первую очередь, стоит ответить немногочисленный характер этих вопросов и скудность материалов. Во вторую очередь, их противоречивость.
Конечно же, я перепробовал практически все возможные комбинации настроек с тем, чтобы получить нужный результат.
Но обо всем по порядку.
https://wiki.asterisk.org/wiki/display/AST/Function_REDIRECTING
Тут существует список возможных данных функции REDIRECTING.
К слову сказать, все что начинается с orig- - не распознается. Подозреваю, эта часть относится к SS7, где существует original called number.
Далее - сухое, для галочки информирование о наличии такой функции
http://www.voip-info.org/wiki/view/Asterisk+func+REDIRECTING
В обоих случаях, скудно представлен набор возможных данных и совершенно нет никакого описания. Единственное, что полезно - datatype,i означает инструкцию каналу не оверрайдить заданные значения. Впрочем, в моем случае работало и без ,i.
В одном из описаний REDIRECTING прямо сказано, что libpri некорректно работает с этой функцией. Или наоборот.
Грязные хаки вроде коррекции заголовочного файла libpri.h ни к чему не привели.
Вывод таков: для libpri это разные байты. Или что-то в самой библиотеке корректирует значение этого байта в момент инициации вызова. В любом случае, положительного эффекта достичь не представляется возможным на данный момент.