sr-users September 2004

sr-users@lists.kamailio.org

190 participants
382 discussions

[Serusers] NatHelper & Mediaproxy question.
by Ricardo Martinez 29 Sep '04

29 Sep '04

Hello list. I have reached a point where i need some advices and a little help. I'm using mediaproxy to solve the NAT'd client "problems" this module works fine, and solves all the scenarios that i'm interested but for i noticed i alway have to enable the mediaproxy, even for the calls between two clients with public.ip, this is a problem for me, i would expected that the media in this case goes directly between the endpoints. Mi first question is : Is this behaivor normal? Is that the way … [View More]

2 1

Re: [Serusers] RTP Proxy Error Compilation.
by David Simmons 29 Sep '04

29 Sep '04

have you run ./configure first? On Tuesday 28 September 2004 20:46, Ricardo Martinez wrote: > Hello. > I'm trying to compile the RTP proxy. I downloades the last version > from the CVS with : > > [root@sipproxy root]# cvs > -d:pserver:anonymous@cvs.ser.berlios.de:/cvsroot/ser co rtpproxy > > cvs server: Updating rtpproxy > U rtpproxy/Makefile.am > U rtpproxy/Makefile.in > U rtpproxy/README > U rtpproxy/README.remote > U rtpproxy/aclocal.m4 > U … [View More]

1 0

[Serusers] serweb click to dial
by Java Rockx 29 Sep '04

29 Sep '04

Hi all. I'm using ser 0.8.99-dev6 with serweb. I'm not sure which version of serweb this is but I checked it out of berlios today with this command: cvs -z3 -d:pserver:anonymous@cvs.serweb.berlios.de:/cvsroot/serweb co iptel Anyhow, my click-to-dial feature is not fully functional. When I click on an entry in the phonebook it rings my extension as it should, but when I go off hook the number I'm calling never rings. Here are the click-to-dial settings from <serweb>/config/config.php $… [View More]config->ctd_target="sip:699@68.90.50.100"; $config->ctd_uri="sip:699@68.90.50.100"; $config->ctd_from="sip:699@mycompany.com"; $config->ctd_outbound_proxy=""; Account 699 does not actually exist in my ser/subscriber table in MySQL. I'm very unclear on what these parameters should be set to. Also here is the ngrep output from my click-to-dial attempt. As you can see about half way down there is a REFER message but it seems to point to my Asterisk voice mail server (vm01.mycompany.com). Shouldn't this point to the person in my phone book that I'm calling? In this call sequence I called sip:1002@mycompany.com from sip:1000@mycompany.com by clicking on the 1002 phonebook entry. ### U 68.90.50.100:5060 -> 12.3.4.10:5060 INVITE sip:1001@12.3.4.10;user=phone SIP/2.0. Max-Forwards: 10. Record-Route: <sip:68.90.50.100;ftag=415a15814acb0;lr=on>. Via: SIP/2.0/UDP 68.90.50.100;branch=z9hG4bK25c5.95425785.0. Via: SIP/2.0/UDP 68.90.50.100;branch=z9hG4bK25c5.85425785.0. To: <sip:1001@mycompany.com>. From: <sip:699@mycompany.com>;tag=415a15814acb0. CSeq: 1 INVITE. Call-ID: 415a15814acb0.fifouacctd. Content-Length: 131. Contact: <sip:caller@68.90.50.100:5060>. Reject-Contact: *;automata="YES". Content-Type: application/sdp. . 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. # U 12.3.4.10:5060 -> 68.90.50.100:5060 SIP/2.0 100 trying. Via: SIP/2.0/UDP 68.90.50.100;branch=z9hG4bK25c5.95425785.0. Via: SIP/2.0/UDP 68.90.50.100;branch=z9hG4bK25c5.85425785.0. From: <sip:699@mycompany.com>;tag=415a15814acb0. To: <sip:1001@mycompany.com>. Call-ID: 415a15814acb0.fifouacctd. CSeq: 1 INVITE. User-Agent: Grandstream BT100 1.0.5.11. Warning: 399 12.3.4.10 "detected NAT type is full cone". Content-Length: 0. . # U 12.3.4.10:5060 -> 68.90.50.100:5060 SIP/2.0 180 ringing. Via: SIP/2.0/UDP 68.90.50.100;branch=z9hG4bK25c5.95425785.0. Via: SIP/2.0/UDP 68.90.50.100;branch=z9hG4bK25c5.85425785.0. Record-Route: <sip:68.90.50.100;ftag=415a15814acb0;lr=on>. From: <sip:699@mycompany.com>;tag=415a15814acb0. To: <sip:1001@mycompany.com>;tag=7a9a058a857c4aba. Call-ID: 415a15814acb0.fifouacctd. CSeq: 1 INVITE. User-Agent: Grandstream BT100 1.0.5.11. Warning: 399 12.3.4.10 "detected NAT type is full cone". Content-Length: 0. . ## U 12.3.4.10:5060 -> 68.90.50.100:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 68.90.50.100;branch=z9hG4bK25c5.95425785.0. Via: SIP/2.0/UDP 68.90.50.100;branch=z9hG4bK25c5.85425785.0. Record-Route: <sip:68.90.50.100;ftag=415a15814acb0;lr=on>. From: <sip:699@mycompany.com>;tag=415a15814acb0. To: <sip:1001@mycompany.com>;tag=7a9a058a857c4aba. Call-ID: 415a15814acb0.fifouacctd. CSeq: 1 INVITE. User-Agent: Grandstream BT100 1.0.5.11. Warning: 399 12.3.4.10 "detected NAT type is full cone". Contact: <sip:1001@12.3.4.10;user=phone>. Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE. Content-Type: application/sdp. Content-Length: 161. . v=0. o=1001 8000 8000 IN IP4 12.3.4.10. s=SIP Call. c=IN IP4 12.3.4.10. t=0 0. m=audio 5004 RTP/AVP 0. a=recvonly. a=rtpmap:0 PCMU/8000. a=ptime:20. # U 68.90.50.100:5060 -> 12.3.4.10:5060 ACK sip:1001@12.3.4.10;user=phone SIP/2.0. Max-Forwards: 10. Record-Route: <sip:68.90.50.100;ftag=415a15814acb0;lr=on>. Via: SIP/2.0/UDP 68.90.50.100;branch=0. Via: SIP/2.0/UDP 68.90.50.100;branch=z9hG4bK25c5.85425785.0. From: <sip:699@mycompany.com>;tag=415a15814acb0. Call-ID: 415a15814acb0.fifouacctd. To: <sip:1001@mycompany.com>;tag=7a9a058a857c4aba. CSeq: 1 ACK. Content-Length: 0. . # U 68.90.50.100:5060 -> 68.84.242.201:5060 REFER sip:1001@vm01.mycompany.com:5060;user=phone SIP/2.0. Max-Forwards: 10. Record-Route: <sip:68.90.50.100;ftag=415a15814acb0;lr=on>. Via: SIP/2.0/UDP 68.90.50.100;branch=0. Via: SIP/2.0/UDP 68.90.50.100;branch=z9hG4bKf4c5.16082cd7.0. To: <sip:1001@mycompany.com>;tag=7a9a058a857c4aba. From: <sip:699@mycompany.com>;tag=415a15814acb0. CSeq: 2 REFER. Call-ID: 415a15814acb0.fifouacctd. Content-Length: 0. Contact: <sip:caller@68.90.50.100:5060>. Referred-By: <sip:699@mycompany.com>. Refer-To: sip:1002@mycompany.com. . # U 68.84.242.201:5060 -> 68.90.50.100:5060 SIP/2.0 202 Accepted. Via: SIP/2.0/UDP 68.90.50.100;branch=0;received=68.90.50.100;rport=5060. Via: SIP/2.0/UDP 68.90.50.100;branch=z9hG4bKf4c5.16082cd7.0. Record-Route: <sip:68.90.50.100;ftag=415a15814acb0;lr=on>. From: <sip:699@mycompany.com>;tag=415a15814acb0. To: <sip:1001@mycompany.com>;tag=7a9a058a857c4aba. Call-ID: 415a15814acb0.fifouacctd. CSeq: 2 REFER. User-Agent: VoiceMail. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER. Contact: . Content-Length: 0. . ## U 68.90.50.100:5060 -> 68.84.242.201:5060 BYE sip:1001@vm01.mycompany.com:5060;user=phone SIP/2.0. Max-Forwards: 10. Record-Route: <sip:68.90.50.100;ftag=415a15814acb0;lr=on>. Via: SIP/2.0/UDP 68.90.50.100;branch=0. Via: SIP/2.0/UDP 68.90.50.100;branch=z9hG4bK05c5.3f0aaa06.0. To: <sip:1001@mycompany.com>;tag=7a9a058a857c4aba. From: <sip:699@mycompany.com>;tag=415a15814acb0. CSeq: 3 BYE. Call-ID: 415a15814acb0.fifouacctd. Content-Length: 0. Contact: <sip:caller@68.90.50.100:5060>. . # U 68.84.242.201:5060 -> 68.90.50.100:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 68.90.50.100;branch=0;received=68.90.50.100;rport=5060. Via: SIP/2.0/UDP 68.90.50.100;branch=z9hG4bK05c5.3f0aaa06.0. Record-Route: <sip:68.90.50.100;ftag=415a15814acb0;lr=on>. From: <sip:699@mycompany.com>;tag=415a15814acb0. To: <sip:1001@mycompany.com>;tag=7a9a058a857c4aba. Call-ID: 415a15814acb0.fifouacctd. CSeq: 3 BYE. User-Agent: VoiceMail. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER. Contact: . Content-Length: 0. . ########## U 12.3.4.10:5060 -> 68.90.50.100:5060 BYE sip:caller@68.90.50.100:5060 SIP/2.0. Via: SIP/2.0/UDP 12.3.4.10;branch=z9hG4bKbb2f53e68cca3b12. Route: <sip:68.90.50.100;ftag=415a15814acb0;lr=on>. From: <sip:1001@mycompany.com>;tag=7a9a058a857c4aba. To: <sip:699@mycompany.com>;tag=415a15814acb0. Contact: <sip:1001@12.3.4.10;user=phone>. Call-ID: 415a15814acb0.fifouacctd. CSeq: 27932 BYE. User-Agent: Grandstream BT100 1.0.5.11. Max-Forwards: 70. Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE. Content-Length: 0. . # U 68.90.50.100:5060 -> 12.3.4.10:5060 SIP/2.0 404 Not Found. Via: SIP/2.0/UDP 12.3.4.10;branch=z9hG4bKbb2f53e68cca3b12. From: <sip:1001@mycompany.com>;tag=7a9a058a857c4aba. To: <sip:699@mycompany.com>;tag=415a15814acb0. Call-ID: 415a15814acb0.fifouacctd. CSeq: 27932 BYE. Content-Length: 0. Warning: 392 68.90.50.100:5060 "Noisy feedback tells: pid=26213 req_src_ip=68.90.50.100 req_src_port=5060 in_uri=sip:caller@68.90.50.100:5060 out_uri=sip:caller@68.90.50.100:5060 via_cnt==2". . Any ideas why 1002 never rings? Regards, Paul __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail [View Less]

1 0

RE: [Serusers] Ser Register Problem
by yilan＠cs.dal.ca 28 Sep '04

28 Sep '04

Hi Michael, I added the xlog as you told me and got the following results. When I send sipsak command,the log messages on the console showed as following _________________________________________________________________ [root@sipserv ser]# ser start Listening on 127.0.0.1 [127.0.0.1]:5060 134.190.64.164 [134.190.64.164]:5060 Aliases: sipserv:5060 localhost:5060 134.190.64.164:* sipserv.eplgroup.tara.ca:* eplgroup.tara.ca:* stateless - initializing Maxfwd module- … [View More]initializing [root@sipserv ser]# 0(7068) mod_init(): Database connection opened successfuly 0(0) INFO: udp_init: SO_RCVBUF is initially 110592 0(0) INFO: udp_init: SO_RCVBUF is finally 221184 0(0) INFO: udp_init: SO_RCVBUF is initially 110592 0(0) INFO: udp_init: SO_RCVBUF is finally 221184 9(0) INFO: fifo process starting: 7094 9(7094) SER: open_uac_fifo: fifo server up at /tmp/ser_fifo... 5(7082) Begin route 5(7082) Got a OPTIONS (URI = 4500(a)eplgroup.tara.ca) from 134.190.64.164 5(7082) Authenticating Contact (sip:sipsak@sipserv.eplgroup.tara.ca:32839) _________________________________________________________________ The ngrep output is as followed: ________________________________________________________________ [root@sipserv ngrep-1.42]# ./ngrep -n 5060 -d eth0 4500 interface: eth0 (134.190.64.160/255.255.255.224) match: 4500 ############################################ U 134.190.64.171:5060 -> 134.190.64.164:5060 REGISTER sip:134.190.64.164 SIP/2.0..Via:SIP/2.0/UDP 134.190.64.171:5060..From:"4500" <sip:4500@134.190.64.164>;tag=7-366-5f947b49..To:<sip:4500@134.190.64.164>..Contact:<sip:4500@134.190.64.171>..Call-ID:70000-5647a0b0@134.1 90.64.171..CSeq:2 REGISTER..Expires: 7200..User-Agent:Mitel-5055-SIP-Phone 2.0.1.23 08000F0E8F03..Max-Forwards:70..Content-Length:0.... # I 134.190.64.164 -> 134.190.64.171 3:10....E.......<.....@...@......p.HREGISTER sip:134.190.64.164 SIP/2.0..Via:SIP/2.0/UDP 134.190.64.171:5060..From:"4500" <sip:4500@134.190.64.164>;tag=7-366-5f947b49..To:<sip:4500@134.190.64.164>..Contact:<sip:4500@134.190.64.17 1>..Call-ID:70000-5647a0b0@134.190.64.171..CSeq:2 REGISTER..Expires: 7200..User-Agent:Mitel-5055-SIP-Phone 2.0.1.23 08000F0E8F03..Max-Forwards:70..Content-Length:0.... # U 134.190.64.171:5060 -> 134.190.64.164:5060 REGISTER sip:134.190.64.164 SIP/2.0..Via:SIP/2.0/UDP 134.190.64.171:5060..From:"4500" <sip:4500@134.190.64.164>;tag=7-366-5f947b49..To:<sip:4500@134.190.64.164>..Contact:<sip:4500@134.190.64.171>..Call-ID:70000-5647a0b0@134.1 90.64.171..CSeq:2 REGISTER..Expires: 7200..User-Agent:Mitel-5055-SIP-Phone 2.0.1.23 08000F0E8F03..Max-Forwards:70..Content-Length:0.... # I 134.190.64.164 -> 134.190.64.171 3:10 ....E.......<.....@...@......p.HREGISTER sip:134.190.64.164 SIP/2.0..Via:SI P/2.0/UDP 134.190.64.171:5060..From:"4500" sip:4500@134.190.64.164>;tag=7- 366-5f947b49..To:<sip:4500@134.190.64.164>..Contact:<sip:4500@134.190.64.17 1>..Call-ID:70000-5647a0b0@134.190.64.171..CSeq:2 REGISTER..Expires: 7200.. User-Agent:Mitel-5055-SIP-Phone 2.0.1.23 8000F0E8F03..Max-Forwards:70..Con tent-Length:0.... # U 134.190.64.171:5060 -> 134.190.64.164:5060 REGISTER sip:134.190.64.164 SIP/2.0..Via:SIP/2.0/UDP 134.190.64.171:5060..From:"4500" <sip:4500@134.190.64.164>;tag=7-366-5f947b49..To:<sip:4500@134.190.64.164>..Contact:<sip:4500@134.190.64.171>..Call-ID:70000-5647a0b0@134.1 90.64.171..CSeq:2 REGISTER..Expires: 7200..User-Agent:Mitel-5055-SIP-Phone 2.0.1.23 08000F0E8F03..Max-Forwards:70..Content-Length:0.... # I 134.190.64.164 -> 134.190.64.171 3:10 ....E.......<.....@...@......p.HREGISTER sip:134.190.64.164 SIP/2.0..Via:SI P/2.0/UDP 134.190.64.171:5060..From:"4500" sip:4500@134.190.64.164>;tag=7- 366-5f947b49..To:<sip:4500@134.190.64.164>..Contact:<sip:4500@134.190.64.17 1>..Call-ID:70000-5647a0b0@134.190.64.171..CSeq:2 REGISTER..Expires: 7200.. User-Agent:Mitel-5055-SIP-Phone 2.0.1.23 08000F0E8F03..Max-Forwards:70..Content-Length:0.... # U 134.190.64.171:5060 -> 134.190.64.164:5060 REGISTER sip:134.190.64.164 SIP/2.0..Via:SIP/2.0/UDP 134.190.64.171:5060..From:"4500" <sip:4500@134.190.64.164>;tag=7-366-5f947b49..To:<sip:4500@134.190.64.164>..Contact:<sip:4500@134.190.64.171>..Call-ID:70000-5647a0b0@134.1 90.64.171..CSeq:2 REGISTER..Expires: 7200..User-Agent:Mitel-5055-SIP-Phone 2.0.1.23 08000F0E8F03..Max-Forwards:70..Content-Length:0.... # I 134.190.64.164 -> 134.190.64.171 3:10 ....E.......<.....@...@......p.HREGISTER sip:134.190.64.164 SIP/2.0..Via:SI P/2.0/UDP 134.190.64.171:5060..From:"4500" <sip:4500@134.190.64.164>;tag=7- 366-5f947b49..To:<sip:4500@134.190.64.164>..Contact:<sip:4500@134.190.64.17 1>..Call-ID:70000-5647a0b0@134.190.64.171..CSeq:2 REGISTER..Expires: 7200.. User-Agent:Mitel-5055-SIP-Phone 2.0.1.23 08000F0E8F03..Max-Forwards:70..Content-Length:0.... ### U 134.190.64.171:5060 -> 134.190.64.164:5060 REGISTER sip:134.190.64.164 SIP/2.0..Via:SIP/2.0/UDP 134.190.64.171:5060..From:"4500" <sip:4500@134.190.64.164>;tag=7-366-5f947b49..To:<sip:4500@134.190.64.164>..Contact:<sip:4500@134.190.64.171>..Call-ID:70000-5647a0b0@134.1 90.64.171..CSeq:2 REGISTER..Expires: 7200..User-Agent:Mitel-5055-SIP-Phone 2.0.1.23 08000F0E8F03..Max-Forwards:70..Content-Length:0.... # I 134.190.64.164 -> 134.190.64.171 3:10 ....E.......<.....@...@......p.HREGISTER sip:134.190.64.164 SIP/2.0..Via:SI P/2.0/UDP 134.190.64.171:5060..From:"4500" sip:4500@134.190.64.164>;tag=7- 366-5f947b49..To:<sip:4500@134.190.64.164>..Contact:<sip:4500@134.190.64.17 1>..Call-ID:70000-5647a0b0@134.190.64.171..CSeq:2 REGISTER..Expires: 7200.. User-Agent:Mitel-5055-SIP-Phone 2.0.1.23 08000F0E8F03..Max-Forwards:70..Content-Length:0.... ############## _______________________________________________________________ Thanks for your help and time, Yilan > In your next post send the actual ngrep output and any log messages from > the > console or /var/log/messages... Basically what is happening is that the > URI > isn't matching "myself". When you start SER it will tell you what it > binds > to. Include that too next time. > > > Try this: > > xlog("L_INFO", "Got a %rm (URI = %ru) from %is"); > if(uri == myself) > { > xlog("L_INFO", "Authenticating Contact (%ct)"); > > # Make sure they are a valid user on our proxy > if (!www_authorize("yourdomain.com", "location")) > { > www_challenge("yourdomain.com", "0"); > break; > }; > > save("location"); > xlog("L_INFO", "Registered Contact (%ct)"); > break; > }; > > ---------------------------------------- > > Michael Shuler, C.E.O. > BitWise Communications, Inc. (CLEC) And BitWise Systems, Inc. (ISP) > 682 High Point Lane > East Peoria, IL 61611 > Office: (217) 585-0357 > Cell: (309) 657-6365 > Fax: (309) 213-3500 > E-Mail: mike(a)bwsys.net > Customer Service: (877) 976-0711 > >> -----Original Message----- >> From: yilan(a)cs.dal.ca [mailto:yilan@cs.dal.ca] >> Sent: Tuesday, September 28, 2004 9:30 AM >> To: Michael Shuler >> Cc: yilan(a)cs.dal.ca; serusers(a)lists.iptel.org >> Subject: RE: [Serusers] Ser Register Problem >> >> >> Hi Michael, >> >> Thank you for your reply. I really appreciate it. >> >> 1 - Check out xlog() so you can print out the URI, Contact, etc. >> >> I add xlog () in ser.cfg.Then for the sipsak command "sipsak -vv -s >> sip:4500@eplgroup.tara.ca", it shows the following >> 5(6374) not found:time [Tue Sep 28 11:14:48 2004] method >> <OPTIONS> r-uri >> <4500(a)eplgroup.tara.ca> >> I guess sipsak doesn't send register method here. >> >> But for the phone that is going to register for the ser, nothing shows >> although I can see the phone sends register packet from ngrep. >> >> 2 - Are you beheind NAT? >> NO. >> >> 3 - This is all you should be concerend about... What is the last log >> message you are getting from here? Then use xlog() to tell >> you what you >> need to know. If you are not even getting the first log >> message then SER >> is not aware that it is supposed to respond for whatever the >> REGISTER has >> requested. You will need to add it as an "alias" global >> config option at >> the top of the file. >> >> Then how do I let the ser to show the log message? >> I modified the following to show the log in the terminal and I did add >> "alias" for global config option at the top of ser.cfg. >> >> debug=3 >> fork=yes >> log_stderror=yes >> >> alias="eplgroup.tara.ca" >> alias="134.190.64.164" >> >> Thanks, >> Yilan >> > Couple of things to try.... >> > >> > >> > 1 - Check out xlog() so you can print out the URI, Contact, etc. >> > >> > 2 - Are you beheind NAT? >> > >> > 3 - This is all you should be concerend about... What is >> the last log >> > message you are getting from here? Then use xlog() to tell >> you what you >> > need to know. If you are not even getting the first log >> message then SER >> > is >> > not aware that it is supposed to respond for whatever the >> REGISTER has >> > requested. You will need to add it as an "alias" global >> config option at >> > the top of the file. >> > >> >> if (uri==myself) { >> >> >> >> log(1,"in the served domain"); >> >> if (method=="REGISTER") { >> >> log(1,"do the register work"); >> >> >> >> #Uncomment this if you want to use digest authentication >> >> if (!www_authorize("Ip address of >> sip server", >> >> "subscriber")) { >> >> www_challenge("Ip address of >> >> sip server", >> >> "0"); >> >> log(1,"do www_challenge"); >> >> break; >> >> }; >> >> >> >> save("location"); >> >> log(1,"save in the location"); >> >> break; >> >> }; >> >> >> >> # native SIP destinations are handled using >> >> our USRLOC DB >> >> if (!lookup("location")) { >> >> sl_send_reply("404", "Not Found"); >> >> log(1,"not found in the location"); >> >> break; >> >> }; >> >> }else{ >> >> log(1,"not in the domain"); >> >> }; >> > >> > >> > ---------------------------------------- >> > >> > Michael Shuler, C.E.O. >> > BitWise Communications, Inc. (CLEC) And BitWise Systems, Inc. (ISP) >> > 682 High Point Lane >> > East Peoria, IL 61611 >> > Office: (217) 585-0357 >> > Cell: (309) 657-6365 >> > Fax: (309) 213-3500 >> > E-Mail: mike(a)bwsys.net >> > Customer Service: (877) 976-0711 >> > >> > >> > >> > >> > >> > >> >> -----Original Message----- >> >> From: serusers-bounces(a)lists.iptel.org >> >> [mailto:serusers-bounces@lists.iptel.org] On Behalf Of yilan(a)cs.dal.ca >> >> Sent: Monday, September 27, 2004 7:19 PM >> >> To: serusers(a)lists.iptel.org >> >> Subject: [Serusers] Ser Register Problem >> >> >> >> >> >> Dear All, >> >> >> >> I have the latest ser (0.8.14) on fedora 2 as the sip server >> >> ,1 Mitel sip >> >> phone and xpro soft phone as the sip phones. The problem is >> >> that either >> >> the mitel or xpro sip phones can't register in ser. >> >> >> >> I used "serctl ul show",nothing is registered. >> >> >> >> I used "sipsak -vv -s sip:6000@ip address of sipserver",it >> >> shows "SIP/2.0 >> >> 404 Not Found" >> >> >> >> Then I added some log functions in ser.cfg where route >> locates (listed >> >> below).I found out when I used "sipsak -vv -s sip:6000@ip >> address of >> >> sipserver",the log functions execute first at uri==myself, then >> >> (!lookup("location")) and I can see the logs in the terminal. >> >> >> >> But when I started the phone to communicate with the ser, >> those logs >> >> weren't show although I did see the register request from sip >> >> phones to >> >> ser from ngrep. >> >> >> >> So my first question is when the ser.cfg is executed. When I >> >> used sipsak, >> >> I could see ser.cfg is executed. When I started the sip >> >> phone, I can't see >> >> its execution. >> >> >> >> My second question is how to find out the reason for not >> >> registering. I >> >> used the IP address for the domain name. is it right to use? >> >> Because I did >> >> the test in local area network without dns. >> >> >> >> route{ >> >> >> >> log(1,"Begin route\n"); >> >> if (!mf_process_maxfwd_header("10")) { >> >> sl_send_reply("483","Too Many Hops"); >> >> log(1,"Too many hops\n"); >> >> break; >> >> }; >> >> if ( msg:len > max_len ) { >> >> sl_send_reply("513", "Message too big"); >> >> log(1,"Message too big\n"); >> >> break; >> >> }; >> >> >> >> record_route(); >> >> log(1,"record_route\n"); >> >> # loose-route processing >> >> if (loose_route()) { >> >> t_relay(); >> >> log(1,"loose route\n"); >> >> break; >> >> }; >> >> >> >> if (uri==myself) { >> >> >> >> log(1,"in the served domain"); >> >> if (method=="REGISTER") { >> >> log(1,"do the register work"); >> >> >> >> #Uncomment this if you want to use digest authentication >> >> if (!www_authorize("Ip address of >> sip server", >> >> "subscriber")) { >> >> www_challenge("Ip address of >> >> sip server", >> >> "0"); >> >> log(1,"do www_challenge"); >> >> break; >> >> }; >> >> >> >> save("location"); >> >> log(1,"save in the location"); >> >> break; >> >> }; >> >> >> >> # native SIP destinations are handled using >> >> our USRLOC DB >> >> if (!lookup("location")) { >> >> sl_send_reply("404", "Not Found"); >> >> log(1,"not found in the location"); >> >> break; >> >> }; >> >> }else{ >> >> log(1,"not in the domain"); >> >> }; >> >> # 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(); >> >> }; >> >> >> >> } >> >> >> >> Thanks, >> >> Yilan >> >> >> >> >> >> >> >> _______________________________________________ >> >> Serusers mailing list >> >> serusers(a)lists.iptel.org >> >> http://lists.iptel.org/mailman/listinfo/serusers >> >> >> > >> > >> >> > > [View Less]

