[Home]

Summary:ASTERISK-04578: [patch] Function to retrieve SIP channel information
Reporter:otmar (otmar)Labels:
Date Opened:2005-07-13 09:38:22Date Closed:2008-01-15 15:44:47.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) chan_sip_chaninfo.diff
Description:This patch to res_agi.c and chan_sip.c does three things:

1) fill the channel->tech_pvt->from field. From reading the definition of sip_pvt it seems clear to me that the information from the From: header should be placed in there, but (at least for incoming SIP-calls) it never is.

I'm not quite sure whether I found the right place for that line of code, but this single-line solution looked fine to me.

2) export some more SIP-specific information into channel variables

3) When running AGI scripts, pass these SIP-related channel variables to the ago script. Strictly speaking, this part of the patch is not that necessary as the AGI script could fetch this information with $AGI->get_variable calls.

****** ADDITIONAL INFORMATION ******

Thanks to dbruce@transit2.bananatel.com for the hint on asterisk-dev.
Comments:By: Michael Jerris (mikej) 2005-07-13 09:42:20

I think that the additional coppying of vars to the agi script is probably not the way to go, just grab them when you need them, then everybody does not have to take the hit for it...
By: otmar (otmar) 2005-07-13 09:57:39

That's ok for me.

I just *really* need access to the IP-address of the SIP peer and the From: header from an incoming SIP call. The rest is icing on the cake and may simplify the AGI coding a bit.

Passing all variables AGI scripts has the advantage that I do not have to query all possible names to know which variables are there. AFAIK there is no "list all variables"-AGI command.
By: Kevin P. Fleming (kpfleming) 2005-07-13 12:26:43

I'm going to veto this one for architectural reasons; I don't want every system everywhere to carry the burden of these additional variables being set for no reason.

Instead, make chan_sip export a dialplan function call SIPCHANNELINFO (or SIPCALLINFO, or something like that) that takes arguments for what pieces of information to pick out of the chan_sip private structure and return as strings into an expression. This can then be used only when needed in the dialplan, or via AGI.

While you're at it, you can implement a SIPPEER function like the IAXPEER function :-)
By: otmar (otmar) 2005-07-14 08:13:52

ok, I'll take a look at IAXPEER and will check if I can come up with something similar for SIP.

Meanwhile, please apply the single-line patch which saves the From: header to the sip_pvt structure. I'll need that even if I succeed writing a SIPPEER function.
By: otmar (otmar) 2005-07-14 11:50:26

Meanwhile I've been testing how to access asterisk functions (in contrast to applications) from AGI scripts.

That cost me a few grey hairs.

The AGI EXEC command does not find functions. You have to work around a bit. I finally found the following to be reasonably simple (using the Asterisk::AGI perl module):

$AGI->exec("EVAL",'BLU=${SIP_HEADER(From)}');
$test = $AGI->get_variable('BLU');

Is there a better way?
By: dbruce (dbruce) 2005-07-15 05:04:28

As requested, a patch for chan_sip to impliment the sippeer function (al la iaxpeer).

Shamelessly ripped from chan_iax2.c and modified for chan_sip.c (ie: trivial changes, so a disclaimer shouldn't be needed, but one is on file anyways...)

diff -u based on CVS-HEAD-2005-07-15
By: otmar (otmar) 2005-07-15 08:03:29

I've started to do something similar, but you were faster.

Anyway, I will have to modify your solution as I need to access data from an anonymous incoming SIP call, and as fas as I can see it, there is no sip_peer object for such calls.
By: otmar (otmar) 2005-07-15 11:31:37

I've amended the patch from dbruce such that it also creates a function SIP_PARAM which can be used to query parameters from the sip_pvt structure of the current channel.

As mentioned before, the SIPPEER call doesn't help me on anonymous sip calls.
By: Kevin P. Fleming (kpfleming) 2005-07-15 17:11:00

Please work with joshnet on this one, as we already discussed on the conference call yesterday a generic solution for obtaining information from active channels.

This is a separate issue from the SIPPEER function, which I'll now review :-)
By: Kevin P. Fleming (kpfleming) 2005-07-15 17:12:06

dbruce: let's move the SIPPEER patch to a new bug, so you can directly indicate whether you have a disclaimer on file or not...
By: dbruce (dbruce) 2005-07-16 15:57:06

done.

added as bug ASTERISK-4606
By: Olle Johansson (oej) 2005-07-18 03:40:42

I don't like the name "SIP_PARAM" for getting data from a SIP call data structure. Can we come up with a better name?
By: otmar (otmar) 2005-07-18 04:34:57

oej,

actually, my first plan was to use "SIPPEER" as this function retrieves information about the current peer of this channel. But then I noticed that IAXPEER and dbruce's SIPPEER refer to preconfigured peer objects and not to the entity this channel is just now talking with.

How about SIPCALLINFO? SIPCALLPEER?
By: Olle Johansson (oej) 2005-07-20 07:51:02

We already have a SIPPEER function, so that one needs to go out of this patch.

Also, as you see, all functions in chan_sip have comments. Please add comments to your additions, as well as the source in general, to make it easier for others to follow.

SIPCHANINFO might be a good name. A "call" is very unspecified terminology in regards to Asterisk, it contains at least two channels :-) A channel might not have a "peer" from sip.conf or realtime, so including "peer" in the name is misleading.
By: otmar (otmar) 2005-07-27 07:36:07

argh. I should have checked the logs before coding again.

The patch names the function SIPCHANNEL and not SIPCHANINFO as oej suggested.I'll try to get hold of joshnet for furthre input.
By: Olle Johansson (oej) 2005-07-27 10:19:17

You need make sure you check that the channel is alive as well (se recent patches to sip_header in another bug report).
By: otmar (otmar) 2005-07-27 11:28:32

I've renamed the function and added the same check as in sip_header.
By: Olle Johansson (oej) 2005-07-27 11:58:21

Why are you re-using the from variable in that way instead of using the caller ID? Are you really sure that you are not disturbing anything by using the "p->from" ?
By: otmar (otmar) 2005-07-27 15:15:49

For my application, I need the SIP From address (not the comment aka realname, nor the username, but the full uri). I did not see that captured by any standard channel variables. The userpart, yes. But not sip:username@domain.

IIRC from my debugging, the callerp->from is never set in case no matching peer entry is found. It's hardly ever used even in calls from defined peers. My application focusses on random SIP calls from all over the Internet, thus the patch.

I could work-around by using SIP_HEADER(From) and then parse out the URI once again, but why do that when it's already done in the place where I capture it to p->from? After all p->uri is set in a similar way.
By: Olle Johansson (oej) 2005-07-28 02:14:12

I just don't like re-using structure members for other purposes. It will lead to problems somewhere along the road. Let me take a look and come up with a suggestion...
By: Kevin P. Fleming (kpfleming) 2005-08-22 17:11:58

I agree that p->from is rarely used in chan_sip as it stands today, so it's safe to re-use for this purpose.

Committed to CVS HEAD, thanks!
By: Digium Subversion (svnbot) 2008-01-15 15:44:47.000-0600

Repository: asterisk
Revision: 6357

U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r6357 | kpfleming | 2008-01-15 15:44:46 -0600 (Tue, 15 Jan 2008) | 2 lines

add SIPCHANINFO function to retrieve information about the current connected SIP endpoint (issue ASTERISK-4578)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=6357