Re: [repro-devel] ACK uses wrong interface?
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