[Home]

Summary:ASTERISK-07026: SIPCHANINFO(peername) Function returns null value
Reporter:Bruce Reeves (nortex)Labels:
Date Opened:2006-05-23 15:00:23Date Closed:2006-05-25 12:22:49
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) SIPCHANINFO_debug.log
Description:I have tried on 1.2.3 and 2 1.2.7.1 servers to use the SIPCHANINFO(peername) function with out success. however SIPCHANINFO(peerIP)does return the SIP peers IP address. The show function sipchaninfo show peername as a valid argument.  
Comments:By: Kevin P. Fleming (kpfleming) 2006-05-24 11:03:19

As clearly requested in the bug posting guidelines, _all_ SIP bugs must include a complete console trace showing the call being handled, including 'sip debug'. The SIPCHANINFO function has had no changes recently, so it should still be functional.

I would assume that the reason you are having this problem is that the channel you are calling it on is not associated with a SIP peer at all, but there is no way to know without a console log.
By: Bruce Reeves (nortex) 2006-05-25 11:17:22

Sorry for the delayed debug. Kerry, your assumption is slightly flawed, How would I know the the peerIP argument worked if I had not been actually calling on was associated with a SIP peer? At any rate the debug is uploaded The first section shows the extension of the dial plan I am using the SIPCHANINF in and the syntax and the the sip debug is turned on and a call placed. The NoOp returns the peerIP info but is blank on the peername. I sent a copy of the dialplan section to another asterisk user and he had the same results. My first concern was that the underscore in my SIP peer name was the problem, it failed on sip peers with just numbers for a name.
By: Kevin P. Fleming (kpfleming) 2006-05-25 12:22:49

First, my name is not Kerry, it's Kevin :-)

Second, what I told you was correct, because we _always_ have an IP address for the connected SIP 'peer', even if it was not matched to any peer or user from sip.conf, even if it is an unauthenticated guest call.

However... the problem you found was clearly a bug, because SIPCHANINFO(peername) should show the name of a SIP 'type=user' entry that is placing a call as well, but it did not. This is why the console trace was important, because the 'Found user ...' line was the clue as to what was going on. That's why we request (demand) complete traces before opening any SIP-related bug at all in the bug posting guidelines. This problem would have been solved the first time that I or any other developer looked at it, if the trace had been included :-)

In any case, this has been fixed in branch-1.2 revision 30293 and trunk revision 30294.