sr-users September 2004

sr-users@lists.kamailio.org

190 participants
382 discussions

by jacky

I want do this: uaA (invite 9200001@B) ---->proxy A (invite 200001@B )--->proxyB so in proxyA's ser.cfg: --------------------------- if (uri=~"^sip:9[0-9]*@B") { strip(1); t_relay_to_udp( "B", "5060"); break; }; ---------------------------- but proxyB received "sip:9200001" not "sip:200001". please help me how can I do! thanks.

19 years, 9 months

[Serusers] SER with Radius Accounting -- no radius accounting

by jawad bokhari

Hi All, I could now configure SER 0.8.14 with FreeRadius and authentication process goes smoothly for REGISTRATION. But when i call from one sip UA to other, I don't see any radius accounting generated. My Configuration file is as follows: # # $Id: ser.cfg,v 1.21.4.1 2003/11/10 15:35:15 andrei Exp $ # # simple quick-start config script # # ----------- global configuration parameters ------------------------ #debug=9 # debug level (cmd line: -dddddddddd) #fork=no #log_stderror=yes # (cmd line: -E) /* Uncomment these lines to enter debugging mode debug=7 fork=no log_stderror=yes */ check_via=no # (cmd. line: -v) dns=no # (cmd. line: -r) rev_dns=no # (cmd. line: -R) #port=5060 #children=4 fifo="/tmp/ser_fifo" # ------------------ module loading ---------------------------------- # Uncomment this if you want to use SQL database #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/acc.so" # Uncomment this if you want digest authentication # mysql.so must be loaded ! loadmodule "/usr/local/lib/ser/modules/auth.so" loadmodule "/usr/local/lib/ser/modules/auth_radius.so" loadmodule "/usr/local/lib/ser/modules/uri_radius.so" loadmodule "/usr/local/lib/ser/modules/group_radius.so" # ----------------- setting module-specific parameters --------------- # -- usrloc params -- modparam("usrloc", "db_mode", 0) # Uncomment this if you want to use SQL database # for persistent storage and comment the previous line #modparam("usrloc", "db_mode", 2) # -- auth params -- # Uncomment if you are using auth module # #modparam("auth_db", "calculate_ha1", yes) # # If you set "calculate_ha1" parameter to yes (which true in this config), # uncomment also the following parameter) # #modparam("auth_db", "password_column", "password") # -- rr params -- # add value to ;lr param to make some broken UAs happy modparam("rr", "enable_full_lr", 1) # ------------------------- RADIS AUTHENTICTON ACCOUNTING RELATED -------------------- modparam("auth_radius", "radius_config", "/etc/radiusclient/radiusclient.conf") modparam("acc", "radius_config", "/etc/radiusclient/radiusclient.conf") modparam("acc", "radius_flag", 1) modparam("acc", "radius_missed_flag", 2) modparam("uri_radius", "radius_config", "/etc/radiusclient/radiusclient.conf") modparam("uri_radius", "service_type", 11) modparam("group_radius", "radius_config", "/etc/radiusclient/radiusclient.conf") # ------------------------- request routing logic ------------------- # main routing logic route{ # initial sanity checks -- messages with # max_forwards==0, or excessively long requests 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; }; # we record-route all messages -- to make sure that # subsequent messages will go through our proxy; that's # particularly good if upstream and downstream entities # use different transport protocol record_route(); # loose-route processing if (loose_route()) { t_relay(); break; }; # if the request is for other domain use UsrLoc # (in case, it does not work, use the following command # with proper names and addresses in it) if (uri==myself) { if (method=="REGISTER") { # Uncomment this if you want to use digest authentication if (!radius_www_authorize("test1")) { www_challenge("test1", "0"); break; }; save("location"); break; }; # native SIP destinations are handled using our USRLOC DB if (!lookup("location")) { sl_send_reply("404", "Not Found"); break; }; }; # forward to current uri now; use stateful forwarding; that # works reliably even if we forward from TCP to UDP if (!t_relay()) { sl_reply_error(); }; } _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com

19 years, 9 months

[Serusers] SER for call authorization through RADIUS

by jawad bokhari

Hi, Is there any possibility that SER requests radius server to check if a user should be allowed to call a specific user. I mean as SER requsts radius upon REGISTRATION, can it send similar radius request upon INVITE? I configured SER with the simplest configuration as explained in Radius How-To. Probably I need to do something in extra to support this functionality. Thanks for your help. jawad __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail

19 years, 9 months

[Serusers] RE: question on adding a new contact using serweb

by GILBERT PAIK

Hello, I installed serweb and I am having a hard time in having 'add new contact' to work for adding more destination numbers to direct a call to. When I use 'ngrep' to see, I get this: SIP/2.0 500 FQDN in SDP Media cannot be resolved Please, help me know what I am doing wrong in adding new contacts. Thanks in advance. Regards, Gilbert

19 years, 9 months

[Serusers] Radius authentication

by AJ Grinnell

Could someone post or send me the relevent parts of a working config to use radius authentication? Thank you in advance

19 years, 9 months

RE: [Serusers] Please help : how to disable losse routing ???

by Nicolas RUIZ

