From: Kurtis H. <khe...@cs...> - 2012-01-13 01:14:01
|
Wait, so the behavior changes without you modifying SIP.myIP and SIP.myIP2? On Thu, Jan 12, 2012 at 4:58 PM, Arghyadip Paul <arg...@gm...> wrote: > Kurits, > > Verified the SIP.myIP and SIP.myIP2 and they are fine.. > > SIP.myIP=127.0.0.1 > SIP.myIP2=192.168.2.130 (The Ip of the machine where Asterisk, SipAuthServe > and SMS is running) > > I can see some new behavior now: > > I can UE1 message is getting queue. Smqueue is able to discover the ip > address of the receiver but then getting a time out as per the log in > /var/log/OpenBTS.log > > Jan 12 16:51:52 arz smqueue: INFO 140176208975648 > HLR.cpp:318:getRegistrationIP: getRegistrationIP(IMSI404864415448667) > Jan 12 16:51:52 arz smqueue: INFO 140176208975648 HLR.cpp:202:sqlLocal: > select ipaddr from sip_buddies where name = "IMSI404864415448667" > Jan 12 16:51:52 arz smqueue: INFO 140176208975648 HLR.cpp:242:sqlQuery: > result = 192.168.2.148 > Jan 12 16:51:52 arz smqueue: DEBUG 140176208975648 smqueue.cpp:845:set_qtag: > Param tag=bgaaympfvuzorfqh > Jan 12 16:51:52 arz smqueue: DEBUG 140176208975648 > smnet.cpp:104:deliver_msg_datagram: #012--Deliver message: > Jan 12 16:51:52 arz smqueue: DEBUG 140176208975648 > smnet.cpp:105:deliver_msg_datagram: MESSAGE > sip:IMSI404864415448667@127.0.0.1:5062 SIP/2.0#015#012Via: SIP/2.0/UDP > 127.0.0.1:5063;branch=123#015#012Via: SIP/2.0/UDP > 192.168.2.148:5062;branch=z9hG4bKobts287f9f09ab151b2d4c#015#012From: > IMSI404864430002302 <sip:2103@192.168.2.130>;tag=bgaaympfvuzorfqh#015#012To: > 9733013520 <sip:9733013520@192.168.2.130>#015#012Call-ID: > aeZ3e@127.0.0.1#015#012CSeq: 220 MESSAGE#015#012Content-Type: > application/vnd.3gpp.sms#015#012Max-forwards: 5#015#012Content-Length: > 58#015#012#015#01201a303a1000000150004a1123000002110216115222b065076393c2f03 > Jan 12 16:51:52 arz smqueue: INFO 140176208975648 > smqueue.cpp:1909:main_loop: === Jan 12 16:51:52 1 queued; 5 seconds til > Request Destination SIP URL for 220--bgaaympfvuzorfqh > Jan 12 16:51:57 arz smqueue: DEBUG 140176208975648 > smqueue.cpp:1924:main_loop: Timeout... > > > This log is coming repeatedly... > > > Also, I am not able to see any MESSAGE packet in wireshark when Smqueue > forwards the packet to receiver... > > > Please let me know if you can get a catch... > > > > > On Wed, Jan 11, 2012 at 5:19 PM, Kurtis Heimerl <khe...@cs...> > wrote: >> >> The "host not valid" error message is triggered by the following code: >> >> if (!host) { LOG(ERR) << "no host!"; return NO_STATE; } >> if (0 != strcmp("127.0.0.1", host) >> && 0 != strcmp("localhost", host) >> && 0 != strcmp(my_ipaddress.c_str(), host) >> && 0 != strcmp(my_2nd_ipaddress.c_str(), host)) { >> LOG(ERR) << "host not valid"; >> return NO_STATE; >> } >> >> Any chance the SIP.myIP or SIP.myIP2 fields in your smqueue.db file >> are incorrect? >> >> On Wed, Jan 11, 2012 at 4:49 PM, Arghyadip Paul <arg...@gm...> >> wrote: >> > After testing a number of features in a simple SIngle >> > OpenBTS/Asterisk/Smqueue/SipAuthServe setting, I am trying hands-on with >> > multiple BTS station scenario. >> > >> > The test set up is as follows: >> > >> > 1. OpenBTS is installed and configured in machine 1 with ip address >> > 192.168.2.148/ >> > 2. Real Time Asterisk, Smqueue and SipAuthserve is running in machine 2 >> > with >> > ip address 192.168.2.130. >> > >> > Test Cases tried: >> > >> > 1. Register two different UEs in the OpenBTS running in machine 1. [OK] >> > 2. Set up call session. [OK] >> > 3. Sending SMS from one UE to another.[FAILED] >> > >> > >> > In test case 3, I have observed that Message is getting queued in >> > Smqueue >> > and Smqueue is esquiring Asterisk to get the forward address of the >> > receiver >> > but Asterisk is printing some failure messages as follows: >> > >> > Asterisk Logs: >> > ----------------------- >> > [Jan 11 16:35:35] ERROR[5012]: cdr_csv.c:306 csv_log: Unable to re-open >> > master file /var/log/asterisk//cdr-csv//Master.csv : Permission denied >> > == Spawn extension (phones, 9733013520, 5) exited non-zero on >> > 'SIP/IMSI404864430002302-00000002' >> > >> > >> > OpenBTS.log Says: >> > ------------------------------ >> > Jan 11 16:35:56 arz smqueue: NOTICE 140052744574752 >> > smqueue.cpp:1964:main_loop: Got SMS '118--qppefgvlzedfnxth' from >> > IMSI404864415448667 for smsc. >> > Jan 11 16:35:56 arz smqueue: INFO 140052744574752 >> > smqueue.cpp:1855:respond_sip_ack: Responding with "202 Queued". >> > Jan 11 16:35:56 arz smqueue: INFO 140052744574752 >> > smqueue.cpp:1326:handle_short_code: Short-code SMS smsc with text "Sms >> > sending" >> > Jan 11 16:35:56 arz smqueue: INFO 140052744574752 >> > smsc.cpp:216:submitSMS: >> > from IMSI404864415448667 message: 1 RD=0 VPF=2 RP=0 UDHI=0 SRR=0 MR=26 >> > DA=(type=unknown plan=E.164/ISDN digits=2103) PI=0 DCS=0 >> > VP=(expiration=(Wed >> > Mar 27 17:35:56 2013)) UD="DCS=0 UDHI=0 UDLength=11 >> > UD=(cb6f382cf4dd9396ef98)" >> > Jan 11 16:35:56 arz smqueue: INFO 140052744574752 >> > smsc.cpp:106:sendSIP_init: >> > from IMSI404864415448667 to 2103 >> > Jan 11 16:35:56 arz smqueue: ERR 140052744574752 >> > smqueue.cpp:1552:lookup_uri_imsi: host not valid >> > Jan 11 16:35:56 arz smqueue: NOTICE 140052744574752 >> > smqueue.cpp:301:process_timeout: == This message had an error and is >> > being >> > deleted:#012MSG = MESSAGE sip:2103@192.168.2.130 SIP/2.0#015#012Via: >> > SIP/2.0/UDP 127.0.0.1:5063;branch=123#015#012Via: SIP/2.0/UDP >> > 192.168.2.148:5062;branch=z9hG4bKobts282cd0d0037977477c#015#012From: >> > IMSI404864415448667 <sip:211@127.0.0.1>;tag=qppefgvlzedfnxth#015#012To: >> > 2103 >> > <sip:2103@192.168.2.130>#015#012Call-ID: >> > 821936150@192.168.2.148#015#012CSeq: 118 MESSAGE#015#012Content-Type: >> > application/vnd.3gpp.sms#015#012Max-forwards: 5#015#012Content-Length: >> > 45#015#012#015#012IMSI404864415448667@192.168.2.130 Sms sending >> > Jan 11 16:35:56 arz smqueue: INFO 140052744574752 >> > smqueue.cpp:1905:main_loop: === Jan 11 16:35:56 0 queued; waiting. >> > >> > >> > I have configured the Smqueue.db as per the instructions given in >> > https://wush.net/trac/rangepublic/wiki/multiBTS and verified that they >> > are >> > fine. From the logs it seems that it is more of a access permission >> > problem. >> > >> > Any guess?? >> > >> > -- >> > Arghyadip Paul >> > Graduate Student >> > Department of Computer Science >> > University of California Santa Barbara >> > Santa Barbara , CA 93106 USA >> > >> > >> > >> > ------------------------------------------------------------------------------ >> > RSA(R) Conference 2012 >> > Mar 27 - Feb 2 >> > Save $400 by Jan. 27 >> > Register now! >> > http://p.sf.net/sfu/rsa-sfdev2dev2 >> > _______________________________________________ >> > Openbts-discuss mailing list >> > Ope...@li... >> > https://lists.sourceforge.net/lists/listinfo/openbts-discuss >> > > > > > > -- > Arghyadip Paul > Graduate Student > Department of Computer Science > University of California Santa Barbara > Santa Barbara , CA 93106 USA > |