sr-users February 2007

sr-users@lists.kamailio.org

158 participants
285 discussions

Re: [Users] In NAT, I didn't see the ACK packet after the Invited the Callee

by Bogdan-Andrei Iancu

Ravi, so you see any Record-Route hdrs in the 200 OK reply? regards, bogdan raviprakash sunkara wrote: > Hi BogDan, > Good AfterNoon, and Thanks For replying to me, > > I used the Following code for Record_route(); > > route { > .... > ..... > if(method=="INVITE" && nat_uac_test("3") ) > { > record_route_preset("sip: > 192.168.2.3:5060 <http://192.168.2.3:5060>;nat=yes"); > }else if ( method ! = " REGISTER ") > { > record_route(); > } > } > where 192.168.2.3:5060 <http://192.168.2.3:5060> is the private IP of > the SIP server behind the NAT. > > > On 2/5/07, * Bogdan-Andrei Iancu* <bogdan(a)voice-system.ro > <mailto:bogdan@voice-system.ro>> wrote: > > Hi Ravi, > > do you do record_route() for the INVITE? if not, the sequential > requests > of the dialog will bypass your server. > > regards, > bogdan > > raviprakash sunkara wrote: > > > Hello Users, > > > > When I tested the OpenSER server with CISCO ATA 186/188 IP phones > > SIP EyeP media (Softphnoes ) is working fine with RTP , when Both > > Users and SIP Server is in Behind the NAT, > > > > But Problem with Softphones ( X-lite ) . > > > > When I ngrep the Calls of X-lite users i didn't see any Ack > Packet to > > OpenSER After the Invite Packets received . > > > > Please Help me in this Part > > > > > > -- > > Thanks and Regards > > Ravi Prakash Sunkara > > ravi.sunkara(a)hyperion-tech.com > <mailto:ravi.sunkara@hyperion-tech.com> > <mailto:ravi.sunkara@hyperion-tech.com > <mailto:ravi.sunkara@hyperion-tech.com>> > > M:+91 9985077535 > > O:+91 40 23114549 > > F:+91 40 40208727 > > ravi.sunkara(a)hyperion-tech.com > <mailto:ravi.sunkara@hyperion-tech.com> <mailto: > ravi.sunkara(a)hyperion-tech.com > <mailto:ravi.sunkara@hyperion-tech.com>> > > www.hyperion-tech.com <http://www.hyperion-tech.com> > <http://www.hyperion-tech.com> > > > >------------------------------------------------------------------------ > > > > >_______________________________________________ > >Users mailing list > >Users(a)openser.org <mailto:Users@openser.org> > > http://openser.org/cgi-bin/mailman/listinfo/users > > > > > > > > > -- > Thanks and Regards > Ravi Prakash Sunkara > ravi.sunkara(a)hyperion-tech.com <mailto:ravi.sunkara@hyperion-tech.com> > M:+91 9985077535 > O:+91 40 23114549 > F:+91 40 40208727 > ravi.sunkara(a)hyperion-tech.com <mailto:ravi.sunkara@hyperion-tech.com> > www.hyperion-tech.com <http://www.hyperion-tech.com>

17 years, 9 months

Re: [Users] 200 ok not cought in ONREPLY

by Bogdan-Andrei Iancu

