[OpenSIPS-Users] parallel fork and mediaproxy => false behaviour?

[Raúl Alexis Betancor Santana]

Uwe Kastens escribió:
> Raúl Alexis Betancor Santana schrieb:
>   
>> On Friday 23 October 2009 14:14:52 Uwe Kastens wrote:
>>     
>>> 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
>>
>>     
>
> Thanks. How would you handle parallel forking in that case? If I match
> for end_media_session() on BYE the media_session is dropped if the UAS
> sends the BYE for the 2nd call leg
>   

You need to work with branches, so when on_reply route is excecuted, it 
will be executed for each branch reply, so no problems at all, because 
mediaproxy module knows that they are diffent branches, and work ok.