Questions about how to handle media renegotiation and hold. (together with SIPservlets)

40 views
Skip to first unread message

LasseO

unread,
Sep 4, 2014, 4:29:40 AM9/4/14
to sipme-med...@googlegroups.com
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

oifa.yulian

unread,
Sep 4, 2014, 4:38:53 AM9/4/14
to sipme-med...@googlegroups.com
Hello
First of all why dont you use packet relay endpoint , which allows you to connect to clients together on single endpoint?
Bridge is used to join RTP connections to Local Connections , which is not a case in your scenario.

When you want to update 2 legs , one for customer a and one for customer b you should execute 2 mgcp mdcx requests.
One for originating ( that puts on hold ) client with connection mode recv only and with sdp received from client.
Second with connection mode send only and without sdp at all , this will set second leg as send only and will return updated sdp to you.

Best regards
Yulian Oifa

LasseO

unread,
Sep 12, 2014, 6:21:45 AM9/12/14
to sipme-med...@googlegroups.com
Thanks for the answer,

Regarding the choice of endpoint type, I guess this might be a mistake due to lack of knowledge in the area, and since it actually did work I have not paid more attention to it.  So, as I understand your answer, my thoughts with using ModifyConnection should be used and should work when using packet relay endpoint instead of bridge endpoint.. I will definitely look into this.

Also, when using BridgeEndpoint as of now, during setup of a new endpoint (CreateConnection) and using ModifyConnection the first time to set the remote SDP, I sometimes receive a  "ERROR [ua.mobius.protocols.mgcp.stack.JainMgcpStackProviderImpl] (Thread-161) The TransactionHandler not found for TransactionHandle 21 May be the Tx timed out. Event = 400 0The transaction could not be executed due to a transient error." message

This might happen about 5% of the times. Any idea what would be the reason? And a recommendation on how to resolve it?
At the moment I do not see that I receive  a callback when this happens.

Cheers,


oifa.yulian

unread,
Sep 12, 2014, 8:50:00 AM9/12/14
to sipme-med...@googlegroups.com
Hello
To understand the problem i should see mms side log when this happens.
Best regards
Yulian Oifa
Reply all
Reply to author
Forward
0 new messages