Dan, that is rather strange if you are confident you are setting correctly a reply route (not default one) for the INVITE transaction. add the following debug message in modules/tm/t_reply.c, after line 1312: DBG("---------onreply route is %u\n",t->on_reply); recompile ans see the output on runtime. regards, bogdan Dan-Cristian Bogos wrote: > Salut Bogdan, > > theoretically I have. Saw now that with default onreply I can catch it > (log). It is really strange since I am relying both BYE and INVITES in > the same t_relay block with t_on_reply("1"); > t_on_failure("1"); but the 200 OK comes to default. > > Cheers, > Dan > > On 2/5/07, Bogdan-Andrei Iancu <bogdan(a)voice-system.ro> wrote: > >> Salut Dan, >> >> are you sure you have an onreply route sent for this transactions? from >> the output I see no problems. >> >> regards, >> bogdan >> >> Dan-Cristian Bogos wrote: >> >> > Hi Guys, >> > >> > By receiving incoming traffic from some other sip server (configured >> > for different domain than mines) I will not be able to catch in the >> > routing, onreply section, the 200 OK for the INVITE , OK which my >> > client, behind my server, is sending to remote side, therefore not >> > beeing able to modify sdp to use mediaproxy. Bellow is a level8 of >> > debug of the OK. >> > Is there any other way of catching this message in the routing? Any >> > help will be appreciated. >> > >> > Thxs in advance, >> > Dan >> > >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: SIP Reply >> > (status): >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: version: >> > <SIP/2.0> >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: status: >> <200> >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: reason: >> <OK> >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: >> > parse_headers: flags=2 >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: Found param >> > type 232, <branch> = <z9hG4bKeaa9.11b641a2.0>; state=16 >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: end of >> > header reached, state=5 >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: >> > parse_headers: Via found, flags=2 >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: >> > parse_headers: this is the first via >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: After >> > parse_msg... >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: >> > forward_reply: found module nathelper, passing reply to it >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: >> > parse_headers: flags=20 >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: Found param >> > type 232, <branch> = <z9hG4bKeaa9.2ffc88b3.0>; state=16 >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: end of >> > header reached, state=5 >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: >> > parse_headers: Via found, flags=20 >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: >> > parse_headers: this is the second via >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: Found param >> > type 234, <received> = <87.139.12.167>; state=6 >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: Found param >> > type 235, <rport> = <5096>; state=6 >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: Found param >> > type 232, <branch> = <z9hG4bK521554023>; state=16 >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: end of >> > header reached, state=5 >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: >> > parse_headers: Via found, flags=20 >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: DEBUG: >> > add_param: tag=8b2d7e45 >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: >> > DEBUG:parse_to:end of header reached, state=29 >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: >> > DBUG:parse_to: display={}, ruri={sip:dan@de.babble.net} >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: DEBUG: >> > get_hdr_field: <To> [38]; uri=[sip:dan@de.babble.net] >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: DEBUG: to >> > body [<sip:dan@de.babble.net>] >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: >> > get_hdr_field: cseq <CSeq>: <20> <INVITE> >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: >> > forward_reply: found module tm, passing reply to it >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: DEBUG: >> > t_check: msg id=1 global id=0 T start=0xffffffff >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: >> > parse_headers: flags=22 >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: >> > parse_headers: flags=8 >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: DEBUG: >> > t_reply_matching: hash 39598 label 705981201 branch 0 >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: >> > DEBUG:tm:REF_UNSAFE: after is 1 >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: DEBUG: >> > t_reply_matching: reply matched (T=0x4081f430)! >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: DEBUG: >> > t_check: msg id=1 global id=1 T end=0x4081f430 >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: >> > DEBUG:tm:reply_received: org. status uas=180, uac[0]=180 local=0 >> > is_invite=1) >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: >> > DEBUG:tm:t_should_relay_response: T_code=180, new_code=200 >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: >> > DEBUG:tm:relay_reply: branch=0, save=0, relay=0 >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: old size: >> > 911, new size: 850 >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: >> > build_res_from_sip_res: copied size: orig:77, new: 16, rest: 834 msg= >> > SIP/2.0 200 OK^M Via: SIP/2.0/UDP >> > 87.102.50.17;branch=z9hG4bKeaa9.2ffc88b3.0^M Via: SIP/2.0/UDP >> > >> 10.10.10.132:5096;received=87.139.12.167;rport=5096;branch=z9hG4bK521554023^M >> >> > >> > Record-Route: <sip:87.102.50.13;lr=on;ftag=2240571840>^M Record-Route: >> > <sip:87.102.50.17;lr;ftag=2240571840>^M Contact: >> > <sip:dan@87.139.12.167:7472;rinstance=37d0f83d79f3ede2>^M To: >> > <sip:dan@de.babble.net>;tag=8b2d7e45^M From: >> > <sip:dan@babble.net>;tag=2240571840^M Call-ID: >> > 1174762859(a)10.10.10.132^M CSeq: 20 INVITE^M Allow: INVITE, ACK, >> > CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO^M >> > Content-Type: application/sdp^M User-Agent: X-Lite release 1006e stamp >> > 34025^M Content-Length: 185^M ^M v=0^M o=- 5 2 IN IP4 87.139.12.167^M >> > s=CounterPath X-Lite 3.0^M c=IN IP4 87.139.12.167^M t=0 0^M m=audio >> > 34556 RTP/AVP 0 101^M a=fmtp:101 0-15^M a=rtpmap:101 >> > telephone-event/8000^M a=sendrecv^M >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: DEBUG: >> > add_to_tail_of_timer[2]: 0x4081f478 >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: >> > DEBUG:tm:relay_reply: sent buf=0x814a048: SIP/2.0 2..., >> > shmem=0x40821528: SIP/2.0 2 >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: DEBUG: >> > cleanup_uac_timers: RETR/FR timers reset >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: >> > DEBUG:tm:UNREF_UNSAFE: after is 0 >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: >> > DEBUG:destroy_avp_list: destroying list (nil) >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: receive_msg: >> > cleaning up >> > >> > _______________________________________________ >> > Users mailing list >> > Users(a)openser.org >> > http://openser.org/cgi-bin/mailman/listinfo/users >> > >> >> >

17 years, 9 months

[Users] Hijack 'Move Temporarily'

by Sam Lee

Hey Guys, Normally if the SIP-UA is call-forwarded to a different number , it will send a 'Move Temporarily' to the proxy , which in turn relay this message to the originating gateway. The problem is , if they call forward to a number which the originating gateway doesn't know what to do with it , it will just kill the call. Can i hijack 'Move Temporarily' directly in the proxy and sending this call to a different gateway rather than relaying it to the originating gateway ? Please let me know if you can't understand me. Thanks! Regards, Sam

17 years, 9 months

[Users] database persistent connection

by tele

Hi, I've an annoying problem with database persistent connection. I'm using mysql database for location and avp stuff. During the day all it's but after a day i retest some call and seams that the proxy lost connection with the database, and avp and location stuff didn't works anymore. I'm using this version of openser: # openser -V version: openser 1.2.0-dev8-notls (i386/freebsd) flags: STATS: Off, USE_IPV6, USE_TCP, DISABLE_NAGLE, USE_MCAST, SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 poll method support: poll, select, kqueue. @(#) $Id: main.c,v 1.23 2006/10/02 15:51:45 bogdan_iancu Exp $ main.c compiled on 12:38:52 Nov 27 2006 with gcc 3.4.4 i've also configure a small ping_interval for the mysql module modparam("mysql", "ping_interval", 60) modparam("mysql", "auto_reconnect", 1) and the usrloc: modparam("usrloc", "db_mode", 3) modparam("usrloc", "matching_mode", 1) I've also check that the NTP is correct on the servers. I don't know why openser lost connection with the database. any hints? thanks :tele

17 years, 9 months

[Users] Help. in OpenSER in Post-paid and pre-paid

by raviprakash sunkara

Hello Users, I'm Using The Following software of My Sip productions, 1) OpenSER is a Sip Server,proxy, in front-end 2) Asterisk is PBX server, in Back-end 3) Radius for AAA to OpenSER, 4) Asterisk-java for IVR for Billing Customer care if I did any mistakes in these mail , forgive me . My Question is 1) If Caller calls to Callee , Before the call established to callee. The Caller has to know his Balance Account. if the Balance is there, then only the call has to establish, 2) I want the OpenSER total in RealTime application Server like Java application . Call Authorization ( Question no 1 ). If Asterisk is Front-end , ---> problem is Solved, How can a b2bua implement with OpenSER, please when -- Thanks and Regards Ravi Prakash Sunkara ravi.sunkara(a)hyperion-tech.com M:+91 9985077535 O:+91 40 23114549 F:+91 40 40208727 ravi.sunkara(a)hyperion-tech.com www.hyperion-tech.com

17 years, 9 months

[Users] strip_tail() string length?

by Brandon Armstead

Hello everyone, I'm wondering what the easiest method would be to grab how long the RURI is and strip based on that information... or would I have to actually use regex, or is there an easier STRLEN() or LENGTH() operation? Any ideas, or is this something that could be implemented? Thanks. i.e. strip_tail(strlen($ru) - 2); ... or something like such. -- Brandon Armstead

17 years, 9 months

[Serusers] Cisco AS 5300 can't send BYE for SER... It's bug?

by Sho Aihara

Hi all. I have a problem for the following scenario. When I make a call for PSTN and on hook by PSTN side, Cisco As can't send BYE for SER. 01. [UA via Asterisk] dialing "08022223333" -> [SER] 02. [SER] prefix("0333") and rewritehostport("my.cisco.ip.address:5060") -> [Cisco] 03. [Cisco] dial-peer voice 6000 pots, translate-outgoing called from "033308022223333" to "008022223333" 04. [Cisco] process an outbound call to "008022223333" -> [e.g. Mobile] 05. [e.g. Mobile] Catch call 06. [SER] log CDR start 07. [Cisco] talking 08. [e.g. Mobile] On hook and call disconnect 09. [Cisco] can't send BYE for SER *****why??***** 10. [UA via Asterisk] On hook 11. [UA via Asterisk] Send BYE for SER 12. [SER] log CDR End [Cisco] Call finished But another scenario, if make a call from PSTN to Asterisk and on hook by PSTN side, Cisco As send BYE to SER. 01. [e.g. Mobile] dialing "0377771111(Asterisk user number)" 02. [Cisco] receive "77771111" call number 03. [Cisco] dial-peer voice 5000 voip, session target ipv4: my.ser.ip.address -> [SER] 04. [SER] process an incoming call to "0377771111" -> [UA via Asterisk] 05. [UA via Asterisk] Catch call 06. [SER] log CDR start 07. [UA via Asterisk] talking 08. [e.g. Mobile] On hook and call disconnect 09. [Cisco] Send BYE to SER 10. [SER] log CDR End [Cisco] Call finished 11. [UA via Asterisk] receive BYE from SER And sorry for my diffucult example. Why Cisco AS 5300 can't send BYE to SER When PSTN call is disconnected by PSTN side? My ser.cfg as follows: # -------------------------------------------------------------------------- # global configuration parameters # -------------------------------------------------------------------------- fork=no log_stderror=yes check_via=no dns=no rev_dns=no listen=my.ser.ip.address port=5060 fifo="/tmp/ser_fifo" fifo_db_url="mysql://ser:heslo@localhost/ser" # -------------------------------------------------------------------------- # module loading # -------------------------------------------------------------------------- loadmodule "/usr/local/lib/ser/modules/mysql.so" loadmodule "/usr/local/lib/ser/modules/sl.so" loadmodule "/usr/local/lib/ser/modules/tm.so" loadmodule "/usr/local/lib/ser/modules/rr.so" loadmodule "/usr/local/lib/ser/modules/maxfwd.so" loadmodule "/usr/local/lib/ser/modules/usrloc.so" loadmodule "/usr/local/lib/ser/modules/registrar.so" loadmodule "/usr/local/lib/ser/modules/textops.so" loadmodule "/usr/local/lib/ser/modules/auth.so" loadmodule "/usr/local/lib/ser/modules/auth_db.so" loadmodule "/usr/local/lib/ser/modules/avpops.so" loadmodule "/usr/local/lib/ser/modules/permissions.so" loadmodule "/usr/local/lib/ser/modules/acc.so" loadmodule "/usr/local/lib/ser/modules/exec.so" # -------------------------------------------------------------------------- # setting module-specific parameters # -------------------------------------------------------------------------- modparam("usrloc", "db_mode", 2) modparam("auth_db", "calculate_ha1", yes) modparam("auth_db", "password_column", "password") modparam("rr", "enable_full_lr", 1) modparam("usrloc", "db_url", "mysql://ser:heslo@localhost/ser") modparam("auth_db", "db_url", "mysql://ser:heslo@localhost/ser") modparam("permissions", "db_url", "mysql://ser:heslo@localhost/ser") modparam("tm", "fr_inv_timer", 27) modparam("tm", "fr_inv_timer_avp", "inv_timeout") modparam("permissions", "db_mode", 1) modparam("permissions", "trusted_table", "trusted") modparam("acc", "db_url", "mysql://ser:heslo@localhost/ser") modparam("acc", "db_flag", 2) modparam("acc", "db_missed_flag", 3) # -------------------------------------------------------------------------- # route pattern # -------------------------------------------------------------------------- route { if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); break; }; if ( msg:len > max_len ) { sl_send_reply("513", "Message too big"); break; }; record_route(); if (loose_route()) { if (method=="ACK") { acc_db_request("01:CallStart\n", "acc"); }; if (method=="BYE" || method=="CANCEL") { acc_db_request("02:CallEnd\n", "acc"); }; t_relay(); break; }; if (uri==myself) { if (method=="REGISTER") { if (!www_authorize("", "subscriber")) { www_challenge("", "0"); break; }; save("location"); break; }; if (search("^(f|From): .*(a)(my\.cisco\.ip\.address)")) { #PSTN Incoming call from Cisco AS 5300 e.g. 0377771111 rewritehost("my.asterisk.ip.address"); }; lookup("aliases"); if (!lookup("location")) { if (method=="INVITE" && !search("^(f|From): .*(a)(my\.cisco\.ip\.address)")) { if (!proxy_authorize("", "subscriber")) { proxy_challenge("", "0"); break; }; if (uri=~"^sip:0[0-9]{10}@") { # PSTN Outgoing call to Cisco AS 5300 e.g. 08022223333 prefix("0333"); rewritehostport("my.cisco.ip.address:5060"); avp_write("i:45", "inv_timeout"); } else { sl_send_reply("404", "Not Found"); break; }; consume_credentials(); }; }; }; if (!t_relay()) { sl_reply_error(); }; } And my Cisco AS 5300 config as follows: voice call send-alert voice rtp send-recv voice service pots fax protocol t38 ls-redundancy 0 hs-redundancy 0 fallback cisco voice service voip fax protocol t38 ls-redundancy 0 hs-redundancy 0 fallback cisco sip min-se 60 translation-rule 50 Rule 0 0333 0 Rule 1 ^7777 037777 voice class codec 2 codec preference 1 g711ulaw codec preference 2 g711alaw dial-peer voice 5000 voip tone ringback alert-no-PI description ser-asterisk-cisco-test huntstop destination-pattern 77771111$ translate-outgoing called 50 voice-class codec 2 session protocol sipv2 session target ipv4:my.ser.ip.address dtmf-relay rtp-nte max-conn 1 dial-peer voice 6000 pots application session max-conn 2 destination-pattern 0333T progress_ind alert enable 8 translate-outgoing called 50 port 0:D Thanks, Sahria

