Re: [reSIProcate] Question about implementing own Transport and Sip Stack Interactions
I am also trying to figure out other ways of using epoll
without having to create my own transport. One way is to
get the Socket fd using the AfterSocketCreationFuncPrt.
But the problem with this is it's a C func ptr and
doesn't fit neatly with our c++ object model. Is it
possible to provide something like this to make it little
easier to manage the read on the fds:
Socket Tranport::getSocket() or a similar method?
Any ideas on that? It still doesn't solve the DNS/Ares
stuff, but I think it might still make it better than
relying on "AfterSocketCreationFuncPtr"...
~Sunitha.
-----Original Message-----
From: Byron Campen [mailto:bcampen@xxxxxxxxxxxx]
Sent: Monday, March 12, 2007 1:00 PM
To: Sunitha Beeram
Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
Subject: Re: [reSIProcate] Question about implementing
own Transport and Sip Stack Interactions
The DNS stuff does not use resip::Transport, it
uses whatever the DNS backend (in this case, ares) uses.
If you want your DNS resolution to use epoll, there might
be a way to get ares to do that.
Anyone know whether this is possible?
Best regards,
Byron Campen
> Hi,
>
> We plan to use epoll() for our application and sip
stack fds
> instead of going the current select() way. I am
assuming that if I
> implement my own transport this should be possible. I
think I have
> mapped most of what needs to be done to implement the
Transport
> interface, so the sip stack interactions are taken care
of - one issue
> I am not sure about is the DnsStub object in the stack.
Is it possible
> to drive that too through our own transport or do we
have to implement
> an external DNS for it?
>
> Does anybody have notes (dos/donts) for
implementing an external
> Transport?
>
> Thanks,
> Sunitha.
>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
>
https://list.resiprocate.org/mailman/listinfo/resiprocate
-devel