Re: another ListeningPoint issue ...

sounds like a bug (or at least unexpected behavior).  I will take a look.

Ranga

On 6/3/07, Ryan Mitchell <[email protected]> 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
>
>
> --
> Ryan Mitchell <[email protected]>
> Telecom Logic, LLC
>
>
>
> _______________________________________________
> 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