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 ?