While trying to debug some Q Values I noticed the following 90127X2XX9 should get called first || Q-value is 90 90148X7XX9 should get called second || Q-value is 50 <---- This is a Outbound Number 90133X9XX9 should get called last || Q-Value is 40
So for some reason the first and second number get called at the same time in parrallel even though the Q values are different. But I have two-way audio for all calls (The first call in parrallel with 90127X2XX/90148X7XX9 and the second call to 90133X9XX9). Usually the second call to an internal number would have one-way audio. Here is the debug for this. (The debug is a lot longer but I couldn't post it to pastebin. I can email if need be) http://pastebin.com/D8NK50X9 On Wed, Jul 13, 2011 at 11:01 AM, Duane Larson <[email protected]>wrote: > Here is a debug=5 showing the call to outbound number then 90127X2XX9. > http://pastebin.com/ZpsR5WG8 > > Here is a siptrace of the same > http://pastebin.com/Rvg6nNGa > > Not sure if it really helps > > > > On Wed, Jul 13, 2011 at 2:28 AM, Saul Ibarra Corretge < > [email protected]> wrote: > >> Hi, >> >> On Jul 12, 2011, at 9:29 PM, [email protected] wrote: >> >> > I am using append_branch and serial_branches/next_branches to implement >> a FindMe/FollowMe feature. I just noticed that when I do this I am getting >> no audio clients that don't have a public IP. If I bypass the >> FindMe/FollowMe stuff audio works just fine. I am not sure what exactly is >> going on when it breaks. The scenario I have right now is >> > >> > 90133XXX18 calls 90127X2XX9 >> > >> > modparam("mediaproxy", "mediaproxy_socket", >> "/var/run/mediaproxy/dispatcher.sock") >> > modparam("mediaproxy", "ice_candidate", "low-priority") >> > >> > OpenSIPS knows that when 90127X2XX9 is called to first set $ru to >> 90127X2XX9 and then append_branch. Then OpenSIPS sets $ru to an outbound >> number that has to be reached via SIP trunk provider. Q-Values are set for >> both numbers so that the outbound number is called first and then 90127X2XX9 >> is called. Then I call serialize_branches(1) and then next_branches. I turn >> on Mediaproxy by doing the following >> > >> > if (method==INVITE && !has_totag()) { >> > # We can also use a specific media relay if we need to >> > engage_media_proxy(); >> > } >> > >> > Then the call is made. I notice when doing a siptrace on the call that >> sometimes my "c=IN IP4" in the SDP never has the IP of the Mediaproxy when >> it calls the outbound number and then the 90127X2XX9 number. Then other >> times it does include the mediaproxy IP which is "173.XXX.XXX.111". It's >> just random when I test a call. Engage_media_proxy is called when the call >> to the outbound number is made and also when the call to the 90127X2XX9 >> number is made. If I disable ICE on the Blink client it doesn't seem to make >> a difference on this problem. >> > >> > I am using a branch version of OpenSIPS that was posted yesterday and I >> just upgraded Mediaproxy Dispatcher and Relay to the latest version without >> any luck. >> >> Its been a while since I haven't used serial forking, but since you are >> using engage_media_proxy you may need to check how serial forking and the >> dialog module work together. Are you calling engage_media_proxy for every >> new branch that is appended? That is, is this always failing if the *first* >> endpoint doesn't answer? >> >> >> Regards, >> >> -- >> Saúl Ibarra Corretgé >> AG Projects >> >> >> >> >> >> >> _______________________________________________ >> Users mailing list >> [email protected] >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > > > > -- > -- > *--*--*--*--*--* > Duane > *--*--*--*--*--* > -- > -- -- *--*--*--*--*--* Duane *--*--*--*--*--* --
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
