[OpenSIPS-Users] solved ; ( Re: parallel fork and mediaproxy => false behaviour?

[Uwe Kastens]

Hi,
>>
>>>>>> Is there an option to prevent this behavior with mediaproxy?
>>>>>>
>>>>>> opensips: 10.20.20.159 and 10.20.30.159
>>>>>> UACs: 10.20.20.25 and 10.20.20.26
>>>>>> UAS: 17.17.17.167
>>>>> You have something wrong on you opensips.cfg, for sure ... We have lot
>>>>> of UAC's working on that scenario you described, without any problem.
>>>> Good to hear that.
>>>>
>>>>> Are you using the dialog module? ... if yes, take into account it
>>>>> limitations to work with parallel forking.
>>>> You are working not with engage_media_proxy() then?
>>> Of course, becasue engage_media_proxy NEEDS the dialog module ... and
>>> it's a know limitation of dialog module that it doesn't work AT ALL with
>>> parallel forking, or with multiple 1XX replies.
>>>
>>> Better if you limit your uses of the dialog module to the minimum ... let
>>> say ... to 0 .. ;-)
>> At which time are you calling use_media_proxy() then? On the 1st INVITE
>> or later with the 200 OK with SDP? Is there any example out there?
> 
> On First invite after checking if needed, on_reply for 1XX or 200 with SDP, on 
> re-invites ....
> 
> You could see and example on sipwise.com

I was not able to get it up and running with use_media_proxy and
end_media_session, since the mediasession was ended, if a BYE for the
2nd branch arrived.

I changed a lot in my script and now its working with engage_media_proxy
as expected. I have no idea why its working now. The only relevant think
I have changed was. Strange, I will try which changed fixed that point.

old:
route[1] {
...
engage_media_proxy();
...
t_on_branch(1);
t_relay(),
...
}

new:
route[1] {
...
engage_media_proxy();
...
t_on_branch(1);
t_on_reply(1);
route(3),
...
}

route[1] {
...
engage_media_proxy();
...
t_on_reply(2);

t_relay();

...
}

BR

Uwe
-- 

kiste lat: 54.322684, lon: 10.13586