Skip Menu |

This queue is for tickets about the Net-SIP CPAN distribution.

Report information
The Basics
Id: 123829
Status: rejected
Priority: 0/
Queue: Net-SIP

People
Owner: Nobody in particular
Requestors: cpan [...] newgrovetech.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: Bug in Net::SIP::Dispatcher.pm
Date: Wed, 6 Dec 2017 16:59:20 -0700
To: bug-Net-SIP [...] rt.cpan.org
From: H Nylund <cpan [...] newgrovetech.com>
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.
Am Mi 06. Dez 2017, 19:23:18, cpan@newgrovetech.com schrieb: Show quoted text
> 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.
Subject: Re: [rt.cpan.org #123829] Bug in Net::SIP::Dispatcher.pm
Date: Thu, 7 Dec 2017 00:14:25 -0700
To: bug-Net-SIP [...] rt.cpan.org
From: H Nylund <cpan [...] newgrovetech.com>
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. > >
Show quoted text
> > 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.
Dispatcher::deliver does not expect arrays for leg and dst_addr. In fact deliver is called within the library usually with these parameters not being arrays. Can you please provide a minimal but still complete example how you've triggered the problem so that I can reproduce it? Regards, Steffen