There are certain elements of the channel driver data, specifically the 
channel specific pvt data that would be convenient to access from higher 
level applications.  The specific problem I encountered was to access 
the incoming IP address of a particular channel driver.

Each channel driver (chan_sip.c, chan_h323.c, etc) has a unique method 
of managing and storing incoming and outgoing IP address and RTP port 
management; in chan_sip the structure is sip_pvt, in chan_h323 it is 
oh323_pvt - similar facilities are found in chan_mgcp and chan_woomera.

In my case I needed access to the incoming IP address of calls coming in 
via chan_sip and chan_h323.  Each of these channel drivers carries this 
information in a static struct belonging to the specific driver that 
cannot be readily accessed from external modules... UNLESS the struct 
references are replicated in the local source code.

What I did to combat this problem was to alter the sip_pvt struct (in 
chan_sip) and the oh323_pvt struct (in chan_h323.c) to reflect the 
sockaddr_in sa reference the top of each struct such that I could reach 
them ubiquitously via a "psuedo struct" in my local source code that was 
something like:
struct psuedo_pvt {
   struct sockaddr_in sa;
} *_pvt;

In this way I could cause _pvt = chan->tech_pvt and then derive the each 
of the incoming IP of each channel as _pvt->sa.sin_addr

Fortunately for me, each of chan_sip.c and chan_h323.c carried the 
incoming IP address as "sa" in the respective pvt structs - chan_mgcp 
and chan_woomera required more effort but similarly work in the same 
fashion.

I'm certain that there are other such references that each channel 
driver has to have that would be convenient for developers to have 
access to.

I'd like to propose that at least some elements of the channel specific 
pvt data be normalized and required at the top of each structure such 
that they can be reached more conveniently via 3rd party modules.  
Off-hand references to incoming IP, RTP ports and lock variables would 
be good candidates.

Any thoughts?
_______________________________________________
Callweaver-dev mailing list
[email protected]
http://lists.callweaver.org/mailman/listinfo/callweaver-dev

Reply via email to