Thanks a lot for your help! I want really to use strict-routing because I have a UA in rfc3261, and when he make a call, he put the tag "LR" in the route fields of the ACK, and then the call is cut after 20s. Probably because my gateway Cisco (to PSTN) is only according to use RFC 2543. Thats why I want the UA capably to work with IPTEL in strict routing. I have the same problem with an ATA Cisco, but I have put an old firmware, and that's work very good. (CODE 3.1.1 (LR) >> CODE 3.1.0 (NO LR)). I have take the module rr_mod.c and after, how can I compile the module rr??? Best Regards, Nicolas RUIZ. -----Message d'origine----- De : Franz Edler [mailto:franz.edler@utanet.at] Envoyé : jeudi 9 septembre 2004 06:09 À : 'Martin Koenig [toplink-plannet GmbH]'; 'RUIZ Nicolas' Cc : serusers(a)lists.iptel.org Objet : RE: [Serusers] Please help : how to disable losse routing ??? From: Martin Koenig [toplink-plannet GmbH] Sent: Wednesday, September 08, > this is not an SER problem. Loose routing is basically done in the end > devices. All you can control on the server is whether the server should be > in the signalling proxy chain (record_route()) and whether you want to > process route-header-fields (loose_route()) or forward to the final > destinanation directly (t_relay() without loose_route()). Sorry, this is not correct. The routing mechanism (loose or strict) has to be followed by SIP proxies. Look at RFC 3261 para 16.6 step 6 where the strict routing behavior is defined: "If the copy contains a Route header field, the proxy MUST inspect the URI in its first value. If that URI does not contain an lr parameter, the proxy MUST ..." But I expect that this behaviour is implemented in SER. In previous versions of SER there was the possibility to force SER to do only strict routing. This has been disabled now and in my previous comment I looked into the documentation which is not updated accordingly and still mentions the function strict_route(). But looking into the code of rr_mod.c you can read as a comment: "I do not want people to use strict routing so it is disabled by default, you should always use loose routing, if you really need strict routing then you can replace the last zeroes with REQUEST_ROUTE to enable strict_route and record_route_strict. Don't do that unless you know what you are really doing!" > As loose routing is the standard routing procedure as defined in RFC3261, > strict routing is obsolete. To be precise: strict routing is deprecated. If you have a strict router in a SIP router chain the proxy forwarding to a strict router has to be aware of this fact as mentioned above. From: RUIZ Nicolas Sent: Wednesday, September 08, 2004 9:10 PM > When I put strict_route at the place of loose_route, I have an error. > (Module missing). Ser version is : 0.8.12. > What can I modify to apply strict routing only? Sorry I did not check that this previous function has been eliminated. But following the comment in rr_mod.c there is a possibility to force SER into strict routing (see above) behavior. Look into the code. Than you also have to use "record_route_strict" instead of "record_route". But I have heavy doubts that this will help your problems. Do you really know why you want to fall back to a deprecated routing behavior? Franz

19 years, 9 months

RE: [Serusers] Please help : how to disable losse routing ???

by Martin Koenig

