Attention is currently required from: jolly, pespin.

View Change

1 comment:

• File src/twjit.c:

  • Patch Set #2, Line 504: rtph = osmo_rtp_get_hdr(msg);

    Fair enough: I'll add this option to the next iteration of the present patchset. However, something to note a little more generally:

    from experience I recall due to how some 3rd party CN generates RTP this will be needed.

    Should I interpret this comment as meaning that if these patches were to be merged (the present patchset, then OsmoBTS patches to allow selection between ortp and twrtp), then you anticipate the option of twrtp (instead of ortp) to be used by more than just those who choose to use the full Osmocom+ThemWi stack? IOW, do you expect some users of non-ThemWi Osmo-interfacing CN to switch from ortp to twrtp when the latter becomes available as an option? If so, then two responses from me:

    • On the one hand, I would be delighted to see my contribution used in such totally unexpected way;
    • On the other hand, I would be highly concerned that twjit won't work well in that environment - it is really not designed for any applications outside my closed-minded (if you wish to call it so) approach of emulating TDM. Sure, I'll add the option to act on M bit like you ask, treating it as handover - but are you sure there won't be other show-stoppers that would break the use of twjit in environments that aren't TDM-minded like ThemWi? That non-ThemWi CN you are thinking of, will it ever emit a sequence of gap, then a lonely packet (e.g., periodic comfort noise update), then another gap? If so, then twjit will not handle it well - see the last bulleted paragraph in document section 2.3.5.

    Also, are there really people other than me who would want to use something other ortp in OsmoBTS? I thought everyone other than me were totally happy with ortp and hence would have no desire to use twrtp+twjit instead...

To view, visit change 39280. To unsubscribe, or for help writing mail filters, visit settings.