Net::SIP::Request(3pm)

NAME

Net::SIP::Request - handling of SIP request packets

SYNOPSIS

  my $req = Net::SIP::Request->new( 'INVITE',... );
  my $ack = $req->create_ack();

DESCRIPTION

Subclass of Net::SIP::Packet for handling request packets. Has methods to create responses to requests and to authorize requests.

EXAMPLES

  # create INVITE request
  my $invite = Net::SIP::Request->new(
        'INVITE', 'sip:[email protected]',
        { from => ..., to => ... },
        Net::SIP::SDP->new( ... )
  );
  # somehow send request and retrieve response $resp
  ...
  if ( $resp->code eq '401' or $resp->code eq '407' ) {
        # need to authorize request
        $invite->authorize( $resp, [ username, password ] );
        # somehow send again and retrieve response $resp
        ...
  }
  if ( $resp->code ~m{^[2345]\d\d} ) {
        # got final response, send ACK
        my $ack = $invite->create_ack( $resp );
        # somehow send $ack
        ...
  }

CONSTRUCTOR

Inherited from Net::SIP::Packet. See there.

METHODS

method: Get method of request.

uri: Get URI part of request.

set_uri ( STRING ): Set URI of request to STRING

set_cseq ( NUMBER ): Set sequence number if "CSeq" header to NUMBER.

create_ack ( RESPONSE ): Returns Net::SIP::Request object for ACK request for the case when Net::SIP::Response RESPONSE was received in reply for packet $self.

create_cancel: Returns Net::SIP::Request object to cancel request in $self.

create_response ( CODE, [MSG,] [ \%HEADER, BODY ] )

Returns Net::SIP::Response packet for the received request $self with numerical code CODE and text message MSG. Header for the response will be based on the request, but can be added or overridden using \%HEADER. If MSG is not given (e.g. argument is missing, second argument is \%HEADER already) a builtin message for the code will be used.

For details to \%HEADER and BODY see new_from_parts in Net::SIP::Packet.

authorize ( RESPONSE, AUTH )

Tries to authorize request $self based on the information in RESPONSE (a 401 or 407 "Authorization required" response) and AUTH. AUTH is either "[ user,pass ]" if a global authorization info exists for all realms or "{ realm1 => [ user1,pass1 ], realm2 => [ user2,pass2 ],... }" if different credentials are provided for different realms or a callback "callback(realm)->[user,pass]". The realms, for which authorization is needed, are read from RESPONSE.

The request $self is modified in-place. If a modification occurred, e.g. if (parts of) the authorization requests could be resolved it will return TRUE, else FALSE.