Vadim Lebedev wrote:
Hi Thomas
Thomas Monjalon wrote:
Hi Vadim,
Vadim Lebedev wrote:
I've took a look at transport-refactoring branch.... and have couple
of thoughts
1. I'd take another approach:
i'd would add an "int tid;" which would represent the transport
identifier to osip_message structure.
then i'd would add the tid parameter to eXosip request building
APIs used by phapi
then i'd would add a static transport table contaning the
transport descripors.
then udp_send functoin would extract tid from osip_message and
would select correct descripotr in the table and jump to transport
specific send rouitne.
then i'd would add a transport_register function which allow to
register transport descriptor in the table, so the tranposrt could be
realized as plugins.
The transport protocol (UDP, TCP, TLS) that must be used with the SIP
proxy (or server) is stored in the SIP account which is stored in
transactions, dialogs and registrations. I don't think it is the right
place to store it in messages because it has to be persistent in a
dialog.
I agree that the "conceptually" you are right.
My idea to store the tid in the osip_message is an "implementation detail".
This detail however permits to drastically minimize the developpement
effort
to achieve the desired functionality.
The transport descriptors are not stored statically because the SIP
layer and the transport layer must be really separated. This way, the
transport layer could change dynamically the transport plugin without
notify the SIP layer.
My proposal is not contradict this apporach the SIP layer should handle
the 'tid' field
as an opaque user data.
The transport can be realized as plugin. They are declared as
owsl_socket_type. HTTP tunnel will be a socket type.
Depending on the network context, the transport layer can use a tunnel
and choose the right implementation.
This is EXACTLY what i'm talking about... look at this sketch of
send_udp function from eXosip
int send_udp(osip_message_t *m)
{
return transport[m->tid]->send_packet(m);
}
now in case of http tunnel for example the send->packet field will point
to:
httptun_send_packet(osip_message_t *m)
{
int tid = m->tid;
char *buf;
http_tunnel *tun = (http_tunnel *)
(transport[tid].transport_private_data);
osip_message_to_string(m, &buf);
tunnel_send(tun, buf, strlen(buf));
osip_free(buf);
}
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 ?
2. I've looked into eXosip2 today... It became much cleaner, and one
very important point: now
one can modify ALL requests before sending them. This would
simplyfy addition of transport concept even furhere...
no more need to modify eXosip request building APIs, simply
add transporty table, tid field into osip_message and fix udp_send
and receive routines to use/set the above 'tid'
In the last version of transport_refactoring, requests can be modified
by a plugin just before to be sent.
Yes, but it requred a lot of modification of eXosip... In eXosip2 it
occurs naturally
But it could be interesting to estimate the advantages of the last
version of the "official" eXosip, and the effort to merge it into the
OpenWengo one...
I have to notice that the transport_refactoring branch have
improvement that the official eXosip have not:
- account management in the SIP layer
- simultaneous accounts with different proxys
- TCP, TLS
All these fucntionality is easily achievable with my proposal with
almost NO modfications
to eXosip code itself
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.
I made these modifications in the branch.
I think it is very interesting to discuss about all of that.
I do agree on this :) :)
--
Thomas
_______________________________________________
Wengophone-devel mailing list
[email protected]
http://dev.openwengo.com/mailman/listinfo/wengophone-devel
