Re: another ListeningPoint issue ...

Becky,

Your scheme seems OK. In fact the thats the grouping the stack already
maintains for you. Ryan, I think I have a fix for your issue. Please
enter an Issue and I can commit the fix against that issue.

Ranga.

On 6/3/07, Becky McElroy <[email protected]> wrote:
> Ryan,
>
> With regard to the last sentence in your post, I seem to recall some
> discussion about having to switch to use TCP if a message that's being
> sent is too big for UDP. I thought that might be one of the reasons to
> have multiple listening points under a SipProvider. (but I suppose both
> sides would have to do it to make it work in the case you ask about).
>
> To anyone on the list:
>
> 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 wrote:
>
> >Using the following setup:
> >
> >SipProvider A  --  ListeningPoint A : 192.168.2.3, 5060, udp
> >SipProvider B  --  ListeningPoint B : 10.0.2.3, 5060, tcp
> >SipProvider C  --  ListeningPoint C : 10.0.2.3, 5060, udp
> >
> >
> >All under one SipStack, all using the same SipListener implementation.
> >
> >I receive a REGISTER request from C.  Next create a ServerTransaction
> >st = sipProvider.getNewServerTransaction(req);
> >
> >... application processes the request ...
> >
> >Response resp = msgFact.createResponse(Response.OK, req);
> >and send it: st.sendResponse(resp);
> >
> >Problem is response gets sent out A.  The reason I think is because the
> >SIPServerTransaction code gets the message channel to use from
> >sipStack.createRawMessageChannel(this.getPort(), hop); which finds the
> >first MessageProcessor matching the port number and hop protocol.  And
> >in my case it finds A (udp, 5060), whereas C should be the correct choice.
> >
> >If I reconfigure A to use port 5062, no problem.  Is this a problem in
> >the stack or am I missing something?  I think the only requirement per
> >RFC 3261 is that is the request is received "secure" that the reply is
> >also sent secure.  That said, are there any cases where you would want
> >to respond to a request on a different listening point from which it was
> >received?
> >
> >thanks,
> >--Ryan
> >
> >
> >
> >
>
> _______________________________________________
> nist-sip mailing list
> [email protected]
> http://www-x.antd.nist.gov/mailman/listinfo/nist-sip
>


-- 
M. Ranganathan
"There are two ways to write error-free programs; only the third one
works." --  Alan Perlis
http://www.animenewsnetwork.com/encyclopedia/anime.php?id=1052