[OpenSIPS-Users] Possible issue with rtpproxy_offer

Bogdan-Andrei Iancu bogdan at voice-system.ro
Mon Aug 9 09:38:39 CEST 2010


OK :),

Just let me know if with the new configuration, everything works ok.

Regards,
Bogdan

Daniel Goepp wrote:
> 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 
> <bogdan at voice-system.ro <mailto:bogdan at voice-system.ro>> 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
>     > <bogdan at voice-system.ro <mailto:bogdan at voice-system.ro>
>     <mailto:bogdan at voice-system.ro <mailto: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>
>     <mailto:bogdan at voice-system.ro <mailto:bogdan at voice-system.ro>>
>     >     <mailto:bogdan at voice-system.ro
>     <mailto:bogdan at voice-system.ro> <mailto: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> <mailto:Users at lists.opensips.org
>     <mailto:Users at lists.opensips.org>>
>     >     <mailto:Users at lists.opensips.org
>     <mailto:Users at lists.opensips.org> <mailto: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>
>     <http://www.voice-system.ro>
>     >     <http://www.voice-system.ro>
>     >     >
>     >     >
>     >     >     _______________________________________________
>     >     >     Users mailing list
>     >     >     Users at lists.opensips.org
>     <mailto:Users at lists.opensips.org> <mailto:Users at lists.opensips.org
>     <mailto:Users at lists.opensips.org>>
>     >     <mailto:Users at lists.opensips.org
>     <mailto:Users at lists.opensips.org> <mailto: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 <mailto:Users at lists.opensips.org>
>     <mailto: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>
>     <http://www.voice-system.ro>
>     >
>     >
>     >     _______________________________________________
>     >     Users mailing list
>     >     Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>     <mailto: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 <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




More information about the Users mailing list