Net::S...sProxy(3pm)

💖 Net::SIP::StatelessProxy — the vibe

okay bestie, so this is Net::SIP::StatelessProxy, aka Simple implementation of a stateless proxy ✨ It's a Perl module, it lives in the User Contributed Perl Documentation part of your manual, and it is exactly what it says on the tin: a lil stateless SIP proxy that just... forwards stuff. No drama, no memory, no cap. 🫶

---

🌸 SYNOPSIS 🌸

..

that's it. that's the synopsis. iconic behavior honestly. 💅

---

✨ DESCRIPTION ✨

This package implements a simple stateless SIP proxy. The basic idea is that the proxy has either a single leg or two legs, and packets get exchanged between those legs — like, packets coming in on one leg get forwarded out through the other leg. Simple as. 🦋

Because this is a stateless proxy, no retransmits will be done by the proxy. It does not remember anything. It is not keeping receipts. It forwards and moves on. periodt. 💀

If you want the proxy to work as a registrar too, it should be put after a Net::SIP::Registrar inside a Net::SIP::ReceiveChain. order matters, bestie.

While forwarding, the proxy will insert itself into the packet — meaning it adds Via and Record-Route headers while forwarding requests. main character energy, honestly. 👑

On top of that, it rewrites the Contact header while forwarding packets (more on that below). So if the Contact header points to some client, it rewrites it so it points to the proxy instead. And if it already points to the proxy, it rewrites it back so it points to the client again. it's giving ✨ reversible makeover ✨

---

🎀 CONSTRUCTOR 🎀

• new ( %ARGS ) — Creates a new stateless proxy. The %ARGS let you influence the behavior, and here's every single knob:
  • dispatcher — The Net::SIP::Dispatcher object that manages the proxy. your manager, your bestie, your handler.
  • rewrite_contact — Callback used in rewriting Contact headers. If you put user@host in it, or if it's called with force_rewrite, then it should rewrite it. And if you put in something without an '@', it should try to rewrite it back — or return () if it can't be rewritten back.

A working default implementation is provided, so you don't have to write this. But if you wanna implement your own: the callback gets the arguments contact, incoming_leg and outgoing_leg and force_rewrite.

For rewriting a contact of user@host, the legs will be Net::SIP::Leg objects. For rewriting the contact back, outgoing_leg can be either a leg object — and you should check if it's the expected leg — or it can be a scalar reference, which you should fill with the leg extracted from the contact.

The function should return the new contact, or nothing if there was nothing to rewrite or if the rewrite failed. 🫠

Note that some servers apply length limitations to the contact, so the function should not return too long values. keep it cute AND short, bestie.

• rewrite_crypt — If you want your own encryption for the rewritten contact, define a subroutine here. It gets "data" as the first parameter and "dir" as the second, and it should return the de/encrypted data. If "dir" is +1 it should encrypt, and on -1 it should decrypt. The optional third argument "add2mac" should be included in the calculation and verification of the MAC. The function should return the encrypted/decrypted data, or undef if decryption failed because the MAC did not match. 🚨

If this is not defined, then RC4 will be used with a (pseudo)random key, a 4 byte (pseudo)random seed, and a 4 byte MAC (md5) over the seed and data. default slay. 🔥

• nathelper — Optional Net::SIP::NATHelper::* object. When you give it one, it'll be used to do NAT — like, if the incoming and outgoing legs are different, it will rewrite the SDP bodies to use local sockets, and the nathelper will transfer the RTP data between the local and the original sockets. 🧚
• force_rewrite — Usually the Contact header will only be rewritten if the incoming and outgoing leg are different. With this option you can force the rewrite, even if they're the same. do it anyway, bestie. 💅

---

⭐ METHODS ⭐

• receive ( PACKET, LEG, FROM ) — PACKET is the incoming packet, LEG is the Net::SIP::Leg where the packet arrived, and FROM is the "ip:port" of the sender.

Called from the dispatcher on incoming packets. The packet gets rewritten ("Via" and "Record-Route" headers added, Contact modified), and then the packet gets forwarded. bye bestie 👋

For requests, it can figure out the target of the forwarded packet by looking at the route — or if there's no route, it looks at the URI. For responses, it looks at the next Via header. iykyk. 🦋

• do_nat ( PACKET, INCOMING_LEG, OUTGOING_LEG ) — This gets called from receive while forwarding data. If nathelper is defined, it'll be used to rewrite SDP bodies and update the nathelper's internal states so RTP data gets forwarded. 🔄

Return values work like forward_outgoing in Net::SIP::Leg — meaning it returns "[code,text]" on error, or () on success. And "success" can mean either that the packet was rewritten, or that there was no need to touch it at all. either way, we're winning. 🏆

---

🙈 UNDOCUMENTED METHODS 🙈

• idside2hash — no docs, no explanation, just vibes. we don't talk about it. 💀

---

and that's the whole page, bestie!! every flag, every arg, every callback, every byte accounted for. go forth and forward packets statelessly. 🫶

this has been Net::S...sProxy(3pm) from the User Contributed Perl Documentation crew, running on perl v5.40.1, dated 2025-12-07. mwah. 💖✨🎀