sr-users May 2006

sr-users@lists.kamailio.org

195 participants
502 discussions

[Users] openser radius tutorial
by Daniel-Constantin Mierla 11 May '06

11 May '06

Hello, as many of you discovered already, a tutorial about OpenSER and FreeRADIUS integration is now available at: http://openser.org/docs/openser-radius-1.0.x.html It is a step by step tutorial, with many configuration examples, which tries to reveal all the operations that can be done with RADIUS modules. Along with basic operations, the openser configuration example presents a time-based call blocking, as a proof of using together AVPs and RADIUS, confirming once more that OpenSER went beyond router concept, its powerful scripting model turning it very easy in an application server without any new development. Hopefully, the tutorial will reduce the number of questions related to radius support in openser. Feedback and improvements are welcome. Cheers, Daniel

3 7

[Users] looping problem
by unplug 11 May '06

11 May '06

I have experienced a problem (looping problem?) in the system. From the log (ngrep) below, the cancel message issues a loop and it will affect the performance of the system. User can't dial/receive call after the loop happened. How and why this loop will created? Does it related to the rtpproxy that I am using in the system? Any one can give me some hints? Thanks, unplug Note: 10.200.0.228 is an openser server. filter: (ip) and ( port 5060 ) U 10.200.0.228:5060 -> 10.200.0.228:5060 CANCEL sip:85234163634@10.200.0.228 SIP/2.0. Record-Route: <sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on>. Record-Route: <sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on>. Record-Route: <sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on>. Record-Route: <sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on>. Record-Route: <sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on>. Record-Route: <sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on>. Record-Route: <sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on>. Record-Route: <sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on>. Record-Route: <sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on>. Record-Route: <sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on>. Record-Route: <sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on>. Record-Route: <sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on>. Record-Route: <sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on>. Record-Route: <sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on>. Record-Route: <sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on>. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.3ffb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.2ffb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.1ffb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.0ffb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.fefb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.eefb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.defb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.cefb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.befb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.aefb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.9efb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.8efb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.7efb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.6efb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.4efb2934.0. Via: SIP/2.0/UDP 10.0.0.92:5060;branch=z9hG4bKrmPCJR8Xm6JKY4o8. Max-Forwards: 55. User-Agent: Koncept KE10XX v4.32.14 00-09-45-0a-fc-29. From: "871966760539" <sip:871966760539@10.200.0.228>;tag=ckRP8FNJugUqMOjy. To: "85234163634" <sip:85234163634@10.200.0.228>. Call-ID: WfigvZ4YJatMKamV(a)10.0.0.92. Contact: <sip:871966760539@10.0.0.92:5060>. CSeq: 1 CANCEL. Content-Length: 0. . # U 10.200.0.228:5060 -> 10.200.0.228:5060 SIP/2.0 408 Request Timeout. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bK5002.201bae66.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bK5002.101bae66.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bK5002.001bae66.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bK5002.ff0bae66.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bK5002.ef0bae66.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bK5002.df0bae66.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bK5002.cf0bae66.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bK5002.bf0bae66.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bK5002.af0bae66.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bK5002.9f0bae66.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bK5002.8f0bae66.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bK5002.7f0bae66.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bK5002.6f0bae66.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bK5002.5f0bae66.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bK5002.4f0bae66.0. Via: SIP/2.0/UDP 10.0.0.92:5060;branch=z9hG4bKjMEHTGhvWKHZ0R2J. From: "871966760539" <sip:871966760539@10.200.0.228>;tag=SM4dtzpkDKYyCkzu. To: "8521878200" <sip:8521878200@10.200.0.228>;tag=4cdbaed0e769eb1d9b81f5252847cf64-3d33. Call-ID: nQCHB6bq42pOheks(a)10.0.0.92. CSeq: 1 CANCEL. Server: OpenSer (1.0.1 (i386/linux)). Content-Length: 0. Warning: 392 10.200.0.228:5060 "Noisy feedback tells: pid=3174 req_src_ip=10.200.0.228 req_src_port=5060 in_uri=sip:8521878200@10.200.0.228 out_uri=sip:8521878200@10.200.0.228 via_cnt==0". . ######## U 10.200.0.228:5060 -> 10.200.0.228:5060 SIP/2.0 408 Request Timeout. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bK5002.bf0bae66.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bK5002.af0bae66.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bK5002.9f0bae66.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bK5002.8f0bae66.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bK5002.7f0bae66.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bK5002.6f0bae66.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bK5002.5f0bae66.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bK5002.4f0bae66.0. Via: SIP/2.0/UDP 10.0.0.92:5060;branch=z9hG4bKjMEHTGhvWKHZ0R2J. From: "871966760539" <sip:871966760539@10.200.0.228>;tag=SM4dtzpkDKYyCkzu. To: "8521878200" <sip:8521878200@10.200.0.228>;tag=4cdbaed0e769eb1d9b81f5252847cf64-ab74. Call-ID: nQCHB6bq42pOheks(a)10.0.0.92. CSeq: 1 CANCEL. Server: OpenSer (1.0.1 (i386/linux)). Content-Length: 0. Warning: 392 10.200.0.228:5060 "Noisy feedback tells: pid=3174 req_src_ip=10.200.0.228 req_src_port=5060 in_uri=sip:8521878200@10.200.0.228 out_uri=sip:8521878200@10.200.0.228 via_cnt==0". . ########### U 10.200.0.228:5060 -> 10.200.0.228:5060 CANCEL sip:85292558811@10.200.0.228 SIP/2.0. Record-Route: <sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on>. Record-Route: <sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on>. Record-Route: <sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on>. Record-Route: <sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on>. Record-Route: <sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on>. Record-Route: <sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on>. Record-Route: <sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on>. Record-Route: <sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on>. Record-Route: <sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on>. Record-Route: <sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on>. Record-Route: <sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on>. Record-Route: <sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on>. Record-Route: <sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on>. Record-Route: <sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on>. Record-Route: <sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on>. Record-Route: <sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on>. Record-Route: <sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on>. Record-Route: <sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on>. Record-Route: <sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on>. Record-Route: <sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on>. Record-Route: <sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on>. Record-Route: <sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on>. Record-Route: <sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on>. Record-Route: <sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on>. Record-Route: <sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on>. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.edcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.ddcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.cdcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.bdcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.adcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.9dcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.8dcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.7dcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.6dcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.5dcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.4dcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.3dcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.2dcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.1dcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.0dcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.fccf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.eccf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.dccf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.cccf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.bccf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.accf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.9ccf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.8ccf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.7ccf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.6ccf03a7.0. Via: SIP/2.0/UDP 10.0.0.92:5060;branch=z9hG4bKlpjLoMyFjsI1BvQL. Max-Forwards: 45. User-Agent: Koncept KE10XX v4.32.14 00-09-45-0a-fc-29. From: "871966760539" <sip:871966760539@10.200.0.228>;tag=MySoSexGPE0vUXa5. To: "85292558811" <sip:85292558811@10.200.0.228>. Call-ID: 8p3FIbMUfYMXOuW3(a)10.0.0.92. Contact: <sip:871966760539@10.0.0.92:5060>. CSeq: 1 CANCEL. Content-Length: 0. . ### U 10.200.0.228:5060 -> 10.200.0.228:5060 CANCEL sip:85234163634@10.200.0.228 SIP/2.0. Record-Route: <sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on>. Record-Route: <sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on>. Record-Route: <sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on>. Record-Route: <sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on>. Record-Route: <sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on>. Record-Route: <sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on>. Record-Route: <sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on>. Record-Route: <sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on>. Record-Route: <sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on>. Record-Route: <sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on>. Record-Route: <sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on>. Record-Route: <sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on>. Record-Route: <sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on>. Record-Route: <sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on>. Record-Route: <sip:10.200.0.228;ftag=ckRP8FNJugUqMOjy;lr=on>. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.3ffb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.2ffb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.1ffb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.0ffb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.fefb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.eefb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.defb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.cefb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.befb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.aefb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.9efb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.8efb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.7efb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.6efb2934.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf34.4efb2934.0. Via: SIP/2.0/UDP 10.0.0.92:5060;branch=z9hG4bKrmPCJR8Xm6JKY4o8. Max-Forwards: 55. User-Agent: Koncept KE10XX v4.32.14 00-09-45-0a-fc-29. From: "871966760539" <sip:871966760539@10.200.0.228>;tag=ckRP8FNJugUqMOjy. To: "85234163634" <sip:85234163634@10.200.0.228>. Call-ID: WfigvZ4YJatMKamV(a)10.0.0.92. Contact: <sip:871966760539@10.0.0.92:5060>. CSeq: 1 CANCEL. Content-Length: 0. . ######## U 10.200.0.228:5060 -> 10.200.0.228:5060 CANCEL sip:85292558811@10.200.0.228 SIP/2.0. Record-Route: <sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on>. Record-Route: <sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on>. Record-Route: <sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on>. Record-Route: <sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on>. Record-Route: <sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on>. Record-Route: <sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on>. Record-Route: <sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on>. Record-Route: <sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on>. Record-Route: <sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on>. Record-Route: <sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on>. Record-Route: <sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on>. Record-Route: <sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on>. Record-Route: <sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on>. Record-Route: <sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on>. Record-Route: <sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on>. Record-Route: <sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on>. Record-Route: <sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on>. Record-Route: <sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on>. Record-Route: <sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on>. Record-Route: <sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on>. Record-Route: <sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on>. Record-Route: <sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on>. Record-Route: <sip:10.200.0.228;ftag=MySoSexGPE0vUXa5;lr=on>. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.cdcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.bdcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.adcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.9dcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.8dcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.7dcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.6dcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.5dcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.4dcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.3dcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.2dcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.1dcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.0dcf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.fccf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.eccf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.dccf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.cccf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.bccf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.accf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.9ccf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.8ccf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.7ccf03a7.0. Via: SIP/2.0/UDP 10.200.0.228;branch=z9hG4bKf9f4.6ccf03a7.0. Via: SIP/2.0/UDP 10.0.0.92:5060;branch=z9hG4bKlpjLoMyFjsI1BvQL. Max-Forwards: 47. User-Agent: Koncept KE10XX v4.32.14 00-09-45-0a-fc-29. From: "871966760539" <sip:871966760539@10.200.0.228>;tag=MySoSexGPE0vUXa5. To: "85292558811" <sip:85292558811@10.200.0.228>. Call-ID: 8p3FIbMUfYMXOuW3(a)10.0.0.92. Contact: <sip:871966760539@10.0.0.92:5060>. CSeq: 1 CANCEL. Content-Length: 0. .

