[OpenSIPS-Users] SIP Parallel forking and RTPProxy limitation ?

[Pierre-Yves Marche]

Hello Opensips community,

I'm facing an issue using 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 SIP Proxy).
Those 2 UAC are behind NAT
- Incoming call with parallel forking (to those 2 UAC)  [forking is not
handled on opensips]
- 2 dialog 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 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]
- 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 on rtpproxy & rtpproxy module
that handle calls based only on FromTag, Call-ID, ToTag information.

I found something likely similar reported here (
http://permalink.gmane.org/gmane.comp.voip.openser.user/35460)


How can I handle this properly ?

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 ?


Thanks for your lights on this point,
Regards,
Pierre-Yves
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20121119/6332895b/attachment.htm>