17 years, 9 months

Re: [Users] 200 ok not cought in ONREPLY

by Daniel-Constantin Mierla

Hello, On 02/05/07 12:30, Dan-Cristian Bogos wrote: > Dear Daniel, > > many thanks for the reply. I can perfectly catch the OK now. ok > > The only thing which I must find out is why for a normal INVITE the OK > was not coming in the same onreply block as the BYE, since both INVITE > and BYE are relied in the same way out and processed theoretically in > the same route block. BYE is usually following the loose routing -- but I do not know if it is the case of your comfig. Cheers, Daniel > > Anyway, thank you again, it was really great help. > > Cheers, > Dan > > > On 2/5/07, Daniel-Constantin Mierla <daniel(a)voice-system.ro> wrote: >> Hello, >> >> to get a reply in an onreply_route other than the default on, you have >> to arm it via t_on_reply() when you relay the request. >> ... >> t_on_reply("1"); >> ... >> >> t_on_reply[1] { >> } >> >> Otherwise, all replies are processed in the default onreply_route (the >> one which has no index) >> >> onreply_route { >> .... >> } >> >> Cheers, >> Daniel >> >> On 02/01/07 15:48, Dan-Cristian Bogos wrote: >> > Hi Guys, >> > >> > By receiving incoming traffic from some other sip server (configured >> > for different domain than mines) I will not be able to catch in the >> > routing, onreply section, the 200 OK for the INVITE , OK which my >> > client, behind my server, is sending to remote side, therefore not >> > beeing able to modify sdp to use mediaproxy. Bellow is a level8 of >> > debug of the OK. >> > Is there any other way of catching this message in the routing? Any >> > help will be appreciated. >> > >> > Thxs in advance, >> > Dan >> > >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: SIP Reply >> > (status): >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: version: >> > <SIP/2.0> >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: status: >> <200> >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: reason: >> <OK> >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: >> > parse_headers: flags=2 >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: Found param >> > type 232, <branch> = <z9hG4bKeaa9.11b641a2.0>; state=16 >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: end of >> > header reached, state=5 >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: >> > parse_headers: Via found, flags=2 >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: >> > parse_headers: this is the first via >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: After >> > parse_msg... >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: >> > forward_reply: found module nathelper, passing reply to it >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: >> > parse_headers: flags=20 >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: Found param >> > type 232, <branch> = <z9hG4bKeaa9.2ffc88b3.0>; state=16 >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: end of >> > header reached, state=5 >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: >> > parse_headers: Via found, flags=20 >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: >> > parse_headers: this is the second via >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: Found param >> > type 234, <received> = <87.139.12.167>; state=6 >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: Found param >> > type 235, <rport> = <5096>; state=6 >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: Found param >> > type 232, <branch> = <z9hG4bK521554023>; state=16 >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: end of >> > header reached, state=5 >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: >> > parse_headers: Via found, flags=20 >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: DEBUG: >> > add_param: tag=8b2d7e45 >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: >> > DEBUG:parse_to:end of header reached, state=29 >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: >> > DBUG:parse_to: display={}, ruri={sip:dan@de.babble.net} >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: DEBUG: >> > get_hdr_field: <To> [38]; uri=[sip:dan@de.babble.net] >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: DEBUG: to >> > body [<sip:dan@de.babble.net>] >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: >> > get_hdr_field: cseq <CSeq>: <20> <INVITE> >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: >> > forward_reply: found module tm, passing reply to it >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: DEBUG: >> > t_check: msg id=1 global id=0 T start=0xffffffff >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: >> > parse_headers: flags=22 >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: >> > parse_headers: flags=8 >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: DEBUG: >> > t_reply_matching: hash 39598 label 705981201 branch 0 >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: >> > DEBUG:tm:REF_UNSAFE: after is 1 >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: DEBUG: >> > t_reply_matching: reply matched (T=0x4081f430)! >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: DEBUG: >> > t_check: msg id=1 global id=1 T end=0x4081f430 >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: >> > DEBUG:tm:reply_received: org. status uas=180, uac[0]=180 local=0 >> > is_invite=1) >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: >> > DEBUG:tm:t_should_relay_response: T_code=180, new_code=200 >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: >> > DEBUG:tm:relay_reply: branch=0, save=0, relay=0 >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: old size: >> > 911, new size: 850 >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: >> > build_res_from_sip_res: copied size: orig:77, new: 16, rest: 834 msg= >> > SIP/2.0 200 OK^M Via: SIP/2.0/UDP >> > 87.102.50.17;branch=z9hG4bKeaa9.2ffc88b3.0^M Via: SIP/2.0/UDP >> > >> 10.10.10.132:5096;received=87.139.12.167;rport=5096;branch=z9hG4bK521554023^M >> >> > >> > Record-Route: <sip:87.102.50.13;lr=on;ftag=2240571840>^M Record-Route: >> > <sip:87.102.50.17;lr;ftag=2240571840>^M Contact: >> > <sip:dan@87.139.12.167:7472;rinstance=37d0f83d79f3ede2>^M To: >> > <sip:dan@de.babble.net>;tag=8b2d7e45^M From: >> > <sip:dan@babble.net>;tag=2240571840^M Call-ID: >> > 1174762859(a)10.10.10.132^M CSeq: 20 INVITE^M Allow: INVITE, ACK, >> > CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO^M >> > Content-Type: application/sdp^M User-Agent: X-Lite release 1006e stamp >> > 34025^M Content-Length: 185^M ^M v=0^M o=- 5 2 IN IP4 87.139.12.167^M >> > s=CounterPath X-Lite 3.0^M c=IN IP4 87.139.12.167^M t=0 0^M m=audio >> > 34556 RTP/AVP 0 101^M a=fmtp:101 0-15^M a=rtpmap:101 >> > telephone-event/8000^M a=sendrecv^M >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: DEBUG: >> > add_to_tail_of_timer[2]: 0x4081f478 >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: >> > DEBUG:tm:relay_reply: sent buf=0x814a048: SIP/2.0 2..., >> > shmem=0x40821528: SIP/2.0 2 >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: DEBUG: >> > cleanup_uac_timers: RETR/FR timers reset >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: >> > DEBUG:tm:UNREF_UNSAFE: after is 0 >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: >> > DEBUG:destroy_avp_list: destroying list (nil) >> > Feb 1 13:33:48 localhost /usr/local/sbin/openser[17816]: receive_msg: >> > cleaning up >> > >> > _______________________________________________ >> > Users mailing list >> > Users(a)openser.org >> > http://openser.org/cgi-bin/mailman/listinfo/users >> > >> >

