sr-users April 2004

sr-users@lists.kamailio.org

138 participants
266 discussions

[Serusers] Asterisk/Digium as PSTN gateway and SER as backend soft switch?
by Tony Lum 12 Jul '04

12 Jul '04

Hi, Has any one done using Asterisk/Digium T1 card as PSTN gateway, and SER as the backend soft switch? I am looking to install Asterisk boxes in a few cities to act as PSTN gateways and using SER to accept these calls. SER will have to communicate with other long distance carriers to allow world wide calling. Will this combination work? I like to know your comments or suggestions on this combination. thanks Tony Lum

9 14

[Serusers] call logs
by Adrian Georgescu 04 May '04

04 May '04

You have several choices (like always on Unix): 1. Do like this: if (method=="INVITE") { # save messages in mysql for CDRTool exec_msg("/etc/ser/sertrace.py; exit 1"); }; Make your own script to replace /etc/ser/sertrace.py You can log the whole SIP packet from STDIN to mysql and index it by environment variable set by SER (SIP_HF_CALLID). To scale it up a bit you demonize the logger to reuse only one mysql connection. 2. Log all SIP packets to a log file with a script like this one: <<<<<<<<<<<<<<<<<<<<<<<<<<<< #!/bin/sh # # chkconfig: 2345 20 80 # description: controls execution of SIP sniffer # processname: ng NAME=ngrep OPTIONS="-L -d bond0 -t port 5060" BIN=/usr/bin/ngrep ROTATE=/usr/sbin/rotatelogs RETVAL=0 # See how we were called. case "$1" in start) killall $NAME echo -n "Starting SIP sniffer: " $BIN $OPTIONS 2>&1 | $ROTATE /var/log/ser/trace/sip 86400 & RETVAL=$? echo "ngrep." ;; stop) echo -n "Stopping SIP ngrep: " killall $NAME RETVAL=$? echo "done." ;; restart) #$0 stop $0 start RETVAL=$? ;; *) echo "Usage: $0 {start|stop|restart}" exit 1 esac exit $RETVAL <<<<<<<<<<<<<<<<<<<<<<<< -- Adrian How to get the call log and registration request in a different file other that /var/log/messages. Also, can i get some more details on autherisation and accountingpackets. Rt now, iam getting only details given below. ACC: transaction answered: method=BY E, i-uri=sip:12334 at 10.10.0.1, o-uri=sip:12334 at 10.10.0.1, call_id =4F6F069B-4BF4-4CC7-B99C-4E24F0E2C667 at 192.168.10.154, from=Manu Sip <sip:manu at s ip.test.net>;tag=2654486816, code=200 thank you. MANU.

2 1

[Serusers] using voicemail
by Andrea Bondavalli 03 May '04

03 May '04

Hi all, I am configuring SER in order to use the SEMS's voicemail when one of my subscribed users is not avaiable or when all the INVITEs to their contacts fail (fork). I'am using the following configuration: route { .... if (isflagset(4)) { /*voicemail enabled*/ t_on_failure("1"); } if (!t_relay()) { sl_reply_error(); break; } } failure_route[1] { t_reply("100","Trying -- going to voicemail"); if (method=="INVITE" || method=="REFER") { log("**************** vm start - begin ******************\n"); log("**************** voicemail ******************\n"); if(!vm("/tmp/am_fifo","voicemail")){ log("could not contact the answer machine\n"); t_reply("500","could not contact the answer machine"); }; log("**************** vm start - end ******************\n"); } else if (method=="BYE") { log("**************** vm end - begin ******************\n"); log("**************** voicemail ******************\n"); if(!vm("/tmp/am_fifo","bye")){ log("could not contact the answer machine\n"); t_reply("500","could not contact the answer machine"); }; log("**************** vm end - end ******************\n"); }; } ... This works fine when the system calls a user's contact whose username part matches the subscribed user name. Unfortunately, if the system tries to reach such a contact at a phone number (using a gateway) the result is that SEMS reports: "Error: 404 voicemail: no email address for user 034823213213." Can you help me ? Best regards, Andrea

2 4

[Serusers] PSTN termination
by radan 30 Apr '04

30 Apr '04

Hi ! I have a problem with correct accounting for calls to the PSTN SIP UA implemented inside gateway (Mediatrix 2402 ) sends ACK to SER even if the connection wasn't estabilished (no answer or reject by second site). in this way I have a few second in my stats for not estabilished connections. Where is problem ? Inside SER config, gateway config or PBX config ?? How do you resolve this problem ? Thanks Andrzej

2 1

[Serusers] Call drops with 60 sec and Buffer size exceeded message
by Jadylson Bomfim 30 Apr '04

30 Apr '04

Hi guys, I was create a script to route some kinds of routes calls to PSTN ( like that ). So after 59 sec. it is droped. Someone can help me ? Thank you all for attention and kindness in advance. Jadylson Bomfim if (uri=~"sip:0[0-9]*@.*") { route(6); break; }; route[6] { setflag(1); if (uri=~"^sip:0[1-9]*@") { strip(1); prefix("01155"); rewritehostport("ip address:5060"); acc_rad_request("Saindo Para PSTN no Brasil"); if (method=="INVITE" && search("User-Agent: snom")) { replace("100rel, ", ""); }; append_hf("P-hint: GATEWAY\r\n"); # use UDP to guarantee well-known sender port (TCP ephemeral) t_relay_to_udp("ip address","5060"); } else { if (uri=~"^sip:00[0-9][0-9]*@") { # ... forward to gateways then; #Cheque se inicia com 00 if (uri=~"^sip:00") { # strip the leading "1" strip(2); prefix("011"); # if you have passed through all the checks, let your call go to GW! rewritehostport("ip address:5060"); # snom conditioner if (method=="INVITE" && search("User-Agent: snom")) { replace("100rel, ", ""); }; append_hf("P-hint: GATEWAY\r\n"); # use UDP to guarantee well-known sender port (TCP ephemeral) t_relay_to_udp("ip address","5060"); }; } else { if (uri=~"^sip:001*@") { # ... forward to gateways then; #Cheque se inicia com 00 if (uri=~"^sip:00") { # strip the leading "1" strip(2); # if you have passed through all the checks, let your call go to GW! rewritehostport("ip address:5060"); # snom conditioner if (method=="INVITE" && search("User-Agent: snom")) { replace("100rel, ", ""); }; append_hf("P-hint: GATEWAY\r\n"); # use UDP to guarantee well-known sender port (TCP ephemeral) t_relay_to_udp("ip address","5060"); }; }; }; }; } Jadylson da Rocha Passos Bomfim Redevox Telecom Uberlandia +55 34 3234-7813 São Paulo +55 11 5055-6888 Móvel +55 34 9103-6854 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.643 / Virus Database: 411 - Release Date: 25/3/2004

1 0

[Serusers] Problem with registration of the SIP agent
by bbleuez＠numericable.fr 30 Apr '04

30 Apr '04

Hello, I am Benoit and I am working on the SER and the server and the database is working well. The problem is when I try to registrer SIP agent, the error message is "Error 483:" Too Many Hops". In the file ser.cfg there is a function mf_process_maxforward_header("10"), and the problem is that I don't know where is this function and how does it testing the max forward header because the SIP agent that I use set this field to 70. Kind regards Benoit

4 4

[Serusers] problem with BYE
by Vitaly Nikolaev 30 Apr '04

30 Apr '04

Hi all, I have very strange problem with SER. I am making incoming call from PSTN to SER, then number translation (exec_dset) from 12124051759 -> 250000007 And then it hitting my ATA (same with motorolla, innomedia) When I then hung up on ATA side it sends BYE (which goes as loose routing) to SER -> CISCO, CISCO answer OK to SER then to ATA but ATA looks like does not like this OK... sending BYE again and again I have attached config to the letter.. pleas look at it and may be you will have some correction PS: Absolutely same problem I have with incoming call via TCP from another provider Thank you! [root@ser etc]# ngrepcr -q 12124051759 U 209.227.182.44:51835 -> 209.227.182.43:5060 INVITE sip:12124051759@209.227.182.43:5060 SIP/2.0 Via: SIP/2.0/UDP 209.227.182.44:5060 From: <sip:2126882781@209.227.182.44>;tag=DC7456A0-3FE To: <sip:12124051759@209.227.182.43> Date: Fri, 30 Apr 2004 15:30:12 GMT Call-ID: 1B72FBC0-99F211D8-AFEAEAA0-F4703A0(a)209.227.182.44 Supported: timer,100rel Min-SE: 1800 Cisco-Guid: 459440422-2582778328-2951146144-256312224 User-Agent: Cisco-SIPGateway/IOS-12.x Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO CSeq: 101 INVITE Max-Forwards: 6 Remote-Party-ID: <sip:2126882781@209.227.182.44>;party=calling;screen=yes;privacy=off Timestamp: 1083339012 Contact: <sip:2126882781@209.227.182.44:5060> Expires: 180 Allow-Events: telephone-event Content-Type: application/sdp Content-Length: 426 v=0 o=CiscoSystemsSIP-GW-UserAgent 2183 5028 IN IP4 209.227.182.44 s=SIP Call c=IN IP4 209.227.182.44 t=0 0 m=audio 19266 RTP/AVP 18 4 0 100 101 19 c=IN IP4 209.227.182.44 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=yes a=rtpmap:4 G723/8000 a=fmtp:4 annexa=no a=rtpmap:0 PCMU/8000 a=rtpmap:100 X-NSE/8000 a=fmtp:100 192-194 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtpmap:19 CN/8000 a=direction:active U 209.227.182.43:5060 -> 209.227.182.44:5060 SIP/2.0 100 trying -- your call is important to us Via: SIP/2.0/UDP 209.227.182.44:5060 From: <sip:2126882781@209.227.182.44>;tag=DC7456A0-3FE To: <sip:12124051759@209.227.182.43> Call-ID: 1B72FBC0-99F211D8-AFEAEAA0-F4703A0(a)209.227.182.44 CSeq: 101 INVITE Server: Sip EXpress router (0.8.12-tcp_nonb (i386/linux)) Content-Length: 0 Warning: 392 209.227.182.43:5060 "Noisy feedback tells: pid=6791 req_src_ip=209.227.182.44 req_src_port=51835 in_uri=sip:1212 4051759@209.227.182.43:5060 out_uri=sip:250000007@216.236.137.226:1102;user=phone;transport=udp via_cnt==1" U 209.227.182.43:5060 -> 216.236.137.226:1102 INVITE sip:250000007@216.236.137.226:1102;user=phone;transport=udp SIP/2.0 Record-Route: <sip:12124051759@209.227.182.43;ftag=DC7456A0-3FE;lr=on> Via: SIP/2.0/UDP 209.227.182.43;branch=z9hG4bK8198.2b7612d2.0 Via: SIP/2.0/UDP 209.227.182.44:5060 From: <sip:2126882781@209.227.182.44>;tag=DC7456A0-3FE To: <sip:12124051759@209.227.182.43> Date: Fri, 30 Apr 2004 15:30:12 GMT Call-ID: 1B72FBC0-99F211D8-AFEAEAA0-F4703A0(a)209.227.182.44 Supported: timer,100rel Min-SE: 1800 Cisco-Guid: 459440422-2582778328-2951146144-256312224 User-Agent: Cisco-SIPGateway/IOS-12.x Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO CSeq: 101 INVITE Max-Forwards: 5 Remote-Party-ID: <sip:2126882781@209.227.182.44>;party=calling;screen=yes;privacy=off Timestamp: 1083339012 Contact: <sip:2126882781@209.227.182.44:5060> Expires: 180 Allow-Events: telephone-event Content-Type: application/sdp Content-Length: 426 P-hint: request forced to rtp proxy v=0 o=CiscoSystemsSIP-GW-UserAgent 2183 5028 IN IP4 209.227.182.44 s=SIP Call c=IN IP4 209.227.182.43 t=0 0 m=audio 55824 RTP/AVP 18 4 0 100 101 19 c=IN IP4 209.227.182.43 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=yes a=rtpmap:4 G723/8000 a=fmtp:4 annexa=no a=rtpmap:0 PCMU/8000 a=rtpmap:100 X-NSE/8000 a=fmtp:100 192-194 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtpmap:19 CN/8000 a=direction:active U 216.236.137.226:1102 -> 209.227.182.43:5060 SIP/2.0 100 Trying Via: SIP/2.0/UDP 209.227.182.43;branch=z9hG4bK8198.2b7612d2.0 Via: SIP/2.0/UDP 209.227.182.44:5060 From: <sip:2126882781@209.227.182.44>;tag=DC7456A0-3FE To: <sip:12124051759@209.227.182.43>;tag=3720024524 Call-ID: 1B72FBC0-99F211D8-AFEAEAA0-F4703A0(a)209.227.182.44 CSeq: 101 INVITE Timestamp: 1083339012 Server: Cisco ATA 186 v3.0.0 atasip (031210A) Allow: ACK, BYE, CANCEL, INVITE, NOTIFY, OPTIONS, REFER, REGISTER Content-Length: 0 U 216.236.137.226:1102 -> 209.227.182.43:5060 SIP/2.0 180 Ringing Via: SIP/2.0/UDP 209.227.182.43;branch=z9hG4bK8198.2b7612d2.0 Via: SIP/2.0/UDP 209.227.182.44:5060 From: <sip:2126882781@209.227.182.44>;tag=DC7456A0-3FE To: <sip:12124051759@209.227.182.43>;tag=3720024524 Call-ID: 1B72FBC0-99F211D8-AFEAEAA0-F4703A0(a)209.227.182.44 CSeq: 101 INVITE Timestamp: 1083339012 Server: Cisco ATA 186 v3.0.0 atasip (031210A) Allow: ACK, BYE, CANCEL, INVITE, NOTIFY, OPTIONS, REFER, REGISTER Content-Length: 0 U 209.227.182.43:5060 -> 209.227.182.44:5060 SIP/2.0 180 Ringing Via: SIP/2.0/UDP 209.227.182.44:5060 From: <sip:2126882781@209.227.182.44>;tag=DC7456A0-3FE To: <sip:12124051759@209.227.182.43>;tag=3720024524 Call-ID: 1B72FBC0-99F211D8-AFEAEAA0-F4703A0(a)209.227.182.44 CSeq: 101 INVITE Timestamp: 1083339012 Server: Cisco ATA 186 v3.0.0 atasip (031210A) Allow: ACK, BYE, CANCEL, INVITE, NOTIFY, OPTIONS, REFER, REGISTER Content-Length: 0 P-hint: fixed NAT contact for response U 216.236.137.226:1102 -> 209.227.182.43:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 209.227.182.43;branch=z9hG4bK8198.2b7612d2.0 Via: SIP/2.0/UDP 209.227.182.44:5060 Record-Route: <sip:12124051759@209.227.182.43;ftag=DC7456A0-3FE;lr=on> From: <sip:2126882781@209.227.182.44>;tag=DC7456A0-3FE To: <sip:12124051759@209.227.182.43>;tag=3720024524 Call-ID: 1B72FBC0-99F211D8-AFEAEAA0-F4703A0(a)209.227.182.44 CSeq: 101 INVITE Timestamp: 1083339012 Contact: <sip:250000007@172.30.200.59:5060;user=phone;transport=udp> Server: Cisco ATA 186 v3.0.0 atasip (031210A) Allow: ACK, BYE, CANCEL, INVITE, NOTIFY, OPTIONS, REFER, REGISTER Content-Length: 204 Content-Type: application/sdp v=0 o=250000007 85231 85231 IN IP4 172.30.200.59 s=ATA186 Call c=IN IP4 172.30.200.59 t=0 0 m=audio 16386 RTP/AVP 18 101 a=rtpmap:18 G729/8000/1 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 U 209.227.182.43:5060 -> 209.227.182.44:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 209.227.182.44:5060 Record-Route: <sip:12124051759@209.227.182.43;ftag=DC7456A0-3FE;lr=on> From: <sip:2126882781@209.227.182.44>;tag=DC7456A0-3FE To: <sip:12124051759@209.227.182.43>;tag=3720024524 Call-ID: 1B72FBC0-99F211D8-AFEAEAA0-F4703A0(a)209.227.182.44 CSeq: 101 INVITE Timestamp: 1083339012 Contact: <sip:250000007@216.236.137.226:1102;user=phone;transport=udp> Server: Cisco ATA 186 v3.0.0 atasip (031210A) Allow: ACK, BYE, CANCEL, INVITE, NOTIFY, OPTIONS, REFER, REGISTER Content-Length: 205 Content-Type: application/sdp P-hint: fixed NAT contact for response P-hint: response forced to rtp proxy v=0 o=250000007 85231 85231 IN IP4 172.30.200.59 s=ATA186 Call c=IN IP4 209.227.182.43 t=0 0 m=audio 55824 RTP/AVP 18 101 a=rtpmap:18 G729/8000/1 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 U 209.227.182.44:57102 -> 209.227.182.43:5060 ACK sip:12124051759@209.227.182.43:5060;ftag=DC7456A0-3FE;lr=on SIP/2.0 Via: SIP/2.0/UDP 209.227.182.44:5060 From: <sip:2126882781@209.227.182.44>;tag=DC7456A0-3FE To: <sip:12124051759@209.227.182.43>;tag=3720024524 Date: Fri, 30 Apr 2004 15:30:12 GMT Call-ID: 1B72FBC0-99F211D8-AFEAEAA0-F4703A0(a)209.227.182.44 Route: <sip:250000007@216.236.137.226:1102;user=phone;transport=udp> Max-Forwards: 6 Content-Length: 0 CSeq: 101 ACK U 209.227.182.43:5060 -> 216.236.137.226:1102 ACK sip:250000007@216.236.137.226:1102;user=phone;transport=udp SIP/2.0 Via: SIP/2.0/UDP 209.227.182.43;branch=0 Via: SIP/2.0/UDP 209.227.182.44:5060 From: <sip:2126882781@209.227.182.44>;tag=DC7456A0-3FE To: <sip:12124051759@209.227.182.43>;tag=3720024524 Date: Fri, 30 Apr 2004 15:30:12 GMT Call-ID: 1B72FBC0-99F211D8-AFEAEAA0-F4703A0(a)209.227.182.44 Max-Forwards: 5 Content-Length: 0 CSeq: 101 ACK U 216.236.137.226:1102 -> 209.227.182.43:5060 BYE sip:12124051759@209.227.182.43 SIP/2.0 Route: <sip:2126882781@209.227.182.44> Via: SIP/2.0/UDP 172.30.200.59:5060 From: sip:12124051759@209.227.182.43;tag=3720024524 To: sip:2126882781@209.227.182.44;tag=DC7456A0-3FE Call-ID: 1B72FBC0-99F211D8-AFEAEAA0-F4703A0(a)209.227.182.44 CSeq: 1 BYE User-Agent: Cisco ATA 186 v3.0.0 atasip (031210A) Content-Length: 0 U 209.227.182.43:5060 -> 209.227.182.44:5060 BYE sip:2126882781@209.227.182.44 SIP/2.0 Max-Forwards: 10 Via: SIP/2.0/UDP 209.227.182.43;branch=z9hG4bKb7a6.78fba574.0 Via: SIP/2.0/UDP 172.30.200.59:5060;rport=1102;received=216.236.137.226 From: sip:12124051759@209.227.182.43;tag=3720024524 To: sip:2126882781@209.227.182.44;tag=DC7456A0-3FE Call-ID: 1B72FBC0-99F211D8-AFEAEAA0-F4703A0(a)209.227.182.44 CSeq: 1 BYE User-Agent: Cisco ATA 186 v3.0.0 atasip (031210A) Content-Length: 0 U 209.227.182.44:5060 -> 209.227.182.43:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 209.227.182.43;branch=z9hG4bKb7a6.78fba574.0,SIP/2.0/UDP 172.30.200.59:5060;rport=1102;received=216.236.137.2 26 From: <sip:12124051759@209.227.182.43>;tag=3720024524 To: <sip:2126882781@209.227.182.44>;tag=DC7456A0-3FE Date: Fri, 30 Apr 2004 15:30:21 GMT Call-ID: 1B72FBC0-99F211D8-AFEAEAA0-F4703A0(a)209.227.182.44 Server: Cisco-SIPGateway/IOS-12.x Content-Length: 0 CSeq: 1 BYE U 209.227.182.43:5060 -> 216.236.137.226:1102 SIP/2.0 200 OK Via: SIP/2.0/UDP 172.30.200.59:5060;rport=1102;received=216.236.137.226 From: <sip:12124051759@209.227.182.43>;tag=3720024524 To: <sip:2126882781@209.227.182.44>;tag=DC7456A0-3FE Date: Fri, 30 Apr 2004 15:30:21 GMT Call-ID: 1B72FBC0-99F211D8-AFEAEAA0-F4703A0(a)209.227.182.44 Server: Cisco-SIPGateway/IOS-12.x Content-Length: 0 CSeq: 1 BYE U 216.236.137.226:1102 -> 209.227.182.43:5060 BYE sip:12124051759@209.227.182.43 SIP/2.0 Route: <sip:2126882781@209.227.182.44> Via: SIP/2.0/UDP 172.30.200.59:5060 From: sip:12124051759@209.227.182.43;tag=3720024524 To: sip:2126882781@209.227.182.44;tag=DC7456A0-3FE Call-ID: 1B72FBC0-99F211D8-AFEAEAA0-F4703A0(a)209.227.182.44 CSeq: 1 BYE User-Agent: Cisco ATA 186 v3.0.0 atasip (031210A) Content-Length: 0 U 209.227.182.43:5060 -> 216.236.137.226:1102 SIP/2.0 200 OK Via: SIP/2.0/UDP 172.30.200.59:5060;rport=1102;received=216.236.137.226 From: <sip:12124051759@209.227.182.43>;tag=3720024524 To: <sip:2126882781@209.227.182.44>;tag=DC7456A0-3FE Date: Fri, 30 Apr 2004 15:30:21 GMT Call-ID: 1B72FBC0-99F211D8-AFEAEAA0-F4703A0(a)209.227.182.44 Server: Cisco-SIPGateway/IOS-12.x Content-Length: 0 CSeq: 1 BYE U 216.236.137.226:1102 -> 209.227.182.43:5060 BYE sip:12124051759@209.227.182.43 SIP/2.0 Route: <sip:2126882781@209.227.182.44> Via: SIP/2.0/UDP 172.30.200.59:5060 From: sip:12124051759@209.227.182.43;tag=3720024524 To: sip:2126882781@209.227.182.44;tag=DC7456A0-3FE Call-ID: 1B72FBC0-99F211D8-AFEAEAA0-F4703A0(a)209.227.182.44 CSeq: 1 BYE User-Agent: Cisco ATA 186 v3.0.0 atasip (031210A) Content-Length: 0 U 209.227.182.43:5060 -> 216.236.137.226:1102 SIP/2.0 200 OK Via: SIP/2.0/UDP 172.30.200.59:5060;rport=1102;received=216.236.137.226 From: <sip:12124051759@209.227.182.43>;tag=3720024524 To: <sip:2126882781@209.227.182.44>;tag=DC7456A0-3FE Date: Fri, 30 Apr 2004 15:30:21 GMT Call-ID: 1B72FBC0-99F211D8-AFEAEAA0-F4703A0(a)209.227.182.44 Server: Cisco-SIPGateway/IOS-12.x Content-Length: 0 CSeq: 1 BYE U 216.236.137.226:1102 -> 209.227.182.43:5060 BYE sip:12124051759@209.227.182.43 SIP/2.0 Route: <sip:2126882781@209.227.182.44> Via: SIP/2.0/UDP 172.30.200.59:5060 From: sip:12124051759@209.227.182.43;tag=3720024524 To: sip:2126882781@209.227.182.44;tag=DC7456A0-3FE Call-ID: 1B72FBC0-99F211D8-AFEAEAA0-F4703A0(a)209.227.182.44 CSeq: 1 BYE User-Agent: Cisco ATA 186 v3.0.0 atasip (031210A) Content-Length: 0 U 209.227.182.43:5060 -> 216.236.137.226:1102 SIP/2.0 200 OK Via: SIP/2.0/UDP 172.30.200.59:5060;rport=1102;received=216.236.137.226 From: <sip:12124051759@209.227.182.43>;tag=3720024524 To: <sip:2126882781@209.227.182.44>;tag=DC7456A0-3FE Date: Fri, 30 Apr 2004 15:30:21 GMT Call-ID: 1B72FBC0-99F211D8-AFEAEAA0-F4703A0(a)209.227.182.44 Server: Cisco-SIPGateway/IOS-12.x Content-Length: 0 CSeq: 1 BYE U 216.236.137.226:1102 -> 209.227.182.43:5060 BYE sip:12124051759@209.227.182.43 SIP/2.0 Route: <sip:2126882781@209.227.182.44> Via: SIP/2.0/UDP 172.30.200.59:5060 From: sip:12124051759@209.227.182.43;tag=3720024524 To: sip:2126882781@209.227.182.44;tag=DC7456A0-3FE Call-ID: 1B72FBC0-99F211D8-AFEAEAA0-F4703A0(a)209.227.182.44 CSeq: 1 BYE User-Agent: Cisco ATA 186 v3.0.0 atasip (031210A) Content-Length: 0 U 209.227.182.43:5060 -> 209.227.182.44:5060 BYE sip:2126882781@209.227.182.44 SIP/2.0 Max-Forwards: 10 Via: SIP/2.0/UDP 209.227.182.43;branch=z9hG4bKb7a6.88fba574.0 Via: SIP/2.0/UDP 172.30.200.59:5060;rport=1102;received=216.236.137.226 From: sip:12124051759@209.227.182.43;tag=3720024524 To: sip:2126882781@209.227.182.44;tag=DC7456A0-3FE Call-ID: 1B72FBC0-99F211D8-AFEAEAA0-F4703A0(a)209.227.182.44 CSeq: 1 BYE User-Agent: Cisco ATA 186 v3.0.0 atasip (031210A) Content-Length: 0 U 209.227.182.44:5060 -> 209.227.182.43:5060 SIP/2.0 481 Call Leg/Transaction Does Not Exist Via: SIP/2.0/UDP 209.227.182.43;branch=z9hG4bKb7a6.88fba574.0,SIP/2.0/UDP 172.30.200.59:5060;rport=1102;received=216.236.137.2 26 From: sip:12124051759@209.227.182.43;tag=3720024524 To: sip:2126882781@209.227.182.44;tag=DC7456A0-3FE Call-ID: 1B72FBC0-99F211D8-AFEAEAA0-F4703A0(a)209.227.182.44 CSeq: 1 BYE Content-Length: 0 U 209.227.182.43:5060 -> 216.236.137.226:1102 SIP/2.0 481 Call Leg/Transaction Does Not Exist Via: SIP/2.0/UDP 172.30.200.59:5060;rport=1102;received=216.236.137.226 From: sip:12124051759@209.227.182.43;tag=3720024524 To: sip:2126882781@209.227.182.44;tag=DC7456A0-3FE Call-ID: 1B72FBC0-99F211D8-AFEAEAA0-F4703A0(a)209.227.182.44 CSeq: 1 BYE Content-Length: 0

2 1

[Serusers] source address of outbound tcp connections
by Alexander Mayrhofer 30 Apr '04

30 Apr '04

Hi, i'm trying to use t_relay_to_tcp() on a machine with several IP addresses on just one ethernet interface. SER seems not to set the source address of the TCP connection, so the OS (more or less) randomly chooses one of the virtual addresses on the interface, which makes in turn filtering based on source ip address a B<- (pain in the a** ;). Is there any way to configure SER 0.8.12 to use a specific source address in outbound tcp connections (it works for udp, though)? thanks axelm

2 1

[Serusers] setuid and setgid
by Zeus Ng 30 Apr '04

30 Apr '04

In the main.c file, there is a comment saying that 'we need to open fifo before do_suid() and start the fifo server after all the socket are initialized, to inherit them'. I'm wondering why SER has to do it like that. Can't SER lower its privileges first (do_suid), then open fifo and start the fifo server? The reason being that I want to run SER with an unprivileged user. With the current implementation, the fifo file will be created by root which is not accessible to anyone else. Unless I change the fifo_mode to 0666, which I don't want to, I can't make SER more secure and yet accessible. I've tried to move the do_suid() before init_fifo_server() and compile successfully. The server can run as ser:apache with fifo_mode set to 0660. That way, my Apache server can talk to SER yet limiting other user directly talking to SER via serctl. However, I would like to know the reason why it is implemented the way it is now. Maybe I'm not insightful to see the obviously reason. Also, will unix_sock get something like unix_sock_mode in the future? Zeus Ng ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, you are prohibited from reading, copying, distributing and using the information. Please contact the sender immediately by return email and destroy the original message. ******************************************************************

2 1

Re: [Serusers] rewrite & ACK forwarding problem
by lgfausak＠august.net 30 Apr '04

30 Apr '04

I have also had problems with getting the ACK back. I don't completely understand your configuration, you must allow for packets going both directions, right? Here is my config : route { # check to see if the message has been around too long # probably means that it is looping # if (!mf_process_maxfwd_header("10")) { log("LOG: Too many hops\n"); sl_send_reply("483","Too Many Hops"); break; }; # # make sure the length of the message isn't too long! # if (len_gt( max_len )) { sl_send_reply("513", "Wow -- Message too large"); break; }; # # do the loose-routing thing, this is important! # if(loose_route()) { log(1,"doing top loose route"); t_relay(); break; }; # this is where I was dropping the ACKS. # I was simply dropping these, but they must be relayed # because they can be ACKs if(!(uri==myself)) { if(!t_relay()) { sl_reply_error(); break; }; break; }; This gets the ACKs through for me. By the way, I have this configured with Cisco ATAs, version 2.16. ---greg > >I have the same problem and posed it to the group yesterday ([Serusers] >Ignored 200 OK message.) So far the only workaround that I have found is to >use the rules in my gateway to rewrite the dialed digits before sending them >to the PSTN PRI, thus leaving the origianl URI intact for SIP >communications. > >One person told me that this is a bug in the Cisco ATA, but it happens on my >IPDialog phones also. It seems to me that the INVITE is being processed by >the SER dial rules and is rewritten, but the ACK is not. > >Sean >_______________________________________________ > >Sean Robertson > >NETXUSA >p. 800-289-6389 >f. 864-233-4344 "Ask me about Voice over IP." >http://www.netxusa.com/ > >----- Original Message ----- >From: "Alexander Mayrhofer" <axelm(a)nic.at> >To: <serusers(a)lists.iptel.org> >Sent: Friday, June 27, 2003 12:15 PM >Subject: [Serusers] rewrite & ACK forwarding problem > > >> >> Hi, >> >> we're running SER together with a PSTN Gateway. Before a call get's >> forwarded to the gateway, we are rewriting the request URI to make >> rewriting on the GW as simple as possible: >> >> route { >> ... >> strip(3); # +43xxx -> xxx >> prefix("0"); # xxx -> 0xxx >> rewritehostport(xxx.xxx.xxx.xxx, 5060); # request to gateway >> route(1); >> break; >> ... >> >> SIP call flow looks like (record route enabled): >> >> (1) phone -> SER >> INVITE sip:*43699xxxxxxxx@nic.at43.at SIP/2.0 >> >> (2) SER -> phone >> SIP/2.0 100 trying -- your call is important to us >> >> (3) SER -> GW >> INVITE sip:0699xxxxxxxx@xx.xx.xx.xx:5060 SIP/2.0 >> >> (4) GW -> SER >> SIP/2.0 100 Trying >> >> (5) GW -> SER >> SIP/2.0 183 Session Progress >> >> (6) SER -> phone >> SIP/2.0 183 Session Progress >> >> (7) GW -> SER >> SIP/2.0 180 Ringing >> >> (8) SER -> phone >> SIP/2.0 180 Ringing >> >> (9) GW -> SER >> SIP/2.0 200 OK >> Contact: <sip:0699xxxxxxxx@xx.xx.xx.xx:5060> >> >> (10) SER -> phone >> SIP/2.0 200 OK >> Contact: <sip:0699xxxxxxx@xx.xx.xx.xx:5060> >> >> [ call established, we can talk, but ... ] >> >> (11) phone -> SER >> ACK sip:0699xxxxxxxx@xx.xx.xx.xx:5060 SIP/2.0 >> >> --> Here starts the problem. That ACK (11) never gets forwarded to the >> Gateway, so after a few seconds, the GW starts over at (9). Those three >> packets (9-11) repeat a few times until GW runs into a timeout and drops >> the call. >> >> I have the impression that SER can't match the packet to the previous >> requests because of the rewritten URI. Is that correct? >> >> The only output at debug level 3 is: >> >> Warning: sl_send_reply: I won't send a reply for ACK!! >> >> Is that a routing goof somewhere in our scripts or is that a more >> generic problem? Is the problem that the warning indicates somehow >> related to the fact that the ACK is not being forwarded? >> >> Help appreciated. >> >> cheers >> >> axelm >> >> _______________________________________________ >> 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 >

4 5

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