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 or if it is called with force_rewrite then it should rewrite it and if one
                   puts something without '@' it should try to rewrite it back or return () if it
                   cannot be rewritten 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
                   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 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.

                   Note that some servers apply length limitiations to the contact so the
                   function should not return too long values.

           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.  The optional third argument
                   "add2mac" should be included in 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 not defined, then RC4 will be used with a (pseudo)random key, 4 byte
                   (pseudo)random seed and 4 byte MAC (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