Re: another ListeningPoint issue ...

Thanks for the replies to my question. 
I took a look at the getNewClientTransaction(Request) method, and saw 
that the topmost via header in the request plays a <major> role in 
listening point selection. Something to be aware of, no matter the 
grouping scheme I guess...
Regards,
Becky

Ryan Mitchell wrote:

>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
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [email protected]
>For additional commands, e-mail: [email protected]
>
>
>  
>