Thread: Re: [OpenSIPStack] NIC Binding
Brought to you by:
joegenbaclor
Menu
▾
▴
opensipstack-devel
|
From: <sa...@ER...> - 2007-11-14 23:00:50
|
Hello I read that OSBC binds to all NIC. Will it bind when one NIC is set up = an Internet addr and other NIC with a private(192.x.x.x) addr. Or is = there a need for a router between the public and private networks. Are = there instruction? Last question is there a top level scheme (macro) = that shows a network diagram with possible OSBC typical layout? Warren Kreckler |
|
From: <jo...@op...> - 2007-11-16 03:22:05
|
OSBC should be able to intelligently use the appropriate interface based on the destination of the packet. It will act as a natural bridge between the two networks assuming you have a sane routing table. Let me know if you prove me otherwise. joegen sales@ER wrote: > Hello > > I read that OSBC binds to all NIC. Will it bind when one NIC is set up an Internet addr and other NIC with a private(192.x.x.x) addr. Or is there a need for a router between the public and private networks. Are there instruction? Last question is there a top level scheme (macro) that shows a network diagram with possible OSBC typical layout? > > Warren Kreckler > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > opensipstack-devel mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensipstack-devel > > > > |
|
From: <sa...@ER...> - 2007-11-17 12:40:06
|
The problem is the Hostname. The NIC on the private side is a node that dynamically gets it license, ip addr from a dhcpd and dns running on the 192.168 side. It becomes a dhclient of dhcpd. From another node, on the private side, dhcpd is used to provide ipaddr and other setup instructions to the remote phone living on the public side and the private side of the SBC. From the SBC box at the network layer i am able to pings in both directions and run applications living on the private side and the public side only if i use ipaddress. It seems that once the SBC box becomes a dhclient it wants to resolve hostnames using the dns living on the private side. From a remote box on the public side i want to run the SBC admin program, which will only run if i disable the dhclient. This clearly is not just a dhcpd or a routing problem beyond the scope of this list. And as you said maybe it is a misconfigured routing table. Is there anyone out there that has overcome this problem? I hope i'm not the first person asking for guidence on this issue. Warren Kreckler ----- Original Message ----- From: "jo...@op..." <joe...@gm...> To: <ope...@li...> Sent: Thursday, November 15, 2007 9:21 PM Subject: Re: [OpenSIPStack] NIC Binding > OSBC should be able to intelligently use the appropriate interface based > on the destination of the packet. It will act as a natural bridge > between the two networks assuming you have a sane routing table. Let me > know if you prove me otherwise. > > joegen > > > sales@ER wrote: > > Hello > > > > I read that OSBC binds to all NIC. Will it bind when one NIC is set up an Internet addr and other NIC with a private(192.x.x.x) addr. Or is there a need for a router between the public and private networks. Are there instruction? Last question is there a top level scheme (macro) that shows a network diagram with possible OSBC typical layout? > > > > Warren Kreckler > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. > > Still grepping through log files to find problems? Stop. > > Now Search log events and configuration files using AJAX and a browser. > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > _______________________________________________ > > opensipstack-devel mailing list > > ope...@li... > > https://lists.sourceforge.net/lists/listinfo/opensipstack-devel > > > > > > > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > opensipstack-devel mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensipstack-devel |
|
From: Jeremy A <je...@el...> - 2007-11-18 05:21:37
|
Hello, I've just started to evaluate opensbc version 1.1.4 I put a wireshark trace on the traffic and it seems that every packet sent by opensbc is sent twice. Is this correct behaviour ? Here is a trace of a registration and an incoming call. The configuration is a linksys spa962 that normally registers direct with a VOIP provider and no outgoing proxy. I changed this to use the opensbc as outgoing proxy and logged the traffic. The linksys IP ends in .148. the opensbc instance ends in .138. Both addresses are routable and have equivalent firewall enabled access to the internet. The VOIP provider has a fake IP of 1.2.3.4 I also see a NOTIFY from the voip provider is being rejected - is this normal? 0.000817 X.Y.Z.148 -> X.Y.Z.138 SIP Request: REGISTER sip:gw4.fakesipprovider.com 0.018829 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (0 bindings) 0.018837 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (0 bindings) 0.030086 X.Y.Z.138 -> 1.2.3.4 SIP Request: REGISTER sip:gw4.fakesipprovider.com 0.030098 X.Y.Z.138 -> 1.2.3.4 SIP Request: REGISTER sip:gw4.fakesipprovider.com 0.066302 1.2.3.4 -> X.Y.Z.138 SIP Status: 100 Trying (1 bindings) 0.073700 1.2.3.4 -> X.Y.Z.138 SIP Status: 401 Unauthorized (1 bindings) 0.076972 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (1 bindings) 0.076981 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (1 bindings) 0.088366 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 401 Unauthorized (1 bindings) 0.088377 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 401 Unauthorized (1 bindings) 0.096668 X.Y.Z.148 -> X.Y.Z.138 SIP Request: REGISTER sip:gw4.fakesipprovider.com 0.116038 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (0 bindings) 0.116055 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (0 bindings) 0.119375 X.Y.Z.138 -> 1.2.3.4 SIP Request: REGISTER sip:gw4.fakesipprovider.com 0.119384 X.Y.Z.138 -> 1.2.3.4 SIP Request: REGISTER sip:gw4.fakesipprovider.com 0.160873 X.Y.Z.138 -> 1.2.3.4 SIP Request: REGISTER sip:gw4.fakesipprovider.com 0.160885 X.Y.Z.138 -> 1.2.3.4 SIP Request: REGISTER sip:gw4.fakesipprovider.com 0.163720 1.2.3.4 -> X.Y.Z.138 SIP Status: 100 Trying (1 bindings) 0.170387 1.2.3.4 -> X.Y.Z.138 SIP Status: 200 OK (1 bindings) 0.173012 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (1 bindings) 0.173022 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (1 bindings) 0.182666 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 200 OK (1 bindings) 0.182677 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 200 OK (1 bindings) 0.200877 1.2.3.4 -> X.Y.Z.138 SIP Status: 100 Trying (1 bindings) 0.208848 1.2.3.4 -> X.Y.Z.138 SIP Status: 200 OK (1 bindings) 10.019211 1.2.3.4 -> X.Y.Z.138 SIP Request: NOTIFY sip:55555555@X.Y.Z.138:65080 10.027932 X.Y.Z.138 -> 1.2.3.4 SIP Status: 405 Method Not Allowed 10.027945 X.Y.Z.138 -> 1.2.3.4 SIP Status: 405 Method Not Allowed 10.693615 1.2.3.4 -> X.Y.Z.138 SIP Request: OPTIONS sip:55555555@X.Y.Z.138:65080 10.707659 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK 10.707674 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK 70.737972 1.2.3.4 -> X.Y.Z.138 SIP Request: OPTIONS sip:55555555@X.Y.Z.138:65080 70.746471 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK 70.746485 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK 116.129914 1.2.3.4 -> X.Y.Z.138 SIP/SDP Request: INVITE sip:55555555@X.Y.Z.138:65080, with session description 116.146387 X.Y.Z.138 -> 1.2.3.4 SIP Status: 100 Trying 116.146402 X.Y.Z.138 -> 1.2.3.4 SIP Status: 100 Trying 116.150431 X.Y.Z.138 -> X.Y.Z.148 SIP/SDP Request: INVITE sip:55555555@X.Y.Z.148:5060, with session description 116.150443 X.Y.Z.138 -> X.Y.Z.148 SIP/SDP Request: INVITE sip:55555555@X.Y.Z.148:5060, with session description 116.159165 X.Y.Z.148 -> X.Y.Z.138 SIP Status: 100 Trying 116.181582 X.Y.Z.148 -> X.Y.Z.138 SIP Status: 180 Ringing 116.192198 X.Y.Z.138 -> 1.2.3.4 SIP Status: 180 Ringing 116.192218 X.Y.Z.138 -> 1.2.3.4 SIP Status: 180 Ringing 118.894027 X.Y.Z.148 -> X.Y.Z.138 SIP/SDP Status: 200 OK, with session description 118.900656 X.Y.Z.138 -> X.Y.Z.148 SIP Request: ACK sip:55555555@X.Y.Z.148:5060 118.900671 X.Y.Z.138 -> X.Y.Z.148 SIP Request: ACK sip:55555555@X.Y.Z.148:5060 118.908267 X.Y.Z.138 -> 1.2.3.4 SIP/SDP Status: 200 OK, with session description 118.908279 X.Y.Z.138 -> 1.2.3.4 SIP/SDP Status: 200 OK, with session description 118.950770 1.2.3.4 -> X.Y.Z.138 SIP Request: ACK sip:X.Y.Z.138:5060 122.220504 1.2.3.4 -> X.Y.Z.138 SIP Request: BYE sip:X.Y.Z.138:5060 122.236390 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK 122.236401 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK 122.239402 X.Y.Z.138 -> X.Y.Z.148 SIP Request: BYE sip:55555555@X.Y.Z.148:5060 122.239414 X.Y.Z.138 -> X.Y.Z.148 SIP Request: BYE sip:55555555@X.Y.Z.148:5060 122.248420 X.Y.Z.148 -> X.Y.Z.138 SIP Status: 200 OK 130.767892 1.2.3.4 -> X.Y.Z.138 SIP Request: OPTIONS sip:55555555@X.Y.Z.138:65080 130.776518 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK 130.776532 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK |
|
From: Joegen E. B. <joe...@gm...> - 2007-11-18 06:12:40
|
This may just be timer synchronization issues where the first REGISTER request took some time to be resolved via DNS long enough that the timer for retransmission has already fired. OpenSBC is caching DNS records so that the next need for DNS resoltuion would be faster. OpenSBC does not support unsolicited NOTIFY. Your provider might be using NOTIFY to maintain NAT pinholes, in which case the response is not really an issue whether it's a 200 Ok or Method Not Allowed. Jeremy A wrote: > Hello, > > I've just started to evaluate opensbc version 1.1.4 > > I put a wireshark trace on the traffic and it seems that every packet > sent by opensbc is sent twice. Is this correct behaviour ? > > Here is a trace of a registration and an incoming call. The > configuration is a linksys spa962 that normally registers direct with a > VOIP provider and no outgoing proxy. I changed this to use the opensbc > as outgoing proxy and logged the traffic. > > The linksys IP ends in .148. the opensbc instance ends in .138. Both > addresses are routable and have equivalent firewall enabled access to > the internet. The VOIP provider has a fake IP of 1.2.3.4 > > I also see a NOTIFY from the voip provider is being rejected - is this > normal? > > > 0.000817 X.Y.Z.148 -> X.Y.Z.138 SIP Request: REGISTER > sip:gw4.fakesipprovider.com > 0.018829 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (0 bindings) > 0.018837 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (0 bindings) > 0.030086 X.Y.Z.138 -> 1.2.3.4 SIP Request: REGISTER > sip:gw4.fakesipprovider.com > 0.030098 X.Y.Z.138 -> 1.2.3.4 SIP Request: REGISTER > sip:gw4.fakesipprovider.com > 0.066302 1.2.3.4 -> X.Y.Z.138 SIP Status: 100 Trying (1 bindings) > 0.073700 1.2.3.4 -> X.Y.Z.138 SIP Status: 401 Unauthorized (1 bindings) > 0.076972 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (1 bindings) > 0.076981 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (1 bindings) > 0.088366 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 401 Unauthorized (1 > bindings) > 0.088377 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 401 Unauthorized (1 > bindings) > 0.096668 X.Y.Z.148 -> X.Y.Z.138 SIP Request: REGISTER > sip:gw4.fakesipprovider.com > 0.116038 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (0 bindings) > 0.116055 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (0 bindings) > 0.119375 X.Y.Z.138 -> 1.2.3.4 SIP Request: REGISTER > sip:gw4.fakesipprovider.com > 0.119384 X.Y.Z.138 -> 1.2.3.4 SIP Request: REGISTER > sip:gw4.fakesipprovider.com > 0.160873 X.Y.Z.138 -> 1.2.3.4 SIP Request: REGISTER > sip:gw4.fakesipprovider.com > 0.160885 X.Y.Z.138 -> 1.2.3.4 SIP Request: REGISTER > sip:gw4.fakesipprovider.com > 0.163720 1.2.3.4 -> X.Y.Z.138 SIP Status: 100 Trying (1 bindings) > 0.170387 1.2.3.4 -> X.Y.Z.138 SIP Status: 200 OK (1 bindings) > 0.173012 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (1 bindings) > 0.173022 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (1 bindings) > 0.182666 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 200 OK (1 bindings) > 0.182677 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 200 OK (1 bindings) > 0.200877 1.2.3.4 -> X.Y.Z.138 SIP Status: 100 Trying (1 bindings) > 0.208848 1.2.3.4 -> X.Y.Z.138 SIP Status: 200 OK (1 bindings) > 10.019211 1.2.3.4 -> X.Y.Z.138 SIP Request: NOTIFY > sip:55555555@X.Y.Z.138:65080 > 10.027932 X.Y.Z.138 -> 1.2.3.4 SIP Status: 405 Method Not Allowed > 10.027945 X.Y.Z.138 -> 1.2.3.4 SIP Status: 405 Method Not Allowed > 10.693615 1.2.3.4 -> X.Y.Z.138 SIP Request: OPTIONS > sip:55555555@X.Y.Z.138:65080 > 10.707659 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK > 10.707674 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK > 70.737972 1.2.3.4 -> X.Y.Z.138 SIP Request: OPTIONS > sip:55555555@X.Y.Z.138:65080 > 70.746471 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK > 70.746485 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK > 116.129914 1.2.3.4 -> X.Y.Z.138 SIP/SDP Request: INVITE > sip:55555555@X.Y.Z.138:65080, with session description > 116.146387 X.Y.Z.138 -> 1.2.3.4 SIP Status: 100 Trying > 116.146402 X.Y.Z.138 -> 1.2.3.4 SIP Status: 100 Trying > 116.150431 X.Y.Z.138 -> X.Y.Z.148 SIP/SDP Request: INVITE > sip:55555555@X.Y.Z.148:5060, with session description > 116.150443 X.Y.Z.138 -> X.Y.Z.148 SIP/SDP Request: INVITE > sip:55555555@X.Y.Z.148:5060, with session description > 116.159165 X.Y.Z.148 -> X.Y.Z.138 SIP Status: 100 Trying > 116.181582 X.Y.Z.148 -> X.Y.Z.138 SIP Status: 180 Ringing > 116.192198 X.Y.Z.138 -> 1.2.3.4 SIP Status: 180 Ringing > 116.192218 X.Y.Z.138 -> 1.2.3.4 SIP Status: 180 Ringing > 118.894027 X.Y.Z.148 -> X.Y.Z.138 SIP/SDP Status: 200 OK, with session > description > 118.900656 X.Y.Z.138 -> X.Y.Z.148 SIP Request: ACK > sip:55555555@X.Y.Z.148:5060 > 118.900671 X.Y.Z.138 -> X.Y.Z.148 SIP Request: ACK > sip:55555555@X.Y.Z.148:5060 > 118.908267 X.Y.Z.138 -> 1.2.3.4 SIP/SDP Status: 200 OK, with session > description > 118.908279 X.Y.Z.138 -> 1.2.3.4 SIP/SDP Status: 200 OK, with session > description > 118.950770 1.2.3.4 -> X.Y.Z.138 SIP Request: ACK sip:X.Y.Z.138:5060 > 122.220504 1.2.3.4 -> X.Y.Z.138 SIP Request: BYE sip:X.Y.Z.138:5060 > 122.236390 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK > 122.236401 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK > 122.239402 X.Y.Z.138 -> X.Y.Z.148 SIP Request: BYE > sip:55555555@X.Y.Z.148:5060 > 122.239414 X.Y.Z.138 -> X.Y.Z.148 SIP Request: BYE > sip:55555555@X.Y.Z.148:5060 > 122.248420 X.Y.Z.148 -> X.Y.Z.138 SIP Status: 200 OK > 130.767892 1.2.3.4 -> X.Y.Z.138 SIP Request: OPTIONS > sip:55555555@X.Y.Z.138:65080 > 130.776518 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK > 130.776532 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > opensipstack-devel mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensipstack-devel > > > |
|
From: Jeremy A <je...@el...> - 2007-11-18 07:32:23
|
Hello, Thanks for the suggested cause. However I think that DNS is not the issue. In the example there are no DNS requests by openSBC ( I assume it has cached these from earlier experiments) Every packet sent by openSBC is duplicated. This includes packets to the upstream provider and packets to the registering phone. The packets are duplicated long after any DNS caching should have happened - In the example below this occurs over a period of 130 seconds. It also occurs with the phone device where DNS resolution is not used. Joegen E. Baclor wrote: > This may just be timer synchronization issues where the first REGISTER > request took some time to be resolved via DNS long enough that the timer > for retransmission has already fired. OpenSBC is caching DNS records > so that the next need for DNS resoltuion would be faster. OpenSBC does > not support unsolicited NOTIFY. Your provider might be using NOTIFY to > maintain NAT pinholes, in which case the response is not really an issue > whether it's a 200 Ok or Method Not Allowed. > > > Jeremy A wrote: > >> Hello, >> >> I've just started to evaluate opensbc version 1.1.4 >> >> I put a wireshark trace on the traffic and it seems that every packet >> sent by opensbc is sent twice. Is this correct behaviour ? >> >> Here is a trace of a registration and an incoming call. The >> configuration is a linksys spa962 that normally registers direct with a >> VOIP provider and no outgoing proxy. I changed this to use the opensbc >> as outgoing proxy and logged the traffic. >> >> The linksys IP ends in .148. the opensbc instance ends in .138. Both >> addresses are routable and have equivalent firewall enabled access to >> the internet. The VOIP provider has a fake IP of 1.2.3.4 >> >> I also see a NOTIFY from the voip provider is being rejected - is this >> normal? >> >> >> 0.000817 X.Y.Z.148 -> X.Y.Z.138 SIP Request: REGISTER >> sip:gw4.fakesipprovider.com >> 0.018829 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (0 bindings) >> 0.018837 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (0 bindings) >> 0.030086 X.Y.Z.138 -> 1.2.3.4 SIP Request: REGISTER >> sip:gw4.fakesipprovider.com >> 0.030098 X.Y.Z.138 -> 1.2.3.4 SIP Request: REGISTER >> sip:gw4.fakesipprovider.com >> 0.066302 1.2.3.4 -> X.Y.Z.138 SIP Status: 100 Trying (1 bindings) >> 0.073700 1.2.3.4 -> X.Y.Z.138 SIP Status: 401 Unauthorized (1 bindings) >> 0.076972 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (1 bindings) >> 0.076981 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (1 bindings) >> 0.088366 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 401 Unauthorized (1 >> bindings) >> 0.088377 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 401 Unauthorized (1 >> bindings) >> 0.096668 X.Y.Z.148 -> X.Y.Z.138 SIP Request: REGISTER >> sip:gw4.fakesipprovider.com >> 0.116038 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (0 bindings) >> 0.116055 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (0 bindings) >> 0.119375 X.Y.Z.138 -> 1.2.3.4 SIP Request: REGISTER >> sip:gw4.fakesipprovider.com >> 0.119384 X.Y.Z.138 -> 1.2.3.4 SIP Request: REGISTER >> sip:gw4.fakesipprovider.com >> 0.160873 X.Y.Z.138 -> 1.2.3.4 SIP Request: REGISTER >> sip:gw4.fakesipprovider.com >> 0.160885 X.Y.Z.138 -> 1.2.3.4 SIP Request: REGISTER >> sip:gw4.fakesipprovider.com >> 0.163720 1.2.3.4 -> X.Y.Z.138 SIP Status: 100 Trying (1 bindings) >> 0.170387 1.2.3.4 -> X.Y.Z.138 SIP Status: 200 OK (1 bindings) >> 0.173012 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (1 bindings) >> 0.173022 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (1 bindings) >> 0.182666 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 200 OK (1 bindings) >> 0.182677 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 200 OK (1 bindings) >> 0.200877 1.2.3.4 -> X.Y.Z.138 SIP Status: 100 Trying (1 bindings) >> 0.208848 1.2.3.4 -> X.Y.Z.138 SIP Status: 200 OK (1 bindings) >> 10.019211 1.2.3.4 -> X.Y.Z.138 SIP Request: NOTIFY >> sip:55555555@X.Y.Z.138:65080 >> 10.027932 X.Y.Z.138 -> 1.2.3.4 SIP Status: 405 Method Not Allowed >> 10.027945 X.Y.Z.138 -> 1.2.3.4 SIP Status: 405 Method Not Allowed >> 10.693615 1.2.3.4 -> X.Y.Z.138 SIP Request: OPTIONS >> sip:55555555@X.Y.Z.138:65080 >> 10.707659 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK >> 10.707674 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK >> 70.737972 1.2.3.4 -> X.Y.Z.138 SIP Request: OPTIONS >> sip:55555555@X.Y.Z.138:65080 >> 70.746471 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK >> 70.746485 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK >> 116.129914 1.2.3.4 -> X.Y.Z.138 SIP/SDP Request: INVITE >> sip:55555555@X.Y.Z.138:65080, with session description >> 116.146387 X.Y.Z.138 -> 1.2.3.4 SIP Status: 100 Trying >> 116.146402 X.Y.Z.138 -> 1.2.3.4 SIP Status: 100 Trying >> 116.150431 X.Y.Z.138 -> X.Y.Z.148 SIP/SDP Request: INVITE >> sip:55555555@X.Y.Z.148:5060, with session description >> 116.150443 X.Y.Z.138 -> X.Y.Z.148 SIP/SDP Request: INVITE >> sip:55555555@X.Y.Z.148:5060, with session description >> 116.159165 X.Y.Z.148 -> X.Y.Z.138 SIP Status: 100 Trying >> 116.181582 X.Y.Z.148 -> X.Y.Z.138 SIP Status: 180 Ringing >> 116.192198 X.Y.Z.138 -> 1.2.3.4 SIP Status: 180 Ringing >> 116.192218 X.Y.Z.138 -> 1.2.3.4 SIP Status: 180 Ringing >> 118.894027 X.Y.Z.148 -> X.Y.Z.138 SIP/SDP Status: 200 OK, with session >> description >> 118.900656 X.Y.Z.138 -> X.Y.Z.148 SIP Request: ACK >> sip:55555555@X.Y.Z.148:5060 >> 118.900671 X.Y.Z.138 -> X.Y.Z.148 SIP Request: ACK >> sip:55555555@X.Y.Z.148:5060 >> 118.908267 X.Y.Z.138 -> 1.2.3.4 SIP/SDP Status: 200 OK, with session >> description >> 118.908279 X.Y.Z.138 -> 1.2.3.4 SIP/SDP Status: 200 OK, with session >> description >> 118.950770 1.2.3.4 -> X.Y.Z.138 SIP Request: ACK sip:X.Y.Z.138:5060 >> 122.220504 1.2.3.4 -> X.Y.Z.138 SIP Request: BYE sip:X.Y.Z.138:5060 >> 122.236390 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK >> 122.236401 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK >> 122.239402 X.Y.Z.138 -> X.Y.Z.148 SIP Request: BYE >> sip:55555555@X.Y.Z.148:5060 >> 122.239414 X.Y.Z.138 -> X.Y.Z.148 SIP Request: BYE >> sip:55555555@X.Y.Z.148:5060 >> 122.248420 X.Y.Z.148 -> X.Y.Z.138 SIP Status: 200 OK >> 130.767892 1.2.3.4 -> X.Y.Z.138 SIP Request: OPTIONS >> sip:55555555@X.Y.Z.138:65080 >> 130.776518 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK >> 130.776532 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK >> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2005. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> opensipstack-devel mailing list >> ope...@li... >> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel >> >> >> >> > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > opensipstack-devel mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensipstack-devel > |
|
From: <jo...@op...> - 2007-11-18 10:25:18
|
Here are the timestamps 0.030086 X.Y.Z.138 -> 1.2.3.4 SIP Request: REGISTER 0.066302 1.2.3.4 -> X.Y.Z.138 SIP Status: 100 Trying (1 bindings) 0.073700 1.2.3.4 -> X.Y.Z.138 SIP Status: 401 Unauthorized (1 bindings) If you will see, the first response from 1.2.3.4 comes after the SIP_TIMER_A value of 500 ms has expired. Thus a retransmission is required 116.150431 X.Y.Z.138 -> X.Y.Z.148 SIP/SDP Request: INVITE 116.159165 X.Y.Z.148 -> X.Y.Z.138 SIP Status: 100 Trying Same with this sequence. As i said, this is normal retransmission you are seeing. Joegen Jeremy A wrote: > Hello, > > Thanks for the suggested cause. However I think that DNS is not the > issue. In the example there are no DNS requests by openSBC ( I assume it > has cached these from earlier experiments) > > Every packet sent by openSBC is duplicated. This includes packets to the > upstream provider and packets to the registering phone. > > The packets are duplicated long after any DNS caching should have > happened - In the example below this occurs over a period of 130 > seconds. It also occurs with the phone device where DNS resolution is > not used. > > Joegen E. Baclor wrote: > >> This may just be timer synchronization issues where the first REGISTER >> request took some time to be resolved via DNS long enough that the timer >> for retransmission has already fired. OpenSBC is caching DNS records >> so that the next need for DNS resoltuion would be faster. OpenSBC does >> not support unsolicited NOTIFY. Your provider might be using NOTIFY to >> maintain NAT pinholes, in which case the response is not really an issue >> whether it's a 200 Ok or Method Not Allowed. >> >> >> Jeremy A wrote: >> >> >>> Hello, >>> >>> I've just started to evaluate opensbc version 1.1.4 >>> >>> I put a wireshark trace on the traffic and it seems that every packet >>> sent by opensbc is sent twice. Is this correct behaviour ? >>> >>> Here is a trace of a registration and an incoming call. The >>> configuration is a linksys spa962 that normally registers direct with a >>> VOIP provider and no outgoing proxy. I changed this to use the opensbc >>> as outgoing proxy and logged the traffic. >>> >>> The linksys IP ends in .148. the opensbc instance ends in .138. Both >>> addresses are routable and have equivalent firewall enabled access to >>> the internet. The VOIP provider has a fake IP of 1.2.3.4 >>> >>> I also see a NOTIFY from the voip provider is being rejected - is this >>> normal? >>> >>> >>> 0.000817 X.Y.Z.148 -> X.Y.Z.138 SIP Request: REGISTER >>> sip:gw4.fakesipprovider.com >>> 0.018829 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (0 bindings) >>> 0.018837 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (0 bindings) >>> 0.030086 X.Y.Z.138 -> 1.2.3.4 SIP Request: REGISTER >>> sip:gw4.fakesipprovider.com >>> 0.030098 X.Y.Z.138 -> 1.2.3.4 SIP Request: REGISTER >>> sip:gw4.fakesipprovider.com >>> 0.066302 1.2.3.4 -> X.Y.Z.138 SIP Status: 100 Trying (1 bindings) >>> 0.073700 1.2.3.4 -> X.Y.Z.138 SIP Status: 401 Unauthorized (1 bindings) >>> 0.076972 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (1 bindings) >>> 0.076981 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (1 bindings) >>> 0.088366 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 401 Unauthorized (1 >>> bindings) >>> 0.088377 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 401 Unauthorized (1 >>> bindings) >>> 0.096668 X.Y.Z.148 -> X.Y.Z.138 SIP Request: REGISTER >>> sip:gw4.fakesipprovider.com >>> 0.116038 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (0 bindings) >>> 0.116055 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (0 bindings) >>> 0.119375 X.Y.Z.138 -> 1.2.3.4 SIP Request: REGISTER >>> sip:gw4.fakesipprovider.com >>> 0.119384 X.Y.Z.138 -> 1.2.3.4 SIP Request: REGISTER >>> sip:gw4.fakesipprovider.com >>> 0.160873 X.Y.Z.138 -> 1.2.3.4 SIP Request: REGISTER >>> sip:gw4.fakesipprovider.com >>> 0.160885 X.Y.Z.138 -> 1.2.3.4 SIP Request: REGISTER >>> sip:gw4.fakesipprovider.com >>> 0.163720 1.2.3.4 -> X.Y.Z.138 SIP Status: 100 Trying (1 bindings) >>> 0.170387 1.2.3.4 -> X.Y.Z.138 SIP Status: 200 OK (1 bindings) >>> 0.173012 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (1 bindings) >>> 0.173022 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (1 bindings) >>> 0.182666 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 200 OK (1 bindings) >>> 0.182677 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 200 OK (1 bindings) >>> 0.200877 1.2.3.4 -> X.Y.Z.138 SIP Status: 100 Trying (1 bindings) >>> 0.208848 1.2.3.4 -> X.Y.Z.138 SIP Status: 200 OK (1 bindings) >>> 10.019211 1.2.3.4 -> X.Y.Z.138 SIP Request: NOTIFY >>> sip:55555555@X.Y.Z.138:65080 >>> 10.027932 X.Y.Z.138 -> 1.2.3.4 SIP Status: 405 Method Not Allowed >>> 10.027945 X.Y.Z.138 -> 1.2.3.4 SIP Status: 405 Method Not Allowed >>> 10.693615 1.2.3.4 -> X.Y.Z.138 SIP Request: OPTIONS >>> sip:55555555@X.Y.Z.138:65080 >>> 10.707659 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK >>> 10.707674 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK >>> 70.737972 1.2.3.4 -> X.Y.Z.138 SIP Request: OPTIONS >>> sip:55555555@X.Y.Z.138:65080 >>> 70.746471 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK >>> 70.746485 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK >>> 116.129914 1.2.3.4 -> X.Y.Z.138 SIP/SDP Request: INVITE >>> sip:55555555@X.Y.Z.138:65080, with session description >>> 116.146387 X.Y.Z.138 -> 1.2.3.4 SIP Status: 100 Trying >>> 116.146402 X.Y.Z.138 -> 1.2.3.4 SIP Status: 100 Trying >>> 116.150431 X.Y.Z.138 -> X.Y.Z.148 SIP/SDP Request: INVITE >>> sip:55555555@X.Y.Z.148:5060, with session description >>> 116.150443 X.Y.Z.138 -> X.Y.Z.148 SIP/SDP Request: INVITE >>> sip:55555555@X.Y.Z.148:5060, with session description >>> 116.159165 X.Y.Z.148 -> X.Y.Z.138 SIP Status: 100 Trying >>> 116.181582 X.Y.Z.148 -> X.Y.Z.138 SIP Status: 180 Ringing >>> 116.192198 X.Y.Z.138 -> 1.2.3.4 SIP Status: 180 Ringing >>> 116.192218 X.Y.Z.138 -> 1.2.3.4 SIP Status: 180 Ringing >>> 118.894027 X.Y.Z.148 -> X.Y.Z.138 SIP/SDP Status: 200 OK, with session >>> description >>> 118.900656 X.Y.Z.138 -> X.Y.Z.148 SIP Request: ACK >>> sip:55555555@X.Y.Z.148:5060 >>> 118.900671 X.Y.Z.138 -> X.Y.Z.148 SIP Request: ACK >>> sip:55555555@X.Y.Z.148:5060 >>> 118.908267 X.Y.Z.138 -> 1.2.3.4 SIP/SDP Status: 200 OK, with session >>> description >>> 118.908279 X.Y.Z.138 -> 1.2.3.4 SIP/SDP Status: 200 OK, with session >>> description >>> 118.950770 1.2.3.4 -> X.Y.Z.138 SIP Request: ACK sip:X.Y.Z.138:5060 >>> 122.220504 1.2.3.4 -> X.Y.Z.138 SIP Request: BYE sip:X.Y.Z.138:5060 >>> 122.236390 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK >>> 122.236401 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK >>> 122.239402 X.Y.Z.138 -> X.Y.Z.148 SIP Request: BYE >>> sip:55555555@X.Y.Z.148:5060 >>> 122.239414 X.Y.Z.138 -> X.Y.Z.148 SIP Request: BYE >>> sip:55555555@X.Y.Z.148:5060 >>> 122.248420 X.Y.Z.148 -> X.Y.Z.138 SIP Status: 200 OK >>> 130.767892 1.2.3.4 -> X.Y.Z.138 SIP Request: OPTIONS >>> sip:55555555@X.Y.Z.138:65080 >>> 130.776518 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK >>> 130.776532 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK >>> >>> >>> ------------------------------------------------------------------------- >>> This SF.net email is sponsored by: Microsoft >>> Defy all challenges. Microsoft(R) Visual Studio 2005. >>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>> _______________________________________________ >>> opensipstack-devel mailing list >>> ope...@li... >>> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel >>> >>> >>> >>> >>> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2005. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> opensipstack-devel mailing list >> ope...@li... >> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel >> >> > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > opensipstack-devel mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensipstack-devel > > > > |
|
From: Jeremy A <je...@el...> - 2007-11-18 10:45:20
|
Perhaps not? In your first example the time difference 0.030086 to 0.066302 / 0.073700 is of the order of 30-40 milliseconds In your second example the time difference 116.150431 to 116.159165 is 8734 microseconds or 8.734 milliseconds. I have looked carefully at the monitoring process to make sure it is not causing a false result. I can find no obvious problem. FYI The opensbc server is a VMWare virtual machine hosted on the monitoring server. The code running opensbc is the 1.1.4 linux release compiled natively and is the release version. jo...@op... wrote: > Here are the timestamps > > 0.030086 X.Y.Z.138 -> 1.2.3.4 SIP Request: REGISTER > 0.066302 1.2.3.4 -> X.Y.Z.138 SIP Status: 100 Trying (1 bindings) > 0.073700 1.2.3.4 -> X.Y.Z.138 SIP Status: 401 Unauthorized (1 bindings) > > If you will see, the first response from 1.2.3.4 comes after the SIP_TIMER_A value of 500 ms has expired. Thus a retransmission is required > > 116.150431 X.Y.Z.138 -> X.Y.Z.148 SIP/SDP Request: INVITE > 116.159165 X.Y.Z.148 -> X.Y.Z.138 SIP Status: 100 Trying > > Same with this sequence. As i said, this is normal retransmission you > are seeing. > > Joegen > > > > Jeremy A wrote: > >> Hello, >> >> Thanks for the suggested cause. However I think that DNS is not the >> issue. In the example there are no DNS requests by openSBC ( I assume it >> has cached these from earlier experiments) >> >> Every packet sent by openSBC is duplicated. This includes packets to the >> upstream provider and packets to the registering phone. >> >> The packets are duplicated long after any DNS caching should have >> happened - In the example below this occurs over a period of 130 >> seconds. It also occurs with the phone device where DNS resolution is >> not used. >> >> Joegen E. Baclor wrote: >> >> >>> This may just be timer synchronization issues where the first REGISTER >>> request took some time to be resolved via DNS long enough that the timer >>> for retransmission has already fired. OpenSBC is caching DNS records >>> so that the next need for DNS resoltuion would be faster. OpenSBC does >>> not support unsolicited NOTIFY. Your provider might be using NOTIFY to >>> maintain NAT pinholes, in which case the response is not really an issue >>> whether it's a 200 Ok or Method Not Allowed. >>> >>> >>> Jeremy A wrote: >>> >>> >>> >>>> Hello, >>>> >>>> I've just started to evaluate opensbc version 1.1.4 >>>> >>>> I put a wireshark trace on the traffic and it seems that every packet >>>> sent by opensbc is sent twice. Is this correct behaviour ? >>>> >>>> Here is a trace of a registration and an incoming call. The >>>> configuration is a linksys spa962 that normally registers direct with a >>>> VOIP provider and no outgoing proxy. I changed this to use the opensbc >>>> as outgoing proxy and logged the traffic. >>>> >>>> The linksys IP ends in .148. the opensbc instance ends in .138. Both >>>> addresses are routable and have equivalent firewall enabled access to >>>> the internet. The VOIP provider has a fake IP of 1.2.3.4 >>>> >>>> I also see a NOTIFY from the voip provider is being rejected - is this >>>> normal? >>>> >>>> >>>> 0.000817 X.Y.Z.148 -> X.Y.Z.138 SIP Request: REGISTER >>>> sip:gw4.fakesipprovider.com >>>> 0.018829 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (0 bindings) >>>> 0.018837 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (0 bindings) >>>> 0.030086 X.Y.Z.138 -> 1.2.3.4 SIP Request: REGISTER >>>> sip:gw4.fakesipprovider.com >>>> 0.030098 X.Y.Z.138 -> 1.2.3.4 SIP Request: REGISTER >>>> sip:gw4.fakesipprovider.com >>>> 0.066302 1.2.3.4 -> X.Y.Z.138 SIP Status: 100 Trying (1 bindings) >>>> 0.073700 1.2.3.4 -> X.Y.Z.138 SIP Status: 401 Unauthorized (1 bindings) >>>> 0.076972 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (1 bindings) >>>> 0.076981 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (1 bindings) >>>> 0.088366 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 401 Unauthorized (1 >>>> bindings) >>>> 0.088377 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 401 Unauthorized (1 >>>> bindings) >>>> 0.096668 X.Y.Z.148 -> X.Y.Z.138 SIP Request: REGISTER >>>> sip:gw4.fakesipprovider.com >>>> 0.116038 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (0 bindings) >>>> 0.116055 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (0 bindings) >>>> 0.119375 X.Y.Z.138 -> 1.2.3.4 SIP Request: REGISTER >>>> sip:gw4.fakesipprovider.com >>>> 0.119384 X.Y.Z.138 -> 1.2.3.4 SIP Request: REGISTER >>>> sip:gw4.fakesipprovider.com >>>> 0.160873 X.Y.Z.138 -> 1.2.3.4 SIP Request: REGISTER >>>> sip:gw4.fakesipprovider.com >>>> 0.160885 X.Y.Z.138 -> 1.2.3.4 SIP Request: REGISTER >>>> sip:gw4.fakesipprovider.com >>>> 0.163720 1.2.3.4 -> X.Y.Z.138 SIP Status: 100 Trying (1 bindings) >>>> 0.170387 1.2.3.4 -> X.Y.Z.138 SIP Status: 200 OK (1 bindings) >>>> 0.173012 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (1 bindings) >>>> 0.173022 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (1 bindings) >>>> 0.182666 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 200 OK (1 bindings) >>>> 0.182677 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 200 OK (1 bindings) >>>> 0.200877 1.2.3.4 -> X.Y.Z.138 SIP Status: 100 Trying (1 bindings) >>>> 0.208848 1.2.3.4 -> X.Y.Z.138 SIP Status: 200 OK (1 bindings) >>>> 10.019211 1.2.3.4 -> X.Y.Z.138 SIP Request: NOTIFY >>>> sip:55555555@X.Y.Z.138:65080 >>>> 10.027932 X.Y.Z.138 -> 1.2.3.4 SIP Status: 405 Method Not Allowed >>>> 10.027945 X.Y.Z.138 -> 1.2.3.4 SIP Status: 405 Method Not Allowed >>>> 10.693615 1.2.3.4 -> X.Y.Z.138 SIP Request: OPTIONS >>>> sip:55555555@X.Y.Z.138:65080 >>>> 10.707659 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK >>>> 10.707674 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK >>>> 70.737972 1.2.3.4 -> X.Y.Z.138 SIP Request: OPTIONS >>>> sip:55555555@X.Y.Z.138:65080 >>>> 70.746471 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK >>>> 70.746485 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK >>>> 116.129914 1.2.3.4 -> X.Y.Z.138 SIP/SDP Request: INVITE >>>> sip:55555555@X.Y.Z.138:65080, with session description >>>> 116.146387 X.Y.Z.138 -> 1.2.3.4 SIP Status: 100 Trying >>>> 116.146402 X.Y.Z.138 -> 1.2.3.4 SIP Status: 100 Trying >>>> 116.150431 X.Y.Z.138 -> X.Y.Z.148 SIP/SDP Request: INVITE >>>> sip:55555555@X.Y.Z.148:5060, with session description >>>> 116.150443 X.Y.Z.138 -> X.Y.Z.148 SIP/SDP Request: INVITE >>>> sip:55555555@X.Y.Z.148:5060, with session description >>>> 116.159165 X.Y.Z.148 -> X.Y.Z.138 SIP Status: 100 Trying >>>> 116.181582 X.Y.Z.148 -> X.Y.Z.138 SIP Status: 180 Ringing >>>> 116.192198 X.Y.Z.138 -> 1.2.3.4 SIP Status: 180 Ringing >>>> 116.192218 X.Y.Z.138 -> 1.2.3.4 SIP Status: 180 Ringing >>>> 118.894027 X.Y.Z.148 -> X.Y.Z.138 SIP/SDP Status: 200 OK, with session >>>> description >>>> 118.900656 X.Y.Z.138 -> X.Y.Z.148 SIP Request: ACK >>>> sip:55555555@X.Y.Z.148:5060 >>>> 118.900671 X.Y.Z.138 -> X.Y.Z.148 SIP Request: ACK >>>> sip:55555555@X.Y.Z.148:5060 >>>> 118.908267 X.Y.Z.138 -> 1.2.3.4 SIP/SDP Status: 200 OK, with session >>>> description >>>> 118.908279 X.Y.Z.138 -> 1.2.3.4 SIP/SDP Status: 200 OK, with session >>>> description >>>> 118.950770 1.2.3.4 -> X.Y.Z.138 SIP Request: ACK sip:X.Y.Z.138:5060 >>>> 122.220504 1.2.3.4 -> X.Y.Z.138 SIP Request: BYE sip:X.Y.Z.138:5060 >>>> 122.236390 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK >>>> 122.236401 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK >>>> 122.239402 X.Y.Z.138 -> X.Y.Z.148 SIP Request: BYE >>>> sip:55555555@X.Y.Z.148:5060 >>>> 122.239414 X.Y.Z.138 -> X.Y.Z.148 SIP Request: BYE >>>> sip:55555555@X.Y.Z.148:5060 >>>> 122.248420 X.Y.Z.148 -> X.Y.Z.138 SIP Status: 200 OK >>>> 130.767892 1.2.3.4 -> X.Y.Z.138 SIP Request: OPTIONS >>>> sip:55555555@X.Y.Z.138:65080 >>>> 130.776518 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK >>>> 130.776532 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK >>>> >>>> >>>> ------------------------------------------------------------------------- >>>> This SF.net email is sponsored by: Microsoft >>>> Defy all challenges. Microsoft(R) Visual Studio 2005. >>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>>> _______________________________________________ >>>> opensipstack-devel mailing list >>>> ope...@li... >>>> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel >>>> >>>> >>>> >>>> >>>> >>>> >>> ------------------------------------------------------------------------- >>> This SF.net email is sponsored by: Microsoft >>> Defy all challenges. Microsoft(R) Visual Studio 2005. >>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>> _______________________________________________ >>> opensipstack-devel mailing list >>> ope...@li... >>> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel >>> >>> >>> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2005. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> opensipstack-devel mailing list >> ope...@li... >> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel >> >> >> >> >> > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > opensipstack-devel mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensipstack-devel > |
|
From: <jo...@op...> - 2007-11-18 12:13:30
|
Ouch! I guess you are right. For a second there, I thought I was looking at milliseconds. Let me try to replicate this issue. For the mean time would you be able to recompile using a higher value for SIP_TIMER_T1. Just look for #define SIP_TIMER_T1 500 in SIPTimer.h. I want to be sure it's actually Timer_A firing early instead of a rogue code in OpenSIPStack. Joegen Jeremy A wrote: > Perhaps not? > > In your first example the time difference 0.030086 to 0.066302 / > 0.073700 is of the order of 30-40 milliseconds > > In your second example the time difference 116.150431 to 116.159165 is > 8734 microseconds or 8.734 milliseconds. > > I have looked carefully at the monitoring process to make sure it is not > causing a false result. I can find no obvious problem. > > FYI The opensbc server is a VMWare virtual machine hosted on the > monitoring server. The code running opensbc is the 1.1.4 linux release > compiled natively and is the release version. > > > jo...@op... wrote: > >> Here are the timestamps >> >> 0.030086 X.Y.Z.138 -> 1.2.3.4 SIP Request: REGISTER >> 0.066302 1.2.3.4 -> X.Y.Z.138 SIP Status: 100 Trying (1 bindings) >> 0.073700 1.2.3.4 -> X.Y.Z.138 SIP Status: 401 Unauthorized (1 bindings) >> >> If you will see, the first response from 1.2.3.4 comes after the SIP_TIMER_A value of 500 ms has expired. Thus a retransmission is required >> >> 116.150431 X.Y.Z.138 -> X.Y.Z.148 SIP/SDP Request: INVITE >> 116.159165 X.Y.Z.148 -> X.Y.Z.138 SIP Status: 100 Trying >> >> Same with this sequence. As i said, this is normal retransmission you >> are seeing. >> >> Joegen >> >> >> >> Jeremy A wrote: >> >> >>> Hello, >>> >>> Thanks for the suggested cause. However I think that DNS is not the >>> issue. In the example there are no DNS requests by openSBC ( I assume it >>> has cached these from earlier experiments) >>> >>> Every packet sent by openSBC is duplicated. This includes packets to the >>> upstream provider and packets to the registering phone. >>> >>> The packets are duplicated long after any DNS caching should have >>> happened - In the example below this occurs over a period of 130 >>> seconds. It also occurs with the phone device where DNS resolution is >>> not used. >>> >>> Joegen E. Baclor wrote: >>> >>> >>> >>>> This may just be timer synchronization issues where the first REGISTER >>>> request took some time to be resolved via DNS long enough that the timer >>>> for retransmission has already fired. OpenSBC is caching DNS records >>>> so that the next need for DNS resoltuion would be faster. OpenSBC does >>>> not support unsolicited NOTIFY. Your provider might be using NOTIFY to >>>> maintain NAT pinholes, in which case the response is not really an issue >>>> whether it's a 200 Ok or Method Not Allowed. >>>> >>>> >>>> Jeremy A wrote: >>>> >>>> >>>> >>>> >>>>> Hello, >>>>> >>>>> I've just started to evaluate opensbc version 1.1.4 >>>>> >>>>> I put a wireshark trace on the traffic and it seems that every packet >>>>> sent by opensbc is sent twice. Is this correct behaviour ? >>>>> >>>>> Here is a trace of a registration and an incoming call. The >>>>> configuration is a linksys spa962 that normally registers direct with a >>>>> VOIP provider and no outgoing proxy. I changed this to use the opensbc >>>>> as outgoing proxy and logged the traffic. >>>>> >>>>> The linksys IP ends in .148. the opensbc instance ends in .138. Both >>>>> addresses are routable and have equivalent firewall enabled access to >>>>> the internet. The VOIP provider has a fake IP of 1.2.3.4 >>>>> >>>>> I also see a NOTIFY from the voip provider is being rejected - is this >>>>> normal? >>>>> >>>>> >>>>> 0.000817 X.Y.Z.148 -> X.Y.Z.138 SIP Request: REGISTER >>>>> sip:gw4.fakesipprovider.com >>>>> 0.018829 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (0 bindings) >>>>> 0.018837 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (0 bindings) >>>>> 0.030086 X.Y.Z.138 -> 1.2.3.4 SIP Request: REGISTER >>>>> sip:gw4.fakesipprovider.com >>>>> 0.030098 X.Y.Z.138 -> 1.2.3.4 SIP Request: REGISTER >>>>> sip:gw4.fakesipprovider.com >>>>> 0.066302 1.2.3.4 -> X.Y.Z.138 SIP Status: 100 Trying (1 bindings) >>>>> 0.073700 1.2.3.4 -> X.Y.Z.138 SIP Status: 401 Unauthorized (1 bindings) >>>>> 0.076972 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (1 bindings) >>>>> 0.076981 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (1 bindings) >>>>> 0.088366 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 401 Unauthorized (1 >>>>> bindings) >>>>> 0.088377 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 401 Unauthorized (1 >>>>> bindings) >>>>> 0.096668 X.Y.Z.148 -> X.Y.Z.138 SIP Request: REGISTER >>>>> sip:gw4.fakesipprovider.com >>>>> 0.116038 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (0 bindings) >>>>> 0.116055 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (0 bindings) >>>>> 0.119375 X.Y.Z.138 -> 1.2.3.4 SIP Request: REGISTER >>>>> sip:gw4.fakesipprovider.com >>>>> 0.119384 X.Y.Z.138 -> 1.2.3.4 SIP Request: REGISTER >>>>> sip:gw4.fakesipprovider.com >>>>> 0.160873 X.Y.Z.138 -> 1.2.3.4 SIP Request: REGISTER >>>>> sip:gw4.fakesipprovider.com >>>>> 0.160885 X.Y.Z.138 -> 1.2.3.4 SIP Request: REGISTER >>>>> sip:gw4.fakesipprovider.com >>>>> 0.163720 1.2.3.4 -> X.Y.Z.138 SIP Status: 100 Trying (1 bindings) >>>>> 0.170387 1.2.3.4 -> X.Y.Z.138 SIP Status: 200 OK (1 bindings) >>>>> 0.173012 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (1 bindings) >>>>> 0.173022 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (1 bindings) >>>>> 0.182666 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 200 OK (1 bindings) >>>>> 0.182677 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 200 OK (1 bindings) >>>>> 0.200877 1.2.3.4 -> X.Y.Z.138 SIP Status: 100 Trying (1 bindings) >>>>> 0.208848 1.2.3.4 -> X.Y.Z.138 SIP Status: 200 OK (1 bindings) >>>>> 10.019211 1.2.3.4 -> X.Y.Z.138 SIP Request: NOTIFY >>>>> sip:55555555@X.Y.Z.138:65080 >>>>> 10.027932 X.Y.Z.138 -> 1.2.3.4 SIP Status: 405 Method Not Allowed >>>>> 10.027945 X.Y.Z.138 -> 1.2.3.4 SIP Status: 405 Method Not Allowed >>>>> 10.693615 1.2.3.4 -> X.Y.Z.138 SIP Request: OPTIONS >>>>> sip:55555555@X.Y.Z.138:65080 >>>>> 10.707659 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK >>>>> 10.707674 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK >>>>> 70.737972 1.2.3.4 -> X.Y.Z.138 SIP Request: OPTIONS >>>>> sip:55555555@X.Y.Z.138:65080 >>>>> 70.746471 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK >>>>> 70.746485 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK >>>>> 116.129914 1.2.3.4 -> X.Y.Z.138 SIP/SDP Request: INVITE >>>>> sip:55555555@X.Y.Z.138:65080, with session description >>>>> 116.146387 X.Y.Z.138 -> 1.2.3.4 SIP Status: 100 Trying >>>>> 116.146402 X.Y.Z.138 -> 1.2.3.4 SIP Status: 100 Trying >>>>> 116.150431 X.Y.Z.138 -> X.Y.Z.148 SIP/SDP Request: INVITE >>>>> sip:55555555@X.Y.Z.148:5060, with session description >>>>> 116.150443 X.Y.Z.138 -> X.Y.Z.148 SIP/SDP Request: INVITE >>>>> sip:55555555@X.Y.Z.148:5060, with session description >>>>> 116.159165 X.Y.Z.148 -> X.Y.Z.138 SIP Status: 100 Trying >>>>> 116.181582 X.Y.Z.148 -> X.Y.Z.138 SIP Status: 180 Ringing >>>>> 116.192198 X.Y.Z.138 -> 1.2.3.4 SIP Status: 180 Ringing >>>>> 116.192218 X.Y.Z.138 -> 1.2.3.4 SIP Status: 180 Ringing >>>>> 118.894027 X.Y.Z.148 -> X.Y.Z.138 SIP/SDP Status: 200 OK, with session >>>>> description >>>>> 118.900656 X.Y.Z.138 -> X.Y.Z.148 SIP Request: ACK >>>>> sip:55555555@X.Y.Z.148:5060 >>>>> 118.900671 X.Y.Z.138 -> X.Y.Z.148 SIP Request: ACK >>>>> sip:55555555@X.Y.Z.148:5060 >>>>> 118.908267 X.Y.Z.138 -> 1.2.3.4 SIP/SDP Status: 200 OK, with session >>>>> description >>>>> 118.908279 X.Y.Z.138 -> 1.2.3.4 SIP/SDP Status: 200 OK, with session >>>>> description >>>>> 118.950770 1.2.3.4 -> X.Y.Z.138 SIP Request: ACK sip:X.Y.Z.138:5060 >>>>> 122.220504 1.2.3.4 -> X.Y.Z.138 SIP Request: BYE sip:X.Y.Z.138:5060 >>>>> 122.236390 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK >>>>> 122.236401 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK >>>>> 122.239402 X.Y.Z.138 -> X.Y.Z.148 SIP Request: BYE >>>>> sip:55555555@X.Y.Z.148:5060 >>>>> 122.239414 X.Y.Z.138 -> X.Y.Z.148 SIP Request: BYE >>>>> sip:55555555@X.Y.Z.148:5060 >>>>> 122.248420 X.Y.Z.148 -> X.Y.Z.138 SIP Status: 200 OK >>>>> 130.767892 1.2.3.4 -> X.Y.Z.138 SIP Request: OPTIONS >>>>> sip:55555555@X.Y.Z.138:65080 >>>>> 130.776518 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK >>>>> 130.776532 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK >>>>> >>>>> >>>>> ------------------------------------------------------------------------- >>>>> This SF.net email is sponsored by: Microsoft >>>>> Defy all challenges. Microsoft(R) Visual Studio 2005. >>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>>>> _______________________________________________ >>>>> opensipstack-devel mailing list >>>>> ope...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> ------------------------------------------------------------------------- >>>> This SF.net email is sponsored by: Microsoft >>>> Defy all challenges. Microsoft(R) Visual Studio 2005. >>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>>> _______________________________________________ >>>> opensipstack-devel mailing list >>>> ope...@li... >>>> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel >>>> >>>> >>>> >>>> >>> ------------------------------------------------------------------------- >>> This SF.net email is sponsored by: Microsoft >>> Defy all challenges. Microsoft(R) Visual Studio 2005. >>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>> _______________________________________________ >>> opensipstack-devel mailing list >>> ope...@li... >>> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel >>> >>> >>> >>> >>> >>> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2005. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> opensipstack-devel mailing list >> ope...@li... >> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel >> >> > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > opensipstack-devel mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensipstack-devel > > > > |
|
From: <jo...@op...> - 2007-11-18 13:39:46
|
Hi Jeremy, I think I found out whats causing this early firing of retransmission. The timer resolution set for SIPTimerManager is too low. IT's currently set to 500 ms which is as low as it could get. This would increase the chances of SIP Timer A to fire sooner. Try setting #define SIP_TIMER_RESOLUTION from 500 to 10 milliseconds in SIPTimerManager.cxx. Let me know if this solves it. Thanks for pointing it out. Joegen jo...@op... wrote: > Ouch! I guess you are right. For a second there, I thought I was > looking at milliseconds. Let me try to replicate this issue. For the > mean time would you be able to recompile using a higher value for > SIP_TIMER_T1. Just look for #define SIP_TIMER_T1 500 in SIPTimer.h. I > want to be sure it's actually Timer_A firing early instead of a rogue > code in OpenSIPStack. > > Joegen > > Jeremy A wrote: > >> Perhaps not? >> >> In your first example the time difference 0.030086 to 0.066302 / >> 0.073700 is of the order of 30-40 milliseconds >> >> In your second example the time difference 116.150431 to 116.159165 is >> 8734 microseconds or 8.734 milliseconds. >> >> I have looked carefully at the monitoring process to make sure it is not >> causing a false result. I can find no obvious problem. >> >> FYI The opensbc server is a VMWare virtual machine hosted on the >> monitoring server. The code running opensbc is the 1.1.4 linux release >> compiled natively and is the release version. >> >> >> jo...@op... wrote: >> >> >>> Here are the timestamps >>> >>> 0.030086 X.Y.Z.138 -> 1.2.3.4 SIP Request: REGISTER >>> 0.066302 1.2.3.4 -> X.Y.Z.138 SIP Status: 100 Trying (1 bindings) >>> 0.073700 1.2.3.4 -> X.Y.Z.138 SIP Status: 401 Unauthorized (1 bindings) >>> >>> If you will see, the first response from 1.2.3.4 comes after the SIP_TIMER_A value of 500 ms has expired. Thus a retransmission is required >>> >>> 116.150431 X.Y.Z.138 -> X.Y.Z.148 SIP/SDP Request: INVITE >>> 116.159165 X.Y.Z.148 -> X.Y.Z.138 SIP Status: 100 Trying >>> >>> Same with this sequence. As i said, this is normal retransmission you >>> are seeing. >>> >>> Joegen >>> >>> >>> >>> Jeremy A wrote: >>> >>> >>> >>>> Hello, >>>> >>>> Thanks for the suggested cause. However I think that DNS is not the >>>> issue. In the example there are no DNS requests by openSBC ( I assume it >>>> has cached these from earlier experiments) >>>> >>>> Every packet sent by openSBC is duplicated. This includes packets to the >>>> upstream provider and packets to the registering phone. >>>> >>>> The packets are duplicated long after any DNS caching should have >>>> happened - In the example below this occurs over a period of 130 >>>> seconds. It also occurs with the phone device where DNS resolution is >>>> not used. >>>> >>>> Joegen E. Baclor wrote: >>>> >>>> >>>> >>>> >>>>> This may just be timer synchronization issues where the first REGISTER >>>>> request took some time to be resolved via DNS long enough that the timer >>>>> for retransmission has already fired. OpenSBC is caching DNS records >>>>> so that the next need for DNS resoltuion would be faster. OpenSBC does >>>>> not support unsolicited NOTIFY. Your provider might be using NOTIFY to >>>>> maintain NAT pinholes, in which case the response is not really an issue >>>>> whether it's a 200 Ok or Method Not Allowed. >>>>> >>>>> >>>>> Jeremy A wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> Hello, >>>>>> >>>>>> I've just started to evaluate opensbc version 1.1.4 >>>>>> >>>>>> I put a wireshark trace on the traffic and it seems that every packet >>>>>> sent by opensbc is sent twice. Is this correct behaviour ? >>>>>> >>>>>> Here is a trace of a registration and an incoming call. The >>>>>> configuration is a linksys spa962 that normally registers direct with a >>>>>> VOIP provider and no outgoing proxy. I changed this to use the opensbc >>>>>> as outgoing proxy and logged the traffic. >>>>>> >>>>>> The linksys IP ends in .148. the opensbc instance ends in .138. Both >>>>>> addresses are routable and have equivalent firewall enabled access to >>>>>> the internet. The VOIP provider has a fake IP of 1.2.3.4 >>>>>> >>>>>> I also see a NOTIFY from the voip provider is being rejected - is this >>>>>> normal? >>>>>> >>>>>> >>>>>> 0.000817 X.Y.Z.148 -> X.Y.Z.138 SIP Request: REGISTER >>>>>> sip:gw4.fakesipprovider.com >>>>>> 0.018829 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (0 bindings) >>>>>> 0.018837 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (0 bindings) >>>>>> 0.030086 X.Y.Z.138 -> 1.2.3.4 SIP Request: REGISTER >>>>>> sip:gw4.fakesipprovider.com >>>>>> 0.030098 X.Y.Z.138 -> 1.2.3.4 SIP Request: REGISTER >>>>>> sip:gw4.fakesipprovider.com >>>>>> 0.066302 1.2.3.4 -> X.Y.Z.138 SIP Status: 100 Trying (1 bindings) >>>>>> 0.073700 1.2.3.4 -> X.Y.Z.138 SIP Status: 401 Unauthorized (1 bindings) >>>>>> 0.076972 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (1 bindings) >>>>>> 0.076981 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (1 bindings) >>>>>> 0.088366 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 401 Unauthorized (1 >>>>>> bindings) >>>>>> 0.088377 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 401 Unauthorized (1 >>>>>> bindings) >>>>>> 0.096668 X.Y.Z.148 -> X.Y.Z.138 SIP Request: REGISTER >>>>>> sip:gw4.fakesipprovider.com >>>>>> 0.116038 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (0 bindings) >>>>>> 0.116055 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (0 bindings) >>>>>> 0.119375 X.Y.Z.138 -> 1.2.3.4 SIP Request: REGISTER >>>>>> sip:gw4.fakesipprovider.com >>>>>> 0.119384 X.Y.Z.138 -> 1.2.3.4 SIP Request: REGISTER >>>>>> sip:gw4.fakesipprovider.com >>>>>> 0.160873 X.Y.Z.138 -> 1.2.3.4 SIP Request: REGISTER >>>>>> sip:gw4.fakesipprovider.com >>>>>> 0.160885 X.Y.Z.138 -> 1.2.3.4 SIP Request: REGISTER >>>>>> sip:gw4.fakesipprovider.com >>>>>> 0.163720 1.2.3.4 -> X.Y.Z.138 SIP Status: 100 Trying (1 bindings) >>>>>> 0.170387 1.2.3.4 -> X.Y.Z.138 SIP Status: 200 OK (1 bindings) >>>>>> 0.173012 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (1 bindings) >>>>>> 0.173022 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 100 Trying (1 bindings) >>>>>> 0.182666 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 200 OK (1 bindings) >>>>>> 0.182677 X.Y.Z.138 -> X.Y.Z.148 SIP Status: 200 OK (1 bindings) >>>>>> 0.200877 1.2.3.4 -> X.Y.Z.138 SIP Status: 100 Trying (1 bindings) >>>>>> 0.208848 1.2.3.4 -> X.Y.Z.138 SIP Status: 200 OK (1 bindings) >>>>>> 10.019211 1.2.3.4 -> X.Y.Z.138 SIP Request: NOTIFY >>>>>> sip:55555555@X.Y.Z.138:65080 >>>>>> 10.027932 X.Y.Z.138 -> 1.2.3.4 SIP Status: 405 Method Not Allowed >>>>>> 10.027945 X.Y.Z.138 -> 1.2.3.4 SIP Status: 405 Method Not Allowed >>>>>> 10.693615 1.2.3.4 -> X.Y.Z.138 SIP Request: OPTIONS >>>>>> sip:55555555@X.Y.Z.138:65080 >>>>>> 10.707659 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK >>>>>> 10.707674 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK >>>>>> 70.737972 1.2.3.4 -> X.Y.Z.138 SIP Request: OPTIONS >>>>>> sip:55555555@X.Y.Z.138:65080 >>>>>> 70.746471 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK >>>>>> 70.746485 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK >>>>>> 116.129914 1.2.3.4 -> X.Y.Z.138 SIP/SDP Request: INVITE >>>>>> sip:55555555@X.Y.Z.138:65080, with session description >>>>>> 116.146387 X.Y.Z.138 -> 1.2.3.4 SIP Status: 100 Trying >>>>>> 116.146402 X.Y.Z.138 -> 1.2.3.4 SIP Status: 100 Trying >>>>>> 116.150431 X.Y.Z.138 -> X.Y.Z.148 SIP/SDP Request: INVITE >>>>>> sip:55555555@X.Y.Z.148:5060, with session description >>>>>> 116.150443 X.Y.Z.138 -> X.Y.Z.148 SIP/SDP Request: INVITE >>>>>> sip:55555555@X.Y.Z.148:5060, with session description >>>>>> 116.159165 X.Y.Z.148 -> X.Y.Z.138 SIP Status: 100 Trying >>>>>> 116.181582 X.Y.Z.148 -> X.Y.Z.138 SIP Status: 180 Ringing >>>>>> 116.192198 X.Y.Z.138 -> 1.2.3.4 SIP Status: 180 Ringing >>>>>> 116.192218 X.Y.Z.138 -> 1.2.3.4 SIP Status: 180 Ringing >>>>>> 118.894027 X.Y.Z.148 -> X.Y.Z.138 SIP/SDP Status: 200 OK, with session >>>>>> description >>>>>> 118.900656 X.Y.Z.138 -> X.Y.Z.148 SIP Request: ACK >>>>>> sip:55555555@X.Y.Z.148:5060 >>>>>> 118.900671 X.Y.Z.138 -> X.Y.Z.148 SIP Request: ACK >>>>>> sip:55555555@X.Y.Z.148:5060 >>>>>> 118.908267 X.Y.Z.138 -> 1.2.3.4 SIP/SDP Status: 200 OK, with session >>>>>> description >>>>>> 118.908279 X.Y.Z.138 -> 1.2.3.4 SIP/SDP Status: 200 OK, with session >>>>>> description >>>>>> 118.950770 1.2.3.4 -> X.Y.Z.138 SIP Request: ACK sip:X.Y.Z.138:5060 >>>>>> 122.220504 1.2.3.4 -> X.Y.Z.138 SIP Request: BYE sip:X.Y.Z.138:5060 >>>>>> 122.236390 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK >>>>>> 122.236401 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK >>>>>> 122.239402 X.Y.Z.138 -> X.Y.Z.148 SIP Request: BYE >>>>>> sip:55555555@X.Y.Z.148:5060 >>>>>> 122.239414 X.Y.Z.138 -> X.Y.Z.148 SIP Request: BYE >>>>>> sip:55555555@X.Y.Z.148:5060 >>>>>> 122.248420 X.Y.Z.148 -> X.Y.Z.138 SIP Status: 200 OK >>>>>> 130.767892 1.2.3.4 -> X.Y.Z.138 SIP Request: OPTIONS >>>>>> sip:55555555@X.Y.Z.138:65080 >>>>>> 130.776518 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK >>>>>> 130.776532 X.Y.Z.138 -> 1.2.3.4 SIP Status: 200 OK >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------- >>>>>> This SF.net email is sponsored by: Microsoft >>>>>> Defy all challenges. Microsoft(R) Visual Studio 2005. >>>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>>>>> _______________________________________________ >>>>>> opensipstack-devel mailing list >>>>>> ope...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> ------------------------------------------------------------------------- >>>>> This SF.net email is sponsored by: Microsoft >>>>> Defy all challenges. Microsoft(R) Visual Studio 2005. >>>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>>>> _______________________________________________ >>>>> opensipstack-devel mailing list >>>>> ope...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel >>>>> >>>>> >>>>> >>>>> >>>>> >>>> ------------------------------------------------------------------------- >>>> This SF.net email is sponsored by: Microsoft >>>> Defy all challenges. Microsoft(R) Visual Studio 2005. >>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>>> _______________________________________________ >>>> opensipstack-devel mailing list >>>> ope...@li... >>>> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> ------------------------------------------------------------------------- >>> This SF.net email is sponsored by: Microsoft >>> Defy all challenges. Microsoft(R) Visual Studio 2005. >>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>> _______________________________________________ >>> opensipstack-devel mailing list >>> ope...@li... >>> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel >>> >>> >>> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2005. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> opensipstack-devel mailing list >> ope...@li... >> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel >> >> >> >> >> > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > opensipstack-devel mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensipstack-devel > > > > |
|
From: Jeremy A <je...@el...> - 2007-11-18 19:05:47
|
Not much difference I'm afraid. I set SIP_TIMER_MANAGER to 20000 (20 milliseconds?) The trace showed that the only packets sent by openSBC that weren't duplicated were the DNS queries. The rest were duplicated at typically 10-15 microseconds delay jo...@op... wrote: > Hi Jeremy, > > I think I found out whats causing this early firing of retransmission. > The timer resolution set for SIPTimerManager is too low. IT's currently > set to 500 ms which is as low as it could get. This would increase the > chances of SIP Timer A to fire sooner. Try setting #define > SIP_TIMER_RESOLUTION from 500 to 10 milliseconds in > SIPTimerManager.cxx. Let me know if this solves it. Thanks for > pointing it out. > > Joegen > > jo...@op... wrote: > >> Ouch! I guess you are right. For a second there, I thought I was >> looking at milliseconds. Let me try to replicate this issue. For the >> mean time would you be able to recompile using a higher value for >> SIP_TIMER_T1. Just look for #define SIP_TIMER_T1 500 in SIPTimer.h. I >> want to be sure it's actually Timer_A firing early instead of a rogue >> code in OpenSIPStack. >> >> Joegen >> >> Jeremy A wrote: >> >> >>> Perhaps not? >>> >>> In your first example the time difference 0.030086 to 0.066302 / >>> 0.073700 is of the order of 30-40 milliseconds >>> >>> In your second example the time difference 116.150431 to 116.159165 is >>> 8734 microseconds or 8.734 milliseconds. >>> >>> I have looked carefully at the monitoring process to make sure it is not >>> causing a false result. I can find no obvious problem. >>> >>> FYI The opensbc server is a VMWare virtual machine hosted on the >>> monitoring server. The code running opensbc is the 1.1.4 linux release >>> compiled natively and is the release version. >>> >>> |
|
From: Joegen E. B. <joe...@gm...> - 2007-11-18 23:52:33
|
Jeremy, It should be #define SIP_TIMER_RESOLUTION 20 /// 20 milliseconds Joegen Jeremy A wrote: > Not much difference I'm afraid. > > I set SIP_TIMER_MANAGER to 20000 (20 milliseconds?) > > The trace showed that the only packets sent by openSBC that weren't > duplicated were the DNS queries. The rest were duplicated at typically > 10-15 microseconds delay > > > jo...@op... wrote: > >> Hi Jeremy, >> >> I think I found out whats causing this early firing of retransmission. >> The timer resolution set for SIPTimerManager is too low. IT's currently >> set to 500 ms which is as low as it could get. This would increase the >> chances of SIP Timer A to fire sooner. Try setting #define >> SIP_TIMER_RESOLUTION from 500 to 10 milliseconds in >> SIPTimerManager.cxx. Let me know if this solves it. Thanks for >> pointing it out. >> >> Joegen >> >> jo...@op... wrote: >> >> >>> Ouch! I guess you are right. For a second there, I thought I was >>> looking at milliseconds. Let me try to replicate this issue. For the >>> mean time would you be able to recompile using a higher value for >>> SIP_TIMER_T1. Just look for #define SIP_TIMER_T1 500 in SIPTimer.h. I >>> want to be sure it's actually Timer_A firing early instead of a rogue >>> code in OpenSIPStack. >>> >>> Joegen >>> >>> Jeremy A wrote: >>> >>> >>> >>>> Perhaps not? >>>> >>>> In your first example the time difference 0.030086 to 0.066302 / >>>> 0.073700 is of the order of 30-40 milliseconds >>>> >>>> In your second example the time difference 116.150431 to 116.159165 is >>>> 8734 microseconds or 8.734 milliseconds. >>>> >>>> I have looked carefully at the monitoring process to make sure it is not >>>> causing a false result. I can find no obvious problem. >>>> >>>> FYI The opensbc server is a VMWare virtual machine hosted on the >>>> monitoring server. The code running opensbc is the 1.1.4 linux release >>>> compiled natively and is the release version. >>>> >>>> >>>> > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > opensipstack-devel mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensipstack-devel > > > |
|
From: Jeremy A <je...@el...> - 2007-11-19 00:24:47
|
Joegen E. Baclor wrote: > Jeremy, > > It should be > > #define SIP_TIMER_RESOLUTION 20 /// 20 milliseconds > > Joegen > O.K. set to 20, then I rebuilt the complete opensipstack and then relinked opensbc into it but no effect. All SIP packets are duplicated as before. |
|
From: <jo...@op...> - 2007-11-19 00:38:40
|
Maybe you are experiencing cpu clock issue in vmware as discussed here? http://communities.vmware.com/message/432646;jsessionid=050D2118A4F4A0E4285187A4B531F388 Jeremy A wrote: > Joegen E. Baclor wrote: > >> Jeremy, >> >> It should be >> >> #define SIP_TIMER_RESOLUTION 20 /// 20 milliseconds >> >> Joegen >> >> > > O.K. set to 20, then I rebuilt the complete opensipstack and then > relinked opensbc into it but no effect. All SIP packets are duplicated > as before. > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > opensipstack-devel mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensipstack-devel > > > > |
|
From: Jeremy A <je...@el...> - 2007-11-19 03:00:35
|
jo...@op... wrote: > Maybe you are experiencing cpu clock issue in vmware as discussed here? > > http://communities.vmware.com/message/432646;jsessionid=050D2118A4F4A0E4285187A4B531F388 > I have got my VM time sync running fine with no net drift. I think the problem lies elsewhere. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X