[Asterisk-Dev] Passing SIP parameters to AGI scripts: coding adviceneeded

[dbruce]

It may be "easier" for you to export the parameters from the inbound SIP
call to channel variables. Add code to the *sip_new routine to set the
variables with the call information you need. No need to modify any
structures. I use this to capture the IP address of the calling device into
the CDR. The current SIP driver already does this to expose the URI, DOMAIN,
USERAGENT and CALLID to the dialplan.

Regards,

Derek Bruce


----- Original Message -----
From: "Otmar Lendl" <lendl at nic.at>
To: <asterisk-dev at lists.digium.com>
Sent: Tuesday, July 12, 2005 9:12 AM
Subject: [Asterisk-Dev] Passing SIP parameters to AGI scripts: coding
adviceneeded


> Hi,
>
> for some AGI scripts which I was asked to write I need access to more
> than the usual range of parameters which are passed to AGI scripts.
>
> In my case, all (interesting) calls will come in via SIP and for my
> processing logic, I need details like the IP-address of call-originating
> SIP server, the AoR of the caller, and perhaps some RTP parameters.
>
> Digging through the code I saw that the AGI environment is created by
> setup_env in res_agi.c. The only sip-relevant parameters I see there
> are e.g. 'channel' => 'SIP/proxy01.sipphone.com-4081a160', callerid and
> 'type' => 'SIP'.
>
> My first guess was that adding the appropriate fdprintf calls shouldn't
> be a problem, but I was wrong.
>
> Within res_agi.c, I do not have access to the definition of struct
> sip_pvt, and thus I can't access the data stored in chan->tech_pvt.
>
> Ok, I thought, then let's create a function in chan_sip.c which prints
> out the AGI header lines. This doesn't seem to be viable either, as
> chan_sip is dynamically loaded and I can't just call an arbitrary
> function from there.
>
> --------------------------
>
> So what is the best way of doing this? As I see it the correct way seems
> to be to augment the ast_channel_tech structure and add capability to
> output tech-specific AGI parameters there.
>
> Is this assessment correct?
>
> And if yes, would a patch doing this get accepted into the mainstream
> codebase?
>
> /ol
> --
> < Otmar Lendl (lendl at nic.at) | nic.at Systems Engineer >
> _______________________________________________
> Asterisk-Dev mailing list
> Asterisk-Dev at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-dev
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev