megaco_transport(3)

πŸ“¦
version 29.0.6 Β· 2 versions
, in nixos 26.05, nixpkgs unstable, ubuntu stonking

πŸ’– megaco_transport β€” the transport behaviour, bestie πŸ’–

okay so this is megaco_transport, from the Erlang module definition corner of the manual. if you're writing a Megaco transport callback module, this is literally your to-do list. no cap.


✨ DESCRIPTION ✨

so like, here's the thing β€” these functions are the ones your megaco_transport callback module should export, mmkay? πŸ‘‘

  • send_message/2 β€” mandatory, like you have to. no skips. πŸ’…
  • send_message/3 β€” optional πŸŽ€
  • resend_message/2 β€” optional πŸ¦‹

🌸 CALLBACKS 🌸

🫢 resend_message(Handle, Msg)

bestie. this one re-sends a megaco message. that's the whole gig. ✨

ngl, there's a little gatekeeping happening here: this function only ever gets called if the user has set the resend_indication config option to true and it is in fact a message resend. if those two conditions aren't both met, then send_message gets called instead. periodt.

and here's the spicy part 🌢️ β€” if the function returns {cancel, Reason}, that means the transport module decided not to send the message. this is not an error, okay? no error messages will be issued and no error counters incremented. what actually happens next depends on what kind of message was being sent:

  • in the case of requests, megaco will cancel the message in much the same way as if megaco:cancel had been called (after a successfull send). the info gets propagated back to the user differently depending on how the request(s) where issued: if you used megaco:call, the info will be delivered in the return value. if you used megaco:cast, the info will be delivered via a call to the callback function handle_trans_reply. πŸŒ€
  • in the case of reply, megaco will cancel the reply and information of this will be returned to the user via a call to the callback function handle_trans_ack. πŸ’Œ

πŸ’œ send_message(Handle, Msg, Resend)

okay so this is the send-a-megaco-message one. ✨

if the function returns {cancel, Reason}, this means the transport module decided not to send the message. this is not an error β€” no error messages will be issued and no error counters incremented. what actions this will result in depends on what kind of message was sent:

  • in the case of requests, megaco will cancel the message in much the same way as if megaco:cancel had been called (after a successfull send). the information will be propagated back to the user differently depending on how the request(s) where issued: for requests issued using megaco:call/3, the info will be delivered in the return value. for requests issued using megaco:cast the info will be delivered via a call to the callback function handle_trans_reply. πŸŒ€
  • in the case of reply, megaco will cancel the reply and information of this will be returned to the user via a call to the callback function handle_trans_ack. πŸ’Œ

and the tea on send_message/3 β˜• β€” this one only gets called if the resend_indication config option has been set to the value flag. the third argument, Resend, then indicates if the message send is a resend or not. that's it, that's the vibe check. πŸ‘‘

🚨 reminder bestie: send_message/2 is the mandatory one, send_message/3 and resend_message/2 are optional. don't come for me if you skip an optional one, but you absolutely cannot skip the mandatory one. iykyk.

and that's the whole page, fr fr πŸ’– this iconic little number is brought to you by Ericsson AB, living in megaco 4.9.2, answering to the name megaco_transport(3). slay, bye bestie πŸŽ€βœ¨πŸ¦‹

πŸ“¦ where this page comes from