Steffen Ullrich > Net-SIP-0.68 > Net::SIP::Request



Annotate this POD


Open  0
Stalled  1
View/Report Bugs
Source   Latest Release: Net-SIP-0.687


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


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


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


  # create INVITE request
  my $invite = Net::SIP::Request->new(
        'INVITE', '',
        { 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


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



Get method of request.


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.


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

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

syntax highlighting: