Thomas Monjalon wrote:
The difference with your idea is that in the branch
transport_refactoring, all transport details are in a separate layer
(owsl) that is reusable in other contexts (like RTP).
It is clear that we have to abstract the transport methods, so why
do not implement this in a separated component ?
This is EXACTLY what i'm talking about.....!!!!
So you agree with the implementation of the branch which have a
separated component for the transport layer: owsl.
The interface between this layer and eXosip is in transport_manager
which is a subfolder of eXosip.
No, in the current version of eXosip, all the code is written to
deal with UDP and only one local port and only one proxy. All of
this is global and need many changes.
YES... But with my approach the modifcations to eXosip would be
minimal.....
I don't understand how you can remove the constraints (one proxy, one
port, one transport) without modifying the eXosip code which use the
global variables.
Ok,
Let's see constraint by constraint
1) proxy
the proxy adress could be managed in two ways:
a) specify it using (already existing) 'route' parameter to eXosip
request creation functions
b) modify 'cb_udp_send_message' routine in jcallback.c so it looks
like:
transport[sip->tid]->transport_send(transport[sip->tid].transport_private_info
, tr, sip);
the transport_specific send routine will retrieve port number
(or http tunnel pointer) from 'transport_private_info' parameter
2) one port
This information is REALLY needed only in 2 places in whole
eXosip stack
in cb_udp_send_message in jcallbac.c and and eXosip_read_message
in udp.c. Right?
for cb_udp_send_message the solution in the same as in point 1).
eXosip_read_message
will need to be modified to cycle through all available transports
and to call transport specific read_routines
3) the same answer as in 2)
Thanks
Vadim
_______________________________________________
Wengophone-devel mailing list
[email protected]
http://dev.openwengo.com/mailman/listinfo/wengophone-devel