Hello Nicolas, another mail from me, one more thing you should verify. Here you have ngrep from my proxy1 that is directly connected to the Cisco 7960. I stripped everything unimportant from this to enhance readability: # U 2004/09/16 18:57:34.088150 proxy1:5060 -> cisco7960:5070 SIP/2.0 200 OK. Contact: <sip:07154802860@gw1;user=phone>. Record-Route: <sip:+497154802860@proxy3:5070;lr>, <sip:+497154802860@proxy2:5070;lr>, <sip:07154802860@proxy1;lr>. The Cisco 7960 receives the OK message from proxy1. It contains the Contact field and the Record Route Fields for the proxy chain to the gateway. Note that all Record Route Fields contain the ;lr parameter (or ;lr=on in your case). The next step is the ACK from the Cisco 7960. # U 2004/09/16 18:57:34.298054 cisco7960:5070 -> proxy1:5060 ACK sip:07154802860@proxy1:5060;lr SIP/2.0. Route: <sip:+497154802860@proxy2:5070;lr>, <sip:+497154802860@proxy3:5070;lr>, <sip:07154802860@gw1:5060;user=phone>. . As you can see, it does not follow the Loose Route definitions. The ACK Request-URI does not equal the Contact from the preceeding 200 OK. Instead it contains the first hop (thus the last entry) of the Record Route Field from the 200 OK. As you can also see, it added the Contact Field from 200 OK at the End of the Route Field, without the ;lr parameter! This is absolutely fine behaviour. Now watch what happens when the proxy processes this message with loose_route(): # U 2004/09/16 18:57:34.301417 proxy1:5060 -> proxy2:5070 ACK sip:+497154802860@gw1:5060;user=phone SIP/2.0. Route: <sip:+497154802860@proxy2:5070;lr>, <sip:+497154802860@proxy3:5070;lr>. . The proxy detects that the last entry of the Route Field does not contain the ;lr parameter, so it sets this last entry as Request-URI for the ACK message to the next proxy and removes this from the Route Field. From now on we have perfectly fine Loose Routing, even though the Cisco does not care about it. It should not matter for the further processing of the request in the proxy chain. You have to debug your messaging chain at all devices to find out what is going wrong. I really can't see the Cause of the error. Maybe it's related to the NAT-traversal you are performing. Regards, Martin > -----Original Message----- > From: Nicolas RUIZ [mailto:nruiz@vivaction.com] > Sent: Thursday, September 16, 2004 5:05 PM > To: 'Martin Koenig' > Cc: jan(a)iptel.org > Subject: RE: [Serusers] Please help : how to disable losse routing ??? > > thanks for your help, > > 80.118.128.1 : GATEWAY CISCO AS5300 > 80.118.128.5 : SER IPTEL > 192.168.254.7 : IP@ PRIVATE AUDICODES UA > 192.168.254.12 : IP@ PRIVATE CISCO IPPHONE UA > > > > -----Message d'origine----- > De : Martin Koenig [mailto:martin.koenig@toplink-plannet.de] > Envoyé : jeudi 16 septembre 2004 16:59 > À : nruiz(a)vivaction.com > Objet : RE: [Serusers] Please help : how to disable losse routing ??? > > > Hi Nicolas, > > Ah, please give me again the specs of which IP is which device. > > Thanks, > Martin > > > -----Original Message----- > > From: Nicolas RUIZ [mailto:nruiz@vivaction.com] > > Sent: Thursday, September 16, 2004 4:50 PM > > To: 'Martin Koenig' > > Cc: jan(a)iptel.org > > Subject: RE: [Serusers] Please help : how to disable losse > routing ??? > > > > No i dont think so. > > I join ETHEREAL DUMP, look at the line : 8, if is possible. > > > > thanks a lot > > > > -----Message d'origine----- > > De : Martin Koenig [mailto:martin.koenig@toplink-plannet.de] > > Envoyé : jeudi 16 septembre 2004 16:41 > > À : nruiz(a)vivaction.com > > Objet : RE: [Serusers] Please help : how to disable losse > routing ??? > > > > > > Are you doing any transformation of the userpart of the sip > > uri (the part in > > front of the @) at the proxy server? For me this was the > > problem. Right now, > > i really can't figure out the problem. > > > > > -----Original Message----- > > > From: Nicolas RUIZ [mailto:nruiz@vivaction.com] > > > Sent: Thursday, September 16, 2004 2:47 PM > > > To: 'Jan Janak'; 'Martin Koenig' > > > Cc: serusers(a)lists.iptel.org > > > Subject: RE: [Serusers] Please help : how to disable losse > > routing ??? > > > > > > If I have a Cisco Ip phone 7940 with the last code (Loose > > > routing : RFC > > > 3261), a proxy registar Linux IPTEL ser (RFC 3261) and a > > > Gateway Cisco > > > AS5300 (IOS Code 12.3(6a)). > > > And I have see that the IOS code of my gateway AS5300 is not > > > according to > > > RFC3261. > > > > > > And my problem, is : > > > > > > My cisco IPPHONE with Loose routing mode, send the invite to > > > the proxy, and > > > the proxy send the invite to the gateway. > > > But when the IPPHONE send the ACK, he send with this > request line : > > > REQUEST-LINE : ACK sip:0675313859@80.118.128.1:5060 SIP/2.0 > > > > > > And the IP@ is my gateway cisco, and i think, with my AS, i > > > cannot USE SIP > > > RFC 3261??? YES OR NOT??? > > > > > > And that, i want to set iptel to do only strict routing. > > > > > > thanks a lot for your help. > > > > > > Nicolas RUIZ > > > > > > CONF IPTEL SER: > > > > > > #modparam("rr", "enable_full_lr", 1) > > > > > > # ------------------------- request routing logic > > ------------------- > > > > > > # main routing logic > > > > > > route{ > > > # initial sanity checks -- messages with > > > # max_forwards==0, or excessively long requests > > > 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; > > > }; > > > > > > # we record-route all messages -- to make sure that > > > # subsequent messages will go through our proxy; that's > > > # particularly good if upstream and downstream entities > > > # use different transport protocol > > > record_route(); > > > # loose-route processing > > > if (loose_route()) { > > > t_relay(); > > > break; > > > }; > > > > > > > > > -----Message d'origine----- > > > De : Jan Janak [mailto:jan@iptel.org] > > > Envoyé : jeudi 16 septembre 2004 11:03 > > > A : Martin Koenig > > > Cc : nruiz(a)vivaction.com; serusers(a)lists.iptel.org > > > Objet : Re: [Serusers] Please help : how to disable losse > > routing ??? > > > > > > > > > I am using 7960 myself and do not have any problems, please > > send ngrep > > > dumps. > > > > > > Jan. > > > > > > On 16-09 10:48, Martin Koenig wrote: > > > > I'm seeing some strange loose routing behaviour with my > > > testing Cisco 7960 > > > > phone. I'm trying to put ngreps on the list as soon as i > > > have the time. > > > > Maybe this is a cisco-specific problem? > > > > > > > > Regards, > > > > Martin > > > > > > > > > -----Original Message----- > > > > > From: Nicolas RUIZ [mailto:nruiz@vivaction.com] > > > > > Sent: Tuesday, September 14, 2004 12:03 PM > > > > > To: 'Jan Janak' > > > > > Cc: 'Jiri Kuthan'; franz.edler(a)utanet.at; 'Martin Koenig > > > > > [toplink-plannet GmbH]'; serusers(a)lists.iptel.org > > > > > Subject: RE: [Serusers] Please help : how to disable > > > losse routing ??? > > > > > > > > > > OK, > > > > > > > > > > Thanks a lot for your support > > > > > > > > > > Best regards > > > > > > > > > > Nicolas RUIZ > > > > > VIVACTION > > > > > FRANCE, PARIS > > > > > > > > > > -----Message d'origine----- > > > > > De : Jan Janak [mailto:jan@iptel.org] > > > > > Envoyé : mardi 14 septembre 2004 11:44 > > > > > A : Nicolas RUIZ > > > > > Cc : 'Jiri Kuthan'; franz.edler(a)utanet.at; 'Martin Koenig > > > > > [toplink-plannet > > > > > GmbH]'; serusers(a)lists.iptel.org > > > > > Objet : Re: [Serusers] Please help : how to disable losse > > > routing ??? > > > > > > > > > > > > > > > On 13-09 16:41, Nicolas RUIZ wrote: > > > > > > Thanks for your help, > > > > > > > > > > > > That's right, My gateway cisco is not according to RFC > > > > > 3261, and that's > > > > > why > > > > > > , I want to use only strict-routing. > > > > > > > > > > Loose routing is backwards compatible, it should work > > > even if the > > > > > gateway does not support loose routing. The problem must be > > > > > somewhere > > > > > else, presumably one of the end-points is broken. > > > > > > > > > > > And if I want to use "record_route_strict", I have to > > > > > rebuild the module > > > > > rr > > > > > > or not? > > > > > > > > > > Yes. > > > > > > > > > > Jan. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Serusers mailing list > > > > serusers(a)lists.iptel.org > > > > http://lists.iptel.org/mailman/listinfo/serusers > > > > > > > > > > > > > > > > > > > > > > > > > > >

19 years, 9 months

[Serusers] sip to h323 converter

by Adrian Georgescu

Cisco will have for this autumn 2621XM the first platform to support this translation, check Cisco TAC for updates. Otherwise try asterisk, it currently has still an audio bug in H323 code (no audio at all) but the CVS from 28-th of May works fine for H323/SIP. There are some missing features in Q931 stack like Nature of address but you can tweak the missing parts in the h323 channel. Another option that I know of is SIPQuest which supports only G711. Regards, Adrian >>>>>>>>>>>>>> 13704 Research Blvd. Building O-Suite 4 Austin, TX 78750 Tel: 512-257-2274 Ex: 115 Hi, Anybody has any idea where I can find sip to h323 converter? Will cisco 5300 do? Thanks CM

19 years, 9 months

RE: [Serusers] Serweb

by Paul Cowie

