reSIProcate

Mailing Lists

Source Code

Google Search:



< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [repro-devel] ACK uses wrong interface?

I did some more testing with repro - as is from SVN and it doesn't seem to send even the INVITEs on the same interface as received. In my code I have the following line in ResponseContext:beginClientTransaction that I think gets the INVITE to go out on the right interface.
 
request.header(h_Vias).front().sentHost() = Tuple::inet_ntop(request.getReceivedTransport()->getTuple());
Since now the ACKs are processed differently they don't hit that code.
 
Can I just add the same line of code into the block that processes ACK in the RequestContext?
 
when handeling the INVITE and trying to calculate the interface to use my code produces the following debug (Both INVITE and ACK came in on  192.0.0.2) :
 
2008-03-09 09:06:43,665 [0xb75e3bb0] DEBUG RESIP.TRANSPORT TransportSelector.cxx:437
 - hint provided by app: SIP/2.0/ 192.0.0.2:15060;branch=z9hG4bK-d8754z-67c7410736846657-1---d8754z-;rport
2008-03-09 09:06:43,665 [0xb75e3bb0] DEBUG RESIP.TRANSPORT TransportSelector.cxx:1119
 - findTransportBySource([ V4 192.0.0.2:15060 UDP target domain=unspecified mFlowKey=0 ])
2008-03-09 09:06:43,665 [0xb75e3bb0] DEBUG RESIP.TRANSPORT TransportSelector.cxx:1163
 - findTransport (exact) => Transport: [ V4 192.0.0.2:15060 UDP target domain=unspecified mFlowKey=11 ] on 192.0.0.2
2008-03-09 09:06:43,666 [0xb75e3bb0] DEBUG RESIP.TRANSPORT TransportSelector.cxx:949
 - Transmitting to [ V4 xxx.xxx.xxx.xxx:5060 UDP target domain=xxx.xxx.xxx.xxx  mFlowKey=0 ] tlsDomain= via [ V4 192.0.0.2
:15060 UDP target domain=unspecified mFlowKey=0 ]
 
when handeling the ACK this is what I have:
 
2008-03-09 09:06:57,554 [0xb75e3bb0] DEBUG RESIP.TRANSPORT InternalTransport.cxx:86
 - Creating fd=12 V4/UDP
2008-03-09 09:06:57,555 [0xb75e3bb0] DEBUG RESIP.TRANSPORT TransportSelector.cxx:576
 - Looked up source for destination: [ V4 xxx.xxx.xxx.xxx:5060 UDP target domain=xxx.xxx.xxx.xxx mFlowKey=0 ] -> [ V4 192.0.0.3:0 UDP target domain=xxx.xxx.xxx.xxx mFlowKey=0 ] sent-by= sent-port=0
2008-03-09 09:06:57,555 [0xb75e3bb0] DEBUG RESIP.TRANSPORT TransportSelector.cxx:1119
 - findTransportBySource([ V4 192.0.0.3:0 UDP target domain=xxx.xxx.xxx.xxx mFlowKey=0 ])
2008-03-09 09:06:57,555 [0xb75e3bb0] DEBUG RESIP.TRANSPORT TransportSelector.cxx:1220
 - findTransport (any port, specific interface) => Transport: [ V4 192.0.0.3:15060 UDP target domain=unspecified mFlowKey=5 ] on 192.0.0.3
2008-03-09 09:06:57,556 [0xb75e3bb0] DEBUG RESIP.TRANSPORT TransportSelector.cxx:949
 - Transmitting to [ V4 xxx.xxx.xxx.xxx:5060 UDP target domain=xxx.xxx.xxx.xxx mFlowKey=0 ] tlsDomain= via [ V4 192.0.0.3:15060 UDP target domain=xxx.xxx.xxx.xxx mFlowKey=0 ]
 
For comparison here is the log from repro as it is in SVN where the INVITE goes out on the wrong interface (INVITE came in on  192.0.0.2):
 
DEBUG | 20080310-091554.283 | repro | RESIP:TRANSPORT | 3075275696 | InternalTransport.cxx:86 | Creating fd=10 V4/UDP
DEBUG | 20080310-091554.283 | repro | RESIP:TRANSPORT | 3075275696 | TransportSelector.cxx:559 | Looked up source for destination: [ V4 xxx.xxx.xxx.xxx:9000 UDP target domain=xxx.xxx.xxx.xxx mFlowKey=0 ] -> [ V4 192.0.0.3:0 UDP target domain=xxx.xxx.xxx.xxx mFlowKey=0 ] sent-by= sent-port=0
DEBUG | 20080310-091554.283 | repro | RESIP:TRANSPORT | 3075275696 | TransportSelector.cxx:1096 | findTransportBySource([ V4\
 192.0.0.3:0 UDP target domain=xxx.xxx.xxx.xxx mFlowKey=0 ])
DEBUG | 20080310-091554.283 | repro | RESIP:TRANSPORT | 3075275696 | TransportSelector.cxx:1197 | findTransport (any port, s\
pecific interface) => Transport: [ V4 192.0.0.3:5065 UDP target domain=unspecified mFlowKey=3 ] on 192.0.0.3
DEBUG | 20080310-091554.283 | repro | RESIP:TRANSPORT | 3075275696 | TransportSelector.cxx:929 | Transmitting to [ V4 xxx.xxx.xxx.xxx:9000 UDP target domain=xxx.xxx.xxx.xxx mFlowKey=0 ] tlsDomain= via [ V4 192.0.0.3:5065 UDP target domain=xxx.xxx.xxx.xxx mFlowKey=0 ]
 
 
 
 
Thanks,
Brocha
 
(my "repro-based" proxy is not a registrar - only a proxy -  so before never needed any part of the dum - it would be nice if that was still the case.)
 
 

From: Byron Campen [mailto:bcampen@xxxxxxxxxxxx]
Sent: Monday, March 10, 2008 1:55 AM
To: Brocha Strous
Cc: repro-devel@xxxxxxxxxxxxxxxxxxxx
Subject: Re: [repro-devel] ACK uses wrong interface?

Not sure what's going on with the ACK, but do keep in mind that the next hop for the ACK can very easily be different from the next hop for the INVITE. The stack will send stuff on whatever interface the routing tables tell it to; if the next hop for the ACK is different from the next hop for the INVITE, the routing tables might cause it to be forwarded from a different interface than the INVITE was.

If you can send some debug logging, I can try to pinpoint the precise reason your ACK is being sent on the interface it is.

In addition, repro does use DUM to handle registrations, so there is more to it than ContactInstanceRecord.

Best regards,
Byron Campen

Hi,
I just updated my proxy to use the latest code and now my ACK is being sent out using the wrong interface. I want the ACK to be sent out using the same interface it was received on. This works correctly in the INVITE - but not in the ACK, for the ACK it uses the primary interface of the machine. 
 
Any pointers would be appreciated.
 
(Also a small comment, the class ContactInstanceRecord is used by repro - but is part of dum, since repro as a proxy doesn't require dum for anything else, really this class should be part of the stack).
 
Thanks,
Brocha
 
 
 
 
_______________________________________________
repro-devel mailing list