3 2

[Serusers] Ser and RTPProxy with Nathelper
by David Simmons 28 Sep '04

28 Sep '04

Hi, Having tremendous trouble with SER + RTPProxy. Running Fedora Core 1. Have made RTPProxy using: make -f Makefile.gnu Then run it fine by using: ./rtpproxy Netstat shows: Active UNIX domain sockets (servers and established) Proto RefCnt Flags Type State I-Node PID/Program name Path unix 2 [ ACC ] STREAM LISTENING 11433 2443/rtpproxy /var/run/rtpproxy.sock unix 43 [ ] DGRAM 1822 1947/syslogd /dev/… [View More]log unix 2 [ ] DGRAM 13503 2580/ser unix 2 [ ] DGRAM 13500 2616/ser unix 2 [ ] DGRAM 13497 2615/ser ...... [cropped] When I start SER (version 0.8.14 - latest) I get this in the messages file: Sep 28 16:03:46 testsip2 /sbin/ser[2582]: ERROR: send_rtpp_command: can't read reply from a RTP proxy Sep 28 16:03:46 testsip2 /sbin/ser[2582]: WARNING: rtpp_test: can't get version of the RTP proxy Sep 28 16:03:46 testsip2 /sbin/ser[2582]: WARNING: rtpp_test: support for RTP proxyhas been disabled temporarily Sep 28 16:03:46 testsip2 /sbin/ser[2583]: ERROR: send_rtpp_command: can't read reply from a RTP proxy Sep 28 16:03:46 testsip2 /sbin/ser[2583]: WARNING: rtpp_test: can't get version of the RTP proxy Sep 28 16:03:46 testsip2 /sbin/ser[2583]: WARNING: rtpp_test: support for RTP proxyhas been disabled temporarily Sep 28 16:03:46 testsip2 /sbin/ser[2584]: ERROR: send_rtpp_command: can't read reply from a RTP proxy Sep 28 16:03:46 testsip2 /sbin/ser[2584]: WARNING: rtpp_test: can't get version of the RTP proxy Sep 28 16:03:46 testsip2 /sbin/ser[2584]: WARNING: rtpp_test: support for RTP proxyhas been disabled temporarily Sep 28 16:03:46 testsip2 /sbin/ser[2585]: ERROR: send_rtpp_command: can't read reply from a RTP proxy Sep 28 16:03:46 testsip2 /sbin/ser[2585]: WARNING: rtpp_test: can't get version of the RTP proxy Sep 28 16:03:46 testsip2 /sbin/ser[2585]: WARNING: rtpp_test: support for RTP proxyhas been disabled temporarily Sep 28 16:03:46 testsip2 /sbin/ser[2586]: ERROR: send_rtpp_command: can't read reply from a RTP proxy Sep 28 16:03:46 testsip2 /sbin/ser[2589]: ERROR: send_rtpp_command: can't read reply from a RTP proxy Sep 28 16:03:46 testsip2 /sbin/ser[2587]: ERROR: send_rtpp_command: can't read reply from a RTP proxy Sep 28 16:03:46 testsip2 /sbin/ser[2588]: ERROR: send_rtpp_command: can't read reply from a RTP proxy Sep 28 16:03:46 testsip2 /sbin/ser[2589]: WARNING: rtpp_test: can't get version of the RTP proxy Sep 28 16:03:46 testsip2 /sbin/ser[2590]: ERROR: send_rtpp_command: can't read reply from a RTP proxy Sep 28 16:03:46 testsip2 /sbin/ser[2591]: ERROR: send_rtpp_command: can't read reply from a RTP proxy Sep 28 16:03:46 testsip2 /sbin/ser[2592]: ERROR: send_rtpp_command: can't read reply from a RTP proxy Sep 28 16:03:46 testsip2 /sbin/ser[2586]: WARNING: rtpp_test: can't get version of the RTP proxy Sep 28 16:03:46 testsip2 /sbin/ser[2587]: WARNING: rtpp_test: can't get version of the RTP proxy Sep 28 16:03:46 testsip2 /sbin/ser[2593]: ERROR: send_rtpp_command: can't read reply from a RTP proxy Sep 28 16:03:46 testsip2 /sbin/ser[2594]: ERROR: send_rtpp_command: can't read reply from a RTP proxy Sep 28 16:03:46 testsip2 /sbin/ser[2595]: ERROR: send_rtpp_command: can't read reply from a RTP proxy Sep 28 16:03:46 testsip2 /sbin/ser[2596]: ERROR: send_rtpp_command: can't read reply from a RTP proxy Sep 28 16:03:46 testsip2 /sbin/ser[2588]: WARNING: rtpp_test: can't get version of the RTP proxy Sep 28 16:03:46 testsip2 /sbin/ser[2597]: ERROR: send_rtpp_command: can't read reply from a RTP proxy Sep 28 16:03:46 testsip2 /sbin/ser[2598]: ERROR: send_rtpp_command: can't read reply from a RTP proxy Sep 28 16:03:46 testsip2 /sbin/ser[2599]: ERROR: send_rtpp_command: can't read reply from a RTP proxy Sep 28 16:03:46 testsip2 /sbin/ser[2600]: ERROR: send_rtpp_command: can't read reply from a RTP proxy Sep 28 16:03:46 testsip2 /sbin/ser[2589]: WARNING: rtpp_test: support for RTP proxyhas been disabled temporarily Sep 28 16:03:46 testsip2 /sbin/ser[2601]: ERROR: send_rtpp_command: can't read reply from a RTP proxy Sep 28 16:03:46 testsip2 /sbin/ser[2602]: ERROR: send_rtpp_command: can't read reply from a RTP proxy Sep 28 16:03:46 testsip2 /sbin/ser[2603]: ERROR: send_rtpp_command: can't read reply from a RTP proxy Sep 28 16:03:46 testsip2 /sbin/ser[2604]: ERROR: send_rtpp_command: can't read reply from a RTP proxy Sep 28 16:03:46 testsip2 /sbin/ser[2590]: WARNING: rtpp_test: can't get version of the RTP proxy ...... [cropped] My ser.cfg if it helps is: # # $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=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" #alias=davidsimmons.co.uk # ------------------ module loading ---------------------------------- # Uncomment this if you want to use SQL database #loadmodule "//lib/ser/modules/mysql.so" loadmodule "//lib/ser/modules/nathelper.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" # 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" # ----------------- 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) # ------------------------- 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 (!www_authorize("iptel.org", "subscriber")) { # www_challenge("iptel.org", "0"); # break; # }; save("location"); break; }; # native SIP destinations are handled using our USRLOC DB if (!lookup("location")) { sl_send_reply("404", "Not Found"); break; }; }; # inserted by klaus if (method=="INVITE") { record_route(); force_rtp_proxy(); /* set up reply processing */ t_on_reply("1"); }; # 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(); }; } #inserted by klaus # all incoming replies for t_onrepli-ed transactions enter here onreply_route[1] { if (status=~"[12][0-9][0-9]") force_rtp_proxy(); } Hope you can help as this is driving me mad now :( Best Regards, Dave [View Less]

