Re: [reSIProcate] Dynamic binding to interfaces and ports
On 10/27/05, Matthias Moetje - TERASENS GmbH <moetje@xxxxxxxxxxx> wrote:
> Hi,
>
> I already posted this a while ago (as a reply
> to another post) but I didn't receive any
> responses, so I would be thankful if someone
> could comment on this or if we should rather
> create our own branch of the project.
>
> The proposal is about binding to different
> IP-Addresses, interfaces and ports in a dynamic
> way.
>
> These are the tasks that I think might be necessary:
>
> - add a removeTransport method
yes. this is a good idea. it is non-trivial to implement since
SipMessages can have pointers to Transports. We would need to switch
to using TransportHandles to solve this issue. Additionally, the
removeTransport will need to be made thread-safe. Ideally, removing a
transport will happen when that Transport is no longer being used by
any active transactions.
> - make sure that addTransport without specified
> IP address binds to all unused IP addresses
> and does not interfere with explicit bindings
I'm not sure I agree with this. Current behavior assumes that if you
want to bind to specific interfaces that you will not also bind to all
interfaces. How would you implement the behavior that you want? Keep
in mind that you would need to do this on all of our supported
operating systems. I think I prefer the assumption of mutual
exclusivity. What is the use case for first binding to a specific
interface and then later binding to "all the rest"?
> (I don't know what the current behaviour is,
> I haven't checked.
> - maybe make sure that addTransport with an
> explicit IP address causes resip to stop
> listening on this ip address for existing
> instances without explicit binding
>
same argument as previous one.
> - add a tag or name property to the transport
> class for easy identification
>
what is this tag used for?
> - add a way to specify the transport for outgoing
> calls (either via profile or via member of
> InviteSession?)
>
This facility already exists (although probably is not documented).
You can specify a transport hint to use in the Via transport, host
and port.
> - add functionality to retrieve the involved
> transport for incoming calls (as member of
> InviteSession?)
>
The SipMessage already has this on it. When the new session is
created, the SipMessage is one of the parameters passed up to the
application.
>
> I would be interested in you comments about
> these changes.
>
>
> Thanks and best regards,
>
>
> Matthias
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>