[OpenSIPS-Users] ICE and Mediaproxy break when using append_branch and serial_branches/next_branches

[Duane Larson]

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 <duane.larson at gmail.com>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 <
> saul at ag-projects.com> wrote:
>
>> Hi,
>>
>> On Jul 12, 2011, at 9:29 PM, duane.larson at gmail.com 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
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
>
>
> --
> --
> *--*--*--*--*--*
> Duane
> *--*--*--*--*--*
> --
>



-- 
--
*--*--*--*--*--*
Duane
*--*--*--*--*--*
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20110714/35faf351/attachment-0001.htm>