[sr-dev] mohqueue docs and suggestions
Jorj Bauer
jorj at isc.upenn.edu
Wed Oct 2 17:29:53 CEST 2013
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
More information about the sr-dev
mailing list