Looks good to me. @kb2ma do you see any reason not to expose this?

I understand the need. Let me think over the weekend about how this fits in the bigger picture.

I agree that we could add the coap_udp_ep_t* remote value as an attribute of coap_pkt_t, and this approach has the advantage of being a simple solution. However, I recommend that we use this need to make gcoap more extensible for the future with the addition of a context struct.

IMO coap_pkt_t is not a great fit for the nature of the data because the remote endpoint is not a part of the CoAP PDU. For client requests the remote is provided directly to gcoap_req_send(), so it's just using up space in that context. In addition, adding the attribute to the PDU means there are now two sources for the remote in gcoap's server side handling in _handle_req() as well as _find_obs_memo().

So similar to #9857, I think it is worthwhile to add a separate struct for server side handling. Let's call it gcoap_recv_ctx_t. This struct could hold the coap_udp_ep_t*, and gives us a place to turn this into a union for different transports and add an attribute to identify the union member. It also future proofs this pathway for passing data to the application. Maybe OSCORE would find it useful. We also could move the current observe_value attribute in here.

The downside to this approach is the limitation of the coap_resp_handler_t function definition to pass this data to the application handler. In this case we could specify a convention for gcoap that the void* context must be cast to a gcoap_recv_ctx_t* by the application. In this case the void* context itself must be moved to an attribute of the gcoap_recv_ctx_t struct.

I don't think this change to coap_resp_handler_t use will be too intrusive, but that depends on how much the context pointer is used at present. We could provide a macro based migration mechanism by defining GCOAP_REQ_HANDLER_CONTEXT_VOID and GCOAP_REQ_HANDLER_CONTEXT_CTX. When VOID, the code would work as it does at present.

I am a proponent of these context structs as a way to accommodate growth in an API. #13637 is now another example from today that can be served in this way. Let me know what you think.

Agree. Closing in favor of #13819