Change in osmo-hnodeb[master]: First implementation of the LLSK audio SAPI

[laforge]

laforge has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-hnodeb/+/26502 )

Change subject: First implementation of the LLSK audio SAPI
......................................................................


Patch Set 2:

(4 comments)

https://gerrit.osmocom.org/c/osmo-hnodeb/+/26502/2/include/osmocom/hnodeb/hnb_prim.h 
File include/osmocom/hnodeb/hnb_prim.h:

https://gerrit.osmocom.org/c/osmo-hnodeb/+/26502/2/include/osmocom/hnodeb/hnb_prim.h@173 
PS2, Line 173: HNB_AUDIO_PRIM_CONN_ESTABLISH,
             : 	HNB_AUDIO_PRIM_CONN_RELEASE,
             : 	HNB_AUDIO_PRIM_CONN_DATA,
             : 	_HNB_AUDIO_PRIM_MAX
IIRC "DATA" should be "UNITDATA" as there is no retransmission in RTP


https://gerrit.osmocom.org/c/osmo-hnodeb/+/26502/2/include/osmocom/hnodeb/hnb_prim.h@184 
PS2, Line 184: uint8_t remote_rtp_address_type;  /* enum u_addr_type */
             : 	union u_addr remote_rtp_addr;
wouldn't it make sense to define a struct that encapsulates the address type and the union for the payload?  IIRC we alreay have something like this in libosmocore, but of course we want a packed version here :/

In fact, one could also think of adding the port into it,  At that point, you could actually pass a sockaddr_storage around, as it includes type, port and l3 address?


https://gerrit.osmocom.org/c/osmo-hnodeb/+/26502/2/include/osmocom/hnodeb/hnb_prim.h@217 
PS2, Line 217: 	struct osmo_prim_hdr hdr;
as all of your primitives have a context_id, it might make sense to shift the context_id up one layer, out of the union.

This introduced possibilities like a generic function/macro for logigng, to which you pass the entire hnb_audio_prim, and which then dereferences not just the prim-op/... but also the context_id.

You could then have LOGHAP(struct hnb_audio_prim, format, ...)


https://gerrit.osmocom.org/c/osmo-hnodeb/+/26502/2/src/osmo-hnodeb/llsk_audio.c 
File src/osmo-hnodeb/llsk_audio.c:

https://gerrit.osmocom.org/c/osmo-hnodeb/+/26502/2/src/osmo-hnodeb/llsk_audio.c@180 
PS2, Line 180: 		LOGP(DLLSK, LOGL_ERROR, "Rx AUDIO-CONN_ESTABLISH.req: CS chan not active! ctx=%u rem_addr=%s\n",
I think you could introduce a logging macro for printing the 'ctx' in a structured way. Like LOGPCTX() or so?  This way it's guaranteed the formatting is identical everywhere.  Now  you repeate the %u in every line, and most have ctx=%u while at leat two have context_id=%u.

This is important later on if somebody wants to grep the logs.



-- 
To view, visit https://gerrit.osmocom.org/c/osmo-hnodeb/+/26502
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings

Gerrit-Project: osmo-hnodeb
Gerrit-Branch: master
Gerrit-Change-Id: I9909a7c054ddaabb1bb63d7d06331cc79f642b5d
Gerrit-Change-Number: 26502
Gerrit-PatchSet: 2
Gerrit-Owner: pespin <pespin at sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-CC: laforge <laforge at osmocom.org>
Gerrit-Comment-Date: Sun, 12 Dec 2021 07:50:27 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Gerrit-MessageType: comment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20211212/72d8b3af/attachment.htm>