2 1

[Serusers] RTP Proxy Error Compilation.
by Ricardo Martinez 28 Sep '04

28 Sep '04

Hello. I'm trying to compile the RTP proxy. I downloades the last version from the CVS with : [root@sipproxy root]# cvs -d:pserver:anonymous@cvs.ser.berlios.de:/cvsroot/ser co rtpproxy cvs server: Updating rtpproxy U rtpproxy/Makefile.am U rtpproxy/Makefile.in U rtpproxy/README U rtpproxy/README.remote U rtpproxy/aclocal.m4 U rtpproxy/config.h.in U rtpproxy/configure U rtpproxy/configure.ac U rtpproxy/depcomp U rtpproxy/install-sh U rtpproxy/main.c U rtpproxy/missing U rtpproxy/… [View More]

1 0

[Serusers] ser x86_64 support
by Andrei Pelinescu-Onciul 28 Sep '04

28 Sep '04

I've just commited support for x86_64 (athlon64, athlon fx, opteron) for both the stable (rel_0_8_14) and unstable (HEAD) cvs branches. The x86_64 support is still experimental (it compiles, it starts, but I haven't run any extensive tests). Special thanks go to Michael Shuler for providing access to an Athlon64 machine. Andrei

1 0

RE: [Serusers] Ser Register Problem
by yilan＠cs.dal.ca 28 Sep '04

