2 Oct
2013
2 Oct
'13
11:48 a.m.
I am sure there are dozen of alternatives and eventual improvements. For
this discussion now, I would like to focus on finishing the import of
current module, in preparation to freeze for v4.1.
In the future people can came with new code to it and if people want to
discuss about that now, maybe is better to start a new thread.
Here let's discuss and review current code and to summarize the status:
- some fixup functions would be nice to be replaced with the ones
already offered from core via mod_fix.h, used by the other modules
- database tables have to be defined with xml format in lib/srdb1/schema
These are all we got in regard to the code.
Related to the name, it can stay as it is if the author is happy with it
and relevant for what the modules provide. In any case, keep or rename,
the name of the module has to be all in lower cases. Also, have in mind
renaming can happen later, we did it with many modules.
That would be all it needs to get merged in master branch.
As a side remark to previous comment, I think UPDATE is not that
widespread as well as support to play URIs, so using INVITE and rtp
proxy sounds safer for me.
Cheers,
Daniel
On 10/2/13 5:29 PM, Jorj Bauer wrote:
It seems to me that this would be more flexible and
useful if, instead of using rtpproxy to provide audio, it specified a URI for early media
and send out appropriate UPDATEs. Using rtpproxy feels like an unnecessary hack (albeit
one that simplifies the signaling).
- Jorj
On Oct 2, 2013, at 11:19 AM, Robert Boisvert <rdboisvert(a)gmail.com>
wrote:
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Trainings - Berlin, Nov 25-28; Miami, Nov 18-20, 2013
- more details about Kamailio trainings at http://www.asipto.com -
All,
These are good comments and very helpful. In response, …
The naming decision came up early in the design process and I concluded
that queue is too generic. I thought of “callqueue” but decided against it
since there are many ways to put calls into queues and I didn’t want to
conflict with future modules which might have their own “call queues”. I
used “mohqueue” because it is concise and hopefully makes the function more
apparent. I could call it “MOHqueue” if that makes the “MOH” part stand
out more.
Using the payload number was not my choice but is the way Sippy RTPproxy
works. Like others, (
http://lists.sip-router.org/pipermail/sr-users/2011-July/069391.html) I
found this out by going directly into the source code. If I am wrong in
this conclusion, please help me get it right.
Being able to choose a specific call out of queue is very flexible, but
under what circumstances would this feature be useful?
xavp is a useful extension and something to consider for the future. I was
in a hurry to meet deadlines so I chose what worked best in the current
environment.
I will adjust the comment about request routes. I appreciate the help with
documentation since it is just as important as the code.
Thanks,
Bob
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev