[OpenSIPS-Devel] [ opensips-Bugs-3599495 ] SIP Parallel forking and RTPProxy limitation

[SourceForge.net]

Bugs item #3599495, was opened at 2013-01-04 08:20
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3599495&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.8.x
Status: Open
>Resolution: Remind
>Priority: 4
Private: No
Submitted By: Pierre-Yves (pym67)
>Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary:  SIP Parallel forking and RTPProxy limitation

Initial Comment:
Hello,

I have found a limitation using opensips and rtpproxy with Parallel forking.
Version: opensips (v1.8.2) + rtpproxy.
Opensips is used as a SIP proxy (+ NAT traversal).
Another component is handling the service logic (Application Server)

The call scenario is the following:
- 2 UAC are registered using the same identity (using the same opensips SIP Proxy). Those 2 UAC are behind NAT
- Incoming call with parallel forking (to those 2 UAC)  [forking is not handled on opensips itself]
- 2 dialogs are well created (one for each fork)
- Upon the first UAC has sent his 200OK, the other fork call is CANCELED.


The problem is :
- both calls ( fork.0 and fork.1) have the same FromTag, Call-ID).
- on each INVITE, rtpproxy provide the same media port for both calls fork .  [RTPProxy consider both INVITE as being part of the same call]
- on CANCEL on fork.1, unforce_rtpproxy() is closing the call (and as there is only 1 "media" call ), no media can be established on fork.0

In my opinion, there is here a limitation of rtpproxy & rtpproxy module that handle calls based only on From Tag, Call-ID, To Tag information which is not enough in case of forking.

Might it be possible to enhance the rtpproxy module in order to provide to "rtpproxy" a dialog ID/hash instead of the real Call-ID of the Call ?
(trough a modparam to enable/disable this behavior). 

Do you think that this could be implemented ?


----------------------------------------------------------------------

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2013-01-28 05:40

Message:
Hi Pierre-Yves,

This scenario is not supported by RTPproxy itself - as it use as key for
the sessions the callid+from_tag+to_tag which are the same for all
branches.

We will do a brain storming to see how something like this can be solved,
but I would say solutions are not handy.

I would rather suggest you to move the rtpp stuff before the parallel
forking point, if possible.

Regards,
Bogdan

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3599495&group_id=232389