The Perl Toolchain Summit needs more sponsors. If your company depends on Perl, please support this very important event.

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:you@example.com',
    { 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 overriden using \%HEADER.

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. 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.

Supports only RFC2617 with md5 and empty qop or qop 'auth', not md5-sess or qop's like 'auth-int'.