Re: another ListeningPoint issue ...

Regarding grouping listening points under SipProviders --

In our application (a b2bua), we have one ListeningPoint per
SipProvider.  The reason is that when creating a new outgoing request
(e.g. 3pcc), the application may have a preference or requirement about
which ListeningPoint to use.  Maybe the client is on a network only
reachable from a particular interface.  Or maybe as a matter of policy
you want to communicate only over TLS.

But when creating a new transaction, I only see how that's done with
reference to the SipProvider, not any particular ListeningPoint.  So
instead of  sipProvider.getNewClientTransaction(req), I would want to
write sipProvider.getNewClientTransaction(req, "TCP"), if the API
offered it, thus uniquely specifying a ListeningPoint.

By forcing a 1-to-1 association of SipProviders to ListeningPoints, I
can effectively choose the latter by selecting the former.  If there's a
better way to do it, somebody let me know!

thanks,
--Ryan



> > Is there a particular way that listening points should be grouped
> > under SipProviders of a given stack? (other than the rule of at most
> > one listening point of a given transport type per SipProvider). IE:
> > Given a user-specified configuration containing any number of
> > IPaddress/port/transport combinations for a single stack/SipListener
> > instance, I have created a separate SipProvider for each
> > IPaddress/port combination and grouped the LPs for the different
> > protocols underneath those. From an application perspective, is there
> > any reason why you might NOT want to do that?
> >
> > Thanks for any advice-
> > Becky
> >
>   


-- Ryan Mitchell <[email protected]> Telecom Logic, LLC