17 years, 9 months

[Users] OpenSER 1.2.0 + Presence

by Bernard Chan

Hello, I'm currently experimenting with OpenSER 1.2.0 with Presence module. Earlier I tried OpenSER 1.0/1.1 with PA. I'm using a third-party softphone which for some reasons, I would not like to disclose the name of it. After switching to 1.2.0+Presence, the softphone segfaults on startup. After tracing the source code of the phone and OpenSER and performing hundreds of packet sniffing over the past several days, I have grown to suspect that a certain behaviour with the new presence module may be the cause, but I would like to verify whether that is the case. For some reasons it is infeasible for me to modify the source code of the softphone used (actually I may be able to but that is what I would like to avoid). But it seems to choke on receiving a NOTIFY before the OK for the corresponding SUBSCRIBE is received by the softphone. So, any chance that I can test it by just modifying the config of OpenSER alone without changing the sources, both of OpenSER and the softphone? Thanks in advance for any invaluable insights. Regards, Bernard Chan.

17 years, 9 months

[Users] In NAT, I didn't see the ACK packet after the Invited the Callee

by raviprakash sunkara

Hello Users, When I tested the OpenSER server with CISCO ATA 186/188 IP phones SIP EyeP media (Softphnoes ) is working fine with RTP , when Both Users and SIP Server is in Behind the NAT, But Problem with Softphones ( X-lite ) . When I ngrep the Calls of X-lite users i didn't see any Ack Packet to OpenSER After the Invite Packets received . Please Help me in this Part -- Thanks and Regards Ravi Prakash Sunkara ravi.sunkara(a)hyperion-tech.com M:+91 9985077535 O:+91 40 23114549 F:+91 40 40208727 ravi.sunkara(a)hyperion-tech.com www.hyperion-tech.com

17 years, 9 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users February 2007