Neels Hofmeyr nhofmeyr@sysmocom.de wrote:
I would appreciate if you could explain your concerns. What do you expect to break?
I don't know whether anything will break or not - I will need to take a closer look at your branch - but as a general question, have you given a thought to the possibility of external MNCC agents other than o-s-c that might not wish to deal with SDP? Here is how I currently handle RTP when talking MNCC to OsmoMSC:
* When I receive an MNCC_RTP_CREATE message from OsmoMSC, I expect to find RTP UDP connection info in the addr member of struct gsm_mncc_rtp, I expect to find GSM_TCHF_FRAME etc in the payload_msg_type member, telling me which codec ended up being selected, and I expect to find the right value for the 'payload type' field in RTP packets in the payload_type member. Will all these struct members still be there, so I can get all this info without parsing SDP?
* To complete the RTP connection, I send an MNCC_RTP_CONNECT message to OsmoMSC, with only the addr member filled in, giving my side of RTP UDP - will your new version still accept such "bare minimum" MNCC_RTP_CONNECT messages without SDP?
* I never send MNCC_RTP_CREATE to OsmoMSC - reading o-s-c code, I see that it sends such, but I never bothered, because the only effect is to initiate channel assignment, and the same trigger already happens as part of "main" MNCC signaling message handling.
Maybe we can prevent that before it gets merged.
I will need to allocate some time to review your branch a little closer, and hopefully also test it.
M~