Hello Opensips community,<br><br>I'm facing an issue using opensips (v1.8.2) + rtpproxy.<br>opensips is used as a SIP proxy (+ NAT traversal).<br>another component is handling the service logic (Application Server)<br>
<br>The call scenario is the following:<br>- 2 UAC are registered using the same identity (using the same SIP Proxy). Those 2 UAC are behind NAT<br>- Incoming call with parallel forking (to those 2 UAC) [forking is not handled on opensips]<br>
- 2 dialog are well created (one for each fork)<br>- Upon the first UAC has sent his 200OK, the other fork call is CANCELED.<br><br><br>The problem is :<br>- both calls ( fork.0 and fork.1) have the same FromTag, Call-ID). <br>
- on INVITE, rtpproxy provide the same media port for both calls (not really a problem). [RTPProxy consider both INVITE as being part of the same call]<br>- 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<br>
<br><br>In my opinion, there is here a limitation on rtpproxy & rtpproxy module that handle calls based only on FromTag, Call-ID, ToTag information.<br><br>I found something likely similar reported here (<a href="http://permalink.gmane.org/gmane.comp.voip.openser.user/35460">http://permalink.gmane.org/gmane.comp.voip.openser.user/35460</a>)<br>
<br><br>How can I handle this properly ?<br><br>I have imagined that opensips "rtpproxy module" could be enhanced 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 ?<br>
<br><br>Thanks for your lights on this point,<br>Regards,<br>Pierre-Yves<br><br><br><br><br><br><br><br>