Hi all,
I am on my way to learn a little bit more about the media server and the MGCP protocol so I do have a couple of questions.
I am a little bit curious how the recommended way to handle a SIP media renegotiation looks like.
During my testing phase I have got a little bit confused by the MGCP protocol, and my experiment results in a "Not supported yet" error message on the media server.
Scenario:
I am using the media server in SBC mode to route media from clients on net A to other clients on net B together with a B2BUA.
MGCP is used as protocol to control the media server.
Lets assume the following scenario happens.
A SIP client connects to my sip server on net A and make a call to a client on net B.
- I create a new bridge endpoint and returns the negotiated SDP to the client.
- I create a new bridge endpoint on the local network and use that for the client on net B.
- I join the two endpoints, and media works fine.
Questions:
- If the client A, puts the call on hold, with "sendrecv" parameter in the SDP.
How shall this be handled in the best way?
-- Sending a ModifyConnection on A's endpoint seams to return "Not supported yet" message.
-- Sending a ModifyConnection with "ConnectionMode.RecvOnly" seams to work, but it will not return a new local SDP to send back to the client. Client A expects to receive an updated SDP with "recvonly" parameter set and updated version number etc.
- Can the media server update this for me?
- Can I ask the media server for an updated SDP for the endpoint in use?
Or would this be a scenario where I need to parse/modify the SDP my self while processing the SIP message?
I am not sure that I really need to do anything on the media server it self, but I must respond to both client A and send a hold to client B with correct SDP´s.
- The questions above are as far as I understand the same when thinking of handling a codec change from a client.
- Another question is if I am using the correct endpoint type(bridge) for doing this? As far as I understand there is no packet forwarding yet.
Best regards,
Lars