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] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