Which version of PHP did you use? -----Original Message----- From: Razvan Nemesiu [mailto:forum@netconnect.ro] Sent: 16 September 2004 16:49 To: serusers(a)lists.iptel.org Subject: [Serusers] Serweb Hi..I hust installed sereweb..everything is fine..i can connect to the admin page but it seems that it needs a username and a password ...the problem is that I don't know the username and password to login..how can I find them ? _______________________________________________ Serusers mailing list serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers ************************************************************************** Disclaimer This email transmission is confidential and intended solely for the person or organisation to whom it is addressed. If you are not the intended recipient, you must not copy, distribute or disseminate the information, or take any action in reliance of it. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of any organisation or employer. If you have received this message in error, do not open any attachment but please notify the sender (above) and delete this message from your system. Please rely on your own virus check. Although all outbound mail is checked for viruses, no responsibility is taken by the sender for any damage rising out of any bug or virus infection. **************************************************************************

19 years, 9 months

[Serusers] Click to dial - error 408

by Peter Herre

Hello serusers, currently I am configuring serweb's click to dial application. Both clients are inside the same private network without any NAT in between. Standard calls between the two clients work well. When I invoke ctd, the SIP phone of the calling party rings. Pick-up of the phone works, I get connected to the referrer, but the connection to the called party fails. See an excerpt of the log file: (Scenario: peter.herre calls helga.herre, i.e. helga.herre is referred by the ctd application's e-mail address 'clicktodial(a)inconsult.at'.) 9(13200) fifo_get_method: method: 'REFER' 9(13200) DEBUG: fifo_get_ruri: 'sip:peter.herre@10.49.9.170:5060' 9(13200) DEBUG: fifo_get_nexthop: hop: 'sip:peter.herre@10.49.9.170:5060' 9(13200) fifo_get_headers: headers: To: <sip:peter.herre@inconsult.at>;tag=414750038e741 From: <sip:clicktodial@inconsult.at>;tag=414750038e741 Call-ID: 414750038e741.fifouacctd Contact: <sip:caller@!!> CSeq: 2 REFER Referred-By: <sip:clicktodial@inconsult.at> Refer-To: sip:helga.herre@inconsult.at 9(13200) parse_headers: flags=-1 9(13200) DEBUG: add_param: tag=414750038e741 9(13200) end of header reached, state=29 9(13200) DEBUG: get_hdr_field: <To> [50]; uri=[sip:peter.herre@inconsult.at] 9(13200) DEBUG: to body [<sip:peter.herre@inconsult.at>] 9(13200) get_hdr_field: cseq <CSeq>: <2> <REFER> 9(13200) DEBUG: fifo_uac: parse_headers succeeded 9(13200) fifo_get_body: body: 9(13200) DEBUG: add_param: tag=414750038e741 9(13200) end of header reached, state=29 9(13200) DEBUG: mk_proxy: doing DNS lookup... 9(13200) DEBUG: get_hf_block: one more hf processed 9(13200) DEBUG: get_hf_block: one more hf processed 9(13200) DEBUG: get_hf_block: one more hf processed 9(13200) DEBUG: fifo_uac: EoL -- proceeding to transaction creation 9(13200) DEBUG: mk_proxy: doing DNS lookup... 9(13200) DEBUG: dlg2hash: 49113 9(13200) DEBUG: add_to_tail_of_timer[4]: 0x402e2b58 9(13200) DEBUG: add_to_tail_of_timer[0]: 0x402e2b6c 9(13200) INFO: fifo_server: command empty 10(13212) DEBUG: timer routine:1,tl=0x402e1fb4 next=0x402e09a4 10(13212) DEBUG: timer routine:1,tl=0x402e09a4 next=(nil) 10(13212) DEBUG: timer routine:4,tl=0x402e2b58 next=(nil) 10(13212) DEBUG: retransmission_handler : request resending (t=0x402e2a30, REFER sip ... ) 10(13212) DEBUG: add_to_tail_of_timer[5]: 0x402e2b58 10(13212) DEBUG: retransmission_handler : done 10(13212) DEBUG: timer routine:5,tl=0x402e2b58 next=(nil) Does anybody has a hint what is going wrong? DNS lookup fails?! Currently I have my domain in /etc/hosts. Below find the complete log file of the whole call. Best regards, Peter sip:/usr/local/etc/ser # tail -f /var/log/ser.log 4(13176) udp_rcv_loop: probing packet received from 10.49.9.170 34820 3(13161) udp_rcv_loop: probing packet received from 10.49.8.8 50195 9(13200) fifo_get_method: method: 'INVITE' 9(13200) DEBUG: fifo_get_ruri: 'sip:peter.herre@inconsult.at' 9(13200) DEBUG: fifo_get_nexthop: next hop empty 9(13200) fifo_get_headers: headers: From: <sip:clicktodial@inconsult.at>;tag=414750038e741 Call-ID: 414750038e741.fifouacctd Contact: <sip:caller@!!> To: <sip:peter.herre@inconsult.at> CSeq: 1 INVITE Content-Type: application/sdp 9(13200) parse_headers: flags=-1 9(13200) end of header reached, state=9 9(13200) DEBUG: get_hdr_field: <To> [32]; uri=[sip:peter.herre@inconsult.at] 9(13200) DEBUG: to body [<sip:peter.herre@inconsult.at> ] 9(13200) get_hdr_field: cseq <CSeq>: <1> <INVITE> 9(13200) DEBUG: fifo_uac: parse_headers succeeded 9(13200) fifo_get_body: body: v=0 o=click-to-dial 0 0 IN IP4 0.0.0.0 s=session c=IN IP4 0.0.0.0 b=CT:1000 t=0 0 m=audio 9 RTP/AVP 0 a=rtpmap:0 PCMU/8000 9(13200) DEBUG: add_param: tag=414750038e741 9(13200) end of header reached, state=29 9(13200) DEBUG: mk_proxy: doing DNS lookup... 9(13200) get_record: lookup(_sip._udp.inconsult.at, 33) failed 9(13200) sip_resolvehost: no SRV record found for inconsult.at, trying 'normal' lookup... 9(13200) DEBUG: get_hf_block: one more hf processed 9(13200) DEBUG: get_hf_block: one more hf processed 9(13200) DEBUG: fifo_uac: EoL -- proceeding to transaction creation 9(13200) DEBUG: mk_proxy: doing DNS lookup... 9(13200) get_record: lookup(_sip._udp.inconsult.at, 33) failed 9(13200) sip_resolvehost: no SRV record found for inconsult.at, trying 'normal' lookup... 9(13200) DEBUG: dlg2hash: 49116 9(13200) DEBUG: add_to_tail_of_timer[4]: 0x402e0990 9(13200) DEBUG: add_to_tail_of_timer[0]: 0x402e09a4 9(13200) INFO: fifo_server: command empty 2(13160) SIP Request: 2(13160) method: <INVITE> 2(13160) uri: <sip:peter.herre@inconsult.at> 2(13160) version: <SIP/2.0> 2(13160) parse_headers: flags=1 2(13160) Found param type 232, <branch> = <z9hG4bKcdfb.4a6c0fb3.0>; state=16 2(13160) end of header reached, state=5 2(13160) parse_headers: Via found, flags=1 2(13160) parse_headers: this is the first via 2(13160) After parse_msg... 2(13160) preparing to run routing scripts... 2(13160) ------------------------------------------- 2(13160) entering main loop 2(13160) check_via_address(10.52.0.11, 10.52.0.11, 0) 2(13160) INVITE message received 2(13160) DEBUG : is_maxfwd_present: searching for max_forwards header 2(13160) parse_headers: flags=128 2(13160) end of header reached, state=9 2(13160) DEBUG: get_hdr_field: <To> [32]; uri=[sip:peter.herre@inconsult.at] 2(13160) DEBUG: to body [<sip:peter.herre@inconsult.at> ] 2(13160) get_hdr_field: cseq <CSeq>: <1> <INVITE> 2(13160) DEBUG: get_hdr_body : content_length=131 2(13160) found end of header 2(13160) DEBUG: is_maxfwd_present: max_forwards header not found! 2(13160) parse_headers: flags=256 2(13160) find_first_route(): No Route headers found 2(13160) loose_route(): There is no Route HF 2(13160) check_self - checking if host==us: 12==20 && [inconsult.at] == [sip.int.inconsult.at] 2(13160) check_self - checking if port 5060 matches port 5060 2(13160) check_self - checking if host==us: 12==16 && [inconsult.at] == [sip.inconsult.at] 2(13160) check_self - checking if port 5060 matches port 5060 2(13160) lookup(): 'peter.herre' Not found in usrloc 2(13160) query="select grp from grp where username='peter.herre' AND grp='voicemail'" 2(13160) is_user_in(): User is in group 'voicemail' 2(13160) requested user is in voicemail group 2(13160) rwrite(): Rewriting Request-URI with 'sip:peter.herre@10.49.9.17 0:5060' 2(13160) invite for voicemail user->initiate failureroute[1] 2(13160) ------------------------------------------- 2(13160) entering route[1] - relaying SIP message 2(13160) parse_headers: flags=44 2(13160) DEBUG: add_param: tag=414750038e741 2(13160) end of header reached, state=29 2(13160) relaying message ... 2(13160) DEBUG: t_addifnew: msg id=19 , global msg id=16 , T on entrance=0xffffffff 2(13160) parse_headers: flags=-1 2(13160) parse_headers: flags=60 2(13160) t_lookup_request: start searching: hash=49116, isACK=0 2(13160) DEBUG: RFC3261 transaction matching failed 2(13160) DEBUG: t_lookup_request: no transaction found 2(13160) DBG: callback type 2, id 3 entered 2(13160) parse_headers: flags=44 2(13160) DEBUG: noisy_timer set for accounting 2(13160) SER: new INVITE 2(13160) parse_headers: flags=-1 2(13160) check_via_address(10.52.0.11, 10.52.0.11, 0) 2(13160) WARNING:vqm_resize: resize(0) called 4(13176) SIP Reply (status): 4(13176) version: <SIP/2.0> 4(13176) status: <100> 4(13176) reason: <trying -- your call is important to us> 4(13176) parse_headers: flags=1 4(13176) Found param type 232, <branch> = <z9hG4bKcdfb.4a6c0fb3.0>; state=16 4(13176) end of header reached, state=5 4(13176) parse_headers: Via found, flags=1 4(13176) parse_headers: this is the first via 4(13176) After parse_msg... 4(13176) forward_reply: found module tm, passing reply to it 4(13176) DEBUG: t_check: msg id=18 global id=15 T start=0xffffffff 4(13176) parse_headers: flags=17 4(13176) end of header reached, state=9 4(13176) DEBUG: get_hdr_field: <To> [32]; uri=[sip:peter.herre@inconsult.at] 4(13176) DEBUG: to body [<sip:peter.herre@inconsult.at> ] 4(13176) get_hdr_field: cseq <CSeq>: <1> <INVITE> 4(13176) parse_headers: flags=4 4(13176) DEBUG: t_reply_matching: hash 49116 label 1005635236 branch 0 4(13176) DEBUG: t_reply_matching: reply matched (T=0x402e0868)! 4(13176) DEBUG: t_check: msg id=18 global id=18 T end=0x402e0868 4(13176) DEBUG: t_on_reply: org. status uas=0, uac[0]=0 local=1 is_invite=1) 4(13176) ->>>>>>>>> T_code=0, new_code=100 4(13176) DEBUG: local_reply: branch=0, save=0, winner=-1 4(13176) DEBUG: add_to_tail_of_timer[1]: 0x402e09a4 4(13176) DEBUG:destroy_avp_list: destroing list (nil) 4(13176) receive_msg: cleaning up 2(13160) DEBUG: reply sent out. buf=0x80d1d38: SIP/2.0 1..., shmem=0x402df5b8: SIP/2.0 1 2(13160) DEBUG: t_reply: finished 2(13160) DEBUG: mk_proxy: doing DNS lookup... 2(13160) check_via_address(10.52.0.11, 10.52.0.11, 0) 2(13160) DEBUG: add_to_tail_of_timer[4]: 0x402e1fa0 2(13160) DEBUG: add_to_tail_of_timer[0]: 0x402e1fb4 2(13160) SER: new transaction fwd'ed 2(13160) DEBUG:destroy_avp_list: destroing list (nil) 2(13160) receive_msg: cleaning up 3(13161) SIP Reply (status): 3(13161) version: <SIP/2.0> 3(13161) status: <100> 3(13161) reason: <Trying> 3(13161) parse_headers: flags=1 3(13161) Found param type 232, <branch> = <z9hG4bKcdfb.5a6c0fb3.0>; state=16 3(13161) end of header reached, state=5 3(13161) parse_headers: Via found, flags=1 3(13161) parse_headers: this is the first via 3(13161) After parse_msg... 3(13161) forward_reply: found module tm, passing reply to it 3(13161) DEBUG: t_check: msg id=18 global id=14 T start=0xffffffff 3(13161) parse_headers: flags=17 3(13161) Found param type 232, <branch> = <z9hG4bKcdfb.4a6c0fb3.0>; state=16 3(13161) end of header reached, state=5 3(13161) parse_headers: Via found, flags=17 3(13161) parse_headers: this is the second via 3(13161) DEBUG: add_param: tag=414750038e741 3(13161) end of header reached, state=29 3(13161) DEBUG: get_hdr_field: <To> [50]; uri=[sip:peter.herre@inconsult.at] 3(13161) DEBUG: to body [<sip:peter.herre@inconsult.at>] 3(13161) get_hdr_field: cseq <CSeq>: <1> <INVITE> 3(13161) parse_headers: flags=4 3(13161) DEBUG: t_reply_matching: hash 49116 label 1005635237 branch 0 3(13161) DEBUG: t_reply_matching: reply matched (T=0x402e1e78)! 3(13161) DBG: callback type 1, id 5 entered 3(13161) DEBUG: t_check: msg id=18 global id=18 T end=0x402e1e78 3(13161) DEBUG: t_on_reply: org. status uas=100, uac[0]=0 local=0 is_invite=1) 3(13161) ->>>>>>>>> T_code=100, new_code=100 3(13161) DEBUG: relay_reply: branch=0, save=0, relay=-1 3(13161) DEBUG: add_to_tail_of_timer[1]: 0x402e1fb4 3(13161) DEBUG:destroy_avp_list: destroing list (nil) 3(13161) receive_msg: cleaning up 4(13176) SIP Reply (status): 4(13176) version: <SIP/2.0> 4(13176) status: <180> 4(13176) reason: <Ringing> 4(13176) parse_headers: flags=1 4(13176) Found param type 232, <branch> = <z9hG4bKcdfb.5a6c0fb3.0>; state=16 4(13176) end of header reached, state=5 4(13176) parse_headers: Via found, flags=1 4(13176) parse_headers: this is the first via 4(13176) After parse_msg... 4(13176) forward_reply: found module tm, passing reply to it 4(13176) DEBUG: t_check: msg id=19 global id=18 T start=0xffffffff 4(13176) parse_headers: flags=17 4(13176) Found param type 232, <branch> = <z9hG4bKcdfb.4a6c0fb3.0>; state=16 4(13176) end of header reached, state=5 4(13176) parse_headers: Via found, flags=17 4(13176) parse_headers: this is the second via 4(13176) DEBUG: add_param: tag=414750038e741 4(13176) end of header reached, state=29 4(13176) DEBUG: get_hdr_field: <To> [50]; uri=[sip:peter.herre@inconsult.at] 4(13176) DEBUG: to body [<sip:peter.herre@inconsult.at>] 4(13176) get_hdr_field: cseq <CSeq>: <1> <INVITE> 4(13176) parse_headers: flags=4 4(13176) DEBUG: t_reply_matching: hash 49116 label 1005635237 branch 0 4(13176) DEBUG: t_reply_matching: reply matched (T=0x402e1e78)! 4(13176) DBG: callback type 1, id 5 entered 4(13176) DEBUG: t_check: msg id=19 global id=19 T end=0x402e1e78 4(13176) DEBUG: t_on_reply: org. status uas=100, uac[0]=100 local=0 is_invite=1) 4(13176) ->>>>>>>>> T_code=100, new_code=180 4(13176) DEBUG: relay_reply: branch=0, save=0, relay=0 4(13176) old size: 393, new size: 334 4(13176) build_res_from_sip_res: copied size: orig:80, new: 21, rest: 313 msg= SIP/2.0 180 Ringing Via: SIP/2.0/UDP 10.52.0.11;branch=z9hG4bKcdfb.4a6c0fb3.0 From: <sip:clicktodial@inconsult.at>;tag=414750038e741 To: <sip:peter.herre@inconsult.at>;tag=414750038e741 Contact: <sip:peter.herre@10.49.9.170:5060> Call-ID: 414750038e741.fifouacctd CSeq: 1 INVITE Server: X-Lite build 1095 Content-Length: 0 4(13176) DEBUG: reply relayed. buf=0x80d1c10: SIP/2.0 1..., shmem=0x402dfbf0: SIP/2.0 1 4(13176) DBG: callback type 7, id 1 entered 4(13176) DEBUG: add_to_tail_of_timer[1]: 0x402e1fb4 4(13176) DEBUG:destroy_avp_list: destroing list (nil) 4(13176) receive_msg: cleaning up 4(13176) SIP Reply (status): 4(13176) version: <SIP/2.0> 4(13176) status: <180> 4(13176) reason: <Ringing> 4(13176) parse_headers: flags=1 4(13176) Found param type 232, <branch> = <z9hG4bKcdfb.4a6c0fb3.0>; state=16 4(13176) end of header reached, state=5 4(13176) parse_headers: Via found, flags=1 4(13176) parse_headers: this is the first via 4(13176) After parse_msg... 4(13176) forward_reply: found module tm, passing reply to it 4(13176) DEBUG: t_check: msg id=20 global id=19 T start=0xffffffff 4(13176) parse_headers: flags=17 4(13176) DEBUG: add_param: tag=414750038e741 4(13176) end of header reached, state=29 4(13176) DEBUG: get_hdr_field: <To> [50]; uri=[sip:peter.herre@inconsult.at] 4(13176) DEBUG: to body [<sip:peter.herre@inconsult.at>] 4(13176) get_hdr_field: cseq <CSeq>: <1> <INVITE> 4(13176) parse_headers: flags=4 4(13176) DEBUG: t_reply_matching: hash 49116 label 1005635236 branch 0 4(13176) DEBUG: t_reply_matching: reply matched (T=0x402e0868)! 4(13176) DEBUG: t_check: msg id=20 global id=20 T end=0x402e0868 4(13176) DEBUG: t_on_reply: org. status uas=0, uac[0]=100 local=1 is_invite=1) 4(13176) ->>>>>>>>> T_code=0, new_code=180 4(13176) DEBUG: local_reply: branch=0, save=0, winner=0 4(13176) DEBUG: add_to_tail_of_timer[1]: 0x402e09a4 4(13176) DEBUG:destroy_avp_list: destroing list (nil) 4(13176) receive_msg: cleaning up 10(13212) DEBUG: timer routine:4,tl=0x402e0990 next=0x402e1fa0 10(13212) DEBUG: timer routine:4,tl=0x402e1fa0 next=(nil) 3(13161) SIP Reply (status): 3(13161) version: <SIP/2.0> 3(13161) status: <200> 3(13161) reason: <Ok> 3(13161) parse_headers: flags=1 3(13161) Found param type 232, <branch> = <z9hG4bKcdfb.5a6c0fb3.0>; state=16 3(13161) end of header reached, state=5 3(13161) parse_headers: Via found, flags=1 3(13161) parse_headers: this is the first via 3(13161) After parse_msg... 3(13161) forward_reply: found module tm, passing reply to it 3(13161) DEBUG: t_check: msg id=19 global id=18 T start=0xffffffff 3(13161) parse_headers: flags=17 3(13161) Found param type 232, <branch> = <z9hG4bKcdfb.4a6c0fb3.0>; state=16 3(13161) end of header reached, state=5 3(13161) parse_headers: Via found, flags=17 3(13161) parse_headers: this is the second via 3(13161) DEBUG: add_param: tag=414750038e741 3(13161) end of header reached, state=29 3(13161) DEBUG: get_hdr_field: <To> [50]; uri=[sip:peter.herre@inconsult.at] 3(13161) DEBUG: to body [<sip:peter.herre@inconsult.at>] 3(13161) get_hdr_field: cseq <CSeq>: <1> <INVITE> 3(13161) parse_headers: flags=4 3(13161) DEBUG: t_reply_matching: hash 49116 label 1005635237 branch 0 3(13161) DEBUG: t_reply_matching: reply matched (T=0x402e1e78)! 3(13161) parse_headers: flags=4 3(13161) DBG: callback type 1, id 5 entered 3(13161) parse_headers: flags=4 3(13161) DEBUG: t_check: msg id=19 global id=19 T end=0x402e1e78 3(13161) DEBUG: t_on_reply: org. status uas=180, uac[0]=180 local=0 is_invite=1) 3(13161) ->>>>>>>>> T_code=180, new_code=200 3(13161) DEBUG: relay_reply: branch=0, save=0, relay=0 3(13161) old size: 725, new size: 666 3(13161) build_res_from_sip_res: copied size: orig:75, new: 16, rest: 650 msg= SIP/2.0 200 Ok Via: SIP/2.0/UDP 10.52.0.11;branch=z9hG4bKcdfb.4a6c0fb3.0 From: <sip:clicktodial@inconsult.at>;tag=414750038e741 To: <sip:peter.herre@inconsult.at>;tag=414750038e741 Contact: <sip:peter.herre@10.49.9.170:5060> Call-ID: 414750038e741.fifouacctd CSeq: 1 INVITE Content-Type: application/sdp Server: X-Lite build 1095 Content-Length: 304 v=0 o=peter.herre 1042331213 1042331213 IN IP4 10.49.9.170 s=X-Lite c=IN IP4 10.49.9.170 t=0 0 m=audio 8000 RTP/AVP 0 8 3 97 110 101 a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:3 gsm/8000 a=rtpmap:97 iLBC/8000 a=rtpmap:110 speex/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 3(13161) DEBUG: update_totag_set: new totag 3(13161) DEBUG: reply relayed. buf=0x80d2408: SIP/2.0 2..., shmem=0x402df5b8: SIP/2.0 2 3(13161) DBG: callback type 7, id 1 entered 3(13161) ACC: transaction answered: method=INVITE, i-uri=sip:peter.herre@inconsult.at, o-uri=sip:peter.herre@10.49.9.17 0:5060, call_id=414750038e741.fifouacctd, from=<sip:clicktodial@inconsult.at>;tag=414750038e741, code=200 3(13161) DEBUG: cleanup_uacs: RETR/FR timers reset 3(13161) DEBUG: add_to_tail_of_timer[2]: 0x402e1ec0 3(13161) DEBUG:destroy_avp_list: destroing list (nil) 3(13161) receive_msg: cleaning up 4(13176) SIP Reply (status): 4(13176) version: <SIP/2.0> 4(13176) status: <200> 4(13176) reason: <Ok> 4(13176) parse_headers: flags=1 4(13176) Found param type 232, <branch> = <z9hG4bKcdfb.4a6c0fb3.0>; state=16 4(13176) end of header reached, state=5 4(13176) parse_headers: Via found, flags=1 4(13176) parse_headers: this is the first via 4(13176) After parse_msg... 4(13176) forward_reply: found module tm, passing reply to it 4(13176) DEBUG: t_check: msg id=21 global id=20 T start=0xffffffff 4(13176) parse_headers: flags=17 4(13176) DEBUG: add_param: tag=414750038e741 4(13176) end of header reached, state=29 4(13176) DEBUG: get_hdr_field: <To> [50]; uri=[sip:peter.herre@inconsult.at] 4(13176) DEBUG: to body [<sip:peter.herre@inconsult.at>] 4(13176) get_hdr_field: cseq <CSeq>: <1> <INVITE> 4(13176) parse_headers: flags=4 4(13176) DEBUG: t_reply_matching: hash 49116 label 1005635236 branch 0 4(13176) DEBUG: t_reply_matching: reply matched (T=0x402e0868)! 4(13176) DEBUG: t_check: msg id=21 global id=21 T end=0x402e0868 4(13176) DEBUG: t_on_reply: org. status uas=180, uac[0]=180 local=1 is_invite=1) 4(13176) parse_headers: flags=-1 4(13176) DEBUG: get_hdr_body : content_length=304 4(13176) found end of header 4(13176) DEBUG: mk_proxy: doing DNS lookup... 4(13176) DEBUG: mk_proxy: doing DNS lookup... 4(13176) ->>>>>>>>> T_code=180, new_code=200 4(13176) DEBUG: local_reply: branch=0, save=0, winner=0 4(13176) DEBUG: update_totag_set: new totag 4(13176) DEBUG: local transaction completed 4(13176) !!!!! ref_counter: 1 4(13176) DEBUG: fifo UAC completed with status 200 4(13176) parse_headers: flags=-1 4(13176) DEBUG: fifo_callback sucesssfuly completed 4(13176) DEBUG: cleanup_uacs: RETR/FR timers reset 4(13176) DEBUG: add_to_tail_of_timer[2]: 0x402e08b0 4(13176) DEBUG:destroy_avp_list: destroing list (nil) 4(13176) receive_msg: cleaning up 9(13200) fifo_get_method: method: 'REFER' 9(13200) DEBUG: fifo_get_ruri: 'sip:peter.herre@10.49.9.170:5060' 9(13200) DEBUG: fifo_get_nexthop: hop: 'sip:peter.herre@10.49.9.170:5060' 9(13200) fifo_get_headers: headers: To: <sip:peter.herre@inconsult.at>;tag=414750038e741 From: <sip:clicktodial@inconsult.at>;tag=414750038e741 Call-ID: 414750038e741.fifouacctd Contact: <sip:caller@!!> CSeq: 2 REFER Referred-By: <sip:clicktodial@inconsult.at> Refer-To: sip:helga.herre@inconsult.at 9(13200) parse_headers: flags=-1 9(13200) DEBUG: add_param: tag=414750038e741 9(13200) end of header reached, state=29 9(13200) DEBUG: get_hdr_field: <To> [50]; uri=[sip:peter.herre@inconsult.at] 9(13200) DEBUG: to body [<sip:peter.herre@inconsult.at>] 9(13200) get_hdr_field: cseq <CSeq>: <2> <REFER> 9(13200) DEBUG: fifo_uac: parse_headers succeeded 9(13200) fifo_get_body: body: 9(13200) DEBUG: add_param: tag=414750038e741 9(13200) end of header reached, state=29 9(13200) DEBUG: mk_proxy: doing DNS lookup... 9(13200) DEBUG: get_hf_block: one more hf processed 9(13200) DEBUG: get_hf_block: one more hf processed 9(13200) DEBUG: get_hf_block: one more hf processed 9(13200) DEBUG: fifo_uac: EoL -- proceeding to transaction creation 9(13200) DEBUG: mk_proxy: doing DNS lookup... 9(13200) DEBUG: dlg2hash: 49113 9(13200) DEBUG: add_to_tail_of_timer[4]: 0x402e2b58 9(13200) DEBUG: add_to_tail_of_timer[0]: 0x402e2b6c 9(13200) INFO: fifo_server: command empty 10(13212) DEBUG: timer routine:1,tl=0x402e1fb4 next=0x402e09a4 10(13212) DEBUG: timer routine:1,tl=0x402e09a4 next=(nil) 10(13212) DEBUG: timer routine:4,tl=0x402e2b58 next=(nil) 10(13212) DEBUG: retransmission_handler : request resending (t=0x402e2a30, REFER sip ... ) 10(13212) DEBUG: add_to_tail_of_timer[5]: 0x402e2b58 10(13212) DEBUG: retransmission_handler : done 10(13212) DEBUG: timer routine:5,tl=0x402e2b58 next=(nil) 10(13212) DEBUG: retransmission_handler : request resending (t=0x402e2a30, REFER sip ... ) 10(13212) DEBUG: add_to_tail_of_timer[6]: 0x402e2b58 10(13212) DEBUG: retransmission_handler : done 4(13176) udp_rcv_loop: probing packet received from 10.49.9.170 34820 1(13158) udp_rcv_loop: probing packet received from 10.49.8.8 50195 10(13212) DEBUG: timer routine:6,tl=0x402e2b58 next=(nil) 10(13212) DEBUG: retransmission_handler : request resending (t=0x402e2a30, REFER sip ... ) 10(13212) DEBUG: add_to_tail_of_timer[7]: 0x402e2b58 10(13212) DEBUG: retransmission_handler : done 10(13212) DEBUG: timer routine:0,tl=0x402e2b6c next=(nil) 10(13212) DEBUG: FR_handler:stop retr. and send CANCEL (0x402e2a30) 10(13212) ->>>>>>>>> T_code=0, new_code=408 10(13212) DBG: callback type 6, id 4 entered 10(13212) DBG: acc: on_missed: no uas.request, local t; skipping 10(13212) DEBUG: local_reply: branch=0, save=0, winner=0 10(13212) DEBUG: local transaction completed 10(13212) !!!!! ref_counter: 0 10(13212) DEBUG: fifo UAC completed with status 408 10(13212) DEBUG: fifo_callback sucesssfuly completed 10(13212) DEBUG: add_to_tail_of_timer[2]: 0x402e2a78 10(13212) DEBUG: final_response_handler : done 10(13212) DEBUG: timer routine:2,tl=0x402e1ec0 next=0x402e08b0 10(13212) DEBUG: wait_handler : removing 0x402e1e78 from table 10(13212) DEBUG: delete transaction 0x402e1e78 10(13212) DEBUG: wait_handler : done 10(13212) DEBUG: timer routine:2,tl=0x402e08b0 next=(nil) 10(13212) DEBUG: wait_handler : removing 0x402e0868 from table 10(13212) DEBUG: delete transaction 0x402e0868 10(13212) DEBUG: wait_handler : done 10(13212) DEBUG: timer routine:7,tl=0x402e2b58 next=(nil) 2(13160) udp_rcv_loop: probing packet received from 10.49.9.170 34820 4(13176) udp_rcv_loop: probing packet received from 10.49.8.8 50195

19 years, 9 months

← Newer
1
...
16
17
18
19
20
21
22
...
39
Older →

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 September 2004