RE: [reSIProcate] Dynamic binding to interfaces and ports

["Matthias Moetje - TERASENS GmbH" <moetje@xxxxxxxxxxx>]

Jason,

thanks very much for your reply.


> 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.

OK. What about marking a transport as disabled instead? Would this
be easier? The transport object could continue to exist but the 
TCP/IP binding would be removed...?


> > - 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"?

Idea behind is a scenario like this:

Transport 1: All unassigned IP Addresses:5060
Transport 2: 192.168.1.1:5060

If an additional transport would added:

Transport 3: 192.168.1.2:5060

this might cause problems, that's why I thought it might be
helpful if the unspecified binding would be recreated to 
allow Transport 3 to work.

Moreover, requirement would be that this works across several
dum/resip stacks that are loaded simultaneously....

Well, that's not a priority, though.


> > - add a tag or name property to the transport
> >   class for easy identification
> >
> what is this tag used for?

It would be for matching transports to corresponding 
elements in our project, in order not to iterate through
all transports (and our "address" objects) and compare
IP, addresses, ports and protocol types.


> > - 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.

OK, I'll try to find it..


> > - 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.

OK, found it!

Best regards,

Matthias