Get new SDP after rtpproxy_offer()

helbert
2011-11-22
2013-05-09
  • helbert
    helbert
    2011-11-22

    Hello all,
    I'm using OpenSIPS with RTPProxy to relay media. When I receive an Invite, I do an offer so Nathelper can modify the SDP before sending this the B party.
    Now I need to get this updated SDP. If I try to get the SDP the only one I can get is the original one and not the changed.
    Is there any way I can access this new SDP?
    Another option would be to get the entire outgoing SIP message but I can get that ether.
    Does anyone have any idea on how to do that?
    Thanks in advance,
    Helbert

     
  • Hi Helbert,

    Basically there is no way to get the changed SDP from script (in OpenSIPS, all changes are applied only when the message is sent out). May I ask what info you are looking in the new SDP and for what purpose ? Maybe I can suggest an workaround.

    Regards,
    Bogdan

     
  • helbert
    helbert
    2011-11-23

    Hi Bogdan,
    Thanks for your reply.

    I'm trying to implement a call hold/resume feature.
    In my behavior I cannot send the call hold information to B party so I need to treat it on OpenSIPS.
    By this reason, I need to use the same ports as negotiated on the first Invite/200OK when resuming and also I cannot let the RTP session die. In this case, I was thinking about storing the sent SDP (changed by nathelper) in the created dialog so I can query this afterwards. The problem is that I cannot get the changed SDP.

    Do you have any idea on how can I solve this issue?

    Thanks again,
    Helbert

     
  • Hi  Helbert,

    The onhold / resume events are actually translate into re-INVITEs at signaling level. I suppose you want to implement music on-hold, right ? in this case how do you plan to inject the RTP ? Could you make a small SIP flow + changes to understand better ?

    Anyhow, maybe a small help for you will be to configure an AVP (via module params) to be used by rtproxy module to return to script the new used port.

    Regards,
    Bogdan

     
  • helbert
    helbert
    2011-11-24

    Hi Bogdan,

    I don't want to implement music on-hold. At least not yet. :-) I do want to implement onhold / resume events in OpenSIPS. In my scenario, A will call B using OpenSIPS. The problem is that client A supports onhold events, but client B doesn't. My idea is to put the leg A-OpenSIPS on hold while the leg OpenSIPS-B remains active. The flow is the following:

               A                                         OpenSIPS                                          B
                |----- INVITE/SDP (1) ----->|                                                   |
                |                                                   |----- INVITE/SDP (2) ---->|
                |                                                   |<---- 200 OK/SDP (3) -----|
                |<---- 200 OK/SDP (4) -----|                                                   |
                |                                                   |                                                   |
                |<=======  RTP ========>|<=======  RTP ========>|
                |                                                   |                                                   |
                |----- INVITE/SDP (5) ----->|                                                   |
                |<---- 200 OK/SDP (6) -----|                                                   |
                |                                                   |                                                   |
                |                                                   |<=======  RTP =========|
                |                                                   |                                                   |
                |----- INVITE/SDP (7) ----->|                                                   |
                |<---- 200 OK/SDP (8) -----|                                                   |
                |                                                   |                                                   |
                |<=======  RTP ========>|<=======  RTP ========>|
                |                                                   |                                                   |

    But in order to implement this, I need to store the outgoing SDP (4). Thus, when OpenSIPS receives SDP (5), I want to send SDP (4) (plus a=inactive) as a response. This would put the leg A-OpenSIPS on hold. When OpenSIPS receives SDP (7), I would send SDP (4) again as a response and that would resume the call between A and OpenSIPS.

    From B point of view, the call would be active during all the time. The only difference is that for some time he won't receive RTP packets.

    Do you have any idea of how could I deal with the problem of storing the outgoing SDP?

    Thank you in advance,
    Helbert

     
  • Hi Helbert,

    Really useful  description :).
    Short suggestion - shouldn't be simpler to reply the on-hold re-INVITE (5) on opensips (as per your schema), but to allow to pass through the resume re-INVITE (7) and to simply to re-arm rtpproxy at that moment  ? doing this:
        1) no need to store SDP info
        2) should be also ok for B as a resume re-INVITE looks like a normal re-INVITE that maybe changes the SDP ip/port

    Regards,
    Bogdan

     
  • helbert
    helbert
    2011-11-28

    Hi Bogdan,

    Thanks for your reply.

    This is a very clever idea. The problem is that not only B does not support onhold but it does not support any re-INVITE either. That's why it's needed to keep the leg OpenSIPS-B alive (as well as the session in rtpproxy).

    But anyway, I followed your suggestion of changing rtpproxy_offer and rtpproxy_answer to return the new port used by rtpproxy as a parameter. With this new port and the received SDP (3), it is possible to generate a new SDP that is very similar to the SDP (4), the one I wanted. With this approach, the flow worked fine and the call could be put on hold and resumed for client A.

    Thanks again,
    Helbert

     
  • Hi Helbert ,

    If you changed the code in oder to get the port returned by rtpproxy, do you consider uploading the patch so that we can include it in the official code….maybe other people will need something similar ;)

    Regards,
    Bogdan