28 Sep '04

Hi Michael, Thank you for your reply. I really appreciate it. 1 - Check out xlog() so you can print out the URI, Contact, etc. I add xlog () in ser.cfg.Then for the sipsak command "sipsak -vv -s sip:4500@eplgroup.tara.ca", it shows the following 5(6374) not found:time [Tue Sep 28 11:14:48 2004] method <OPTIONS> r-uri <4500(a)eplgroup.tara.ca> I guess sipsak doesn't send register method here. But for the phone that is going to register for the ser, nothing shows although I can … [View More]see the phone sends register packet from ngrep. 2 - Are you beheind NAT? NO. 3 - This is all you should be concerend about... What is the last log message you are getting from here? Then use xlog() to tell you what you need to know. If you are not even getting the first log message then SER is not aware that it is supposed to respond for whatever the REGISTER has requested. You will need to add it as an "alias" global config option at the top of the file. Then how do I let the ser to show the log message? I modified the following to show the log in the terminal and I did add "alias" for global config option at the top of ser.cfg. debug=3 fork=yes log_stderror=yes alias="eplgroup.tara.ca" alias="134.190.64.164" Thanks, Yilan > Couple of things to try.... > > > 1 - Check out xlog() so you can print out the URI, Contact, etc. > > 2 - Are you beheind NAT? > > 3 - This is all you should be concerend about... What is the last log > message you are getting from here? Then use xlog() to tell you what you > need to know. If you are not even getting the first log message then SER > is > not aware that it is supposed to respond for whatever the REGISTER has > requested. You will need to add it as an "alias" global config option at > the top of the file. > >> if (uri==myself) { >> >> log(1,"in the served domain"); >> if (method=="REGISTER") { >> log(1,"do the register work"); >> >> #Uncomment this if you want to use digest authentication >> if (!www_authorize("Ip address of sip server", >> "subscriber")) { >> www_challenge("Ip address of >> sip server", >> "0"); >> log(1,"do www_challenge"); >> break; >> }; >> >> save("location"); >> log(1,"save in the location"); >> break; >> }; >> >> # native SIP destinations are handled using >> our USRLOC DB >> if (!lookup("location")) { >> sl_send_reply("404", "Not Found"); >> log(1,"not found in the location"); >> break; >> }; >> }else{ >> log(1,"not in the domain"); >> }; > > > ---------------------------------------- > > Michael Shuler, C.E.O. > BitWise Communications, Inc. (CLEC) And BitWise Systems, Inc. (ISP) > 682 High Point Lane > East Peoria, IL 61611 > Office: (217) 585-0357 > Cell: (309) 657-6365 > Fax: (309) 213-3500 > E-Mail: mike(a)bwsys.net > Customer Service: (877) 976-0711 > > > > > > >> -----Original Message----- >> From: serusers-bounces(a)lists.iptel.org >> [mailto:serusers-bounces@lists.iptel.org] On Behalf Of yilan(a)cs.dal.ca >> Sent: Monday, September 27, 2004 7:19 PM >> To: serusers(a)lists.iptel.org >> Subject: [Serusers] Ser Register Problem >> >> >> Dear All, >> >> I have the latest ser (0.8.14) on fedora 2 as the sip server >> ,1 Mitel sip >> phone and xpro soft phone as the sip phones. The problem is >> that either >> the mitel or xpro sip phones can't register in ser. >> >> I used "serctl ul show",nothing is registered. >> >> I used "sipsak -vv -s sip:6000@ip address of sipserver",it >> shows "SIP/2.0 >> 404 Not Found" >> >> Then I added some log functions in ser.cfg where route locates (listed >> below).I found out when I used "sipsak -vv -s sip:6000@ip address of >> sipserver",the log functions execute first at uri==myself, then >> (!lookup("location")) and I can see the logs in the terminal. >> >> But when I started the phone to communicate with the ser, those logs >> weren't show although I did see the register request from sip >> phones to >> ser from ngrep. >> >> So my first question is when the ser.cfg is executed. When I >> used sipsak, >> I could see ser.cfg is executed. When I started the sip >> phone, I can't see >> its execution. >> >> My second question is how to find out the reason for not >> registering. I >> used the IP address for the domain name. is it right to use? >> Because I did >> the test in local area network without dns. >> >> route{ >> >> log(1,"Begin route\n"); >> if (!mf_process_maxfwd_header("10")) { >> sl_send_reply("483","Too Many Hops"); >> log(1,"Too many hops\n"); >> break; >> }; >> if ( msg:len > max_len ) { >> sl_send_reply("513", "Message too big"); >> log(1,"Message too big\n"); >> break; >> }; >> >> record_route(); >> log(1,"record_route\n"); >> # loose-route processing >> if (loose_route()) { >> t_relay(); >> log(1,"loose route\n"); >> break; >> }; >> >> if (uri==myself) { >> >> log(1,"in the served domain"); >> if (method=="REGISTER") { >> log(1,"do the register work"); >> >> #Uncomment this if you want to use digest authentication >> if (!www_authorize("Ip address of sip server", >> "subscriber")) { >> www_challenge("Ip address of >> sip server", >> "0"); >> log(1,"do www_challenge"); >> break; >> }; >> >> save("location"); >> log(1,"save in the location"); >> break; >> }; >> >> # native SIP destinations are handled using >> our USRLOC DB >> if (!lookup("location")) { >> sl_send_reply("404", "Not Found"); >> log(1,"not found in the location"); >> break; >> }; >> }else{ >> log(1,"not in the domain"); >> }; >> # 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(); >> }; >> >> } >> >> Thanks, >> Yilan >> >> >> >> _______________________________________________ >> Serusers mailing list >> serusers(a)lists.iptel.org >> http://lists.iptel.org/mailman/listinfo/serusers >> > > [View Less]

2 1

AW: [Serusers] No use_domain in cvs registrar?
by Jankowski, Jan 28 Sep '04

28 Sep '04

The problem is that ser doesn't find any user in usrloc, because when registering from my Cisco Phones the username in the usrloc database is always "user@ip_adress_of_ser". I want "user@domain". A problem of the Cisco 7905G Phones is, that they always use the adress/ip of the sip proxy as domain. Using my domain name as proxy adress in the phones is not possible because the domain name has no dns entry pointing at my SER Server. > >That has been removed for almost 10 months already. … [View More]

5 5

[Serusers] no BYE request
by Pavel Siderov 28 Sep '04

28 Sep '04

I'm using latest CVS version of asterisk and I have one problem - I start ser this way: ser -dddddddddddddddddddddddddd So when user is calling another user there is INVITE - everything is ok. But when user hang up call is finished but I don't see BYE... So this way I can't use acc module to calculate call time. Somebody can help me? Thanks in advance. P.S. root@sip:/var/www/sw# 9(12166) SIP Request: 9(12166) method: <INVITE> 9(12166) uri: <sip:piem@192.168.2.14> 9(… [View More]12166) version: <SIP/2.0> 9(12166) parse_headers: flags=1 9(12166) Found param type 235, <rport> = <n/a>; state=6 9(12166) Found param type 232, <branch> = <z9hG4bK05DA6E2E759C4BFEBA57195FC350EE17>; state=16 9(12166) end of header reached, state=5 9(12166) parse_headers: Via found, flags=1 9(12166) parse_headers: this is the first via 9(12166) After parse_msg... 9(12166) preparing to run routing scripts... 9(12166) parse_headers: flags=128 9(12166) end of header reached, state=9 9(12166) DEBUG: get_hdr_field: <To> [25]; uri=[sip:piem@192.168.2.14] 9(12166) DEBUG: to body [<sip:piem@192.168.2.14> ] 9(12166) get_hdr_field: cseq <CSeq>: <45242> <INVITE> 9(12166) DEBUG:maxfwd:is_maxfwd_present: value = 70 9(12166) DBG:maxfwd:process_maxfwd_header: value 70 decreased to 16 9(12166) parse_headers: flags=256 9(12166) DEBUG: get_hdr_body : content_length=295 9(12166) found end of header 9(12166) find_first_route(): No Route headers found 9(12166) loose_route(): There is no Route HF 9(12166) check_self - checking if host==us: 12==12 && [192.168.2.14] == [192.168.2.14] 9(12166) check_self - checking if port 5060 matches port 5060 9(12166) rewrite(): Rewriting Request-URI with 'sip:piem@192.168.2.2:5060' 9(12166) DEBUG: t_newtran: msg id=5 , global msg id=3 , T on entrance=0xffffffff 9(12166) parse_headers: flags=-1 9(12166) parse_headers: flags=60 9(12166) t_lookup_request: start searching: hash=23406, isACK=0 9(12166) DEBUG: RFC3261 transaction matching failed 9(12166) DEBUG: t_lookup_request: no transaction found 9(12166) DEBUG: add_param: tag=4060601702 9(12166) end of header reached, state=29 9(12166) DBG: trans=0x4043e0f8, callback type 1, id 0 entered 9(12166) SER: new INVITE 9(12166) parse_headers: flags=-1 9(12166) check_via_address(192.168.2.111, 192.168.2.111, 3) 9(12166) WARNING:vqm_resize: resize(0) called 9(12166) DEBUG: reply sent out. buf=0x80ff2a0: SIP/2.0 1..., shmem=0x4043f9f0: SIP/2.0 1 9(12166) DEBUG: _reply_light: finished 9(12166) DEBUG: mk_proxy: doing DNS lookup... 9(12166) check_via_address(192.168.2.111, 192.168.2.111, 3) 9(12166) DEBUG: add_timer_unsafe[4]: 0x4043e210 9(12166) DEBUG: add_timer_unsafe[0]: 0x4043e220 9(12166) SER: new transaction fwd'ed 9(12166) parse_headers: flags=44 9(12166) DEBUG:destroy_avp_list: destroying list (nil) 9(12166) receive_msg: cleaning up 4(12158) SIP Reply (status): 4(12158) version: <SIP/2.0> 4(12158) status: <100> 4(12158) reason: <Trying> 4(12158) parse_headers: flags=1 4(12158) Found param type 232, <branch> = <z9hG4bKe6b5.2905a5f7.0>; state=16 4(12158) end of header reached, state=5 4(12158) parse_headers: Via found, flags=1 4(12158) parse_headers: this is the first via 4(12158) After parse_msg... 4(12158) forward_reply: found module tm, passing reply to it 4(12158) DEBUG: t_check: msg id=2 global id=0 T start=0xffffffff 4(12158) parse_headers: flags=17 4(12158) Found param type 235, <rport> = <5060>; state=6 4(12158) Found param type 232, <branch> = <z9hG4bK05DA6E2E759C4BFEBA57195FC350EE17>; state=16 4(12158) end of header reached, state=5 4(12158) parse_headers: Via found, flags=17 4(12158) parse_headers: this is the second via 4(12158) DEBUG: add_param: tag=2313100209 4(12158) end of header reached, state=29 4(12158) DEBUG: get_hdr_field: <To> [40]; uri=[sip:piem@192.168.2.14] 4(12158) DEBUG: to body [<sip:piem@192.168.2.14>] 4(12158) get_hdr_field: cseq <CSeq>: <45242> <INVITE> 4(12158) parse_headers: flags=4 4(12158) DEBUG: t_reply_matching: hash 23406 label 2136625298 branch 0 4(12158) DEBUG: t_reply_matching: reply matched (T=0x4043e0f8)! 4(12158) DEBUG: t_check: msg id=2 global id=2 T end=0x4043e0f8 4(12158) DEBUG: reply_received: org. status uas=100, uac[0]=0 local=0 is_invite=1) 4(12158) ->>>>>>>>> T_code=100, new_code=100 4(12158) DEBUG: relay_reply: branch=0, save=0, relay=-1 4(12158) DEBUG: add_timer_unsafe[1]: 0x4043e220 4(12158) DEBUG:destroy_avp_list: destroying list (nil) 4(12158) receive_msg: cleaning up 4(12158) SIP Reply (status): 4(12158) version: <SIP/2.0> 4(12158) status: <180> 4(12158) reason: <Ringing> 4(12158) parse_headers: flags=1 4(12158) Found param type 232, <branch> = <z9hG4bKe6b5.2905a5f7.0>; state=16 4(12158) end of header reached, state=5 4(12158) parse_headers: Via found, flags=1 4(12158) parse_headers: this is the first via 4(12158) After parse_msg... 4(12158) forward_reply: found module tm, passing reply to it 4(12158) DEBUG: t_check: msg id=3 global id=2 T start=0xffffffff 4(12158) parse_headers: flags=17 4(12158) Found param type 235, <rport> = <5060>; state=6 4(12158) Found param type 232, <branch> = <z9hG4bK05DA6E2E759C4BFEBA57195FC350EE17>; state=16 4(12158) end of header reached, state=5 4(12158) parse_headers: Via found, flags=17 4(12158) parse_headers: this is the second via 4(12158) DEBUG: add_param: tag=2313100209 4(12158) end of header reached, state=29 4(12158) DEBUG: get_hdr_field: <To> [40]; uri=[sip:piem@192.168.2.14] 4(12158) DEBUG: to body [<sip:piem@192.168.2.14>] 4(12158) get_hdr_field: cseq <CSeq>: <45242> <INVITE> 4(12158) parse_headers: flags=4 4(12158) DEBUG: t_reply_matching: hash 23406 label 2136625298 branch 0 4(12158) DEBUG: t_reply_matching: reply matched (T=0x4043e0f8)! 4(12158) DEBUG: t_check: msg id=3 global id=3 T end=0x4043e0f8 4(12158) DEBUG: reply_received: org. status uas=100, uac[0]=100 local=0 is_invite=1) 4(12158) ->>>>>>>>> T_code=100, new_code=180 4(12158) DEBUG: relay_reply: branch=0, save=0, relay=0 4(12158) old size: 438, new size: 377 4(12158) build_res_from_sip_res: copied size: orig:82, new: 21, rest: 356 msg= SIP/2.0 180 Ringing Via: SIP/2.0/UDP 192.168.2.111:5060;rport=5060;branch=z9hG4bK05DA6E2E759C4BFEBA57195FC350EE17 From: pi <sip:pi@192.168.2.14>;tag=4060601702 To: <sip:piem@192.168.2.14>;tag=2313100209 Contact: <sip:piem@192.168.2.2:5060> Call-ID: B6387609-0B3E-4F5E-A9C2-BFFF87EF4F86(a)192.168.2.111 CSeq: 45242 INVITE Server: X-Lite release 1103m Content-Length: 0 4(12158) DEBUG: reply relayed. buf=0x80ff088: SIP/2.0 1..., shmem=0x4043f410: SIP/2.0 1 4(12158) DEBUG: add_timer_unsafe[1]: 0x4043e220 4(12158) DEBUG:destroy_avp_list: destroying list (nil) 4(12158) receive_msg: cleaning up 10(12171) DEBUG: timer routine:4,tl=0x4043e210 next=(nil) 8(12165) SIP Reply (status): 8(12165) version: <SIP/2.0> 8(12165) status: <200> 8(12165) reason: <Ok> 8(12165) parse_headers: flags=1 8(12165) Found param type 232, <branch> = <z9hG4bKe6b5.2905a5f7.0>; state=16 8(12165) end of header reached, state=5 8(12165) parse_headers: Via found, flags=1 8(12165) parse_headers: this is the first via 8(12165) After parse_msg... 8(12165) forward_reply: found module tm, passing reply to it 8(12165) DEBUG: t_check: msg id=4 global id=0 T start=0xffffffff 8(12165) parse_headers: flags=17 8(12165) Found param type 235, <rport> = <5060>; state=6 8(12165) Found param type 232, <branch> = <z9hG4bK05DA6E2E759C4BFEBA57195FC350EE17>; state=16 8(12165) end of header reached, state=5 8(12165) parse_headers: Via found, flags=17 8(12165) parse_headers: this is the second via 8(12165) DEBUG: add_param: tag=2313100209 8(12165) end of header reached, state=29 8(12165) DEBUG: get_hdr_field: <To> [40]; uri=[sip:piem@192.168.2.14] 8(12165) DEBUG: to body [<sip:piem@192.168.2.14>] 8(12165) get_hdr_field: cseq <CSeq>: <45242> <INVITE> 8(12165) parse_headers: flags=4 8(12165) DEBUG: t_reply_matching: hash 23406 label 2136625298 branch 0 8(12165) DEBUG: t_reply_matching: reply matched (T=0x4043e0f8)! 8(12165) parse_headers: flags=4 8(12165) DEBUG: t_check: msg id=4 global id=4 T end=0x4043e0f8 8(12165) DEBUG: reply_received: org. status uas=180, uac[0]=180 local=0 is_invite=1) 8(12165) ->>>>>>>>> T_code=180, new_code=200 8(12165) DEBUG: relay_reply: branch=0, save=0, relay=0 8(12165) old size: 735, new size: 674 8(12165) build_res_from_sip_res: copied size: orig:77, new: 16, rest: 658 msg= SIP/2.0 200 Ok Via: SIP/2.0/UDP 192.168.2.111:5060;rport=5060;branch=z9hG4bK05DA6E2E759C4BFEBA57195FC350EE17 From: pi <sip:pi@192.168.2.14>;tag=4060601702 To: <sip:piem@192.168.2.14>;tag=2313100209 Contact: <sip:piem@192.168.2.2:5060> Call-ID: B6387609-0B3E-4F5E-A9C2-BFFF87EF4F86(a)192.168.2.111 CSeq: 45242 INVITE Content-Type: application/sdp Server: X-Lite release 1103m Content-Length: 269 v=0 o=piem 101970734 101978031 IN IP4 192.168.2.2 s=X-Lite c=IN IP4 192.168.2.2 t=0 0 m=audio 8000 RTP/AVP 8 3 98 97 101 a=rtpmap:8 pcma/8000 a=rtpmap:3 gsm/8000 a=rtpmap:98 iLBC/8000 a=rtpmap:97 speex/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 8(12165) DEBUG: update_totag_set: new totag 8(12165) DEBUG: reply relayed. buf=0x80ff110: SIP/2.0 2..., shmem=0x4043f410: SIP/2.0 2 8(12165) DEBUG: cleanup_uac_timers: RETR/FR timers reset 8(12165) DEBUG: add_timer_unsafe[2]: 0x4043e140 8(12165) DEBUG:destroy_avp_list: destroying list (nil) 8(12165) receive_msg: cleaning up 10(12171) DEBUG: timer routine:1,tl=0x4043e220 next=(nil) 10(12171) DEBUG: timer routine:2,tl=0x4043e140 next=(nil) 10(12171) DEBUG: wait_handler : removing 0x4043e0f8 from table 10(12171) DEBUG: delete transaction 0x4043e0f8 10(12171) DEBUG: wait_handler : done [View Less]

2 1

← Newer
1
2
3
4
5
6
7
8
...
39
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 September 2004