[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>

> 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