NAME¶
Net::SIP::StatelessProxy - Simple implementation of a stateless proxy
SYNOPSIS¶
..
DESCRIPTION¶
This package implements a simple stateless SIP proxy. Basic idea is that the
proxy has either a single or two legs and that the packets are exchanged
between those legs, e.g. packets incoming on one leg will be forwarded through
the other leg.
Because this is a stateless proxy no retransmits will be done by the proxy.
If the proxy should work as a registrar too it should be put after a
Net::SIP::Registrar in a Net::SIP::ReceiveChain.
While forwarding the proxy will be insert itself into the packet, e.g. it will
add
Via and
Record-Route header while forwarding requests.
Additionally it will rewrite the
Contact header while forwarding packets
(see below), e.g. if the
Contact header points to some client it will
rewrite it, so that it points to the proxy and if it already points to the
proxy it will rewrite it back so that it again points to the client.
CONSTRUCTOR¶
- new ( %ARGS )
- Creates a new stateless proxy. With %ARGS the behavior can be
influenced:
- dispatcher
- The Net::SIP::Dispatcher object managing the proxy.
- rewrite_contact
- Callback which is used in rewriting Contact headers. If one puts
user@host in it should rewrite it and if one puts something without '@' it
should try to rewrite it back (and return () if it cannot rewrite
it back).
A working default implementation is provided. If you want to implement your
own: the callbacks gets the arguments contact, incoming_leg
and outgoing_leg. 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
is the expected leg. Or it is 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 the rewrite
failed.
- rewrite_crypt
- If you want to have your own encryption for the rewritten contact you
should defined a subroutine here, which gets "data" as the first
and "dir" as the second parameter and should return the
de/encrypted data. If "dir" is +1 it should encrypt and on -1 it
should decrypt.
If not defined, then RC4 will be used with a (pseudo)random key, 4 byte
(pseudo)random seed and 4 byte "checksum" (md5) over seed and
data.
- nathelper
- Optional Net::SIP::NATHelper::* object. When given it will be used to do
NAT, e.g. 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 one can force the rewrite,
even if they are the same.
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 will be rewritten
("Via" and "Record-Route" headers added,
Contact modified) and then the packet will be forwarded.
For requests it can determine the target of the forwarded packet by looking
at the route or if no route it looks at the URI. For responses it looks at
the next Via header.
- do_nat ( PACKET, INCOMING_LEG, OUTGOING_LEG )
- This will be called from receive while forwarding data. If
nathelper is defined it will be used to rewrite SDP bodies and
update nathelpers internal states to forward RTP data.
Return values are like forward_outgoing in Net::SIP::Leg, e.g. it
will return "[code,text]" on error or "()" on success,
where success can be that the packet was rewritten or that there was no
need to touch it.
UNDOCUMENTED METHODS¶
- idside2hash