|Summary:||ASTERISK-08810: Retrieve peer address of inbound call.|
|Reporter:||Bluce Ree (tasker)||Labels:|
|Date Opened:||2007-02-14 13:19:15.000-0600||Date Closed:||2007-03-19 08:33:10|
|Description:||There is currently no uniform way of retrieving the IP address of an incoming call. Many implementations in the carrier world will accept inbound calls dynamically and will not define every single possible peer in the corresponding driver's .conf file but instead authenticate the call against a list of IPs from a database or other source.|
Currently, there is SIPCHANINFO(recvip) under SIP and IAXPEER() under IAX. There is no way to do this under H.323 currently (all H.323 drivers). The method should be more general rather than protocol specific.
|Comments:||By: Bluce Ree (tasker) 2007-02-19 16:16:20.000-0600|
One workaround was to extract it from the channel name when using ooh323. The method works unreliably as the chan_ooh323 prefers to use the username instead of the ip address so I added this piece of code:
p->host = strdup(call->remoteIP);
That was applied on line 1283 of chan_ooh323 in Addons 1.4.0 in ooh323_onReceivedSetup().
Isn't there a more uniform way of retrieving recv IP from within asterisk? I looked through the code and could not find anything that keeps a reference of the inbound port information. The most obvious place for this sort of information would be the CHANNEL() function using the field 'recvip'.
Destination IP address would also be useful since H.323 gatekeepers and SIP Proxy servers may forward calls directly to an endpoint and the terminating IP is not necessarily known before establishing the call.
By: Olle Johansson (oej) 2007-02-20 00:45:23.000-0600
The bug guidelines says that the bug tracker is no longer used for feature requests. Please use the asterisk-dev mailing list for this kind of discussions!
By: Bluce Ree (tasker) 2007-03-16 22:37:30
Is this really a feature request or consequence of an oversight, which could make it a bug?
By: Serge Vecher (serge-v) 2007-03-19 08:33:10
Bug is when Asterisk does not behave as documented or against standards. This case is neither, so it's a feature request. Please do not reopen bugs closed by a bug-marshall, unless you have a disclaimed patch implementing the feature.