sr-users July 2004

sr-users@lists.kamailio.org

178 participants
449 discussions

[Serusers] SER, Radius and /etc/passwd
by Steve Fraser 18 Jul '04

18 Jul '04

Hi All, I'm trying to implement SER into an existing system, and having problems with radius authentication. RTFM and lots of google hasnt helped! The existing working freeradius server uses Unix (/etc/passwd) file (on FreeBSD) to authenticate users who dial into a modem server. I'd like to use the same accounts and passwords for SIP users, using the same radius server. I'm using the default modparam values for module auth_radius. However, the doco suggests to me that I have to use Digest authentication when I call radius_www_authorize. But the cleartext password is not available to the Radius server(ie I'm not using entries in the radius "users" file) so I cant see how it could do Digest authentication at its end. The existing authentication uses Auth Type := System. So, can I get SER to do cleartext auth to the radius server (both are on the same, isolated subnet, so I'm not worried about traffic being captured) Is there a service_type or something else? Any advice appreciated Steve

2 1

[Serusers] Voice Mail options for an SER environment
by Steve Blair 17 Jul '04

17 Jul '04

Hello: I'm interested in how this community is providing voicemail service to IP phone users registered to a SER proxy. If you can speak to this point I'd appreciate any feedback you can provide. Specifically I'm interested in: 1) What product is providing voice mail service? 2) With this system can users manipulate messages via the telephone set? 3) If the answer to #2 is yes then how is this functionality implemented. Do you provision a lead number for users to call into voicemail? Thanks,Steve -- ISC Network Engineering The University of Pennsylvania 3401 Walnut Street, Suite 221A Philadelphia, PA 19104 voice: 215-573-8396 215-746-7903 fax: 215-898-9348 sip:blairs@upenn.edu

8 11

Re: [Serusers] ACK message Via field branch=0 problem
by ks lf 17 Jul '04

17 Jul '04

Hi, I already know why there have new branch ID in the response ACK ( as Jiri explained, it's belongs to a new session so SIPURA and SER use different branch ID ), we double checked with terminaiton gateway side, they said because the response branch ID isn't same to the value in 200 OK so their gateway refuse the message, we will push them to do a trouble-shooting on their sip firmware, any way, thank you guys, have a nice weekend. ----- Original Message ----- From: Jiri Kuthan <jiri(a)iptel.org> Date: Sat, 17 Jul 2004 11:47:04 +0200 To: Andrei Pelinescu-Onciul <pelinescu-onciul(a)fokus.fraunhofer.de>,ks lf <ksabc(a)lycos.com> Subject: Re: [Serusers] ACK message Via field branch=0 problem > At 09:58 AM 7/17/2004, Andrei Pelinescu-Onciul wrote: > >On Jul 16, 2004 at 19:09, ks lf <ksabc(a)lycos.com> wrote: > >> Use SER 0.8.12 stable release, enabled nathelper+rtpproxy for NAT traversal, forward 1(xxx)xxx-xxxx to SIp termiantion gateway, when the call was connected, PSTN gateway send 200 OK back, sip client ( behind NAT ) response with ACK ( which has branch value in Via head ), but when SER forward the ACK back to PSTN gateway, in Via header it includes branch=0, PSTN gateway refuse this ACk because it think the branch id is invalid, > > I don't know if this is the reason why the gateway denies the ACK, but if so, > you should submit a trouble ticket to the gateway vendor. According to RFC3261, > ACK for positive replies is a separate transaction and there is no guarantee > that it would have the same branch id. People who have difficults to understand > that typically get the "aha" effect when they see a scenario with multiple proxy > servers as follows: > > > UAC PROXY1 PROXY2 UAS > (record-routing) (no rr-ing) > > INVITE -----------------> ----------------> --------------> > ACK -----------------> -------------------------------------> > > in this scenario, only proxy 1 record routes, i.e., subsequent requests such > as ACK will not visit proxy2. Consequently, proxy2 cannot generate the same > branch ID as it did for proxy1. UAS will thus see proxy1's branch in the ACK, > which is different from proxy2's branch in the original INVITE. > > Tell the vendor to match ACKs _DIALOG-WISE_. > > -jiri > -- _______________________________________________ Find what you are looking for with the Lycos Yellow Pages http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.as…

1 0

Re: [Serusers] ACK message Via field branch=0 problem
by ks lf 17 Jul '04

17 Jul '04

Thank you Andrei and Jiri for your quick response on this issue, I really like SER project, not only its apache like functions as a sip system, but also you always can get help from so many good heart experts all over the world; We tried the first suggestion from Andrei by adding syn_branch=no to ser.cfg, it did work - adds the branch id into ACK Via header, but strange thing is it inserted an unknown branch Id which is still not recognized by the termination gateway, and call disconnected after "Recover on Timer Expiry" occur; here is the branch ID I captured ( this time I use SIPURA 2000 as the UA ): SIPURA -> SER INVITE branch=z9hG4bK-d5f36318 SIPURA <- SER 100 trying branch=z9hG4bK-d5f36318 SER -> TermGW INVITE branch=z9hG4bK193b.e50217463437115c3052e9a41f0a84b7.0 ( public IP ) branch=z9hG4bK-d5f36318 ( private IP ) SER <- TermGW 100 trying branch=z9hG4bK193b.e50217463437115c3052e9a41f0a84b7.0 SER <- TermGW 183 Session Pro branch=z9hG4bK193b.e50217463437115c3052e9a41f0a84b7.0 SIPURA <- SER 183 Session Pro branch=z9hG4bK-d5f36318 SER <- TermGW 200 OK branch=z9hG4bK193b.e50217463437115c3052e9a41f0a84b7.0 SIPURA <- SER 200 OK branch=z9hG4bK-d5f36318 SIPURA -> SER ACK branch=z9hG4bK-3207bbd5 (why new branch id value here ???) SER -> TermGW ACK branch=z9hG4bK193b.47867d49d7e7231dfc249720f8269f5d.0 ( public IP ) (where new branch id value here ???) branch=z9hG4bK-3207bbd5 ( private IP ) We don't know what brand name of the SIP Gateway it's, but will notice the termination partner ( a big carrier ) the valued suggestions all of you contribute, thanks. Regards, ----- Original Message ----- From: Jiri Kuthan <jiri(a)iptel.org> Date: Sat, 17 Jul 2004 11:47:04 +0200 To: Andrei Pelinescu-Onciul <pelinescu-onciul(a)fokus.fraunhofer.de>,ks lf <ksabc(a)lycos.com> Subject: Re: [Serusers] ACK message Via field branch=0 problem > At 09:58 AM 7/17/2004, Andrei Pelinescu-Onciul wrote: > >On Jul 16, 2004 at 19:09, ks lf <ksabc(a)lycos.com> wrote: > >> Use SER 0.8.12 stable release, enabled nathelper+rtpproxy for NAT traversal, forward 1(xxx)xxx-xxxx to SIp termiantion gateway, when the call was connected, PSTN gateway send 200 OK back, sip client ( behind NAT ) response with ACK ( which has branch value in Via head ), but when SER forward the ACK back to PSTN gateway, in Via header it includes branch=0, PSTN gateway refuse this ACk because it think the branch id is invalid, > > I don't know if this is the reason why the gateway denies the ACK, but if so, > you should submit a trouble ticket to the gateway vendor. According to RFC3261, > ACK for positive replies is a separate transaction and there is no guarantee > that it would have the same branch id. People who have difficults to understand > that typically get the "aha" effect when they see a scenario with multiple proxy > servers as follows: > > > UAC PROXY1 PROXY2 UAS > (record-routing) (no rr-ing) > > INVITE -----------------> ----------------> --------------> > ACK -----------------> -------------------------------------> > > in this scenario, only proxy 1 record routes, i.e., subsequent requests such > as ACK will not visit proxy2. Consequently, proxy2 cannot generate the same > branch ID as it did for proxy1. UAS will thus see proxy1's branch in the ACK, > which is different from proxy2's branch in the original INVITE. > > Tell the vendor to match ACKs _DIALOG-WISE_. > > -jiri > -- _______________________________________________ Find what you are looking for with the Lycos Yellow Pages http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.as…

1 0

RE: [Serusers] Remote Party ID
by Joseph Cheung 17 Jul '04

17 Jul '04

Any idea which .c file support the append_rpid_hf()? -----Original Message----- From: serusers-bounces(a)iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Charles Galea Sent: July 12, 2004 6:55 AM To: serusers(a)lists.iptel.org Cc: 'Andrew Caruana' Subject: [Serusers] Remote Party ID We have downloaded the latest ser software from cvs in order to support appending of remote party id while using mysql as the ser database. After compiling and installing the ser software we included the auth and auth_db parameters and also the append_rpid_hf() function in our ser.cfg file as shown below. SER server starts and registration is successfull however when forwarding to the pstn gateway, ser will not append the remote party id header, even if the rpid and uri columns in mysql database are populated accordingly using the serctl add rpid command. Calls are also successfull however the gateway will not include the calling party number in the setup message because the rpid header is missing. Any ideas please? Thanks Charles and Andrew # ----------- global configuration parameters ------------------------ #debug=3 # debug level (cmd line: -dddddddddd) #fork=yes #log_stderror=no # (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 ---------------------------------- loadmodule "/our_downloads/sip_router/modules/mysql/mysql.so" #loadmodule "//lib/ser/modules/mysql.so" loadmodule "//lib/ser/modules/sl.so" loadmodule "//lib/ser/modules/tm.so" loadmodule "//lib/ser/modules/rr.so" loadmodule "//lib/ser/modules/maxfwd.so" loadmodule "//lib/ser/modules/usrloc.so" loadmodule "//lib/ser/modules/registrar.so" loadmodule "//lib/ser/modules/textops.so" # Uncomment this if you want digest authentication # mysql.so must be loaded ! loadmodule "//lib/ser/modules/auth.so" loadmodule "//lib/ser/modules/auth_db.so" #loadmodule "//lib/ser/modules/acc.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", 1) # -- auth params -- modparam("auth_db", "use_rpid", 1) modparam("auth_db", "rpid_column", "rpid") modparam("auth", "rpid_prefix", "<sip:") modparam("auth", "rpid_suffix", "@testphone.com>:party=calling;screen=no;privacy=off") # 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) # ------------------------- 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=~"testphone.com") { lookup("aliases"); if (method=="REGISTER") { #Uncomment this if you want to use digest authentication if (!www_authorize("testphone.com", "subscriber")) { www_challenge("testphone.com", "0"); append_rpid_hf(); break; }; save("location"); break; }; if (uri=~"^sip:21") { append_rpid_hf(); forward(a valid ip address for the gateway was inserted here); break; } if (uri=~"^sip:123") { forward(a valid ip address for the gareway was inserted here); 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(); }; }

2 1

[Serusers] route managment
by Jev 17 Jul '04

17 Jul '04

Hi all, What route management facilities exist for ser besides what we can put in ser.cfg? Is there any existing facilities of using metrics based on Quality and Cost, and also allowing for route failover? Also, if we have new (for example) pstn gateways coming on to our network, how can we add these routes without restarting ser? Where is the appropriate place for this type of functionality to live? In a ser module, pulling routes (with cost/quality metrics) from a DB? Thnx! -Jev

8 11

[Serusers] question...
by Chris Crawford 17 Jul '04

17 Jul '04

Hey! Does anyone know how to do the following (if it can be done at all)? In the ser.cfg, I would like to use a return value from a module's function as a prefix to a URI. .... VALUE=function_a( ); <-- exported from a module prefix( "$VALUE" ); <-- URI prefix'ing of user routine .... I do not want to use the exec module, (the admin module shows nice examples), as the processing expense is too high. Thanks ahead of time. Chris

5 4

[Serusers] ACK message Via field branch=0 problem
by ks lf 17 Jul '04

17 Jul '04

Use SER 0.8.12 stable release, enabled nathelper+rtpproxy for NAT traversal, forward 1(xxx)xxx-xxxx to SIp termiantion gateway, when the call was connected, PSTN gateway send 200 OK back, sip client ( behind NAT ) response with ACK ( which has branch value in Via head ), but when SER forward the ACK back to PSTN gateway, in Via header it includes branch=0, PSTN gateway refuse this ACk because it think the branch id is invalid, so call was dropped after 30- 60 seconds, what's wrong with that? I really appreciate if you met such problems before, thanks, and have a nice day. Here is captured message between pstn gateway and ser: SIP MESSAGE 4 65.22.14.3:42326(1) -> 182.156.33.10:5060(2) UDP Frame 13 10/Jul/04 13:29:33.6715 TimeFromPreviousSipFrame=3.4065 TimeFromStart=6.3374 SIP/2.0 200 OK Call-ID: 3164823746(a)192.168.0.102 From: <sip:2103334444@182.156.33.10;user=phone>;tag=1842950071 To: <sip:021445333321@182.156.33.10;user=phone>;tag=17810 Content-Length: 215 Content-Type: application/sdp CSeq: 1 INVITE Via: SIP/2.0/UDP 182.156.33.10;branch=z9hG4bK2681.4c495f05.0,SIP/2.0/UDP 192.168.0.102:5060;rport=64069;received=65.33.22.6 Contact: sip:19727925475@65.22.14.3:5060 Record-Route: <sip:021445333321@182.156.33.10;ftag=1842950071;lr=on> SIP MESSAGE 5 182.156.33.10:5060(2) -> 65.22.14.3:42326(1) UDP Frame 23 10/Jul/04 13:29:33.7641 TimeFromPreviousSipFrame=0.0926 TimeFromStart=6.4300 ACK sip:19727925475@65.22.14.3:42326 SIP/2.0 Max-Forwards: 10 Record-Route: <sip:021445333321@182.156.33.10;ftag=1842950071;lr=on> Via: SIP/2.0/UDP 182.156.33.10;branch=0 Via: SIP/2.0/UDP 192.168.0.102:5060;rport=64069;received=65.33.22.6 From: <sip:2103334444@182.156.33.10;user=phone>;tag=1842950071 To: <sip:021445333321@182.156.33.10;user=phone>;tag=17810 Call-ID: 3164823746(a)192.168.0.102 CSeq: 1 ACK User-Agent: Cisco ATA v2.15 ata18x (020927a) Content-Length: 0 Here is the configuration file: debug=0 fork=yes log_stderror=yes check_via=no # (cmd. line: -v) dns=no # (cmd. line: -r) rev_dns=no # (cmd. line: -R) port=5060 children=8 listen=182.156.33.10 fifo="/tmp/ser_fifo" loadmodule "/usr/lib/ser/modules/nathelper.so" loadmodule "/usr/lib/ser/modules/mysql.so" loadmodule "/usr/lib/ser/modules/sl.so" loadmodule "/usr/lib/ser/modules/tm.so" loadmodule "/usr/lib/ser/modules/rr.so" loadmodule "/usr/lib/ser/modules/maxfwd.so" loadmodule "/usr/lib/ser/modules/usrloc.so" loadmodule "/usr/lib/ser/modules/registrar.so" loadmodule "/usr/lib/ser/modules/textops.so" loadmodule "/usr/lib/ser/modules/uri.so" loadmodule "/usr/lib/ser/modules/auth.so" loadmodule "/usr/lib/ser/modules/auth_radius.so" loadmodule "/usr/lib/ser/modules/acc.so" modparam("usrloc", "db_mode", 2) modparam("usrloc", "db_mode", 2) modparam("rr", "enable_full_lr", 1) modparam("auth_radius", "radius_config", "/etc/radiusclient/radiusclient.conf") modparam("auth_radius", "service_type", 15) modparam("acc", "service_type", 15) modparam("acc", "radius_config", "/etc/radiusclient/radiusclient.conf") modparam("acc", "log_level", 2) modparam("acc", "radius_flag", 1) modparam("acc", "radius_missed_flag", 9) modparam("nathelper", "natping_interval", 10) 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; }; setflag(1); /* Radius Accouting */ loose_route(); record_route(); if (search("@192.168.*") || search("@10.*") || search("@172.16.*")) { setflag(2); force_rport(); fix_nated_contact(); }; /* For Radius Accounting */ if (method=="INVITE") { log(1, "INVITE: Radius Accounting\n"); setflag(1); /* Radius Accouting */ if (isflagset(2)) { force_rtp_proxy(); }; t_on_reply("1"); }; if (method=="MESSAGE") { log(1, "MESSAGE: Radius Accounting\n"); setflag(1); /* Radius Accouting */ }; if (method=="BYE" || method=="CANCEL") { log (1, "BYE or CANCEL: Radius Accounting\n"); setflag(1); /* Radius Accouting */ }; if (uri==myself) { if (method=="REGISTER") { if (!radius_www_authorize("")) { log(1, "REGISTER: Radius Challenging User\n"); www_challenge("", "0"); break; }; save("location"); break; }; lookup("aliases"); if (uri=~"sip:1[0-9][0-9][0-9]*@.*") { t_relay_to_udp("65.22.14.3", "5060"); break; }; # native SIP destinations are handled using our USRLOC DB if (!lookup("location")) { sl_send_reply("404", "Not Found"); break; }; }; setflag(1); if (!t_relay()) { sl_reply_error(); }; } onreply_route[1] { if ( ((status=~"2[0-9][0-9]")||(status=~"183")) && (search("192.168.*") || search("@10.*") || search("172.16.*") )) { fix_nated_contact(); force_rtp_proxy(); }; } -- _______________________________________________ Find what you are looking for with the Lycos Yellow Pages http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.as…

3 2

RE: [Serusers] Problem with messages + msilo
by Dave Bath 17 Jul '04

17 Jul '04

Daniel, many thanks for swift response!. If I set fork=yes I get the same error. If I set listen=<ip> then strange things break.. calls are no longer connected properly, and UAs cant log in. Any more suggestions?! D -----Original Message----- From: Daniel-Constantin Mierla [mailto:daniel@iptel.org] Sent: 16 July 2004 22:34 To: Dave Bath Cc: serusers(a)lists.iptel.org Subject: Re: [Serusers] Problem with messages + msilo Do you have fork=yes in your config file? If no, then either set fork=yes or set the public ip explicitly to listen to with: listen=ip_address. Daniel On 07/16/04 23:22, Dave Bath wrote: >I don't know! I have perhaps misunderstood... it is not explicitly >bound to anything. It is a single machine with a single network card >with a single external Ip address? > >D > >-----Original Message----- >From: Daniel-Constantin Mierla [mailto:daniel@iptel.org] >Sent: 16 July 2004 22:16 >To: Dave Bath >Cc: serusers(a)lists.iptel.org >Subject: Re: [Serusers] Problem with messages + msilo > >Hello, >there is a self explanatory error message -- is it the case? > >On 07/16/04 18:26, Dave Bath wrote: > > > >>Hey guys, >> >>I have been battling with msilo, and the routing logic. It finally >>looks like it might be beginning to get there, (ser actually restarts >>now!) lol, but I have a problem when I try and send a message. >> >>I am using the serweb utility to try and send to "sip:admin@<ip>" and >>it reports "message accepted for delivery"... but I don't receive it. >>Checking the log shows; >> >>Jul 16 17:20:01 sip /usr/sbin/ser[20227]: MSILO: the downstream UA >>does not support MESSAGE requests ... >> >>Jul 16 17:20:01 sip /usr/sbin/ser[20227]: ACC: transaction answered: >>method=MESSAGE, i-uri=sip:admin@161.30.94.68, >>o-uri=sip:admin@81.86.136.86:5060, call_id=7971f97d-0(a)127.0.0.1, >> >> >> >from=sip:admin@sip.dev.inmarsat.com;tag=533cb9e91f4b999cf76861cbb9ed54e d >-79e5, > > >>code=202 >> >>Jul 16 17:20:01 sip /usr/sbin/ser[20187]: ERROR: udp_send: >>sendto(sock,0xbd70f700,671,0,0xbd70e1dc,16): Invalid argument(22) >> >>Jul 16 17:20:01 sip /usr/sbin/ser[20187]: CRITICAL: invalid >>sendtoparameters one possible reason is the server is bound to >>localhost and attempts to send to the net >> >> >> >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >Daniel > > > >>Jul 16 17:20:01 sip /usr/sbin/ser[20187]: msg_send: ERROR: udp_send >> >> >failed > > >>Jul 16 17:20:01 sip /usr/sbin/ser[20187]: ERROR: t_forward_nonack: >>sending request failed >> >>Jul 16 17:20:01 sip /usr/sbin/ser[20187]: ACC: transaction answered: >>method=MESSAGE, i-uri=sip:admin@161.30.94.68, >>o-uri=sip:admin@81.86.136.86:5060, call_id=7971f97d-0(a)161.30.94.68, >> >> >> >from=sip:sip_registrar@161.30.94.68;tag=533cb9e91f4b999cf76861cbb9ed54e d >-8a85, > > >>code=477 >> >>Any ideas? >> >>Many thanks again, and thanks for a brilliant list! >> >>Dave >> >>---------------------------------------------------------------------- - >> >> >- > > >>_______________________________________________ >>Serusers mailing list >>serusers(a)lists.iptel.org >>http://lists.iptel.org/mailman/listinfo/serusers >> >> >> >> > > > > >_______________________________________________ >Serusers mailing list >serusers(a)lists.iptel.org >http://lists.iptel.org/mailman/listinfo/serusers > > >

2 1

RE: [Serusers] Problem with messages + msilo
by Dave Bath 16 Jul '04

16 Jul '04

I don't know! I have perhaps misunderstood... it is not explicitly bound to anything. It is a single machine with a single network card with a single external Ip address? D -----Original Message----- From: Daniel-Constantin Mierla [mailto:daniel@iptel.org] Sent: 16 July 2004 22:16 To: Dave Bath Cc: serusers(a)lists.iptel.org Subject: Re: [Serusers] Problem with messages + msilo Hello, there is a self explanatory error message -- is it the case? On 07/16/04 18:26, Dave Bath wrote: > Hey guys, > > I have been battling with msilo, and the routing logic. It finally > looks like it might be beginning to get there, (ser actually restarts > now!) lol, but I have a problem when I try and send a message. > > I am using the serweb utility to try and send to "sip:admin@<ip>" and > it reports "message accepted for delivery"... but I don't receive it. > Checking the log shows; > > Jul 16 17:20:01 sip /usr/sbin/ser[20227]: MSILO: the downstream UA > does not support MESSAGE requests ... > > Jul 16 17:20:01 sip /usr/sbin/ser[20227]: ACC: transaction answered: > method=MESSAGE, i-uri=sip:admin@161.30.94.68, > o-uri=sip:admin@81.86.136.86:5060, call_id=7971f97d-0(a)127.0.0.1, > from=sip:admin@sip.dev.inmarsat.com;tag=533cb9e91f4b999cf76861cbb9ed54ed -79e5, > code=202 > > Jul 16 17:20:01 sip /usr/sbin/ser[20187]: ERROR: udp_send: > sendto(sock,0xbd70f700,671,0,0xbd70e1dc,16): Invalid argument(22) > > Jul 16 17:20:01 sip /usr/sbin/ser[20187]: CRITICAL: invalid > sendtoparameters one possible reason is the server is bound to > localhost and attempts to send to the net > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Daniel > Jul 16 17:20:01 sip /usr/sbin/ser[20187]: msg_send: ERROR: udp_send failed > > Jul 16 17:20:01 sip /usr/sbin/ser[20187]: ERROR: t_forward_nonack: > sending request failed > > Jul 16 17:20:01 sip /usr/sbin/ser[20187]: ACC: transaction answered: > method=MESSAGE, i-uri=sip:admin@161.30.94.68, > o-uri=sip:admin@81.86.136.86:5060, call_id=7971f97d-0(a)161.30.94.68, > from=sip:sip_registrar@161.30.94.68;tag=533cb9e91f4b999cf76861cbb9ed54ed -8a85, > code=477 > > Any ideas? > > Many thanks again, and thanks for a brilliant list! > > Dave > >----------------------------------------------------------------------- - > >_______________________________________________ >Serusers mailing list >serusers(a)lists.iptel.org >http://lists.iptel.org/mailman/listinfo/serusers > >

2 1

← Newer
1
...
23
24
25
26
27
28
29
...
45
Older →

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