| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index |
|
Hi Scott! Thanks, for pointing us into the right direction! addTransport without IP address will be used in future. Instead, the setFixedTransportInterface method is utilized (as recommended). Things are solved. J Thanks a lot for fast help and detailed explanations! Peter From: slgodin@xxxxxxxxx [mailto:slgodin@xxxxxxxxx] On Behalf Of Scott Godin Hi Peter, You mentioned that the resip stack is bound to 9.9.9.3:25000 - however the log lines you include indicate that it is actually bound to 9.9.9.4 instead: DEBUG | 20120329-130256.631 | reSIPUA | RESIP:TRANSPORT | 4544 | TransportSelector.cxx:1344 | Exact interface / Specific port: [[ V4 9.9.9.4:25000 UDP target domain=unspecified mFlowKey=0 ] -> 01818BE8] Looking at the logs below - it would seem that binding to 9.9.9.3 should be working fine (at least for routing to 9.9.9.4). To help you understand the logic resip uses, I've outlined part of the process below: -when a packet needs to be sent - two fn's are called to find the transport that should be used : - TransportSelector::determineSourceInterface - and TransportSelector::findTransportBySource -determineSourceInterface typically ends up calling WinCompat::determineSourceInterface, which uses WIN32 API's: - GetIpAddrTable - to see if the destination IP is a local address (ie. owned by a NIC in the system) - if so then the NIC's default address is returned - since 9.9.9.4 is a local address and 9.9.9.3 is returned I am assuming that 9.9.9.3 is the NIC's default or highest priority address - GetBestRoute - If address is not local - queries the windows OS to have it select interface to be used to route to the destination based on internal routing tables and OS selection rules - return the first ip address that matches this route - In your case this process returned 9.9.9.3 (first log line below) -Next we need to find the transport using the source address: findTransportBySource - this is where the process is failing - since it appears that your transport is actually bound to 9.9.9.4:25000 and resip cannot find a transport for source address 9.9.9.3 Resips logic could be improved by allowing it to somehow recognize that the transport/address that it is actually bound to can still route the packet, even if it's not the transport that the determineSourceInterface process identified. Another way you may be able handle this scenario, is to bind to 0.0.0.0, and then pre-populate the via sent host in your outbound messages before sending them down to the stack (ie. let's the application choose the transport, so the above logic is not required). If you are using DUM, the Profile setting setFixedTransportInterface will accomplish this. (Note: The binding to 0.0.0.0 step may not actually be required). Also - please make sure you've seen the note on the following page about using the 1.7 release in Windows: http://www.resiprocate.org/ReSIProcate_1.7_Release Regards, Scott On Thu, Mar 29, 2012 at 6:39 AM, Schollbach, Peter <peter.schollbach@xxxxxxx> wrote: Hi all! My company is using reciprocate 1.7 to do performance tests for our own SIP products. It’s working pretty well but we run into the following problem. Assume the following test environment (Windows Server 2003): !!!! Ethernet adapter Local Area Connection 3: Connection-specific DNS Suffix . : IP Address. . . . . . . . . . . . : 9.9.9.1 Subnet Mask . . . . . . . . . . . : 255.255.255.0 IP Address. . . . . . . . . . . . : 9.9.9.2 Subnet Mask . . . . . . . . . . . : 255.255.255.0 IP Address. . . . . . . . . . . . : 9.9.9.3 à SIP stack wants to use this IP as source IP address for all outgoing traffic Subnet Mask . . . . . . . . . . . : 255.255.255.0 IP Address. . . . . . . . . . . . : 9.9.9.4 à system under test resides behind this IP address (destination IP from SIP stack’s point of view) Subnet Mask . . . . . . . . . . . : 255.255.255.0 Evidently, all IP addresses, SIP stack tester, software under test are running on the same physical machine. This is the intended traffic flow: 9.9.9.3:25000 (stack) à 9.9.9.4:5060 (system under test) !!!! The SIP stack is initialized like this: !!!! mDum->addTransport(UDP, “25000”, V4, “9.9.9.3”); !!!! While running the tests the following error occur: !!!! DEBUG | 20120329-130256.631 | reSIPUA | RESIP:TRANSPORT | 4544 | TransportSelector.cxx:651 | Looked up source for destination: [ V4 9.9.9.4:5060 UDP target domain=9.9.9.4 mFlowKey=0 ] -> [ V4 9.9.9.3:0 UDP target domain=9.9.9.4 mFlowKey=0 ] sent-by= sent-port=0 DEBUG | 20120329-130256.631 | reSIPUA | RESIP:TRANSPORT | 4544 | TransportSelector.cxx:1276 | findTransportBySource([ V4 9.9.9.3:0 UDP target domain=9.9.9.4 mFlowKey=0 ]) DEBUG | 20120329-130256.631 | reSIPUA | RESIP:TRANSPORT | 4544 | TransportSelector.cxx:1344 | Exact interface / Specific port: [[ V4 9.9.9.4:25000 UDP target domain=unspecified mFlowKey=0 ] -> 01818BE8] DEBUG | 20120329-130256.631 | reSIPUA | RESIP:TRANSPORT | 4544 | TransportSelector.cxx:1345 | Any interface / Specific port: [] DEBUG | 20120329-130256.631 | reSIPUA | RESIP:TRANSPORT | 4544 | TransportSelector.cxx:1346 | Exact interface / Any port: [[ V4 9.9.9.4:25000 UDP target domain=unspecified mFlowKey=0 ] -> 01818BE8] DEBUG | 20120329-130256.631 | reSIPUA | RESIP:TRANSPORT | 4544 | TransportSelector.cxx:1347 | Any interface / Any port: [] WARNING | 20120329-130256.631 | reSIPUA | RESIP:TRANSPORT | 4544 | TransportSelector.cxx:1349 | Can't find matching transport [ V4 9.9.9.3:0 UDP target domain=9.9.9.4 mFlowKey=0 ] !!!! Things would work if I would use addTransport with address “9.9.9.1” (first address if checked with ipconfig) or in case IP address is not specified at all (where source address will be automatically chosen as 9.9.9.4). Question: Is there any way SIP stack would use a defined source IP address and still find the correct route? Thanks for your help in advance! Best regards, Peter Schollbach
|