A few comments:
I think the module name should be "queue". The moh-part is a just a nice way of handling the queue...
From reading the docs:
- The example on 3.4. moh_maxcalls illustrates usage of mohdir.
- Change "from the main (request) route" to "a request route". Routes can call routes.
I would love for this module to expose the queue in an xavp (as an alternative to the database) so I can manipulate weights and stuff. Queues need management. I would also like to be able to pick a call out of the queue at any point, regardless of position. But that's a future change. This is a very good contribution.
I don't think naming audio files after payload number is a good scheme. Payload numbers are dynamic for all new codecs and one should use the name tags. I think we should simply copy the file name extensions used by Asterisk for the codecs, like "alaw" for alaw. Or the names used in rtpmap. One of them - but not the numbers, that is not extensible enough as they are no longer assigned. Opus will not get a fixed number, just a name tag.
/O
On 10/2/13 3:54 PM, Olle E. Johansson wrote:
A few comments:
I think the module name should be "queue". The moh-part is a just a nice way of handling the queue...
I don't like "queue" alone, because it is not suggestive for the functionality. It can be callqueue or something else that contains queue if the current name is no longer preferred, but not just 'queue'.
Cheers, Daniel
From reading the docs:
The example on 3.4. moh_maxcalls illustrates usage of mohdir.
Change "from the main (request) route" to "a request route". Routes can call routes.
I would love for this module to expose the queue in an xavp (as an alternative to the database) so I can manipulate weights and stuff. Queues need management. I would also like to be able to pick a call out of the queue at any point, regardless of position. But that's a future change. This is a very good contribution.
I don't think naming audio files after payload number is a good scheme. Payload numbers are dynamic for all new codecs and one should use the name tags. I think we should simply copy the file name extensions used by Asterisk for the codecs, like "alaw" for alaw. Or the names used in rtpmap. One of them - but not the numbers, that is not extensible enough as they are no longer assigned. Opus will not get a fixed number, just a name tag.
/O
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
2 okt 2013 kl. 16:01 skrev Daniel-Constantin Mierla miconda@gmail.com:
On 10/2/13 3:54 PM, Olle E. Johansson wrote:
A few comments:
I think the module name should be "queue". The moh-part is a just a nice way of handling the queue...
I don't like "queue" alone, because it is not suggestive for the functionality. It can be callqueue or something else that contains queue if the current name is no longer preferred, but not just 'queue'.
I see. +1 for "callqueue".
/O
Cheers, Daniel
From reading the docs:
The example on 3.4. moh_maxcalls illustrates usage of mohdir.
Change "from the main (request) route" to "a request route". Routes can call routes.
I would love for this module to expose the queue in an xavp (as an alternative to the database) so I can manipulate weights and stuff. Queues need management. I would also like to be able to pick a call out of the queue at any point, regardless of position. But that's a future change. This is a very good contribution.
I don't think naming audio files after payload number is a good scheme. Payload numbers are dynamic for all new codecs and one should use the name tags. I think we should simply copy the file name extensions used by Asterisk for the codecs, like "alaw" for alaw. Or the names used in rtpmap. One of them - but not the numbers, that is not extensible enough as they are no longer assigned. Opus will not get a fixed number, just a name tag.
/O
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- 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 -
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
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
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@gmail.com wrote:
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Jorj Bauer writes:
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).
it is also quite easy to implement this kind of "call center" application in sems.
-- juha
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@gmail.com wrote:
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
2 okt 2013 kl. 17:29 skrev Jorj Bauer jorj@isc.upenn.edu:
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).
It's functionality we've been missing and the ability to play stuff with RTPproxy is already used in Kamailio. I like your idea too. I suggest that you open a wiki page where we can list "future ideas" for this module.
/O
- Jorj
On Oct 2, 2013, at 11:19 AM, Robert Boisvert rdboisvert@gmail.com wrote:
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--- * Olle E Johansson - oej@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden
2 okt 2013 kl. 17:19 skrev Robert Boisvert rdboisvert@gmail.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.
No camelcase in module names, please.
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.
It is still wrong and not very future-safe. Please add a conversion table. What's the state with rtpproxy-ng? Still using old payload numbers?
Being able to choose a specific call out of queue is very flexible, but under what circumstances would this feature be useful?
It's just an idea. Many users have implemented this in UIs to Asterisk call queues. It's quite often a requirement.
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.
Can understand that. Just a suggestion too.
I will adjust the comment about request routes. I appreciate the help with documentation since it is just as important as the code.
That's the spirit!!!
Good work, Bob!
/O
Thanks, Bob
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--- * Olle E Johansson - oej@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden
-
Daniel-Constantin Mierla -
Jorj Bauer -
Juha Heinanen -
Olle E. Johansson -
Robert Boisvert