Neels Hofmeyr <[email protected]> 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~
