reSIProcate

Mailing Lists

Source Code

Google Search:



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

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

If you're attached to both transports, there's not a whole lot you can do apart from what you're already doing with the INVITE (setting the host in the topmost Via). The stack has no idea that the ACK the proxy sends has anything to do with the ACK it received from the wire, so it just treats it like any new request and sends it according to the routing tables (ie, whatever comes back from the ::socket call in TransportSelector). 

Best regards,
Byron Campen


Hi Byron,
Thanks for your help. I don't really understand your suggestion. I am
running repro on a machine that listens on 2 IPs using the interfaces
parameter like this:
--interfaces=sip:192.0.0.3:5065;transport=udp,sip: 192.0.0.2:5065;transpo 
rt=udp
I would expect that by default any packet that comes to 192.0.0.3 would go out on same itnerface and if it comes on 192.0.0.2 it would go out on 192.0.0.2. But this is not the case. Is there something different that I 
can do when calling
SipStack::addTransport() then what the code in repro.cxx does?

Thanks,
Brocha
________________________________

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


Ok, so it just looks like the routing tables are preferring 192.0.0.3
over 192.0.0.2. Your code will work, but you can also solve this problem 
by explicitly binding your transports to 192.0.0.2 (see
SipStack::addTransport()). (When you don't supply an ip-address in this call, transports are bound to IN_ADDR_ANY, which means that stuff could 
go out on any interface).

Best regards,
Byron Campen


        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
                repro-devel@xxxxxxxxxxxxxxx
        
https://list.resiprocate.org/mailman/listinfo/repro-devel

Attachment: smime.p7s
Description: S/MIME cryptographic signature