Menu ▾ ▴

#603 SIP Parallel forking and RTPProxy limitation

1.8.x
open-remind
Bogdan-Andrei Iancu
modules (454)
4
2013-01-28
2013-01-04
Pierre-Yves
No

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 ?

Discussion

  • Bogdan-Andrei Iancu

    Bogdan-Andrei Iancu - 2013-01-28

    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

     

  • Bogdan-Andrei Iancu

    Bogdan-Andrei Iancu - 2013-01-28
    • assigned_to: nobody --> bogdan_iancu
    • priority: 5 --> 4
    • status: open --> open-remind
     

  • Pierre-Yves

    Pierre-Yves - 2013-02-07

    Hi Bogdan,

    Thanks for the reply..

    In our architecture it is not possible to move rtpp stuff before the parallel forking :-(.

    My idea was (don't know if it's possible) to provide to rtpproxy a "callid" which is not a sip callid but the identifier/hash of the current dialog.

    In such case for rtpproxy it self, i guess it would be transparent, as the key for sessions would the same.

    Regards,
    Pierre-Yves

     

Log in to post a comment.