Asterisk 1.6.x + OH323
|
Сообщений: 47
|
Re: Asterisk 1.6.x + OH323
ded: under, если разделить уважение + неуважение и суть концептуального спора (использование мемберов класса PIPSocket::Address), то рабочая совесть должна заставить Вас взглянуть на проблему глазами оппонентов (любых!), и, возможно, пересмотреть позицию по этому вопросу.
Пока что продавливается програмное решение, которое может быть не идеальным, и это может повредить делу революции.
ded, после комментариев собеседника в стиле "верх безграмотности" или "оторавать яйца" мне не хочется с ним вообще о чем либо говорить.
Мне за это не платят, а тратить свое свободное время на занятие неприятными вещами я не намерен.
Можем обсудить реализацию с вами. Я даже спасибо скажу вам если баги найдете.
В чем проблема "использования мемберов класса PIPSocket::Address"?
Ниже класс (class A), аналогичный PIPSocket::Address.
#include <iostream>
struct in_addr
{
};
class A
{
in_addr m_some_member;
public:
operator in_addr() const
{
std::cout << "operator in_addr() called" << std::endl;
return m_some_member;
}
};
int main()
{
A a;
static_cast<in_addr>(a);
a.operator in_addr();
}
Вывод:
operator in_addr() called
operator in_addr() called
Тут хоть static_cast используй, хоть напрямую оператор вызывай, разницы никакой.
|
|
Сообщений: 1129
|
Re: Asterisk 1.6.x + OH323
чем проблема "использования мемберов класса PIPSocket::Address"?
Ниже класс (class A), аналогичный PIPSocket::Address.
#include <iostream>
struct in_addr
{
};
class A
{
in_addr m_some_member;
public:
operator in_addr() const
{
std::cout << "operator in_addr() called" << std::endl;
return m_some_member;
}
};
int main()
{
A a;
static_cast<in_addr>(a);
a.operator in_addr();
}
Вывод:
operator in_addr() called
operator in_addr() called
Тут хоть static_cast используй, хоть напрямую оператор вызывай, разницы никакой.
на языке горе программистов это называется
"и так сойдет"
зайдите на форум знатоков c++
интересно что они вам скажут на ваше "и так сойдет"
и я вам уже сказал
вам никто не мешает переделать патч под "лучше"
переписав биндинг на момент открытие RTP
а не на момемт когда попало
но вы же как девочка обиделись и надули губки
ну коммите свои патчи, мне все равно как я уже говорил
я за чистоту и правильность кода
кой в астериске небыло и благодаря таким как вы, никогда не будет
ортодоксальный антиастерискер || антилинуксоид! (астериск || линукс) - иррациональное решение!. и здесь я тоже http://forum.asterisk.ru
|
|
Сообщений: 6521
|
Re: Asterisk 1.6.x + OH323
under, не больно?
Я не смогу брать на себя роль третейского судьи, меня тут (и не только) поливали соевым соусом по-белому за резкий тон по отношению ко многим. Тысячи их!
|
|
Сообщений: 47
|
Re: Asterisk 1.6.x + OH323
мда, конструктивного диалога я вижу не получится. жаль.
|
|
Сообщений: 1129
|
Re: Asterisk 1.6.x + OH323
конструктивный диалог:
вы делаете правильно
+
еще переписываете существующий биндинг RTP в chan_h323
что бы он биндился в RTP конструкторе MyH323_ExternalRTPChannel
сразу, а не когда попало перебиндивался в __oh323_rtp_create
и мы все дружно апаем ваш такой патч
ps
я не настаиваю что бы именно мой патч был использован
мне без разницы чей он будет.
но если коммитить то что то правильное,
а не "лиш бы работало"
ортодоксальный антиастерискер || антилинуксоид! (астериск || линукс) - иррациональное решение!. и здесь я тоже http://forum.asterisk.ru
|
|
Сообщений: 6521
|
Re: Asterisk 1.6.x + OH323
under: ded, после комментариев собеседника в стиле "верх безграмотности" или "оторавать яйца" мне не хочется с ним вообще о чем либо говорить.
Мне за это не платят
Мне тоже за это не платят, это вообще не аргумент в мире Open Source.
Что я могу рекомендовать, принимать эти буквы за слова - не стоит. Хороший контраргумент всегда - так называемая "реверсивная рекурсия", берём антонимы этих слов и понятий и отражаем как зеркальцем
- эти конструкции не верх, а самый низ безграмотности;
- яйца следует не отрывать, а приращивать (дополнительные) IMHO.
и тогда дискуссии сразу теряют накал.
|
|
Сообщений: 1129
|
Re: Asterisk 1.6.x + OH323
under: ded, после комментариев собеседника в стиле "верх безграмотности" или "оторавать яйца" мне не хочется с ним вообще о чем либо говорить.
оторвать яйца нужно PCadach (к вам это не относится)
за то что он разламал h323
из добавленого им это только cisco тунелинг который никто не использует
он даже не смог нормально сделать что бы chan_h323 собирался с разными версиями openh323+pwlib
а верх безграмотности в отношении программирования, могу привести один пример
в году 200x учась в университете был у нас одногрупник
который cдавал лабораторные по С и С++
так вот он писал так, что ваш static_cast на классе, выглядит еще плюшками
он писал программы в нарушение всех синтаксисов С и С++
при этом его программы как не удивительно работали
препод приходил в шок, но зачеты по лабам ему приходилось ставить
ибо довод одногрупника звучал так "да какая разница как написано?! оно же работает!"
ортодоксальный антиастерискер || антилинуксоид! (астериск || линукс) - иррациональное решение!. и здесь я тоже http://forum.asterisk.ru
|
|
Сообщений: 1129
|
Re: Asterisk 1.6.x + OH323
2 ddkprog А можно делать дифы на сорцах текущей версии ? А то хлопотно каждый раз руками править.
Разница в сорцах:
В вашем патче:
я и делаю на текущей svn/trunk
а то что вы показываете это какой то релиз
посколько астериск я не собираю и не использую
а только слежу за изменениями
не вижу смысла делать патч на релизы
да и патчи если принимаются то только в trunk, насколько я знаю
на вышедший релиз никаких фютерс не будут накладывать
это вам не FreeBSD, понятие MFC в астериске отсутсвует напроч
ортодоксальный антиастерискер || антилинуксоид! (астериск || линукс) - иррациональное решение!. и здесь я тоже http://forum.asterisk.ru
|
|
Сообщений: 147
|
Re: Asterisk 1.6.x + OH323
Ну тогда извините .. ваш патч протестить не получится.
|
|
Сообщений: 147
|
Re: Asterisk 1.6.x + OH323
До патча, при звонке с h323 канала пользователю с музывкой вместо кпв работала следующая конструкция:
exten => _1XXX,1,Dial(SIP/${EXTEN},60,tTm(some_sound))
Сейчас же, необходимо перед проключением ансверить:
exten => _1XXX,1,Answer()
exten => _1XXX,n,Dial(SIP/${EXTEN},60,tTm(some_sound))
Насколько правильна данная ситуация ? В документации написано:
m: Provide Music on Hold to the calling party until the called channel answers. This is mutually exclusive with option 'r', obviously. Use m(class) to specify a class for the music on hold. [.quote]
|
|
