Neels Hofmeyr <nhofmeyr(a)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~