3 9

[Users] strict to loose - Route Header not removed
by Walter Schober 11 May '06

11 May '06

Hello! Acc to 3261, 16.4: the proxy MUST replace the Request-URI in the request with the last value from the Route header field, and remove that value from the Route header field. The proxy MUST then proceed as if it received this modified request. The loose_route() function does only the half on my if (looose_route()) { .. t_relay() .. } script. It replaces the RURI with the value of the last Route header, but then doesn't remove it, causing problems on the last hop. The strict.txt contains a ACK with comes in strict and leaves loose - with the Route header. Aliases are configured with ip.ip.ip.ip and ip.ip.ip.ip:5060. Why is the Route header not stripped? Walter

2 6

RE: [Serusers] SER and XCAP Server
by İlker Aktuna (Koç.net) 11 May '06

11 May '06

At this time using DB is not very important for us. I just need a working configuration. I don't know why it doesn't work even if I do everything as described in the book. I am desperately seeking help... Thanks for everything you do... ilker -----Original Message----- From: Vaclav Kubart [mailto:vaclav.kubart@iptel.org] Sent: Thursday, May 11, 2006 11:45 AM To: İlker Aktuna (Koç.net) Cc: Miguel Freitas; serusers(a)lists.iptel.org Subject: Re: [Serusers] SER and XCAP Server Hi Ilker, this will not help you - in your case is a problem with routing, but I don't know what. You don't need "db_mode" or "use_db" parameters set if you don't want to use database as backup. It is useful if you want it for "failover" (to restore existing subscriptions on SER startup). Vaclav On Thu, May 11, 2006 at 11:37:50AM +0300, ?lker Aktuna (Koç.net) wrote: > Hi, > > Would that correction be a solution to my case ? > If so, which version should I try (CVS or snapshot) ? > And what configuration is correct ? > > Thanks, > ilker > > -----Original Message----- > From: serusers-bounces(a)iptel.org [mailto:serusers-bounces@lists.iptel.org] > On Behalf Of Vaclav Kubart > Sent: Thursday, May 11, 2006 11:33 AM > To: Miguel Freitas > Cc: serusers(a)lists.iptel.org > Subject: Re: [Serusers] SER and XCAP Server > > I have corrected it on CVS and added new snapshot version 4.1 with this correction on ftp.iptel.org. It is not tested like normal snapshot, but it seems to be working for the first look. > > The settings > modparam("rls", "db_mode", 1) > says that only resource list subscriptions (subscriptions to resource lists NOT subscriptions to standalone users) will be stored into database. If you want to store subscriptions to standalone users and published information you have to set > modparam("pa", "use_db", 1) > > [more information about module parameters you can read in presence > handbook in description of PA and RLS module] > > Vaclav > > On Wed, May 10, 2006 at 06:13:06PM +0100, Miguel Freitas wrote: > > just glad of being useful > > > > Thanks for your feedback! > > > > One last question: subscriptions are stored on the SER DB? > > I have <modparam("rls", "db_mode", 1)> on the config file > > > > Miguel > > > > > > On 5/10/06, Vaclav Kubart <vaclav.kubart(a)iptel.org> wrote: > > > > > >> > > >> > > >> I was missing line > > >> lookup_user("To"); > > > > > >It was missing in the presence handbook too - it will be corrected > > >in next version. > > > > > >> > > >> Shouldn't the resource list of subscriptions be stored on the SER DB? > > >> Because I'm getting that Waning all the time and I can't find any > > >> entry related with subscriptions (table rls_subscription, ...) > > > > > >No DB is not problem there. I will correct it in CVS - this warning > > >will not be displayed if parameter will be "0". > > > > > > > > > > >I have captured SIP and HTTP packets with Ethereal, sending file.. > > >> (It doesn't include packets changed between SER and apache > > >> because they > > >are > > >> on the same machine and I don't have access to it right now) SER > > >> and apache on 193.136.93.140 SIP domain = itav140.av.it.pt > > >> eyeBeam <sip:4004@193.136.93.252> and <sip:4002@193.136.92.68 > > > >> After register, client <sip:4002@193.136.92.68 > > >> <sip:4002@193.136.92.68>> changes his status to Away (packet 53) > > >> <sip:4004> receives the new presence status of <sip:4002> (packet > > >> 55 and > > >75) > > >> But when <sip:4002> renew his PUBLISH (packet 79) he doesn't > > >> include a message body with his presence state. > > >> So, the subsequent NOTIFY received by <sip:4004> (packet 85) > > >> doesn't > > >include > > >> the presence status Away any more, even thou <sip:4002> hasn't > > >> changed > > >his > > >> status. > > >> After that, the client <sip:4004> shows <sip:4002> as Available, > > >> when he > > >is > > >> Away. > > > > > >Bingo! You have found a bug in SER - thanks! I have read it in RFC > > >now, and in the case of empty body needs the state be refreshed, > > >not cleared as was done. I will correct it soon. > > > > > > Vaclav > > > > > > > > _______________________________________________ > Serusers mailing list > serusers(a)lists.iptel.org > http://lists.iptel.org/mailman/listinfo/serusers > > > > > > <http://387555.sigclick.mailinfo.com/sigclick/000C0601/04034E04/05044D > 06/13414162.jpg> > ______________________________________________________________________ > ______________________________________________________________________ > _ Bu e-posta mesaji kisiye ozel olup, gizli bilgiler iceriyor > olabilir. Eger bu e-posta mesaji size yanlislikla ulasmissa, icerigini hic bir sekilde kullanmayiniz ve ekli dosyalari acmayiniz. Bu durumda lutfen e-posta mesajini kullaniciya hemen geri gonderiniz ve tum kopyalarini mesaj kutunuzdan siliniz. Bu e-posta mesaji, hic bir sekilde, herhangi bir amac icin cogaltilamaz, yayinlanamaz ve para karsiligi satilamaz. Bu e-posta mesaji viruslere karsi anti-virus sistemleri tarafindan taranmistir. Ancak yollayici, bu e-posta mesajinin - virus koruma sistemleri ile kontrol ediliyor olsa bile - virus icermedigini garanti etmez ve meydana gelebilecek zararlardan dogacak hicbir sorumlulugu kabul etmez. > This message is intended solely for the use of the individual or entity to whom it is addressed , and may contain confidential information. If you are not the intended recipient of this message or you receive this mail in error, you should refrain from making any use of the contents and from opening any attachment. In that case, please notify the sender immediately and return the message to the sender, then, delete and destroy all copies. This e-mail message, can not be copied, published or sold for any reason. This e-mail message has been swept by anti-virus systems for the presence of computer viruses. In doing so, however, sender cannot warrant that virus or other forms of data corruption may not be present and do not take any responsibility in any occurrence. > ______________________________________________________________________ > ______________________________________________________________________ > _ <http://387555.sigclick.mailinfo.com/sigclick/05090204/0D014B04/00004903/161…> _____________________________________________________________________________________________________________________________________________ Bu e-posta mesaji kisiye ozel olup, gizli bilgiler iceriyor olabilir. Eger bu e-posta mesaji size yanlislikla ulasmissa, icerigini hic bir sekilde kullanmayiniz ve ekli dosyalari acmayiniz. Bu durumda lutfen e-posta mesajini kullaniciya hemen geri gonderiniz ve tum kopyalarini mesaj kutunuzdan siliniz. Bu e-posta mesaji, hic bir sekilde, herhangi bir amac icin cogaltilamaz, yayinlanamaz ve para karsiligi satilamaz. Bu e-posta mesaji viruslere karsi anti-virus sistemleri tarafindan taranmistir. Ancak yollayici, bu e-posta mesajinin - virus koruma sistemleri ile kontrol ediliyor olsa bile - virus icermedigini garanti etmez ve meydana gelebilecek zararlardan dogacak hicbir sorumlulugu kabul etmez. This message is intended solely for the use of the individual or entity to whom it is addressed , and may contain confidential information. If you are not the intended recipient of this message or you receive this mail in error, you should refrain from making any use of the contents and from opening any attachment. In that case, please notify the sender immediately and return the message to the sender, then, delete and destroy all copies. This e-mail message, can not be copied, published or sold for any reason. This e-mail message has been swept by anti-virus systems for the presence of computer viruses. In doing so, however, sender cannot warrant that virus or other forms of data corruption may not be present and do not take any responsibility in any occurrence. _____________________________________________________________________________________________________________________________________________

