Oh, I see what you mean. I thought you meant initially not to put it in the main routing block. You are right, I have it in the route(1) block, and I should put it in the route_branch(1) block.
Thanks -dg On Thu, Aug 5, 2010 at 7:26 AM, Bogdan-Andrei Iancu <[email protected]>wrote: > Hi Daniel, > > by "I do the rtpproxy_offer in the first branch" do you mean you do the > rtpproxy_offer() in a branch_route ? > > Regards, > Bogdan > > Daniel Goepp wrote: > > I'm not actually doing it globally, I do the rtpproxy_offer in the > > first branch (since I need to for the first call), then when it fails, > > it calls the second branch. I'm thinking the better way to handle > > this I guess is to serialize the branches. > > > > -dg > > > > > > On Wed, Aug 4, 2010 at 2:51 PM, Bogdan-Andrei Iancu > > <[email protected] <mailto:[email protected]>> wrote: > > > > Hi Daniel, > > > > not really....the bad idea was to to rtpproxy stuff in request route > > (globally), considering that you want to do per-branch changes > > :)....Again use only branch route to do the per-branch changes. > > > > REgards, > > Bogdan > > > > Daniel Goepp wrote: > > > Okay, I guess I will have to figure out a different way to handle > > > this. Am I correct in assuming then the idea of putting a > route(10) > > > for example nested in the failure block of another route is a > > bad idea? > > > > > > -dg > > > > > > > > > On Wed, Aug 4, 2010 at 10:04 AM, Bogdan-Andrei Iancu > > > <[email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>> > > wrote: > > > > > > Hi Daniel, > > > > > > it is not a bug - the idea is you must not call RTPproxy > > function more > > > than once per branch - and keep in mind that whatever > > changes you > > > do in > > > request route do apply to all branches..... > > > > > > If you want to do per branch changed, use the branch route. > > > > > > Regards, > > > Bogdan > > > > > > Daniel Goepp wrote: > > > > I don't think I would call this a "bug" quite yet, but > > figured it > > > > might be worth bringing up. Here is the call scenario: > > > > > > > > User A calls User B, no answer, timer hit, forward call. The > > > original > > > > timeout was on route(1), and I just rewrite some info, and > > execute > > > > route(10) from the failure branch. This is probably bad > > > practice, and > > > > I would appreciate input on how this would be better > > handled. But > > > > that said, here is what I see. Since route(1) had already > > done a > > > > rtpproxy_offer, when I hit route (10), it does the same > again, > > > > resulting in a line in the SDP that looks like: > > > > > > > > m=audio 3061830618 RTP/AVP 99 100 101 9 11 0 102. > > > > > > > > See the problem? If I make a call that naturally would go > to > > > > route(10), that is not a problem, I see: > > > > > > > > m=audio 28568 RTP/AVP 99 100 101 9 11 0 102. > > > > > > > > It would appear that rtpproxy_offer is trying to append > > the port > > > > number to an already existing port number. Make sense? > > > > > > > > -dg > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > _______________________________________________ > > > > Users mailing list > > > > [email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>> > > > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > > > > > > > > > > -- > > > Bogdan-Andrei Iancu > > > OpenSIPS Bootcamp > > > 20 - 24 September 2010, Frankfurt, Germany > > > www.voice-system.ro <http://www.voice-system.ro> > > <http://www.voice-system.ro> > > > > > > > > > _______________________________________________ > > > Users mailing list > > > [email protected] <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>> > > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > Users mailing list > > > [email protected] <mailto:[email protected]> > > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > > > > > > -- > > Bogdan-Andrei Iancu > > OpenSIPS Bootcamp > > 20 - 24 September 2010, Frankfurt, Germany > > www.voice-system.ro <http://www.voice-system.ro> > > > > > > _______________________________________________ > > Users mailing list > > [email protected] <mailto:[email protected]> > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Users mailing list > > [email protected] > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > > -- > Bogdan-Andrei Iancu > OpenSIPS Bootcamp > 20 - 24 September 2010, Frankfurt, Germany > www.voice-system.ro > > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
