opensipstack-devel Mailing List for OpenSIPStack (Page 38)
Brought to you by:
joegenbaclor
Menu
▾
▴
opensipstack-devel
You can subscribe to this list here.
| 2006 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(5) |
Jun
(12) |
Jul
(4) |
Aug
(3) |
Sep
(24) |
Oct
(45) |
Nov
(41) |
Dec
(67) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(51) |
Feb
(93) |
Mar
(54) |
Apr
(76) |
May
(114) |
Jun
(133) |
Jul
(124) |
Aug
(180) |
Sep
(53) |
Oct
(41) |
Nov
(109) |
Dec
(92) |
| 2008 |
Jan
(52) |
Feb
(40) |
Mar
(29) |
Apr
(40) |
May
(83) |
Jun
(68) |
Jul
(30) |
Aug
(72) |
Sep
(50) |
Oct
(48) |
Nov
(25) |
Dec
(80) |
| 2009 |
Jan
(9) |
Feb
(2) |
Mar
(32) |
Apr
(67) |
May
|
Jun
(7) |
Jul
(7) |
Aug
(4) |
Sep
(3) |
Oct
|
Nov
(6) |
Dec
(2) |
| 2010 |
Jan
|
Feb
(4) |
Mar
|
Apr
|
May
(10) |
Jun
(2) |
Jul
|
Aug
(2) |
Sep
(1) |
Oct
|
Nov
(5) |
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
(1) |
Apr
(2) |
May
(2) |
Jun
|
Jul
|
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <jo...@op...> - 2007-11-20 09:09:10
|
Thomas Raschbacher wrote: > Hi. > > I just downloaded opensipstack and opensbc to try if it is suitable for= our purpose (integration of SIP registrar in our product - which has it'= s own database of users and also manages calls as it is a telephony app.)= > > While trying out the software I was wondering why ENABLE_TCP_TRANSPORT = is set to 0 by default. I set it to true and got some compile errors (wh= ich were trivial to 'Fix'. Is there any reason as to why this is disabled= ? Also I couldn't find anywhere where TLS is actually enabled. Did I just= miss something, or is there a reason for this? Opensbc did start listeni= ng on TCP port 5060 after I changed the define. > =20 I guess, (may be to your dismay), I have answered the mystery behind=20 why TCP is currently disabled in the build process. > Apart from that I was wondering if anyone has any experience of integra= ting opensipstack into an existing telephony server. > > =20 By Telephony Server you mean building a PSTN gateway with boards and=20 using OpenSIPStack as the core or do you mean something else? > Regards, > > Mit freundlichen Gr=FC=DFen > Thomas Raschbacher > ____________________________________________ > itCampus Technology GmbH > =D6sterreich * Deutschland * Italien > Wehlistra=DFe 27b > 1200 Wien > tho...@it... > Tel: +43 (1) 33418557-58 > Fax: +43 (1) 33418557-958 > http://www.itctec.com > UID: ATU 6339 0618 > Firmenbuchnr: FN292598t, Handelsgericht Wien > Gesch=E4ftsf=FChrer: Andreas G=FCnser, Andreas Lassmann > Joint Venture von itCampus und MEC > > itCampus Gruppe > Deutschland * Gro=DFbritannien * Italien * =D6sterreich * Schweiz * Slo= wakei > http://www.itcampus.eu > > > -----------------------------------------------------------------------= -- > 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 > > > > =20 |
|
From: <jo...@op...> - 2007-11-20 09:05:58
|
Hi Thomas, TCP is work in progress and have a big chance that it will not work. =20 However TCP is almost 90 % done. If you are a developer, feel free to=20 contribute the remaining 10% back to the project ;-) TLS of course requires TCP so TCP needs to be delivered first before we=20 can get into it. SRTP is not supported entirely and is currently not in = the pipeline. There is of course a reason why TCP did not get too much=20 of an attention. TCP breaks NAT and the only way currently to have TCP=20 work with NAT is to support the outbound draft which is another =20 functionality that is not in the pipeline just yet. I admit that we=20 have a long way to go but we are getting there. Joegen Thomas Raschbacher wrote: > Hi. > > Can someone clarify the status of the implementations for TCP, TLS and = secure RTP for me please? > After looking at the code I noticed TCP was disabled by default, TLS do= es seem to have a header only and no actual implementation / use. > Didn't find any info on whether the stack supports secure RTP at all or= not (apart from some encrypted flag ..) > > Regards, > > Mit freundlichen Gr=FC=DFen > Thomas Raschbacher > ____________________________________________ > itCampus Technology GmbH > =D6sterreich * Deutschland * Italien > Wehlistra=DFe 27b > 1200 Wien > tho...@it...<mailto:dan...@it...> > Tel: +43 (1) 33418557-58 > Fax: +43 (1) 33418557-958 > http://www.itctec.com<http://www.itctec.com/> > UID: ATU 6339 0618 > Firmenbuchnr: FN292598t, Handelsgericht Wien > Gesch=E4ftsf=FChrer: Andreas G=FCnser, Andreas Lassmann > Joint Venture von itCampus und MEC > > itCampus Gruppe > Deutschland * Gro=DFbritannien * Italien * =D6sterreich * Schweiz * Slo= wakei > http://www.itcampus.eu > > -----------------------------------------------------------------------= -- > 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 > > > > =20 |
|
From: Thomas R. <tho...@it...> - 2007-11-20 08:54:31
|
Hi. Can someone clarify the status of the implementations for TCP, TLS and secu= re RTP for me please? After looking at the code I noticed TCP was disabled by default, TLS does s= eem to have a header only and no actual implementation / use. Didn't find any info on whether the stack supports secure RTP at all or not= (apart from some encrypted flag ..) Regards, Mit freundlichen Gr=FC=DFen Thomas Raschbacher ____________________________________________ itCampus Technology GmbH =D6sterreich * Deutschland * Italien Wehlistra=DFe 27b 1200 Wien tho...@it...<mailto:dan...@it...> Tel: +43 (1) 33418557-58 Fax: +43 (1) 33418557-958 http://www.itctec.com<http://www.itctec.com/> UID: ATU 6339 0618 Firmenbuchnr: FN292598t, Handelsgericht Wien Gesch=E4ftsf=FChrer: Andreas G=FCnser, Andreas Lassmann Joint Venture von itCampus und MEC itCampus Gruppe Deutschland * Gro=DFbritannien * Italien * =D6sterreich * Schweiz * Slowake= i http://www.itcampus.eu |
|
From: Thomas R. <tho...@it...> - 2007-11-19 15:26:19
|
Hi. I just downloaded opensipstack and opensbc to try if it is suitable for our= purpose (integration of SIP registrar in our product - which has it's own = database of users and also manages calls as it is a telephony app.) While trying out the software I was wondering why ENABLE_TCP_TRANSPORT is = set to 0 by default. I set it to true and got some compile errors (which we= re trivial to 'Fix'. Is there any reason as to why this is disabled? Also I= couldn't find anywhere where TLS is actually enabled. Did I just miss some= thing, or is there a reason for this? Opensbc did start listening on TCP po= rt 5060 after I changed the define. Apart from that I was wondering if anyone has any experience of integrating= opensipstack into an existing telephony server. Regards, Mit freundlichen Gr=FC=DFen Thomas Raschbacher ____________________________________________ itCampus Technology GmbH =D6sterreich * Deutschland * Italien Wehlistra=DFe 27b 1200 Wien tho...@it... Tel: +43 (1) 33418557-58 Fax: +43 (1) 33418557-958 http://www.itctec.com UID: ATU 6339 0618 Firmenbuchnr: FN292598t, Handelsgericht Wien Gesch=E4ftsf=FChrer: Andreas G=FCnser, Andreas Lassmann Joint Venture von itCampus und MEC itCampus Gruppe Deutschland * Gro=DFbritannien * Italien * =D6sterreich * Schweiz * Slowake= i http://www.itcampus.eu |
|
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. |
|
From: <jo...@op...> - 2007-11-19 01:18:13
|
Can you send a level 5 log for this case? OpenSBC giving 0.0.31.64 as the media address is strange. Jeremy A wrote: > Joegen E. Baclor wrote: > >> OpenSBC will stay away from proxying media if the endpoints in the call >> are both using public addresses. You can tell OpenSBC to always proxy >> media in all cases by setting "Always Proxy Media" in HTTP admin >> "General Parameters" section. >> >> >> > I have that flag ticked. There are two distinct cases. > > 1. The phone makes an outgoing call (actually to voicemail on the remote > SIP server). All RTP traffic goes direct from the remote host to the > local phone bypassing opensbc. it is bidirectional. > > 2. I make an incoming call from the remote SIP server. The call is > handled by opensbc and the local phone rings. When the phone is answered > the SDP handshake managed by opensbc directs both the remote SIP server > and the local phone to send packets to 0.0.31.64 - so no sound on the > phone and no traffic through opensbc. > > It would appear that the note "Enable proxying media on all incoming > call" on the "General Parameters" "Always Proxy Media" is literal - only > incoming calls are proxied. > > It would also appear that there is a bug in the code setting up the RTP > proxy. Possibly this is due to me running on fully routable addresses? > > Jeremy > > > > ------------------------------------------------------------------------- > 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 01:04:46
|
Joegen E. Baclor wrote: > OpenSBC will stay away from proxying media if the endpoints in the call > are both using public addresses. You can tell OpenSBC to always proxy > media in all cases by setting "Always Proxy Media" in HTTP admin > "General Parameters" section. > > I have that flag ticked. There are two distinct cases. 1. The phone makes an outgoing call (actually to voicemail on the remote SIP server). All RTP traffic goes direct from the remote host to the local phone bypassing opensbc. it is bidirectional. 2. I make an incoming call from the remote SIP server. The call is handled by opensbc and the local phone rings. When the phone is answered the SDP handshake managed by opensbc directs both the remote SIP server and the local phone to send packets to 0.0.31.64 - so no sound on the phone and no traffic through opensbc. It would appear that the note "Enable proxying media on all incoming call" on the "General Parameters" "Always Proxy Media" is literal - only incoming calls are proxied. It would also appear that there is a bug in the code setting up the RTP proxy. Possibly this is due to me running on fully routable addresses? Jeremy |
|
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 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: Joegen E. B. <joe...@gm...> - 2007-11-18 23:55:11
|
OpenSBC will stay away from proxying media if the endpoints in the call are both using public addresses. You can tell OpenSBC to always proxy media in all cases by setting "Always Proxy Media" in HTTP admin "General Parameters" section. hth. Joegen Jeremy A wrote: > Hello, > > In doing tests on 1.1.4 opensbc I notice that the media stream is not > being proxied. > > In my test setup I have a remote SIP registrar, and a local Linksys > phone. Normally the phone registers with the remote proxy. I changed the > phone setup to use an opensbc instance by setting the 'Outbound Proxy:' > value on the phone. > > The following fields on the phone are set to 'no' or are blank. > > NAT Mapping Enable: > SIP Proxy-Require: > > Handle VIA received: > Handle VIA rport: > Insert VIA received: > Insert VIA rport: > Substitute VIA Addr: > Send Resp To Src Port: > > The phone and the opensbc instance are on routable addresses > > The phone uses the opensbc in its SIP dialog as expected. My assumption > was that the opensbc instance would automatically proxy the RTP audio as > well as manage the SIP conversation. > > Is this assumption correct? > > Is there any special setting I need to make to the phone or openSBC to > allow audio proxying? > > Thanks > > Jeremy > > > ------------------------------------------------------------------------- > 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: 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-18 19:42:04
|
Hello, In doing tests on 1.1.4 opensbc I notice that the media stream is not being proxied. In my test setup I have a remote SIP registrar, and a local Linksys phone. Normally the phone registers with the remote proxy. I changed the phone setup to use an opensbc instance by setting the 'Outbound Proxy:' value on the phone. The following fields on the phone are set to 'no' or are blank. NAT Mapping Enable: SIP Proxy-Require: Handle VIA received: Handle VIA rport: Insert VIA received: Insert VIA rport: Substitute VIA Addr: Send Resp To Src Port: The phone and the opensbc instance are on routable addresses The phone uses the opensbc in its SIP dialog as expected. My assumption was that the opensbc instance would automatically proxy the RTP audio as well as manage the SIP conversation. Is this assumption correct? Is there any special setting I need to make to the phone or openSBC to allow audio proxying? Thanks Jeremy |
|
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: <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: <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: 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 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 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: 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 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: ehernaez <ope...@op...> - 2007-11-18 05:17:47
|
Andrew, You state that the to-uri and r-uri are usually the same. This is not the case when using Upper Registration - where the UA has OSBC as an outbound proxy (as it was designed). In this case, the r-uri will contain a domain or IP address that is local to OSBC while the to-uri will contain the domain or IP address of the registrar. Unfortunately there is no solutionton to your issue currently, because OSBC does perform routing based on the to-uri. However, work is currently underway to allow for more granular routing rules. |
|
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: <sa...@ER...> - 2007-11-17 12:01:39
|
Not using gcc as such, using g++ on Cento5 with the latest yum update. This time I started on a brand new server. This time i follow your most recent instruction sheet. I installed the source codes but did not compile until after i ran the two CVS instructions. I had to open port 2401 on the firewall for CVS to run properly. i did a ./configure in both opensipstack and then in the opensbc directories. While still in the opensbc directory i did a make bothnoshared. This time it failed compiling the ???_r_s_a. segment. Thinking maybe i read the instuction wrong, maybe the instructions were not clear i went back into the opensipstack dir and ran the make bothnoshared from there. I went back into the opensbc dir and ran the bothnoshared again and this time it compiled. I want to thank you for all your help. Warren Kreckler ----- Original Message ----- From: "jo...@op..." <joe...@gm...> To: <ope...@li...> Sent: Thursday, November 15, 2007 9:19 PM Subject: Re: [OpenSIPStack] CVS compile error > What version of GCC is involved and on which OS? Can you paste the > entire compilation console log? > > > sales@ER wrote: > > Hello > > > > I found a howto in the wiki that explained the steps. > > > > I have install both the download source code and then the CVS into the same /tmp directory before i compiled. > > > > I first ./configue the opensipstack > > > > then i changed into the opensbc directory. > > > > I ran the autoconf in the opensbc directory then ran the ./configure and then make oooptnoshared, which failed to Make > > > > error is in main..o cannot declare varible 'instant' to be of abstract type "OpenSBCDeamon" > > > > Can someone help me? > > > > Warren Kreckler > > > > P.S. i set PWLIBDIR AND OPALDIR = /tmp/opensipstack > > > > ------------------------------------------------------------------------- > > 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: <jo...@op...> - 2007-11-16 08:08:02
|
Hi Gaurav, While I'm finding the time to see what's causing the crash, can you try setting inbound-route="sip:102@192.168.96.123:5060" to inbound-route="sip:102@192.168.96.123" -> (without the port) I am suspecting a string comparison failure. Thanks for the information. Joegen Gaurav Kheterpal wrote: > Hi Joegen, > > We were able to get trunking working for inbound calls with OpenSBC. For the > outbound trunking issue, you mentioned:- > > " I guessing OpenSBC was not able to identify the call as a trunk call > properly. You are correct that the trunk should have handled the > authentication instead of relaying the 407. If you are using the Main trunk > to route your calls to the SIP Trunk, you may try to use "sip-trunk" > parameter in our b2bua route > Example: [sip:1212*] sip:mytrunkprovider.com;sip-trunk=true" > > I subsequently tried that and found that sbc crashes in > SBCSIPTrunkReg::GetEgressAuthInfo function at the start of For loop. > > *Configuration* > > OpenSBC 192.168.96.123 > Xlite 192.168.96.36 > Public LAN IP 59.95.152.178 > voipvoip.com 69.90.209.57 > > *B2BAUA Route* > > [sip:*@192.168.96.123] sip:sip3.voipvoip.com:5060;sip-trunk=true > > *Trunking* > > <root> > <siptrunk trunk-name="SIP" > route-set="sip3.voipvoip.com" > sip-domain="59.95.152.178" > expires="3600"> > > <trunk-accounts> > <account user-name="phonenumber" > auth-user-name="phonenumber" > auth-password="password" > inbound-route="sip:102@192.168.96.123:5060" > expires="3600"/> > </trunk-accounts> > </siptrunk> > </root> > > The pcap file is attached for your reference. > > As always, thanks in advance for your help! > > Regards, > Gaurav > > > > ------------------------------------------------------------------------ > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.503 / Virus Database: 269.15.33/1133 - Release Date: 11/15/2007 8:57 PM > |
|
From: Gaurav K. <gkh...@is...> - 2007-11-16 05:59:12
|
Hi Joegen, We were able to get trunking working for inbound calls with OpenSBC. For the outbound trunking issue, you mentioned:- " I guessing OpenSBC was not able to identify the call as a trunk call properly. You are correct that the trunk should have handled the authentication instead of relaying the 407. If you are using the Main trunk to route your calls to the SIP Trunk, you may try to use "sip-trunk" parameter in our b2bua route Example: [sip:1212*] sip:mytrunkprovider.com;sip-trunk=true" I subsequently tried that and found that sbc crashes in SBCSIPTrunkReg::GetEgressAuthInfo function at the start of For loop. *Configuration* OpenSBC 192.168.96.123 Xlite 192.168.96.36 Public LAN IP 59.95.152.178 voipvoip.com 69.90.209.57 *B2BAUA Route* [sip:*@192.168.96.123] sip:sip3.voipvoip.com:5060;sip-trunk=true *Trunking* <root> <siptrunk trunk-name="SIP" route-set="sip3.voipvoip.com" sip-domain="59.95.152.178" expires="3600"> <trunk-accounts> <account user-name="phonenumber" auth-user-name="phonenumber" auth-password="password" inbound-route="sip:102@192.168.96.123:5060" expires="3600"/> </trunk-accounts> </siptrunk> </root> The pcap file is attached for your reference. As always, thanks in advance for your help! Regards, Gaurav |
18 messages has been excluded from this view by a project administrator.
