It's really not a big deal. I called deliver, which in turn called __deliver. I wasn't treating leg or dst_addr as arrays which caused __deliver to ignore them, allowing it to fall through to line 604, which is only used if leg or dst_addr aren't properly defined. Line 604 would still work for requests, but not for responses.
Here's the code that triggered the error:
$sip_dispatcher->deliver( $packet->create_response(200, {"Content-Type" => 'application/sdp'},"v=0
o=- $dt $dt IN IP4 $call{My_SIP_IP}
s=Polycom IP Phone
c=IN IP4 $call{My_SIP_IP}
t=0 0
a=sendrecv
m=audio $my_rtp_port RTP/AVP 0 101
a=sendrecv
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000"
),
leg => $sip_leg,
dst_addr => {addr => $call{Peer_SIP_IP}},
do_retransmits => 0 );
Putting square brackets around the leg and dst_addr assignments made it work (the .pod does not indicate these are to be treated as arrays -- I only figured that out from the code).
My suggestions are 1) make it clear in the documentation that you expect arrays for those arguments and 2) fail more gracefully if the uri method isn't available. I think 1) is more important.
Thanks!
Show quoted text> On Dec 6, 2017, at 11:22 PM, Steffen Ullrich via RT <bug-Net-SIP@rt.cpan.org> wrote:
>
> <URL:
https://rt.cpan.org/Ticket/Display.html?id=123829 >
>
> Am Mi 06. Dez 2017, 19:23:18, cpan@newgrovetech.com schrieb:
>> Bug in Net::SIP::Dispatcher.pm line 604:
>>
>> Assumes uri method is available for all packet objects.
>>
>> The method is only available for Net::SIP::Request, not for
>> Net::SIP::Packet or Net::SIP::Response.
>
> __deliver is an internal function which makes certain assumption about how it is called and what data are provided. One of the assumptions is that for response packets the address and leg for delivery should already been known and thus we deal with a request at the specific code position. If you feel that this assumption is not true please provide the use case and code where this is not true so I can have a closer look at how to handle this issue.
>
>