302 reply *forces* redirection

[whosgonna]

Is there any way to optionally NOT force a forward on a 302 response? In a variety of situations it may not be desirable to follow the contact header.

Right now I've simply commented out the code in my local copy, but this could be probably controlled with:

• A dedicated callback for 3xx
• A dedicated callback for raw replies before any other handling (if there is one, I apologize for missing it)
• A boolean value in the Endpoint, etc. to ignore this type of behavior.

Thoughts?

[kobaz]

I opened #66 recently to address the lack of a generic response callback handler to handle things like 3xx

[kobaz]

I'm working on the subclass implementation instead of using a modified Net::SIP

new MyLeg=HASH(0x560ad133b780) MyLeg
Foo UA->Loop Start
Leg Receieve: MyLeg=HASH(0x560ad133b780) 100 -- Trying
Foo Preliminary Response: 100
Leg Receieve: MyLeg=HASH(0x560ad133b780) 302 -- Moved Temporarily
Leg Receieve: MyLeg=HASH(0x560ad133b780) 100 -- Trying
Foo Preliminary Response: 100
Leg Receieve: MyLeg=HASH(0x560ad133b780) 302 -- Moved Temporarily
Leg Receieve: MyLeg=HASH(0x560ad133b780) 100 -- Trying
Foo Preliminary Response: 100
Leg Receieve: MyLeg=HASH(0x560ad133b780) 302 -- Moved Temporarily
Leg Receieve: MyLeg=HASH(0x560ad133b780) 100 -- Trying
Foo Preliminary Response: 100
Leg Receieve: MyLeg=HASH(0x560ad133b780) 302 -- Moved Temporarily
Leg Receieve: MyLeg=HASH(0x560ad133b780) 100 -- Trying
Foo Preliminary Response: 100
Leg Receieve: MyLeg=HASH(0x560ad133b780) 302 -- Moved Temporarily
Leg Receieve: MyLeg=HASH(0x560ad133b780) 100 -- Trying
Foo Preliminary Response: 100
Leg Receieve: MyLeg=HASH(0x560ad133b780) 302 -- Moved Temporarily
Leg Receieve: MyLeg=HASH(0x560ad133b780) 100 -- Trying
Foo Preliminary Response: 100
Leg Receieve: MyLeg=HASH(0x560ad133b780) 302 -- Moved Temporarily
Leg Receieve: MyLeg=HASH(0x560ad133b780) 100 -- Trying
Foo Preliminary Response: 100
Leg Receieve: MyLeg=HASH(0x560ad133b780) 302 -- Moved Temporarily

using the code:
package MyLeg;

use base 'Net::SIP::Leg';

use warnings;
use strict;
use feature 'say';

use Digest::MD5 'md5_hex';
use Socket;
use Net::SIP::Debug;
use Net::SIP::Util ':all';
use Net::SIP::SocketPool;
use Net::SIP::Packet;
use Net::SIP::Request;
use Net::SIP::Response;
use Errno qw(EHOSTUNREACH EINVAL);
use Hash::Util 'lock_ref_keys';
use Carp;

use Data::Dumper;

use fields qw(_leg_responses);

sub new {
    my $class  = shift();
    my ($opts)  = @_;

    my $self = $class->SUPER::new(@_);

    # Keep track of Incoming SIP
    $self->{_leg_responses} = [];

    say "new $self $class";

    return $self;
}

sub receive {
    my $self = shift;
    my ($packet,$from) = @_;

    my $response = $packet;

    my $code   = $response->code();
    my $msg    = $response->msg();

    say "Leg Receieve: $self $code -- $msg";

    $DEBUG && DEBUG( 2,"received packet on %s from %s:\n%s",
        sip_sockinfo2uri($self->{proto},@{$self->{src}}{qw(addr port family)}),
        sip_sockinfo2uri(@{$from}{qw(proto addr port family)}),
        $packet->dump( Net::SIP::Debug->level -2 )
    );

    # Trying
    goto done if ($code eq '100');

    if ($code eq '302') {
      # do some stuff
    }

   done:
    return ($packet, $from);
}

I can't make the 302 stop processing.  Net::SIP will send infinite INVITE and keep looping until the timeout

[kobaz]

Found the problem:
Net/SIP/Endpoint/Context.pm -- It seems impossible to force Net::SIP to avoid internally processing the 302 and sending an outgoing INVITE in response.

You mentioned subclassing Net::SIP::Leg, but the limitation in handling 302 in Endpoint::Context makes this not possible.

You can write your own receive logic in a subclassed Net:SIP::Leg, but internally, Endpoint::Context will always take over and send an INVITE for the 302. It does not look possible to change this behavior simply by subclassing Net::SIP::leg.

I have a patch to add a callback which will allow to interrupt the flow for 302 and do your own user-defined handling:

I will also submit a PR for this. I think this is a great feature to have.
302.patch.txt

[kobaz]

@whosgonna would you mind giving feedback on this patch? Thanks