1 0

RE: [Serusers] SER and XCAP Server
by İlker Aktuna (Koç.net) 11 May '06

11 May '06

Hi, Would that correction be a solution to my case ? If so, which version should I try (CVS or snapshot) ? And what configuration is correct ? Thanks, ilker -----Original Message----- From: serusers-bounces(a)iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Vaclav Kubart Sent: Thursday, May 11, 2006 11:33 AM To: Miguel Freitas Cc: serusers(a)lists.iptel.org Subject: Re: [Serusers] SER and XCAP Server I have corrected it on CVS and added new snapshot version 4.1 with this correction on ftp.iptel.org. It is not tested like normal snapshot, but it seems to be working for the first look. The settings modparam("rls", "db_mode", 1) says that only resource list subscriptions (subscriptions to resource lists NOT subscriptions to standalone users) will be stored into database. If you want to store subscriptions to standalone users and published information you have to set modparam("pa", "use_db", 1) [more information about module parameters you can read in presence handbook in description of PA and RLS module] Vaclav On Wed, May 10, 2006 at 06:13:06PM +0100, Miguel Freitas wrote: > just glad of being useful > > Thanks for your feedback! > > One last question: subscriptions are stored on the SER DB? > I have <modparam("rls", "db_mode", 1)> on the config file > > Miguel > > > On 5/10/06, Vaclav Kubart <vaclav.kubart(a)iptel.org> wrote: > > > >> > >> > >> I was missing line > >> lookup_user("To"); > > > >It was missing in the presence handbook too - it will be corrected in > >next version. > > > >> > >> Shouldn't the resource list of subscriptions be stored on the SER DB? > >> Because I'm getting that Waning all the time and I can't find any > >> entry related with subscriptions (table rls_subscription, ...) > > > >No DB is not problem there. I will correct it in CVS - this warning > >will not be displayed if parameter will be "0". > > > > > >I have captured SIP and HTTP packets with Ethereal, sending file.. > >> (It doesn't include packets changed between SER and apache because > >> they > >are > >> on the same machine and I don't have access to it right now) SER > >> and apache on 193.136.93.140 SIP domain = itav140.av.it.pt eyeBeam > >> <sip:4004@193.136.93.252> and <sip:4002@193.136.92.68 > After > >> register, client <sip:4002@193.136.92.68 <sip:4002@193.136.92.68>> > >> changes his status to Away (packet 53) <sip:4004> receives the new > >> presence status of <sip:4002> (packet 55 and > >75) > >> But when <sip:4002> renew his PUBLISH (packet 79) he doesn't > >> include a message body with his presence state. > >> So, the subsequent NOTIFY received by <sip:4004> (packet 85) > >> doesn't > >include > >> the presence status Away any more, even thou <sip:4002> hasn't > >> changed > >his > >> status. > >> After that, the client <sip:4004> shows <sip:4002> as Available, > >> when he > >is > >> Away. > > > >Bingo! You have found a bug in SER - thanks! I have read it in RFC > >now, and in the case of empty body needs the state be refreshed, not > >cleared as was done. I will correct it soon. > > > > Vaclav > > > > _______________________________________________ Serusers mailing list serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers <http://387555.sigclick.mailinfo.com/sigclick/000C0601/04034E04/05044D06/134…> _____________________________________________________________________________________________________________________________________________ Bu e-posta mesaji kisiye ozel olup, gizli bilgiler iceriyor olabilir. Eger bu e-posta mesaji size yanlislikla ulasmissa, icerigini hic bir sekilde kullanmayiniz ve ekli dosyalari acmayiniz. Bu durumda lutfen e-posta mesajini kullaniciya hemen geri gonderiniz ve tum kopyalarini mesaj kutunuzdan siliniz. Bu e-posta mesaji, hic bir sekilde, herhangi bir amac icin cogaltilamaz, yayinlanamaz ve para karsiligi satilamaz. Bu e-posta mesaji viruslere karsi anti-virus sistemleri tarafindan taranmistir. Ancak yollayici, bu e-posta mesajinin - virus koruma sistemleri ile kontrol ediliyor olsa bile - virus icermedigini garanti etmez ve meydana gelebilecek zararlardan dogacak hicbir sorumlulugu kabul etmez. This message is intended solely for the use of the individual or entity to whom it is addressed , and may contain confidential information. If you are not the intended recipient of this message or you receive this mail in error, you should refrain from making any use of the contents and from opening any attachment. In that case, please notify the sender immediately and return the message to the sender, then, delete and destroy all copies. This e-mail message, can not be copied, published or sold for any reason. This e-mail message has been swept by anti-virus systems for the presence of computer viruses. In doing so, however, sender cannot warrant that virus or other forms of data corruption may not be present and do not take any responsibility in any occurrence. _____________________________________________________________________________________________________________________________________________

