[OpenSIPS-Users] Possible issue with rtpproxy_offer

[Daniel Goepp]

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
<bogdan at voice-system.ro>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
> > <bogdan at voice-system.ro <mailto:bogdan at voice-system.ro>> 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
> >     > Users at lists.opensips.org <mailto:Users at lists.opensips.org>
> >     > 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
> >     Users at lists.opensips.org <mailto:Users at lists.opensips.org>
> >     http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Users mailing list
> > Users at lists.opensips.org
> > 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
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20100804/82d631be/attachment.htm