Also removes a comment in sdp_create_file() about the
IP address in o= and c= having to be the same.
It is completely legal in SDP and often normal for the
originator and the connection information IP to be different.
Change-Id: I057573467c335fc27ead391c0bb4c775f2f6ba0a
Add function pointers to the call_leg struct for call hold and retrieve.
Add function to send re-INVITE to SIP side when MNCC side puts call on HOLD/RETRIEVES.
Add MNCC/SIP CC_HOLD to call states.
Change-Id: I2595626dfa50eb2f8e29a02540b708c9c1dce88c
Start with a show call summary that lists simple data about the
current set of calls:
Call(5002) initial(type=SIP,state=CONFIRMED) remote(type=MNCC,state=INITIAL)
Call(5001) initial(type=MNCC,state=PROCEEDING) remote(type=SIP,state=CONFIRMED)
Related: OS#1680
I had modified my code to do nothing after having sent the PROCEEDING
message. First the MS will issue a DISCONNECT.IND (which I ignored) and
then there will be REL.IND. Let's inform the other leg about this event
and let's assume the call will then be terminated.
Reading the "releasing" log output sounded like one more message
had been sent and this code is waiting for something. Take a copy
of the call id and then print that the call has been released.
The code is not tested and might be broken. Parse the setup request
of a MO call, create a new "call" with a MNCC leg and then issue the
call to create a RTP socket. Once this has been done, release the call
as the code to open a second leg has not been written yet.
In case the MNCC server is crashing we need to release all calls,
use the event emitted by the MNCC connection and iterate over all
calls and call the release function.
Right now a call has two legs, the initial one and the remote. In
general this will allow a SIP to SIP, SIP to MNCC and MNCC to MNCC
structure in the future.
Keith Whyte
Holger Hans Peter Freyther