[sr-dev] mohqueue docs and suggestions

[Daniel-Constantin Mierla]

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 at 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 at lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
> _______________________________________________
> sr-dev mailing list
> sr-dev at 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 -