2 1

Re: [Serusers] SER and XCAP Server
by Vaclav Kubart 11 May '06

11 May '06

On Wed, May 10, 2006 at 03:24:51PM +0100, Miguel Freitas wrote: > > > >It is no problem if you have in config file something like this: > > > > if (method=="SUBSCRIBE") { > > ... > > if (@to.tag=="") { > > ... > > } > > else { > > if (!handle_rls_subscription("0")) { > > lookup_user("To"); > > handle_subscription("registrar"); > > } > > } > > > >This means that SUBSCRIBE requests with nonempty to tag (renewal > >subscriptions) are handled by RLS module first and if it fails (for > >example the subscription doesn't exist) it is handled by PA. In the case > >of unexisting resource list subscription it shows this warning. > > > I was missing line > lookup_user("To"); It was missing in the presence handbook too - it will be corrected in next version. > > Shouldn't the resource list of subscriptions be stored on the SER DB? > Because I'm getting that Waning all the time and I can't find any entry > related with subscriptions (table rls_subscription, ...) No DB is not problem there. I will correct it in CVS - this warning will not be displayed if parameter will be "0". > > > >Could you send network dump of such messages? > > > > > I have captured SIP and HTTP packets with Ethereal, sending file.. > (It doesn't include packets changed between SER and apache because they are > on the same machine and I don't have access to it right now) > SER and apache on 193.136.93.140 > SIP domain = itav140.av.it.pt > eyeBeam <sip:4004@193.136.93.252> and <sip:4002@193.136.92.68 > > After register, client <sip:4002@193.136.92.68 <sip:4002@193.136.92.68>> > changes his status to Away (packet 53) > <sip:4004> receives the new presence status of <sip:4002> (packet 55 and 75) > But when <sip:4002> renew his PUBLISH (packet 79) he doesn't include a > message body with his presence state. > So, the subsequent NOTIFY received by <sip:4004> (packet 85) doesn't include > the presence status Away any more, even thou <sip:4002> hasn't changed his > status. > After that, the client <sip:4004> shows <sip:4002> as Available, when he is > Away. Bingo! You have found a bug in SER - thanks! I have read it in RFC now, and in the case of empty body needs the state be refreshed, not cleared as was done. I will correct it soon. Vaclav

2 2

[Serusers] Running SER Server behind NAT
by Alan 11 May '06

11 May '06

Is it possible to run SER SIP server behind a NAT? If so, what type of configuration changes am i looking at? My current scenario is as follows. Internet <-----> Pix (12.x.x.x translates to 10.x.x.x) <----> SIP Server Requests to and from the internet have a static NAT translation rule in a PIX firewall. Traffic flows from the outside global IP to an inside NAT'ed IP (non-routable) and vice versa. The SIP server's interface is configured with a non-routable IP addresss (10.x.x.x) for example. My problem is related to the message header and the ACK has a record route with the 10.x.x.x in it. Please help.

2 1

[Serusers] Re: Serusers Digest, Vol 37, Issue 3 -- IM + Presence help
by Suraj Kumar 11 May '06

11 May '06

Hi Vaclav, Thanks for the help! That helped!! However, when I registered two users from windows messanger, I can login but I cannot see them with the serctl ul show command which shows the following message : >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 500 Command 'ul_dump' not found >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If i add a contact in the IM client, SER displays the following message: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> subscription to invalid user sip:201@xxx.xxx.248.115 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I have used the config sample from the example with DB in the presence hand book: but my user location is set as follows : modparam("usrloc", "db_mode", 0) Thanks a lot! Suraj

2 1

[Users] problem in sending bye
by openser user 11 May '06

11 May '06

hi all, do any one faced a problem like, if i call a person and i will cut(disconnect) the call before it rings. even after cutting the call before it ring's the called person will get a ring. but when i cut the call after it rings it works properly(mean to say the called person gets disconnet before the called person pickup the call). with regards openseruser --------------------------------- Yahoo! India Answers: Share what you know. Learn something new. Click here Send instant messages to your online friends - NOW

1 0

[Serusers] SER+asterisk MOH
by dashy dude 11 May '06

11 May '06

Dear All I am trying to deliver MOH service in the following manner; _____ _____ _____ |UA1 |<--->|SER |<--->|UA2| ______ _____ _____ | | ________ |Asterisk| ________ When UA1 is talking to UA2, either of them presses a hold button, and asterisk serves MOH Requesting all the gurus to comment on whether it is possible. and will appreciate if someone can guide what is needed on SER. Thanks D __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 3

← Newer
1
...
31
32
33
34
35
36
37
...
51
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 May 2006