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