sr-users

sr-users@lists.kamailio.org

19 participants
37529 discussions

[Users] Hijack 'Move Temporarily'
by Sam Lee 05 Feb '07

05 Feb '07

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

6 23

[Users] database persistent connection
by tele 05 Feb '07

05 Feb '07

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

2 2

[Users] Help. in OpenSER in Post-paid and pre-paid
by raviprakash sunkara 05 Feb '07

05 Feb '07

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

2 2

[Users] strip_tail() string length?
by Brandon Armstead 05 Feb '07

05 Feb '07

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

3 5

[Serusers] Cisco AS 5300 can't send BYE for SER... It's bug?
by Sho Aihara 05 Feb '07

05 Feb '07

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

3 2

Re: [Users] 200 ok not cought in ONREPLY
by Daniel-Constantin Mierla 05 Feb '07

05 Feb '07

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

1 0

[Users] OpenSER 1.2.0 + Presence
by Bernard Chan 05 Feb '07

05 Feb '07

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.

2 1

[Users] In NAT, I didn't see the ACK packet after the Invited the Callee
by raviprakash sunkara 05 Feb '07

05 Feb '07

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

2 1

[Users] 200 ok not cought in ONREPLY
by Dan-Cristian Bogos 05 Feb '07

05 Feb '07

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

3 2

Res: [Users] 407 and algorithm=MD5
by Bruno Machado 05 Feb '07

05 Feb '07

The section 3.2.1 (The WWW-Authenticate Response Header) from RFC 2617 says: "algorithm A string indicating a pair of algorithms used to produce the digest and a checksum. If this is not present it is assumed to be "MD5". " I send a INVITE to Openser but it send back a 407 (Proxy Authentication). The parameter response was OK. But, without the parameter 'algorithm', the proxy didn't allow the authentication. It neither consult at Radius. Looking at the RFC above, the SIP proxy must to use MD5 by default, but it don't accept the message without the parameter. Who needs to assume the algorithm? UAC or SIP Proxy? Can it be a bug of OpenSER? Or my interpretation is wrong? Best regards. Bruno Machado ----- Mensagem original ---- De: Bogdan-Andrei Iancu <bogdan(a)voice-system.ro> Para: Bruno Machado <bsmufu(a)yahoo.com.br> Cc: users(a)openser.org Enviadas: Segunda-feira, 29 de Janeiro de 2007 14:21:31 Assunto: Re: [Users] 407 and algorithm=MD5 Hi Bruno, you cannot configure to have the algorithm param added. If I'm not wrong, the digest RFC says this is an optional param and the default value is MD5. regards, bogdan Bruno Machado wrote: > Hi. > > When I use the function proxy_challenge(), the 407 don't have the > parameter 'algorithm=MD5'. Look below: > > ... > Proxy-Authenticate: Digest realm="proxy.com.br", > nonce="45be00f941f137ff037436c77f80a9531a02155f". > ... > > How can I put this parameter in digest informations? > > ... > Proxy-Authenticate: Digest realm="proxy.com.br", > nonce="45be00f941f137ff037436c77f80a9531a02155f", > algorithm="MD5". > ... > > > Thanks in advance. > > Bruno > > __________________________________________________ > Fale com seus amigos de graça com o novo Yahoo! Messenger > http://br.messenger.yahoo.com/ > >------------------------------------------------------------------------ > >_______________________________________________ >Users mailing list >Users(a)openser.org >http://openser.org/cgi-bin/mailman/listinfo/users > > __________________________________________________ Fale com seus amigos de graça com o novo Yahoo! Messenger http://br.messenger.yahoo.com/

3 3

Jump to page:

2025

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