- sr-users - kamailio.org

[OpenSER-Users] TM-module and ACK to 2xx (doesnt terminate txn?)
by Taisto Qvist 18 Feb '08

18 Feb '08

Hi Guys, I'm having trouble with my ACK's on 2xx, and reading about the TM-module, it says for *t_check_trans()* : *ACK request - *true if the ACK is a local end-to-end ACK for an existent INVITE transaction. To me, that sounds like a contradiction in terms, since there is (rfc-wise) no transaction left after 2xx has been proxied through, and the ACK starts coming in(because of record-routing). (and my script's ACK-logic for consuming ACK for 3++ also eats the ACK for 2xx :-( ) Does the TM module not follow the rfc-described termination of invite-txn's? Then how long does the transaction live after 2xx has been forwarded? How come its implemented this way? If this is so, then how do I differentiate between an end-to-end ACK for 2xx, and a 3++ hop-by-hop ACK? I have to use flags and stuff? (Havent got that far yet in my openser understanding...) Regards Taisto Qvist Ip-Solutions.se

3 4

[OpenSER-Users] Can we have different session identifiers for one session?
by Vikas CG. 18 Feb '08

18 Feb '08

HI all, Can we have different session identifiers for one session?? Scenario: For INVITE (Offer) im getting 200 OK (Answer). And it will have one session id at "o" line in sdp. I will send re-INVITE with different session id. Is it possible??? In RFC they have suggested to use unique identifier for session, But some sip hard phones are sending different session id's is it possible??? Plz suggest how to handle this scenario. Thanks, Vikas C.G.

1 0

Re: [OpenSER-Users] [OpenSER-Devel] How to stop OpenSER from replying with 100 Trying?
by Henning Westerholt 18 Feb '08

18 Feb '08

On Monday 18 February 2008, Rajat Dudeja wrote: > (moved this thread to user list) > > I've even tried t_relay, but it gives 500 Application Server Error. Below > is my route logic: > route{ > if(!t_relay("0x01")) > { > sl_reply_error(); > exit; > } > if(!as_relay_t("app_server")){ > t_reply("500","Application Server error"); > } > } Hi Rajat, the as_relay_t from seas returns false, so your server returns correctly the 500. I assume that you've configured your SEAS server correctly. Please look into the log messages of your server to get some hints why this fail. You can also activate logging to the console with a config parameter if you like. If you don't spot any problems in the output, increase the debug level to get more hints. Please don't post this type of questions to the devel list. Thank you! Henning

1 0

[OpenSER-Users] Question abour acc and failed INVITEs in 1.3
by Phil D'Amore 18 Feb '08

18 Feb '08

Hello: I have a situation where I am trying to send an INVITE to two different gateways serially. If the first gateway fails, and the second one succeeds, I would expect to see a record for the failure, and a record for the success. At least, this is the way 1.1 did it. In 1.3, I only see a record for the final success. I have both my db_flag and db_missed_flag set. Does anyone have an idea why I would not see the failure? Something new in 1.3? Thanks, Phil

3 3

Re: [OpenSER-Users] SIP Trunk doesn't response to 200OK with an ACK
by Eric Phetteplace 17 Feb '08

17 Feb '08

On their end, they see they send an ACK after I send an OK. I sent them a tcdump file of my traffic during the session. Any suggestions? Eric

2 1

[OpenSER-Users] SIP Trunk doesn't response to 200OK with an ACK
by Eric Phetteplace 17 Feb '08

17 Feb '08

Hello, Here's the results of an ngrep command. It is showing a situation where I make a call on the PSTN to a DID, which terminates on my SIP Trunk. OpenSER receives the INVITE, etc. and I answer with my SIP phone, my phone OKs to OpenSER, OpenSER OKs to the SIP Trunk, but the SIP Trunk never ACKS. What causes this? Thanks, Eric interface: eth0 (192.168.2.0/255.255.255.0) filter: (ip) and ( port 5060 ) # U 8.21.8.24:5060 -> 192.168.2.10:5060 INVITE sip:1001@2.6.7.9 SIP/2.0. Via: SIP/2.0/UDP 8.21.8.24:5060;branch=z9hG4bK69c359bd;rport. From: "19195551212" <sip:19195551212@8.21.8.24>;tag=as6869d7f8. To: <sip:1001@2.6.7.9>. Contact: <sip:19195551212@8.21.8.24>. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. CSeq: 102 INVITE. User-Agent: Vox Callcontrol. Max-Forwards: 70. Date: Sun, 17 Feb 2008 15:37:23 GMT. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Content-Type: application/sdp. Content-Length: 311. . v=0. o=root 25921 25921 IN IP4 8.21.8.24. s=session. c=IN IP4 8.21.8.24. t=0 0. m=audio 15994 RTP/AVP 0 8 18 101. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=silenceSupp:off - - - -. a=ptime:20. a=sendrecv. # U 192.168.2.10:5060 -> 8.21.8.24:5060 SIP/2.0 100 Giving a try. Via: SIP/2.0/UDP 8.21.8.24:5060;branch=z9hG4bK69c359bd;rport=5060. From: "19195551212" <sip:19195551212@8.21.8.24>;tag=as6869d7f8. To: <sip:1001@2.6.7.9>. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. CSeq: 102 INVITE. Server: OpenSER (1.3.0-notls (i386/linux)). Content-Length: 0. . # U 192.168.2.10:5060 -> 192.168.2.3:5060 INVITE sip:1001@192.168.2.3 SIP/2.0. Record-Route: <sip:192.168.2.10;lr=on;ftag=as6869d7f8>. Via: SIP/2.0/UDP 192.168.2.10;branch=z9hG4bKd949.f8032901.0. Via: SIP/2.0/UDP 8.21.8.24:5060;branch=z9hG4bK69c359bd;rport=5060. From: "19195551212" <sip:19195551212@8.21.8.24>;tag=as6869d7f8. To: <sip:1001@2.6.7.9>. Contact: <sip:19195551212@8.21.8.24>. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. CSeq: 102 INVITE. User-Agent: Vox Callcontrol. Max-Forwards: 69. Date: Sun, 17 Feb 2008 15:37:23 GMT. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Content-Type: application/sdp. Content-Length: 329. P-hint: usrloc applied. . v=0. o=root 25921 25921 IN IP4 8.21.8.24. s=session. c=IN IP4 192.168.2.10. t=0 0. m=audio 35058 RTP/AVP 0 8 18 101. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=silenceSupp:off - - - -. a=ptime:20. a=sendrecv. a=nortpproxy:yes. # U 192.168.2.3:5060 -> 192.168.2.10:5060 SIP/2.0 100 Trying. Content-Length: 0. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. CSeq: 102 INVITE. From: <sip:19195551212@8.21.8.24>;tag=as6869d7f8. To: "ericp"<sip:1001@2.6.7.9>;tag=35794812523426. Server: SJphone/1.50.271d (SJ Labs). Via: SIP/2.0/UDP 192.168.2.10;branch=z9hG4bKd949.f8032901.0,SIP/2.0/UDP 8.21.8.24:5060;rport=5060;branch=z9hG4bK69c359bd. . # U 192.168.2.3:5060 -> 192.168.2.10:5060 SIP/2.0 180 Ringing. Content-Length: 0. Contact: <sip:192.168.2.3:5060>. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. CSeq: 102 INVITE. From: <sip:19195551212@8.21.8.24>;tag=as6869d7f8. Record-Route: <sip:192.168.2.10;lr=on;ftag=as6869d7f8>. To: "ericp"<sip:1001@2.6.7.9>;tag=35794812523426. Server: SJphone/1.50.271d (SJ Labs). Via: SIP/2.0/UDP 192.168.2.10;branch=z9hG4bKd949.f8032901.0,SIP/2.0/UDP 8.21.8.24:5060;rport=5060;branch=z9hG4bK69c359bd. . # U 192.168.2.10:5060 -> 8.21.8.24:5060 SIP/2.0 180 Ringing. Content-Length: 0. Contact: <sip:192.168.2.3:5060>. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. CSeq: 102 INVITE. From: <sip:19195551212@8.21.8.24>;tag=as6869d7f8. Record-Route: <sip:192.168.2.10;lr=on;ftag=as6869d7f8>. To: "ericp"<sip:1001@2.6.7.9>;tag=35794812523426. Server: SJphone/1.50.271d (SJ Labs). Via: SIP/2.0/UDP 8.21.8.24:5060;rport=5060;branch=z9hG4bK69c359bd. . # U 192.168.2.3:5060 -> 192.168.2.10:5060 SIP/2.0 200 OK. Content-Length: 217. Contact: <sip:192.168.2.3:5060>. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. Content-Type: application/sdp. CSeq: 102 INVITE. From: <sip:19195551212@8.21.8.24>;tag=as6869d7f8. Record-Route: <sip:192.168.2.10;lr=on;ftag=as6869d7f8>. To: "ericp"<sip:1001@2.6.7.9>;tag=35794812523426. Server: SJphone/1.50.271d (SJ Labs). Via: SIP/2.0/UDP 192.168.2.10;branch=z9hG4bKd949.f8032901.0,SIP/2.0/UDP 8.21.8.24:5060;rport=5060;branch=z9hG4bK69c359bd. . v=0. o=- 3412233443 3412233443 IN IP4 192.168.2.3. s=SJphone. c=IN IP4 192.168.2.3. t=0 0. a=direction:active. m=audio 49162 RTP/AVP 0 100. a=rtpmap:0 PCMU/8000. a=rtpmap:100 telephone-event/8000. a=fmtp:100 0-11,16. # U 192.168.2.10:5060 -> 8.21.8.24:5060 SIP/2.0 200 OK. Content-Length: 236. Contact: <sip:192.168.2.3:5060>. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. Content-Type: application/sdp. CSeq: 102 INVITE. From: <sip:19195551212@8.21.8.24>;tag=as6869d7f8. Record-Route: <sip:192.168.2.10;lr=on;ftag=as6869d7f8>. To: "ericp"<sip:1001@2.6.7.9>;tag=35794812523426. Server: SJphone/1.50.271d (SJ Labs). Via: SIP/2.0/UDP 8.21.8.24:5060;rport=5060;branch=z9hG4bK69c359bd. . v=0. o=- 3412233443 3412233443 IN IP4 192.168.2.3. s=SJphone. c=IN IP4 192.168.2.10. t=0 0. a=direction:active. m=audio 35060 RTP/AVP 0 100. a=rtpmap:0 PCMU/8000. a=rtpmap:100 telephone-event/8000. a=fmtp:100 0-11,16. a=nortpproxy:yes. # U 192.168.2.3:5060 -> 192.168.2.10:5060 SIP/2.0 200 OK. Content-Length: 217. Contact: <sip:192.168.2.3:5060>. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. Content-Type: application/sdp. CSeq: 102 INVITE. From: <sip:19195551212@8.21.8.24>;tag=as6869d7f8. Record-Route: <sip:192.168.2.10;lr=on;ftag=as6869d7f8>. To: "ericp"<sip:1001@2.6.7.9>;tag=35794812523426. Server: SJphone/1.50.271d (SJ Labs). Via: SIP/2.0/UDP 192.168.2.10;branch=z9hG4bKd949.f8032901.0,SIP/2.0/UDP 8.21.8.24:5060;rport=5060;branch=z9hG4bK69c359bd. . v=0. o=- 3412233443 3412233443 IN IP4 192.168.2.3. s=SJphone. c=IN IP4 192.168.2.3. t=0 0. a=direction:active. m=audio 49162 RTP/AVP 0 100. a=rtpmap:0 PCMU/8000. a=rtpmap:100 telephone-event/8000. a=fmtp:100 0-11,16. # U 192.168.2.10:5060 -> 8.21.8.24:5060 SIP/2.0 200 OK. Content-Length: 236. Contact: <sip:192.168.2.3:5060>. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. Content-Type: application/sdp. CSeq: 102 INVITE. From: <sip:19195551212@8.21.8.24>;tag=as6869d7f8. Record-Route: <sip:192.168.2.10;lr=on;ftag=as6869d7f8>. To: "ericp"<sip:1001@2.6.7.9>;tag=35794812523426. Server: SJphone/1.50.271d (SJ Labs). Via: SIP/2.0/UDP 8.21.8.24:5060;rport=5060;branch=z9hG4bK69c359bd. . v=0. o=- 3412233443 3412233443 IN IP4 192.168.2.3. s=SJphone. c=IN IP4 192.168.2.10. t=0 0. a=direction:active. m=audio 35060 RTP/AVP 0 100. a=rtpmap:0 PCMU/8000. a=rtpmap:100 telephone-event/8000. a=fmtp:100 0-11,16. a=nortpproxy:yes. # U 192.168.2.3:5060 -> 192.168.2.10:5060 SIP/2.0 200 OK. Content-Length: 217. Contact: <sip:192.168.2.3:5060>. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. Content-Type: application/sdp. CSeq: 102 INVITE. From: <sip:19195551212@8.21.8.24>;tag=as6869d7f8. Record-Route: <sip:192.168.2.10;lr=on;ftag=as6869d7f8>. To: "ericp"<sip:1001@2.6.7.9>;tag=35794812523426. Server: SJphone/1.50.271d (SJ Labs). Via: SIP/2.0/UDP 192.168.2.10;branch=z9hG4bKd949.f8032901.0,SIP/2.0/UDP 8.21.8.24:5060;rport=5060;branch=z9hG4bK69c359bd. . v=0. o=- 3412233443 3412233443 IN IP4 192.168.2.3. s=SJphone. c=IN IP4 192.168.2.3. t=0 0. a=direction:active. m=audio 49162 RTP/AVP 0 100. a=rtpmap:0 PCMU/8000. a=rtpmap:100 telephone-event/8000. a=fmtp:100 0-11,16. # U 192.168.2.10:5060 -> 8.21.8.24:5060 SIP/2.0 200 OK. Content-Length: 236. Contact: <sip:192.168.2.3:5060>. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. Content-Type: application/sdp. CSeq: 102 INVITE. From: <sip:19195551212@8.21.8.24>;tag=as6869d7f8. Record-Route: <sip:192.168.2.10;lr=on;ftag=as6869d7f8>. To: "ericp"<sip:1001@2.6.7.9>;tag=35794812523426. Server: SJphone/1.50.271d (SJ Labs). Via: SIP/2.0/UDP 8.21.8.24:5060;rport=5060;branch=z9hG4bK69c359bd. . v=0. o=- 3412233443 3412233443 IN IP4 192.168.2.3. s=SJphone. c=IN IP4 192.168.2.10. t=0 0. a=direction:active. m=audio 35060 RTP/AVP 0 100. a=rtpmap:0 PCMU/8000. a=rtpmap:100 telephone-event/8000. a=fmtp:100 0-11,16. a=nortpproxy:yes. # U 192.168.2.3:5060 -> 192.168.2.10:5060 BYE sip:19195551212@8.21.8.24 SIP/2.0. Content-Length: 0. Contact: <sip:192.168.2.3:5060>. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. Max-Forwards: 70. CSeq: 1 BYE. From: <sip:1001@2.6.7.9>;tag=35794812523426. Route: <sip:192.168.2.10;lr=on;ftag=as6869d7f8>. To: <sip:19195551212@8.21.8.24>;tag=as6869d7f8. User-Agent: SJphone/1.50.271d (SJ Labs). Via: SIP/2.0/UDP 192.168.2.3;rport;branch=z9hG4bKc0a802030131c9b147b80e6900007d3200000019. . # U 192.168.2.10:5060 -> 8.21.8.24:5060 BYE sip:19195551212@8.21.8.24 SIP/2.0. Record-Route: <sip:192.168.2.10;lr=on;ftag=35794812523426>. Content-Length: 0. Contact: <sip:192.168.2.3:5060>. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. Max-Forwards: 69. CSeq: 1 BYE. From: <sip:1001@2.6.7.9>;tag=35794812523426. To: <sip:19195551212@8.21.8.24>;tag=as6869d7f8. User-Agent: SJphone/1.50.271d (SJ Labs). Via: SIP/2.0/UDP 192.168.2.10;branch=z9hG4bK3067.f0fdf201.0. Via: SIP/2.0/UDP 192.168.2.3;rport=5060;branch=z9hG4bKc0a802030131c9b147b80e6900007d320000001 9. P-hint: rr-enforced. . # U 192.168.2.10:5060 -> 8.21.8.24:5060 BYE sip:19195551212@8.21.8.24 SIP/2.0. Record-Route: <sip:192.168.2.10;lr=on;ftag=35794812523426>. Content-Length: 0. Contact: <sip:192.168.2.3:5060>. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. Max-Forwards: 69. CSeq: 1 BYE. From: <sip:1001@2.6.7.9>;tag=35794812523426. To: <sip:19195551212@8.21.8.24>;tag=as6869d7f8. User-Agent: SJphone/1.50.271d (SJ Labs). Via: SIP/2.0/UDP 192.168.2.10;branch=z9hG4bK3067.f0fdf201.0. Via: SIP/2.0/UDP 192.168.2.3;rport=5060;branch=z9hG4bKc0a802030131c9b147b80e6900007d320000001 9. P-hint: rr-enforced. . # U 192.168.2.3:5060 -> 192.168.2.10:5060 BYE sip:19195551212@8.21.8.24 SIP/2.0. Content-Length: 0. Contact: <sip:192.168.2.3:5060>. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. Max-Forwards: 70. CSeq: 1 BYE. From: <sip:1001@2.6.7.9>;tag=35794812523426. Route: <sip:192.168.2.10;lr=on;ftag=as6869d7f8>. To: <sip:19195551212@8.21.8.24>;tag=as6869d7f8. User-Agent: SJphone/1.50.271d (SJ Labs). Via: SIP/2.0/UDP 192.168.2.3;rport;branch=z9hG4bKc0a802030131c9b147b80e6900007d3200000019. . # U 8.21.8.24:5060 -> 192.168.2.10:5060 SIP/2.0 481 Call leg/transaction does not exist. Via: SIP/2.0/UDP 192.168.2.10;branch=z9hG4bK3067.f0fdf201.0;received=2.6.7.9. Via: SIP/2.0/UDP 192.168.2.3;rport=5060;branch=z9hG4bKc0a802030131c9b147b80e6900007d320000001 9. From: <sip:1001@2.6.7.9>;tag=35794812523426. To: <sip:19195551212@8.21.8.24>;tag=as6869d7f8. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. CSeq: 1 BYE. User-Agent: Vox Callcontrol. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Content-Length: 0. . # U 192.168.2.10:5060 -> 192.168.2.3:5060 SIP/2.0 481 Call leg/transaction does not exist. Via: SIP/2.0/UDP 192.168.2.3;rport=5060;branch=z9hG4bKc0a802030131c9b147b80e6900007d320000001 9. From: <sip:1001@2.6.7.9>;tag=35794812523426. To: <sip:19195551212@8.21.8.24>;tag=as6869d7f8. Call-ID: 41d92a2106bd8b50595d335717906399(a)8.21.8.24. CSeq: 1 BYE. User-Agent: Vox Callcontrol. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Content-Length: 0. . exit 18 received, 0 dropped

3 5

Re: [OpenSER-Users] Failover using NAPTR/SRV
by Douglas Garstang 17 Feb '08

17 Feb '08

Ok, so rfc3263 defines what the user agent should do when a 503 reply, or no reply is received. What about the rest of the possible SIP replies? We use several different ITSP's. I just checked the logs for our last 50,000 calls from all of them and there was a total of 19 different replies received. They are: 200,400,401,403,404,408,410,480,484,486,487,488,500,501,502,503,504,603 Some of these can occur under normal conditions, 486 is busy for example, or 487 is generated by a CANCEL. What about the rest? Most of the rest can be classified as error conditions. Are you saying that if another error condition besides 503 is received that you don't do failover? Why? Douglas. ----- Original Message ---- From: Bogdan-Andrei Iancu <bogdan(a)voice-system.ro> To: Douglas Garstang <dougmig33(a)yahoo.com>; users openser.org <users(a)openser.org> Sent: Friday, February 15, 2008 5:56:45 AM Subject: Re: [OpenSER-Users] Failover using NAPTR/SRV Of course it is.....by IETF - see RFC3263. 4.3 Details of RFC 2782 Process Regards, Bogdan Douglas Garstang wrote: > Well that's weird. What do you mean by 'fail'? I thought dns_blacklist > was used when a 503 response was received? What if the connection > times out? What if another negative reply is received? Is this stuff > documented anywhere? > > ----- Original Message ---- > From: Bogdan-Andrei Iancu <bogdan(a)voice-system.ro> > To: Tobias Lindgren <tobias.lindgren(a)ip-only.se> > Cc: users(a)openser.org > Sent: Thursday, February 14, 2008 3:25:33 AM > Subject: Re: [OpenSER-Users] Failover using NAPTR/SRV > > Hi Tobias, > > if you have "dns_backlist=yes" in your config, if one of the destination > server fails (according to SIP definition), it's IP will be added to a > temporary blacklist (for 4 minutes) and not used. So, openser should do > dns-based failover and use the next entry provided by NAPTR/SRV/A lookup. > > Regards, > Bogdan > > Tobias Lindgren wrote: > > Hi all, > > > > I've been trying to find this information but I cannot find any exact > > specifications on how it really works. > > > > >From what I know using NAPTR/SRV records with OpenSER will allow > it to > > find and use servers behind those DNS-records. This works just fine. > > > > However, what I'm not sure about is what actually will happen in > OpenSER > > when one of two servers in this scenario would fail. > > > > For example, I have two servers as SRV where one is primary and one is > > secondary for SIP/UDP. What will happend in OpenSER when the primary > > server is down? Will OpenSER continue to send all request first towards > > that server or will it learn that one server is down and always send > > requests to the second server for a period of time and try the primary > > one just occassionally? > > > > Please direct me to any page where this is explained in detail, if such > > page exists. > > > > Br, > > /Tobias > > > > _______________________________________________ > > Users mailing list > > Users(a)lists.openser.org <mailto:Users@lists.openser.org> > > http://lists.openser.org/cgi-bin/mailman/listinfo/users > > > > > > > _______________________________________________ > Users mailing list > Users(a)lists.openser.org <mailto:Users@lists.openser.org> > http://lists.openser.org/cgi-bin/mailman/listinfo/users > > > ------------------------------------------------------------------------ > Never miss a thing. Make Yahoo your homepage. > <http://us.rd.yahoo.com/evt=51438/*http://www.yahoo.com/r/hs> Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

1 0

Re: [OpenSER-Users] SIP Trunk doesn't response to 200OK with an ACK
by Eric Phetteplace 17 Feb '08

17 Feb '08

Thanks for the comments, I?aki and Robert. I have a tech support ticket open with the SIP Trunk provider. I'll let you know what we figure out. Their engineers won't be in for another 12 hours, so it might have to wait until then. Eric

1 0

[OpenSER-Users] Why OpenSer sends a "NOTIFY" when un-SUBSCRIBE for a contact?
by Iñaki Baz Castillo 16 Feb '08

16 Feb '08

Hi, if I send a un-SUBSCRIBE: ------------------------------------------------------------------ SUBSCRIBE sip:OPENSER_IP SIP/2.0 To: <sip:piru@domain.org>;tag=10.30692.1202986670.2 From: <sip:angel@domain.org>;tag=utxpu Accept: application/pidf+xml Event: presence Expires: 0 ------------------------------------------------------------------ then OpenSer replies with a 202 OK: ------------------------------------------------------------------ SIP/2.0 202 OK Expires: 0 ------------------------------------------------------------------ and later OpenSer sends me a NOTIFY: ------------------------------------------------------------------ NOTIFY sip:angel_aliax_net@212.121.235.18:5060 SIP/2.0 To: sip:angel@domain.org;tag=utxpu From: sip:piru@domain.org;tag=10.30692.1202986670.2 Event: presence Subscription-State: terminated;reason=timeout Content-Type: application/pidf+xml <?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" entity="sip:piru@domain.org"> <tuple id="mzlben"> <status> <basic>open</basic> </status> </tuple> </presence> ------------------------------------------------------------------ My question is: why OpenSer sends the pidf+xml body in the NOTIFY? it's obvious that the user has no interest in the presence status of that contact. Maybe it's RFC mandatory? -- Iñaki Baz Castillo ibc(a)in.ilimit.es

2 1

[OpenSER-Users] [CDRTool] BUG: Wrong price when multiple span
by Iñaki Baz Castillo 16 Feb '08

16 Feb '08

Hi, CDRTool can calculate the price of a call involving various spans (rates). But it does it wrongly since the start time for each span is set to the start time of the call, so the price is much higher than the correct one. An example: This is a call of more than 3 days of duration. Note that in spans 2, 3 and 4 the "StartTime" is 2008-02-16 15:57:05 in all (the start time of the call), and note also that the "Duration" of spans 2, 3 and 4 are the sum of each span and its previous spans: -- Span: 1 Duration: 28975 s StartTime: 2008-02-16 15:57:05 (Europe/Madrid) ProfileId: 01 Festivo for weekend RateId: Reducida for 0-24h Rate: 0.0100 / 60 s Price: 4.8292 -- Span: 2 Duration: 115375 s <---- WRONG !!! StartTime: 2008-02-16 15:57:05 (Europe/Madrid) <---- WRONG !!! ProfileId: 01 Festivo for weekend RateId: Reducida for 0-24h Rate: 0.0100 / 60 s Price: 19.2292 -- Span: 3 Duration: 144175 s <---- WRONG !!! StartTime: 2008-02-16 15:57:05 (Europe/Madrid) <---- WRONG !!! ProfileId: 01 Laboral for weekday RateId: Reducida for 0-8h Rate: 0.0100 / 60 s Price: 24.0292 -- Span: 4 Duration: 229878 s <---- WRONG !!! StartTime: 2008-02-16 15:57:05 (Europe/Madrid) <---- WRONG !!! ProfileId: 01 Laboral for weekday RateId: Normal for 8-22h Rate: 0.0300 / 60 s Price: 114.9390 -- Total: 163.0765 -- Iñaki Baz Castillo

1 0

[OpenSER-Users] OpenSerand RTPProxy, no RTP audio
by Eric Phetteplace 15 Feb '08

15 Feb '08

Hello, Following http://www.voip-info.org/wiki/index.php?page=OpenSER%20v1.2.x%20and%20RTPPro xy and cleaning up the errors in the log, I have OpenSER 1.3 and RTPProxy running in my local domain (192.168.2.10) I have two SIP phones in my local domain, on two machines. (2.5 and 2.3) I added an alias via openserctl ul add gail sip:192.168.2.5 Looking at the packets captured from a call between 2.5 and 2.3, 2.3 should start streaming RTP packets after it ACKs the 200 from 2.5 I call from 192.168.2.5 to gail(a)192.168.2.10 and the connection is established between the three, but no RTP streams ever begin. I expected to see 2.3 streaming RTP after it ACKs the 200 from 2.10. Any suggestions? Here's my cfg file: # # sample config file to be used with nathelper/rtpproxy # # start RTPProxy with: rtpproxy -l your_public_ip -s udp:localhost:8899 # # ----------- 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 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 # --- module loading mpath="/usr/local/lib/openser/modules/" loadmodule "mysql.so" loadmodule "sl.so" loadmodule "tm.so" loadmodule "rr.so" loadmodule "maxfwd.so" loadmodule "usrloc.so" loadmodule "textops.so" loadmodule "auth.so" loadmodule "auth_db.so" loadmodule "xlog.so" loadmodule "registrar.so" loadmodule "mi_fifo.so" loadmodule "presence.so" loadmodule "presence_xml.so" loadmodule "xcap_client.so" loadmodule "nathelper.so" # --- setting module parameters modparam("mi_fifo", "fifo_name", "/tmp/openser_fifo") modparam("auth_db","db_url","mysql://openser:secret@127.0.0.1/openser") modparam("registrar", "received_avp", "$avp(s:rcv)") modparam("xcap_client", "db_url", "mysql://openser:secret@127.0.0.1/openser") # -- usrloc params -- modparam("usrloc", "db_url", "mysql://openser:secret@127.0.0.1/openser") modparam("usrloc", "db_mode", 2) modparam("usrloc", "nat_bflag", 3) # -- registrar params -- modparam("registrar", "received_avp", "$avp(s:rcv)") # -- auth params -- modparam("auth_db", "calculate_ha1", yes) modparam("auth_db", "password_column", "password") # -- rr params -- modparam("rr", "enable_full_lr", 1) # -- nathelper modparam("nathelper", "rtpproxy_sock", "udp:127.0.0.1:8899") modparam("nathelper", "natping_interval", 30) modparam("nathelper", "ping_nated_only", 1) #modparam("nathelper", "sipping_bflag", 7) modparam("nathelper", "sipping_from", "sip:pinger@openser.org") modparam("nathelper", "received_avp", "$avp(s:rcv)") # -- xlog modparam("xlog", "buf_size", 8192) # -- presence params -- modparam("presence|presence_xml|usrloc", "db_url", "mysql://openser:secret@127.0.0.1/openser") modparam("presence", "max_expires", 3600) modparam("presence_xml", "force_active", 1) modparam("presence", "server_address", "sip:127.0.0.1:5060" ) # --- main routing logic route{ xlog("***start***\n"); if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); xlog("***end - Too Many Hops"); exit; }; if (msg:len >= 2048 ) { sl_send_reply("513", "Message too big"); xlog("***end - Too big"); exit; }; # NAT detection route(2); if (!method=="REGISTER") { xlog("***route - recordroute\n"); record_route(); } if (loose_route()) { xlog("***route - looseroute\n"); append_hf("P-hint: rr-enforced\r\n"); route(1); }; if (!uri==myself) { xlog("***route - not myself\n"); append_hf("P-hint: outbound\r\n"); route(1); }; if (uri==myself) { if (method=="REGISTER") { xlog("***route - register"); if (!www_authorize("openser.org", "subscriber")) { xlog("***route - challenging"); www_challenge("openser.org", "0"); exit; }; if (isflagset(5)) { xlog("***route - isflagset(5)"); setflag(6); # if you want OPTIONS natpings uncomment next # setflag(7); }; save("location"); xlog("***route - registered"); exit; }; if (!lookup("location")) { sl_send_reply("404", "Not Found"); xlog("***route - 404, Not found"); exit; }; append_hf("P-hint: usrloc applied\r\n"); }; route(1); xlog("***end***\n"); } route[1] { xlog("***route1***\n"); if (subst_uri('/(sip:.*);nat=yes/\1/')){ xlog("***route[1] - setflag(6)"); setflag(6); }; if (isflagset(5)||isflagset(6)) { xlog("***route[1] - route(3)"); route(3); } if (!t_relay()) { xlog("***route[1] - error"); sl_reply_error(); }; xlog("***end - route[1]"); exit; } route[2]{ xlog("***route2***\n"); force_rport(); if (nat_uac_test("19")) { xlog("***route2 - nat_uac_test(19)\n"); if (method=="REGISTER") { xlog("***route2 - register\n"); fix_nated_register(); } else { xlog("***route2 - contact\n"); fix_nated_contact(); }; setflag(5); }; } route[3] { xlog("***route3***\n"); if (is_method("BYE|CANCEL")) { xlog("***route3 - unforce\n"); unforce_rtp_proxy(); } else if (is_method("INVITE")){ xlog("***route3 - force\n"); force_rtp_proxy("i"); t_on_failure("1"); }; if (isflagset(5)) { xlog("***route3 - isflagset(5)\n"); search_append('Contact:.*sip:[^>[:cntrl:]]*', ';nat=yes'); } t_on_reply("1"); } failure_route[1] { xlog("***failureroute1***\n"); if (isflagset(6) || isflagset(5)) { xlog("***failroute1 - unforce\n"); unforce_rtp_proxy(); } } onreply_route[1] { xlog("***onreplyroute1***\n"); if ((isflagset(5) || isflagset(6)) && status=~"(183)|(2[0-9][0-9])") { xlog("***onreplyroute1 - force\n"); force_rtp_proxy("i"); } search_append('Contact:.*sip:[^>[:cntrl:]]*', ';nat=yes'); if (isflagset(6)) { xlog("***onreplyroute1 - contact\n"); fix_nated_contact(); } xlog("***end - onreplyrout[1]"); exit; } Thanks, Eric

2 4

[OpenSER-Users] TM-module and ACK to 2xx (doesnt terminate txn?)
by Taisto Qvist 15 Feb '08

15 Feb '08

Oups, I seemed to have my maillist-subscription disabled so I never got the answers.... I seems like we dont agree on the interpretation of the txn handling for invite. Sure, there is a timer for handling retransmitted responses, but thats in earlier states than Terminated. Sure, there is nothing that says that the inner workings of your transactions must exactly behave as the statemachine diagrams in the rfc as long as the external behavior stays the same, but still, I think that the ACK for 2xx should not match the INVITE txn. (It probably boils down to how rfc-isch you want to be.) >The end-to-end ACK establish a separate transaction (RFC 3261) and these >ACKs are not match as part of the INVITE transactions, but correlated >with them. [TQ] Where does it say that ACKs establish a separate transaction? There is no defined ACK transaction, only INVITE/nonInvite, server and client. The ACK is either a part of the INVITE txn, or its a separate request, but I would never call it a standalone transaction. The real purpose of txn's (in my view), is to enable/simplify forking, and to handle retransmissions. Retransmissions of ACK and 2xx, are done by the UAC/UAS, so there is no need for a ack-txn. >but even describe the wait timer. So, there is no contradiction. [TQ] I'd say there is. Where does it describe that this wait-timer should be used for all responses, or for matching ALL acks? My two main reasons for saying that ACKs for 2xx should not be matched, come from the following two texts. (17.1.1.2, and 17.2.1) 17.1.1.2 (client invite txn) The client transaction MUST be destroyed the instant it enters the > "Terminated" state. This is actually necessary to guarantee correct operation. The reason is that 2xx responses to an INVITE are treated differently; each one is forwarded by proxies, and the ACK handling in a UAC is different. Thus, each 2xx needs to be passed to a proxy core (so that it can be forwarded) and to a UAC core (so it can be acknowledged). No transaction layer processing takes place. Whenever a response is received by the transport, if the transport layer finds no matching client transaction (using the rules of Section 17.1.3), the response is passed directly to the core. Since the matching client transaction is destroyed by the first 2xx, > subsequent 2xx will find no match and therefore be passed to the core. [TQ] It even says "actually nessesary to guarantee...." Since the txn's are there to (among other things) absorb retransmissions, the receiving the 2xx MUST destroy the txn, so that when the next retransmission of 2xx is received, it is not consumed by the txn layer. This is what your txn-layer does for 3++ right? Any additional 3++ received on a txn while waiting for Timer D to expire, will just be consumed, and the proxy core will never have to process it. 17.2.1. (server invite txn) The purpose of the "Confirmed" state is to absorb any additional ACK messages that arrive, triggered from retransmissions of the final response. ..snip... Once the transaction is in the "Terminated" state, it MUST be destroyed immediately. [TQ] The Confirmed state is there to absorb retransmissions, not the terminated. When receiving 2xx you go directly to terminated bypassing confirmed. Also, in 18.2.1 the text explicitly says: .. Note that when a UAS core sends a 2xx response to INVITE, the server transaction is destroyed. This means that when the ACK arrives, there will be no matching server transaction, and based on this rule, the ACK is passed to the UAS core, where it is processed. Thats faily clear right? :-) The think that puzzles my a little bit though, is that you must have added "extra" code for this matching...? I mean, you're using the ;branch=z9xxxx for transaction matching right, if its there? And the ACK for 2xx doesnt have the same branch, indicating a "new txn". So matching ALL ACKs would imply that for any ACK that doesnt match a txn, your really checking up Call-Id's, tags and stuff, just to be able to match this ACK to the 2xx? Or are you checking callid's, cseq's, tags, and stuff, for ALL requests in your txn matching? Now, I been working on a sip-stack the last few years myself, and I naturally know that there is often a need to match the ACK, and the stack I've build has similar functions, it just doesnt do it on the txn layer, where we try to be as RFC-isch as possible. What I would like, is simply have some function-parameters to the t_check_trans(<param>), or even better in my little mind, a "modparam("tm", "ack_2xx_matching", 1)". I am looking forward to hearing your reply, and in the mean time, thanks to all of you developers for an extraordinary software :-) Regards Taisto Qvist > Hi guys, > > Just to bring some clarifications on the TM module. > > once a transaction is completed (negative or 2xx reply), it is put on > wait (wait timer - see RFC3261) for catching any potential > retransmissions of replies. > So, the transaction is completed, but not removed from memory - RFC does > not say that you need to trash immediately all the transaction > information, but even describe the wait timer. So, there is no > contradiction. > > The ACK (for 2xx)catching is done based on the completed INVITE > transaction (from wait timer) - nothing else. > > > Inaki, could you please detail what you mean by: > > <quote> > In my opinion OpenSer does a special treatment for ACK in tm mode, even if > they are for failed transaction (hop-by-hop ACK's) or succesfull INVITE > (end-to-end ACK's). > > </quote> > > Maybe I can explain you more if I understand you question.... > > Regards, > Bogdan

3 2

[OpenSER-Users] How to account INVITEs and not "200 OK"s?
by Peter Lemenkov 15 Feb '08

15 Feb '08

Hello All! Right now OpenSER generates Acc-Session-Start when "200 OK" message arrives. I need to generate Acc-Session-Start exactly in that moment when INVITE received (I can't need to wait for answer from other side). So how can I do it? -- With best regards!

3 6

Re: [OpenSER-Users] Failover using NAPTR/SRV
by Bogdan-Andrei Iancu 15 Feb '08

15 Feb '08

Of course it is.....by IETF - see RFC3263. 4.3 Details of RFC 2782 Process Regards, Bogdan Douglas Garstang wrote: > Well that's weird. What do you mean by 'fail'? I thought dns_blacklist > was used when a 503 response was received? What if the connection > times out? What if another negative reply is received? Is this stuff > documented anywhere? > > ----- Original Message ---- > From: Bogdan-Andrei Iancu <bogdan(a)voice-system.ro> > To: Tobias Lindgren <tobias.lindgren(a)ip-only.se> > Cc: users(a)openser.org > Sent: Thursday, February 14, 2008 3:25:33 AM > Subject: Re: [OpenSER-Users] Failover using NAPTR/SRV > > Hi Tobias, > > if you have "dns_backlist=yes" in your config, if one of the destination > server fails (according to SIP definition), it's IP will be added to a > temporary blacklist (for 4 minutes) and not used. So, openser should do > dns-based failover and use the next entry provided by NAPTR/SRV/A lookup. > > Regards, > Bogdan > > Tobias Lindgren wrote: > > Hi all, > > > > I've been trying to find this information but I cannot find any exact > > specifications on how it really works. > > > > >From what I know using NAPTR/SRV records with OpenSER will allow > it to > > find and use servers behind those DNS-records. This works just fine. > > > > However, what I'm not sure about is what actually will happen in > OpenSER > > when one of two servers in this scenario would fail. > > > > For example, I have two servers as SRV where one is primary and one is > > secondary for SIP/UDP. What will happend in OpenSER when the primary > > server is down? Will OpenSER continue to send all request first towards > > that server or will it learn that one server is down and always send > > requests to the second server for a period of time and try the primary > > one just occassionally? > > > > Please direct me to any page where this is explained in detail, if such > > page exists. > > > > Br, > > /Tobias > > > > _______________________________________________ > > Users mailing list > > Users(a)lists.openser.org <mailto:Users@lists.openser.org> > > http://lists.openser.org/cgi-bin/mailman/listinfo/users > > > > > > > _______________________________________________ > Users mailing list > Users(a)lists.openser.org <mailto:Users@lists.openser.org> > http://lists.openser.org/cgi-bin/mailman/listinfo/users > > > ------------------------------------------------------------------------ > Never miss a thing. Make Yahoo your homepage. > <http://us.rd.yahoo.com/evt=51438/*http://www.yahoo.com/r/hs>

1 0

Re: [OpenSER-Users] Radius Acct Syntax Error?
by A.smith 15 Feb '08

15 Feb '08

>modparam("acc", "radius_config", "/usr/local/etc/radiusclient/ >radiusclient.conf"); I think you dont need the ";" as this isnt the last param you set for acc, other than that in theory this should be fine, i have had similar config working, it does need to be a single line of text of course and I dont know if its just the way it apears on the list but there seems to be white space between radiusclient/ and radiusclient.conf Also I´ve had issues with non-printable characters being in my config file from copying and pasting from web pages srewing up what looks like a properly formated cfg, maybe check this...?? cheers Andy. ________________________________________________ Message sent using UK Grid Webmail 2.7.9

1 0

[OpenSER-Users] OpenXcap + Presence
by Andreas M. 15 Feb '08

15 Feb '08

Hello, i installed OSER 1.3-SVN and openxcap-0.9.9 (does not work with OSER 1.2 :) ) XCAP Server is running, also openser, but i can´t see any presence status, clients sends publish but no notifys are sent out. i´m using latest eyebeam clients, i can also see that privacy rules are updated in the xcap database, but subscribtion status is always pending. i can see that xcap doc is loaded through a query, but status is pending. Had a long time presence running mit "force_active = 1", but now i want to introduce also xcap functionality. Where can i start to debug ? r, Andreas M. presence config: ## presence module modparam("presence", "db_url","mysql://xx:xx@127.0.0.1/presence") modparam("presence", "presentity_table", "presentity") modparam("presence", "active_watchers_table", "active_watchers") modparam("presence", "watchers_table", "watchers") modparam("presence", "clean_period", 100) modparam("presence", "to_tag_pref", 'mango') modparam("presence", "expires_offset", 10) modparam("presence", "max_expires", 3600) modparam("presence", "server_address", "sip:10.0.0.1:5065") modparam("presence", "fallback2db", 1) modparam("presence_xml", "db_url","mysql://xxx:xxx@127.0.0.1/presence") modparam("presence_xml", "xcap_table", "xcap") modparam("presence_xml", "force_active", 0) modparam("presence_xml", "pidf_manipulation", 0) modparam("presence_xml", "integrated_xcap_server", 1) also i can see following query in my sql log, that does not work (field does not exists) select id from watchers where inserted_time<1202992297 AND subs_status='pending' source: CREATE TABLE `watchers` ( `id` int(10) unsigned NOT NULL auto_increment, `presentity_uri` varchar(128) NOT NULL, `watcher_username` varchar(64) NOT NULL, `watcher_domain` varchar(64) NOT NULL, `event` varchar(64) NOT NULL default 'presence', `status` int(11) NOT NULL, `reason` varchar(64) default NULL, `inserted_time` int(11) NOT NULL, PRIMARY KEY (`id`), UNIQUE KEY `watcher_idx` (`presentity_uri`,`watcher_username`,`watcher_domain`,`event`) ) ENGINE=MyISAM AUTO_INCREMENT=10 DEFAULT CHARSET=latin1; -- g, Andreas M.

1 0

Re: [Serusers] Fwd: SIP Express Bundle ready-to-go idea, request for input
by Mike Trest - Personal 15 Feb '08

15 Feb '08

Thanks Karel ! I will try the CVS version. ..mike.. At 07:26 AM 2/15/2008, you wrote: >Hi, >the serweb from CVS head is ready to work with 2.0. So you cold >either download it from CVS or use debian package that we also have. >Unfotunately I do not remember URL of package repository. Pavel, >could you remind it? > >regards >Karel > >Mike Trest - Personal napsal(a): >>Hi, >>Can someone guide me to a WEBSER that is in-alignment with current SER-2.0? >>I find myself hacking away serweb-0.9.6 to deal with older >>subscriber with aliases tables >>while running multiple SER-2.0 with a newer table setup. If a >>developer has a WEBSER >>that already works with 2.0 data tables, or there is a 2.0-ready >>webser in CVS tree, >>please advise me by EMAIL how to get it. This will move us closer >>to a complete bundle. >>After serweb, I hope to move onward to the media server. >>..mike.. >> >>At 01:49 AM 2/14/2008, you wrote: >>>All, >>>We started this thread few months ago. Havn't seen any progress >>>since then. Is this still alive. >>> >>>Thank you, >>>-Jai >>> >>> >>> >>>On Fri, Dec 7, 2007 at 1:05 PM, Mike Trest - Personal >>><Mike(a)trest.com <mailto:Mike@trest.com>> wrote: >>> >>> Greger, et. al., >>> I like your idea enough to volunteer as a tester + documentation >>> writer. I do a lot of tech and user writing. Active in >>> VoIP since the >>> beginning. >>> I am active VoIP engineer and developer. Also PSTN & VoIP >>> network designer-builder. I have my own private machines, >>> network, and VoIP gateway resources. >>> Prefer CentOS or FC* ..mike.. >Hi guys, >I have >>> been playing with the following idea: >Create a ready-to-run >>> OS image with everything that is needed for >iptel.org >>> <http://iptel.org> apps pre-installed + a complete >>> installation of: >* SER 2.0 (release) >* >>> rtpproxy >* SEMS >* SERweb >* maybe sipsak, some >>> monitoring tools, etc > > >The idea is to create a >>> small script 'config_iptelorg' for >configuring the >>> installation to your needs. You should then be able >to >>> download the ready image, boot it, go through the script and >>> have >an up and running iptel.org <http://iptel.org> proxy and app >>> server just like the >iptel.org <http://iptel.org> free >>> SIP service in maybe 10-15 >>> minutes. This way you >could host a SIP service for your >>> own domain with close to no >>> setup at all. > >Some questions to you: >* Is >>> there any interest for this at all? >* I was thinking about >>> using Ubuntu 7.10 server as the OS. >>> Any >thoughts/preferences? >* Should the image be an >>> Amazon EC3 image (you could use >http://www.rightscale.com >>> and get it running in no time with 10 >run-hours free) or >>> should it be a VMware appliance to be run with >free VMware >>> Player? >* Other suggestions/comments? > >I could >>> need some help with this, anyone interested in lending me >>> a >hand? (could be anything, documentation, testing, >>> installation, etc) >g-) >>> _______________________________________________ Serusers >>> mailing list Serusers(a)lists.iptel.org >>> <mailto:Serusers@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 >>------------------------------------------------------------------------ >>_______________________________________________ >>Serusers mailing list >>Serusers(a)lists.iptel.org >>http://lists.iptel.org/mailman/listinfo/serusers

1 0

Re: [Serusers] Fwd: SIP Express Bundle ready-to-go idea, request for input
by Mike Trest - Personal 15 Feb '08

15 Feb '08

Hi, Can someone guide me to a WEBSER that is in-alignment with current SER-2.0? I find myself hacking away serweb-0.9.6 to deal with older subscriber with aliases tables while running multiple SER-2.0 with a newer table setup. If a developer has a WEBSER that already works with 2.0 data tables, or there is a 2.0-ready webser in CVS tree, please advise me by EMAIL how to get it. This will move us closer to a complete bundle. After serweb, I hope to move onward to the media server. ..mike.. At 01:49 AM 2/14/2008, you wrote: >All, >We started this thread few months ago. Havn't seen any progress >since then. Is this still alive. > >Thank you, >-Jai > > > >On Fri, Dec 7, 2007 at 1:05 PM, Mike Trest - Personal ><<mailto:Mike@trest.com>Mike(a)trest.com> wrote: >Greger, et. al., >I like your idea enough to volunteer as a tester + documentation writer. > I do a lot of tech and user writing. Active in VoIP since the beginning. >I am active VoIP engineer and developer. Also PSTN & VoIP network >designer-builder. >I have my own private machines, network, and VoIP gateway resources. >Prefer CentOS or FC* >..mike.. > >Hi guys, > >I have been playing with the following idea: > >Create a ready-to-run OS image with everything that is needed for > ><http://iptel.org>iptel.org apps pre-installed + a complete > installation of: > >* SER 2.0 (release) > >* rtpproxy > >* SEMS > >* SERweb > >* maybe sipsak, some monitoring tools, etc > > > > > >The idea is to create a small script 'config_iptelorg' for > >configuring the installation to your needs. You should then be able > >to download the ready image, boot it, go through the script and have > >an up and running <http://iptel.org>iptel.org proxy and app server > just like the > ><http://iptel.org>iptel.org free SIP service in maybe 10-15 > minutes. This way you > >could host a SIP service for your own domain with close to no setup at all. > > > >Some questions to you: > >* Is there any interest for this at all? > >* I was thinking about using Ubuntu 7.10 server as the OS. Any > >thoughts/preferences? > >* Should the image be an Amazon EC3 image (you could use > ><http://www.rightscale.com>http://www.rightscale.com and get it > running in no time with 10 > >run-hours free) or should it be a VMware appliance to be run with > >free VMware Player? > >* Other suggestions/comments? > > > >I could need some help with this, anyone interested in lending me a > >hand? (could be anything, documentation, testing, installation, etc) > >g-) >_______________________________________________ >Serusers mailing list ><mailto:Serusers@lists.iptel.org>Serusers(a)lists.iptel.org >http://lists.iptel.org/mailman/listinfo/serusers > > >_______________________________________________ >Serusers mailing list >Serusers(a)lists.iptel.org >http://lists.iptel.org/mailman/listinfo/serusers

2 1

[OpenSER-Users] CDRTool: Wrong column names in "customers" table?
by Iñaki Baz Castillo 15 Feb '08

15 Feb '08

Hi, using CDRTool 6.1.7. In the Rating section I select "Customers". This view is in fact related to the "billing_customers" table, but the column names look like incorrect: Web MySQL Table --------------------------------------------------------------------------- Gateway gateway Domain domain Subscriber subscriber WeekDay profile_name1 Fallback profile_name1_alt WeekEnd profile_name2 Fallback profile_name2_alt Timezone timezone Incr increment Minim min_duration Are the names asigned to "profile_name*" correct? -- Iñaki Baz Castillo ibc(a)in.ilimit.es

2 2

[OpenSER-Users] UAC tries to register after UAC WAN out but re-registration unsuccessful
by Raju Abhyankar 15 Feb '08

15 Feb '08

Hi, I have setup openser-1.1.1-tls and using it along with Mediaproxy. I have several clients (UAC) which are Grandstream HT486 rev2.0. All clients are behind consumer grade routers such as Linksys, Dlink etc. Few of our clients are over seas and they do see: 1. Frequent power outages 2. ADSL (WAN) link drops at client end Now what we see for item 1, there is no issue, usually power goes off to ADSL modem, router and UAC and it all come back up nicely. For item 2 we see that we can see when WAN goes out and comes back with a diff WAN IP (ADSL): A. UAC sends register request to openser B. openser says "Trying 100" C. Then openser challenges the client with a 401 unauthorized D. After some time UAC resends Register request and this goes on and on and on...till we ask some one to power the UAC (only) off and power it back on. Is there a way to get around this issue? I am using the following Register sequence in openser: # ----------------------------------------------------------------- # REGISTER Message Handler # ---------------------------------------------------------------- sl_send_reply("100", "Trying"); if (!search("^Contact:[ ]*\*") && client_nat_test("7")) { setflag(6); fix_nated_register(); force_rport(); }; if (!www_authorize("","subscriber")) { www_challenge("","0"); return; }; if (!check_to()) { sl_send_reply("401", "Unauthorized"); return; }; consume_credentials(); if (!save("location")) { sl_reply_error(); };

1 0

[Serusers] xlog printing for $avp
by Mike Trest - Personal 14 Feb '08

14 Feb '08

In the 2.0 xlog function , how does one print an $avp value? I do not see how to print something that is NOT a part of the SIP request. ..mike..

2 1

Re: [OpenSER-Users] id openser mising?
by Kalinda G 14 Feb '08

14 Feb '08

Openser admins! I did installation of OpenSER using the source from SVN, and noticed that openser unix id no longer added by itself during installation (i.e. make all; make install). See the following file which state that openser to be started by id openser. $ egrep "USER|GROUP" /etc/default/openser USER=openser GROUP=openser $ I can manually add openser but want to make sure if something got broken along the line. Btw, there was another installation done 2007-12-26 via SVN, I do not re-call adding this id manually. Could someone confirm this please. Suppose this id has to be added manually, what other associated items need to reflect this change. Thanks! ~gkalinda

6 7

[OpenSER-Users] Failover using NAPTR/SRV
by Tobias Lindgren 14 Feb '08

14 Feb '08

Hi all, I've been trying to find this information but I cannot find any exact specifications on how it really works. From what I know using NAPTR/SRV records with OpenSER will allow it to find and use servers behind those DNS-records. This works just fine. However, what I'm not sure about is what actually will happen in OpenSER when one of two servers in this scenario would fail. For example, I have two servers as SRV where one is primary and one is secondary for SIP/UDP. What will happend in OpenSER when the primary server is down? Will OpenSER continue to send all request first towards that server or will it learn that one server is down and always send requests to the second server for a period of time and try the primary one just occassionally? Please direct me to any page where this is explained in detail, if such page exists. Br, /Tobias

2 2

Re: [OpenSER-Users] ERROR: couldn't open sequence file /var/run/radius.seq
by A.smith 14 Feb '08

14 Feb '08

>The problem is that OpenSer run with "openser" user who has not write access >to /var/run. If I change permissions to /var/run the the message doesn't >appear. Create the file manually as root for new OpenSER installation and change the ownership to openser. On my system the file is never delete by OpenSER so no problem once it exists. cheers Andy. ________________________________________________ Message sent using UK Grid Webmail 2.7.9

2 1

[OpenSER-Users] openfire xmpp
by TCB 14 Feb '08

14 Feb '08

Antone tried out openfire and xmpp ? -- TC

2 1

Re: [OpenSER-Users] [CDRTool] How to get the "In" and "Out"
by A.smith 14 Feb '08

14 Feb '08

>Just to clarify, are you speaking about "In" and "Out" columns? do you see >values "In" and "Out" in some of the records in those columns? Oops! Sorry, yeah wasnt talking about the same thing :P No, I see nothing in these columns either. Not sure what they are for, something to do with routing to/from PSTN gateway? In my environment I have no working PSTN gateway (I just have a test rig). cheers Andy. ________________________________________________ Message sent using UK Grid Webmail 2.7.9

1 0

Re: [OpenSER-Users] [CDRTool] How to get the "In" and "Out"
by A.smith 14 Feb '08

14 Feb '08

Hola, >So you see "In" or/and "Out"... ANd do you mean that this info is provided by >MediaProxy instead of be deduced by CDRTool in some way? Yes, I believe this info is provided by mediaproxy as it relates to the KB of RTP data relayed by mediaproxy, this cannot be deduced as you need to be sitting in the data stream to know this... Sounds like the level of functionality provided by mediaproxy DB accouting and radius accouting are not the same. FYI here is an example of the information I see with DB accouting: (this is shown in the signalling information section of CDRTool and also I see data in the KBIn KBout sections in the summary) Media information Application: audio Codecs: G711u Caller RTP: 658.59 KB Called RTP: 653.55 KB Caller SIP UA: Asterisk PBX Called SIP UA: NCH Swift Sound Express Talk 3.02 ________________________________________________ Message sent using UK Grid Webmail 2.7.9

2 1

[OpenSER-Users] OpenSER 1.2.X - Is it possible to check if callee in NAT-ed network?
by David Loh 14 Feb '08

14 Feb '08

Hi Guys, I've encountered one-way voice situation, where caller on Public IP make a P2P call to callee behind NAT, wondering is there any OpenSER module/function that could actually query callee's network type, if OpenSER can detect callee network (whether it's NAT or not), I can use rtp proxy to overcome the one-way voice. Currently my setup works on following: Caller --- Callee 1) WAN to WAN 2) NAT to NAT (force_rtp_proxy) 3) NAT to WAN (force_rtp_proxy) but for the WAN to NAT case, due to the caller aren't behind NAT, I didn't run force_rtp_proxy, but whenever the P2P call established, it result one-way voice. I'm thinking of querying the callee detail from database via AVP, but it doesn't sound feasible; wondering if there's any better solution. P/S: My openser.cfg (INVITE route) ------------------------------- route[3] { if(nat_uac_test("19")) { fix_nated_contact(); } # 10* = P2P call if(uri=~"^sip:10\*.+@.*") { strip(3); if(!lookup("location")) { xlog("L_INFO", "DBG: P2P Peer not found [$tu] from [$fu]($si)"); sl_send_reply("404", "User Offline"); exit; } xlog("L_INFO", "DBG: P2P Call [$fu]($si) to [$tu]"); # For NAT-to-WAN or NAT-to-NAT, supposedly WAN-to-NAT should run this too :( if(nat_uac_test("19") || search("^Route:.*;nat=yes")) { # onreply_route[2] will do a "force_rtp_proxy" t_on_reply("2"); force_rtp_proxy(); xlog("L_INFO", "DBG: NAT-ed P2P Call, RTP Proxy Forced [$fu]($si)"); } } else if(!proxy_authorize("", "subscriber")) { xlog("L_INFO", "DBG: INVITE [$fu]($si) PROXY authentication FAILED"); proxy_challenge("", "1"); exit; } if(!check_from()) { xlog("L_INFO", "INVITE Spoofed From-URI detected - RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); sl_send_reply("403", "Spoofed From-URI Detected"); exit; } rewritehost("1.2.3.4"); } t_on_reply("1"); t_on_failure("1"); t_relay(); xlog("L_INFO", "DBG: INVITE F-[$fu] T-[$tu] IP-[$si] UA-[$ua] SUCCESSFUL"); } ------------------------------- Thanks, David Loh

1 0

Re: [OpenSER-Users] FreeRADIUS-CDRTool Prepaid Connector 1.1 Released
by A.smith 14 Feb '08

14 Feb '08

Hi Dan/List, I was reading the post below and trying to understand how your config works. If you are implementing this with something like a Cisco PSTN then you need all of these: PSTN, OpenSER, Mediaproxy and Yate involved in the SIP route? Does the RTP stream have to route via Yate and mediaproxy? :S thanks for any help! cheers Andy. >Hey Marc, > >I use Yate for doing that. It is simple and works out of the box (with adding few >lines in configs of course). > >I take Session timeout returned from connector and pass it to yate in a sip header >Process that header in regex routing and define the value as timeout for session. >Yate knows by default that when a session has a parameter "timeout" returned >from routing to disconnect the call when timeout is hit. > >Let me know if you need further info, so I can send you some config files if you >want to. You can contact me on IRC for live support (DanB). > > >All the best, >DanB ________________________________________________ Message sent using UK Grid Webmail 2.7.9

4 6

[Serusers] How do you really get rtpptoxy to pass audio between two interfaces?
by Frank Durda IV 13 Feb '08

13 Feb '08

Having abandoned from mediaproxy (which could not cope with a network setup with two or more interfaces), I switched to rtpproxy, but find that it also is not doing the right thing, although it gets closer that mediaproxy does. Perhaps someone will know what the missing piece of this is. To recap, we have three networks connected to the SER+rtpproxy server: 192.168.200.x/24 Connects to various SIP phones and Asterisk server(s). Can be thought to eventually be the network where the SIP clients will all be. Our players in this lab setup are: 192.168.200.10 An Asterisk server 192.168.200.20 A Linksys SIP phone - (SIP+RTP for phone goes via Asterisk server so you won't see this addr at SER server) 192.168.200.30 an interface on the SER server (re2) 10.9.193.132/28 Connects to the various SIP ports on a Class 5 PSTN switch. Only SIP packets pass on this network, eg these can't handle RTP packets. Here, our visible devices are: 10.9.193.130 The active PSTN switch SIP signaling port. 10.9.193.135 An interface on the SER server (re1) 10.9.193.142/29 Connects to the bearer/voice ports on a Class 5 PSTN switch. These are isolated ports, eg, all they do is RTP packets and no SIP packets. The devices here: 10.9.193.146 The active PSTN switch voice bearer port. 10.9.193.148 An interface on the SER server (re0) NONE of these networks can physically see the other nor router traffic, except for what passes through either SER or rtpproxy/mediaproxy. This isolation is intentional and needed because the PSTN switch has no built-in protection against unexpected/unwanted IP traffic. Of the three networks, only two handle RTP/bearer data, and only two handle SIP data. ---------------------------------------------------------------------------- What happens (or doesn't happen): The symptom is that someone (probably rtpproxy) isn't re-writting the correct IP address into the SDP payload emitted by SER, and so the calling party (or PSTN switch party) is editing in an unreachable IP address to send bearer traffic to. So rtpproxy never gets going and you have no two-way audio, although you can see audio packets being emitted by both parties, one hopelessly mis-addresed, and the others audio reaching the SER/rtpproxy server, but apparently not allowed to pass until an audio packet from the other party arrives, which will not be happening. In addition, rtpproxy doesn't listen for RTP packets on both interfaces, so one side of the conversation is always inaccessible, and since both sides must be able to send at least one audio packet for the proxy process to begin, no audio is passed in either direction. ---------------------------------------------------------------------------- A sample call and the SIP messages: 1. The Asterisk server contacts the SER server with the INVITE. It says the audio should go to 192.168.200.10:10860 (which is also the Asterisk box) # U 2008/02/13 13:58:24.691638 192.168.200.10:5060 -> 192.168.200.30:5060 INVITE sip:9613789999@192.168.200.30 SIP/2.0. Via: SIP/2.0/UDP 192.168.200.10:5060;branch=z9hG4bK3ef39ef4;rport. From: "VOIP TEST 1000" <sip:3797271700@192.168.200.30>;tag=as0458f259. To: <sip:9613789999@192.168.200.30>. Contact: <sip:3797271700@192.168.200.10>. Call-ID: 5d27b24903963a384c98f4701f0ce456(a)192.168.200.30. CSeq: 102 INVITE. User-Agent: Asterisk PBX. Max-Forwards: 70. Date: Wed, 13 Feb 2008 14:00:08 GMT. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Content-Type: application/sdp. Content-Length: 475. . v=0. o=root 23759 23759 IN IP4 192.168.200.10. s=session. c=IN IP4 192.168.200.10. t=0 0. m=audio 10860 RTP/AVP 0 3 8 112 5 10 7 97 111 101. a=rtpmap:0 PCMU/8000. a=rtpmap:3 GSM/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:112 AAL2-G726-32/8000. a=rtpmap:5 DVI4/8000. a=rtpmap:10 L16/8000. a=rtpmap:7 LPC/8000. a=rtpmap:97 iLBC/8000. a=fmtp:97 mode=30. a=rtpmap:111 G726-32/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=silenceSupp:off - - - -. a=ptime:20. a=sendrecv. 2. SER send an INVITE message on to the PSTN switch. It has correctly put its own address as where the audio should be sent later on. c=IN IP4 10.9.193.148:35010 # U 2008/02/13 13:58:24.697275 10.9.193.135:5060 -> 10.9.193.130:5060 INVITE sip:9613789999@10.9.193.130:5060 SIP/2.0. Record-Route: <sip:10.9.193.135;r2=on;ftag=as0458f259;lr=on>. Record-Route: <sip:192.168.200.30;r2=on;ftag=as0458f259;lr=on>. Via: SIP/2.0/UDP 10.9.193.135;branch=z9hG4bK606.deb16814.0. Via: SIP/2.0/UDP 192.168.200.10:5060;branch=z9hG4bK3ef39ef4;rport=5060. From: "VOIP TEST 1000" <sip:3797271700@192.168.200.30>;tag=as0458f259. To: <sip:9613789999@192.168.200.30>. Contact: <sip:3797271700@192.168.200.10:5060>. Call-ID: 5d27b24903963a384c98f4701f0ce456(a)192.168.200.30. CSeq: 102 INVITE. User-Agent: Asterisk PBX. Max-Forwards: 16. Date: Wed, 13 Feb 2008 14:00:08 GMT. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Content-Type: application/sdp. Content-Length: 491. . v=0. o=root 23759 23759 IN IP4 192.168.200.10. s=session. c=IN IP4 10.9.193.148. t=0 0. m=audio 35010 RTP/AVP 0 3 8 112 5 10 7 97 111 101. a=rtpmap:0 PCMU/8000. a=rtpmap:3 GSM/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:112 AAL2-G726-32/8000. a=rtpmap:5 DVI4/8000. a=rtpmap:10 L16/8000. a=rtpmap:7 LPC/8000. a=rtpmap:97 iLBC/8000. a=fmtp:97 mode=30. a=rtpmap:111 G726-32/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=silenceSupp:off - - - -. a=ptime:20. a=sendrecv. a=nortpproxy:yes. 3. The PSTN switch send back a TRYING message. # U 2008/02/13 13:58:24.701458 10.9.193.130:5060 -> 10.9.193.135:5060 SIP/2.0 100 Trying. Call-ID: 5d27b24903963a384c98f4701f0ce456(a)192.168.200.30. CSeq: 102 INVITE. From: "VOIP TEST 1000" <sip:3797271700@192.168.200.30>;tag=as0458f259. To: <sip:9613789999@192.168.200.30>;tag=17b0000-0-1077770870. Via: SIP/2.0/UDP 10.9.193.135;branch=z9hG4bK606.deb16814.0. Via: SIP/2.0/UDP 192.168.200.10:5060;branch=z9hG4bK3ef39ef4;rport=5060. Server: DC-SIP/1.2. Supported: timer. Record-Route: <sip:10.9.193.135;r2=on;ftag=as0458f259;lr=on>. Record-Route: <sip:192.168.200.30;r2=on;ftag=as0458f259;lr=on>. Contact: <sip:9613789999@10.9.193.130>. Content-Length: 0. . 4. SER server sends the TRYING message on to Asterisk. # U 2008/02/13 13:58:24.696951 192.168.200.30:5060 -> 192.168.200.10:5060 SIP/2.0 100 trying -- your call is important to us. Via: SIP/2.0/UDP 192.168.200.10:5060;branch=z9hG4bK3ef39ef4;rport=5060. From: "VOIP TEST 1000" <sip:3797271700@192.168.200.30>;tag=as0458f259. To: <sip:9613789999@192.168.200.30>. Call-ID: 5d27b24903963a384c98f4701f0ce456(a)192.168.200.30. CSeq: 102 INVITE. Server: Sip EXpress router (0.9.6 (i386/freebsd)). Content-Length: 0. . 5. PSTN switch sends the SER box a RINGING message. # U 2008/02/13 13:58:24.799647 10.9.193.130:5060 -> 10.9.193.135:5060 SIP/2.0 180 Ringing. Call-ID: 5d27b24903963a384c98f4701f0ce456(a)192.168.200.30. CSeq: 102 INVITE. From: "VOIP TEST 1000" <sip:3797271700@192.168.200.30>;tag=as0458f259. To: <sip:9613789999@192.168.200.30>;tag=17b0000-0-1077770870. Via: SIP/2.0/UDP 10.9.193.135;branch=z9hG4bK606.deb16814.0. Via: SIP/2.0/UDP 192.168.200.10:5060;branch=z9hG4bK3ef39ef4;rport=5060. Server: DC-SIP/1.2. Supported: timer. Record-Route: <sip:10.9.193.135;r2=on;ftag=as0458f259;lr=on>. Record-Route: <sip:192.168.200.30;r2=on;ftag=as0458f259;lr=on>. Contact: <sip:9613789999@10.9.193.130>. Content-Length: 0. . 6. SER box sends on the RINGING message to the Asterisk box. # U 2008/02/13 13:58:24.802106 192.168.200.30:5060 -> 192.168.200.10:5060 SIP/2.0 180 Ringing. Call-ID: 5d27b24903963a384c98f4701f0ce456(a)192.168.200.30. CSeq: 102 INVITE. From: "VOIP TEST 1000" <sip:3797271700@192.168.200.30>;tag=as0458f259. To: <sip:9613789999@192.168.200.30>;tag=17b0000-0-1077770870. Via: SIP/2.0/UDP 192.168.200.10:5060;branch=z9hG4bK3ef39ef4;rport=5060. Server: DC-SIP/1.2. Supported: timer. Record-Route: <sip:10.9.193.135;r2=on;ftag=as0458f259;lr=on>. Record-Route: <sip:192.168.200.30;r2=on;ftag=as0458f259;lr=on>. Contact: <sip:9613789999@10.9.193.130:5060>. Content-Length: 0. . 7. PSTN switch indicates the called party has answered to SER and gives its bearer/audio address & port (10.9.193.146:28006). # U 2008/02/13 13:58:32.736665 10.9.193.130:5060 -> 10.9.193.135:5060 SIP/2.0 200 OK. Call-ID: 5d27b24903963a384c98f4701f0ce456(a)192.168.200.30. CSeq: 102 INVITE. From: "VOIP TEST 1000" <sip:3797271700@192.168.200.30>;tag=as0458f259. To: <sip:9613789999@192.168.200.30>;tag=17b0000-0-1077770870. Via: SIP/2.0/UDP 10.9.193.135;branch=z9hG4bK606.deb16814.0. Via: SIP/2.0/UDP 192.168.200.10:5060;branch=z9hG4bK3ef39ef4;rport=5060. Server: DC-SIP/1.2. Supported: timer. Record-Route: <sip:10.9.193.135;r2=on;ftag=as0458f259;lr=on>. Record-Route: <sip:192.168.200.30;r2=on;ftag=as0458f259;lr=on>. Contact: <sip:9613789999@10.9.193.130>. Content-Type: application/sdp. Content-Length: 175. . v=0 o=- 3411921616 3411921696 IN IP4 10.9.193.130 s=- c=IN IP4 10.9.193.146 t=0 0 m=audio 28006 RTP/AVP 0 a=sendrecv a=ptime:20 a=rtpmap:0 PCMU/8000 a=silenceSupp:off - - - - 8. SER sends Asterisk the OK with the edited-but-WRONG bearer IP address 10.9.193.148:35012, INSTEAD of the reachable 192.168.200.30:35012 value that should have been sent. # U 2008/02/13 13:58:32.743185 192.168.200.30:5060 -> 192.168.200.10:5060 SIP/2.0 200 OK. Call-ID: 5d27b24903963a384c98f4701f0ce456(a)192.168.200.30. CSeq: 102 INVITE. From: "VOIP TEST 1000" <sip:3797271700@192.168.200.30>;tag=as0458f259. To: <sip:9613789999@192.168.200.30>;tag=17b0000-0-1077770870. Via: SIP/2.0/UDP 192.168.200.10:5060;branch=z9hG4bK3ef39ef4;rport=5060. Server: DC-SIP/1.2. Supported: timer. Record-Route: <sip:10.9.193.135;r2=on;ftag=as0458f259;lr=on>. Record-Route: <sip:192.168.200.30;r2=on;ftag=as0458f259;lr=on>. Contact: <sip:9613789999@10.9.193.130:5060>. Content-Type: application/sdp. Content-Length: 193. . v=0 o=- 3411921616 3411921696 IN IP4 10.9.193.130 s=- c=IN IP4 10.9.193.148 t=0 0 m=audio 35012 RTP/AVP 0 a=sendrecv a=ptime:20 a=rtpmap:0 PCMU/8000 a=silenceSupp:off - - - - a=nortpproxy:yes. And DING, we are in trouble, because the 10.9.193.148 is the wrong IP address on the SER/rtpproxy box that the Asterisk server should send the audio to, a network that the Asterisk server can't reach. SER/rtpproxy should have edited that to read c=IN IP4 192.168.200.30 the interface facing towards the SIP phone, one of the two interfaces specified in the SER config file and rtpproxy invocation, AND started listening there. So, no audio from Asterisk will ever reach the SER/rtpproxy box, and rtpproxy will just sit there and wait. Note also that rtpproxy only listens on one of the interfaces specified: lsof -p 852 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME rtpproxy 852 root cwd VDIR 0,90 512 2 / rtpproxy 852 root rtd VDIR 0,90 512 2 / rtpproxy 852 root txt VREG 0,93 71102 386745 /usr/local/bin/rtpproxy rtpproxy 852 root txt VREG 0,90 158712 94213 /libexec/ld-elf.so.1 rtpproxy 852 root txt VREG 0,90 922668 235591 /lib/libc.so.6 rtpproxy 852 root 0u VCHR 0,6 0t0 6 /dev/null rtpproxy 852 root 1u VCHR 0,6 0t0 6 /dev/null rtpproxy 852 root 2u VCHR 0,6 0t0 6 /dev/null rtpproxy 852 root 3u unix 0xc2e4d164 0t0 /var/run/rtpproxy.sock rtpproxy 852 root 7u IPv4 0xc200f870 0t0 UDP 10.9.193.148:35010 rtpproxy 852 root 8u IPv4 0xc200fb40 0t0 UDP 10.9.193.148:35011 rtpproxy 852 root 9u IPv4 0xc200f0b4 0t0 UDP 10.9.193.148:35012 rtpproxy 852 root 10u IPv4 0xc200fd5c 0t0 UDP 10.9.193.148:35013 Swapping the order that the IP addresses are listed on the rtpproxy command line appears to dictate which address will be used exclusively, rather than using whichever is appropriate for the network of the destination. Why rtpproxy opens four sockets per call is another question for later. Now audio is seen flowing from the PSTN switch to the SER box, which seems correct: U 2008/02/13 13:58:32.692840 10.9.193.146:28006 -> 10.9.193.148:35010 ........ 9............................................................................... ................................................................................ ... But we see no audio from the Asterisk server reaching the SER/rtpproxy server, because the SIP phone was given the wrong address by SER/rtpproxy. It is probably sending audio out, but it won't reach the SER box. 9. Asterisk Server ACKs the message with the faulty data back to the SER server. # U 2008/02/13 13:58:32.744216 192.168.200.10:5060 -> 192.168.200.30:5060 ACK sip:9613789999@10.9.193.130:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.200.10:5060;branch=z9hG4bK79c58e2e;rport. Route: <sip:192.168.200.30;r2=on;ftag=as0458f259;lr=on>,<sip:10.9.193.135;r2=on; ftag=as0458f259;lr=on>. From: "VOIP TEST 1000" <sip:3797271700@192.168.200.30>;tag=as0458f259. To: <sip:9613789999@192.168.200.30>;tag=17b0000-0-1077770870. Contact: <sip:3797271700@192.168.200.10>. Call-ID: 5d27b24903963a384c98f4701f0ce456(a)192.168.200.30. CSeq: 102 ACK. User-Agent: Asterisk PBX. Max-Forwards: 70. Content-Length: 0. . 10. SER passes on the ACK message to the PSTN switch. # U 2008/02/13 13:58:32.745038 10.9.193.135:5060 -> 10.9.193.130:5060 ACK sip:9613789999@10.9.193.130:5060 SIP/2.0. Record-Route: <sip:10.9.193.135;r2=on;ftag=as0458f259;lr=on>. Record-Route: <sip:192.168.200.30;r2=on;ftag=as0458f259;lr=on>. Via: SIP/2.0/UDP 10.9.193.135;branch=0. Via: SIP/2.0/UDP 192.168.200.10:5060;branch=z9hG4bK79c58e2e;rport=5060. From: "VOIP TEST 1000" <sip:3797271700@192.168.200.30>;tag=as0458f259. To: <sip:9613789999@192.168.200.30>;tag=17b0000-0-1077770870. Contact: <sip:3797271700@192.168.200.10>. Call-ID: 5d27b24903963a384c98f4701f0ce456(a)192.168.200.30. CSeq: 102 ACK. User-Agent: Asterisk PBX. Max-Forwards: 16. Content-Length: 0. . 11. PSTN switch tells SER that the called party has hung up. # U 2008/02/13 14:00:17.113865 10.9.193.130:5060 -> 10.9.193.135:5060 BYE sip:10.9.193.135;r2=on;ftag=as0458f259;lr=on SIP/2.0. Via: SIP/2.0/UDP 10.9.193.130. Call-ID: 5d27b24903963a384c98f4701f0ce456(a)192.168.200.30. From: <sip:9613789999@192.168.200.30>;tag=17b0000-0-1077770870. To: "VOIP TEST 1000" <sip:3797271700@192.168.200.30>;tag=as0458f259. CSeq: 1 BYE. Route: <sip:192.168.200.30;r2=on;ftag=as0458f259;lr=on>. Route: <sip:3797271700@192.168.200.10>. Supported: timer. Content-Length: 0. Max-Forwards: 70. . 12. SER passes on the hang-up message to Asterisk. # U 2008/02/13 14:00:17.116100 192.168.200.30:5060 -> 192.168.200.10:5060 BYE sip:3797271700@192.168.200.10 SIP/2.0. Record-Route: <sip:192.168.200.30;r2=on;ftag=17b0000-0-1077770870;lr=on>. Record-Route: <sip:10.9.193.135;r2=on;ftag=17b0000-0-1077770870;lr=on>. Via: SIP/2.0/UDP 192.168.200.30;branch=z9hG4bKd67e.7d582993.0. Via: SIP/2.0/UDP 10.9.193.130. Call-ID: 5d27b24903963a384c98f4701f0ce456(a)192.168.200.30. From: <sip:9613789999@192.168.200.30>;tag=17b0000-0-1077770870. To: "VOIP TEST 1000" <sip:3797271700@192.168.200.30>;tag=as0458f259. CSeq: 1 BYE. Supported: timer. Content-Length: 0. Max-Forwards: 16. . 13. Asterisk ACKs the message to SER. # U 2008/02/13 14:00:17.116898 192.168.200.10:5060 -> 192.168.200.30:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.200.30;branch=z9hG4bKd67e.7d582993.0;received=192.168.2 00.30. Via: SIP/2.0/UDP 10.9.193.130. Record-Route: <sip:192.168.200.30;r2=on;ftag=17b0000-0-1077770870;lr=on>. Record-Route: <sip:10.9.193.135;r2=on;ftag=17b0000-0-1077770870;lr=on>. From: <sip:9613789999@192.168.200.30>;tag=17b0000-0-1077770870. To: "VOIP TEST 1000" <sip:3797271700@192.168.200.30>;tag=as0458f259. Call-ID: 5d27b24903963a384c98f4701f0ce456(a)192.168.200.30. CSeq: 1 BYE. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Contact: <sip:3797271700@192.168.200.10>. Content-Length: 0. . ---------------------------------------------------------------------------- Invovation and Configuration Ser is started with "serctl start" and rtpproxy with rtpproxy -l 10.9.193.148/192.168.200.20 Ser is 0.9.6 and rtpproxy is a 1.1 snapshot from December (the 1.0 RELEASE link on the web site is broken) Here is the ser.cfg file. # ----------------------------------------------------------------- # ser.cfg # ----------------------------------------------------------------- # 92.168.200.30 is an interface towards external SIP gear, asterisk # ervers, etc. listen=192.168.200.30 # INSERT YOUR IP ADDRESS HERE # 0.9.193.135 is an interface directly connected to a PSTN switch # also performing SIP->TDM conversion listen=10.9.193.135 # INSERT YOUR IP ADDRESS HERE # mhomed required or ser will not attempt to match destination IPs # with the interface and network that can reach the destination. mhomed=yes # ----------------------------------------------------------------- # handbook defaults # ----------------------------------------------------------------- debug=3 fork=yes log_stderror=no sip_warning=no port=5060 children=4 dns=no rev_dns=no fifo="/tmp/ser_fifo" fifo_db_url="mysql://ser:heslo@localhost/ser" # ----------------------------------------------------------------- # Modules # ----------------------------------------------------------------- loadmodule "/usr/local/lib/ser/modules/mysql.so" loadmodule "/usr/local/lib/ser/modules/sl.so" loadmodule "/usr/local/lib/ser/modules/tm.so" loadmodule "/usr/local/lib/ser/modules/rr.so" loadmodule "/usr/local/lib/ser/modules/maxfwd.so" loadmodule "/usr/local/lib/ser/modules/usrloc.so" loadmodule "/usr/local/lib/ser/modules/registrar.so" loadmodule "/usr/local/lib/ser/modules/auth.so" loadmodule "/usr/local/lib/ser/modules/auth_db.so" loadmodule "/usr/local/lib/ser/modules/uri.so" loadmodule "/usr/local/lib/ser/modules/uri_db.so" loadmodule "/usr/local/lib/ser/modules/domain.so" loadmodule "/usr/local/lib/ser/modules/nathelper.so" loadmodule "/usr/local/lib/ser/modules/textops.so" loadmodule "/usr/local/lib/ser/modules/avpops.so" loadmodule "/usr/local/lib/ser/modules/permissions.so" # ----------------------------------------------------------------- # Module settings # ----------------------------------------------------------------- modparam("auth_db|permissions|uri_db|usrloc", "db_url", "mysql://ser:heslo@local host/ser") modparam("auth_db", "calculate_ha1", 1) modparam("auth_db", "password_column", "password") modparam("nathelper", "natping_interval", 30) modparam("nathelper", "ping_nated_only", 1) modparam("nathelper", "rtpproxy_sock", "unix:/var/run/rtpproxy.sock") modparam("usrloc", "db_mode", 2) modparam("registrar", "nat_flag", 6) modparam("rr", "enable_full_lr", 1) modparam("tm", "fr_inv_timer", 27) modparam("tm", "fr_inv_timer_avp", "inv_timeout") modparam("permissions", "db_mode", 1) modparam("permissions", "trusted_table", "trusted") # ----------------------------------------------------------------- # Main Route Evaluation # ----------------------------------------------------------------- route { log(1, "ENTERING MAIN ROUTE\n"); if (method=="REGISTER") log(1, "REGISTER message received\n"); if (method=="INVITE") log(1, "INVITE message received\n"); if (method=="ACK") log(1, "ACK message received\n"); if (method=="BYE") log(1, "BYE message received\n"); if (method=="CANCEL") log(1, "CANCEL message received\n"); if (method=="SUBSCRIBE") log(1, "SUBSCRIBE message received\n"); if (method=="NOTIFY") log(1, "NOTIFY message received\n"); if (method=="OPTIONS") log(1, "OPTIONS message received\n"); if (method=="INFO") log(1, "INFO message received\n"); if (method=="MESSAGE") log(1, "MESSAGE message received\n"); if (method=="REFER") log(1, "REFER message received\n"); # ----------------------------------------------------------------- # Sanity Check Section # ----------------------------------------------------------------- log(1, "Performing Sanity Check\n"); if (!mf_process_maxfwd_header("10")) { sl_send_reply("483", "Too Many Hops"); break; }; if (msg:len > max_len) { sl_send_reply("513", "Message Overflow"); break; }; # ----------------------------------------------------------------- # Record Route Section # ----------------------------------------------------------------- log(1, "Entering Record Route\n"); if (method!="REGISTER") { record_route(); }; if (method=="BYE" || method=="CANCEL") { unforce_rtp_proxy(); } # ----------------------------------------------------------------- # Call Tear Down Section # ----------------------------------------------------------------- log(1, "Entering Tear Down Section\n"); if (method=="BYE" || method=="CANCEL") { log(1, "Method was Equal to BYE or Cancel\n"); unforce_rtp_proxy(); } # ----------------------------------------------------------------- # Loose Route Section # ----------------------------------------------------------------- log(1, "Entering Loose Route Section\n"); if (loose_route()) { log(1, "Call is Loose_Route\n"); if ((method=="INVITE" || method=="REFER") && !has_totag()) { sl_send_reply("403", "Forbidden"); break; }; if (method=="INVITE") { log(1, "Loose Route Method equals Invite\n"); if (!proxy_authorize("","subscriber")) { proxy_challenge("","0"); break; } else if (!check_from()) { sl_send_reply("403", "Use From=ID"); break; }; log(1, "Consume Credentials\n"); consume_credentials(); if (nat_uac_test("19")) { log(1, "Client was client nat test 19\n"); setflag(6); force_rport(); fix_nated_contact(); }; force_rtp_proxy("l"); }; route(1); break; }; # ----------------------------------------------------------------- # Call Type Processing Section # ----------------------------------------------------------------- log(1, "Entering Call Type Processing\n"); if (!is_uri_host_local()) { if (is_from_local() || allow_trusted()) { log(1, "URI is local or Trusted\n"); log(1, "Going to route 4\n"); route(4); log(1, "Going to route 1\n"); route(1); } else { sl_send_reply("403", "Forbidden"); }; break; }; if (method=="ACK") { log(1, "Call Processing ACK\n"); route(1); break; } else if (method=="CANCEL") { log(1, "Call Processing CANCEL\n"); route(1); break; } else if (method=="INVITE") { log(1, "Call Processing INVITE\n"); route(3); break; } else if (method=="REGISTER") { log(1, "Call Processing REGISTER\n"); route(2); break; }; lookup("aliases"); log(1, "Lookup Aliases\n"); if (!is_uri_host_local()) { log(1, "Call Processing uri_host_local\n"); log(1, "Going to route 4\n"); route(4); log(1, "Going to route 1\n"); route(1); break; }; if (!lookup("location")) { log(1, "Call Processing lookup location\n"); sl_send_reply("404", "User Not Found"); break; }; route(1); } # ----------------------------------------------------------------- # Default Message Handler # ----------------------------------------------------------------- route[1] { log(1, "Entering ROUTE[1]\n"); t_on_reply("1"); setflag(1); if (!t_relay()) { if (method=="INVITE" && isflagset(6)) { log(1, "unforce rtp proxy\n"); unforce_rtp_proxy(); }; sl_reply_error(); }; } # ----------------------------------------------------------------- # REGISTER Message Handler # ----------------------------------------------------------------- route[2] { log(1, "Entering ROUTE[2]\n"); sl_send_reply("100", "Trying"); if (!search("^Contact:[ ]*\*") && nat_uac_test("19")) { log(1, "searching contact\n"); setflag(6); fix_nated_register(); force_rport(); }; if (!www_authorize("","subscriber")) { log(1, "authorize challenge\n"); www_challenge("","0"); break; }; if (!check_to()) { sl_send_reply("401", "Unauthorized"); log(1, "401 unauth break\n"); break; }; consume_credentials(); if (!save("location")) { sl_reply_error(); }; } # ----------------------------------------------------------------- # INVITE Message Handler # ----------------------------------------------------------------- route[3] { log(1, "Entering ROUTE[3]\n"); if (!allow_trusted()) { log(1, "Allow Trusted True\n"); if (!proxy_authorize("","subscriber")) { proxy_challenge("","0"); break; } else if (!check_from()) { sl_send_reply("403", "Use From=ID"); break; }; log(1, "Consume Credentials route 3\n"); consume_credentials(); }; if (uri=~"^sip:1[0-9]{10}@") { strip(1); }; if (nat_uac_test("19")) { setflag(6); } lookup("aliases"); if (!is_uri_host_local()) { route(4); route(1); break; }; if (uri=~"^sip:011[0-9]*@") { # International PSTN route(4); route(5); break; }; if (!lookup("location")) { log(1, "Domestic PSTN\n"); if (uri=~"^sip:[0-9]{10}@") { # Domestic PSTN route(4); route(5); break; }; sl_send_reply("404", "User Not Found"); break; }; route(4); route(1); } # ----------------------------------------------------------------- # NAT Traversal Section # ----------------------------------------------------------------- route[4] { log(1, "Entering ROUTE[4]\n"); if (isflagset(6)) { log(1, "Running NAT Traversal\n"); force_rport(); fix_nated_contact(); force_rtp_proxy(); } } # ----------------------------------------------------------------- # PSTN Handler # ----------------------------------------------------------------- route[5] { log(1, "Entering ROUTE[5]\n"); rewritehost("10.9.193.130:5060"); # INSERT YOUR PSTN GATEWAY IP ADDRESS avp_write("i:45", "inv_timeout"); log(1, "Rewrote IP for PSTN Gateway\n"); log(1, "Returning to Route 1\n"); route(1); } # ----------------------------------------------------------------- # Return Message To Sender # ----------------------------------------------------------------- onreply_route[1] { log(1, "Reached Onreply Route\n"); if (isflagset(6) && status=~"(180)|(183)|2[0-9][0-9]") { if (!search("^Content-Length:[ ]*0")) { log(1, "Running Force RTP Proxy\n"); force_rtp_proxy(); }; }; if (nat_uac_test("1")) { log(1, "Fix Nated Contact\n"); fix_nated_contact(); }; } # ----------------------------------------------------------------- # End of ser.cfg # ----------------------------------------------------------------- Whew, so with all that information, the question comes down to: How do you convince rtpproxy to listen on and tell SER about the right IP addresses when there are two interfaces and you have told rtpproxy about both of them? Thanks in advance for assistance on this! Frank

1 0

[OpenSER-Users] auth_db module problem
by Karol Krasnan 13 Feb '08

13 Feb '08

Hi, Everybody, I would like ask you for help. I am trying start OpenSer with database support. But when I uncomment, in default openser.cfg, line "loadmodule "auth_db.so"" the openser will not start. Until that it work fine. And with loading "mysql" and "auth" module is not problem. I wasn't change originnal openser.cfg. Thank you very much for help. Karol

2 2

Re: [OpenSER-Users] [CDRTool] How to get the "In" and "Out" columns?
by Andy Smith 13 Feb '08

13 Feb '08

Hi Iñaki, For me this is functioning fine, I have just enabled the database accoutning in mediaproxy.ini and it worked as soon as I got mediaproxy working correctly... Do you know if mediaproxy is writing any data to the database? For MySQL you need SQLite and mysql_python. Also for authentication reasons the MySQL user you connect as from Mediaproxy needs to have their password set as OLD_PASSWORD (old/poor security type password) in the users table in mysql DB. cheers Andy. >Hi, my installation of CDRTool with Mediaproxy and FreeRadius works ok. I see >correctly the accounting detail in CDR's (except the fact that I have no yet >created rated, profiles and so...). >Also I see correctly the web SIP trace created with "siptrace" module. > >But in the CDR view the columns "In" and "Out" are always empty. How to fill >them? what do they depend on? I've not read nothing about them in the doc. > >Thanks a lot.

2 2

Re: [OpenSER-Users] [CDRTool] How to get the "In" and "Out" columns?
by Andy Smith 13 Feb '08

13 Feb '08

Hi Iñaki, For me this is functioning fine, I have just enabled the database accoutning in mediaproxy.ini and it worked as soon as I got mediaproxy working correctly... Do you know if mediaproxy is writing any data to the database? For MySQL you need SQLite and mysql_python. Also for authentication reasons the MySQL user you connect as from Mediaproxy needs to have their password set as OLD_PASSWORD (old/poor security type password) in the users table in mysql DB. cheers Andy. >Hi, my installation of CDRTool with Mediaproxy and FreeRadius works ok. I see >correctly the accounting detail in CDR's (except the fact that I have no yet >created rated, profiles and so...). >Also I see correctly the web SIP trace created with "siptrace" module. > >But in the CDR view the columns "In" and "Out" are always empty. How to fill >them? what do they depend on? I've not read nothing about them in the doc. > >Thanks a lot.

1 0

[OpenSER-Users] [CDRTool] How to get the "In" and "Out" columns?
by Iñaki Baz Castillo 13 Feb '08

13 Feb '08

Hi, my installation of CDRTool with Mediaproxy and FreeRadius works ok. I see correctly the accounting detail in CDR's (except the fact that I have no yet created rated, profiles and so...). Also I see correctly the web SIP trace created with "siptrace" module. But in the CDR view the columns "In" and "Out" are always empty. How to fill them? what do they depend on? I've not read nothing about them in the doc. Thanks a lot. -- Iñaki Baz Castillo ibc(a)in.ilimit.es

1 0

Re: [OpenSER-Users] OpenSER - a slow starter?
by Bogdan-Andrei Iancu 13 Feb '08

13 Feb '08

Hi Lars, yes, correct is auto_aliases=no my typo :). Just to clarify - the problem is that openser starts very slow ? or that some requests are processed very slow?? Regards, Bogdan Lars Skjærlund wrote: > Hi Bogdan, > > >> by default openser tries to do reverse DNS lookup on the IPs you put >> > in > >> "listen" to learn all the aliases (DNS records pointing to this IP). >> >> To disable this, set the global parameter: >> auto_alias=no >> > > Beeing a beginner, the above confused me a bit - I think the right > syntax is auto_aliases=no? > > >> Let me know if this makes a difference or not. >> > > Unfortunately, no. I thought I'd solved it last night (see another mail > from me), but the problem has reappeared: > > I cannot register with Twinkle - however, Express Talk works fine? > > Well, we just did another test before hitting send: By switching IDs > between the two softphones, Twinkle registered immediately - it's > getting even more weird... > > Regards, > Lars >

1 0

Re: [OpenSER-Users] Tech prefix and CarrierRoute
by Henning Westerholt 13 Feb '08

13 Feb '08

On Wednesday 13 February 2008, TCB wrote: > > > append the callerid as tech prefix to all outgoing calls > > changing the source code of the rewrite function in the cr module > Any pointers to which specific area of code? Hi, the actual rewrite is done in the route_func.c:actually_rewrite() function. The rewriting URI action is done in the carrier_rewrite_msg() in the same file. But why can't your billing server just evaluate the call-id header field that is probably present in the SIP message header? This would be much more easier then to hack the module code in my opinion. Henning

1 0

Re: [OpenSER-Users] [OpenSER-Devel] next irc meeting
by Daniel-Constantin Mierla 13 Feb '08

13 Feb '08

Hello Henning, On 02/13/08 14:56, Henning Westerholt wrote: > On Tuesday 12 February 2008, Daniel-Constantin Mierla wrote: > >> Hello, >> >> I think is time for a new irc meeting to synchronize on the work for 1.4 >> and discuss 1.3.1 about release. I propose Friday, Feb 15, UTC 13:00. >> >> I created a wiki page to gather the discussion items there and have the >> agenda ready for that date. I added what I would like to touch. Please >> add yours and complete/comment on mine or others. >> > > Hi Daniel, > > good idea! I've already added some of my points to the list. This friday is > not a good date for me, as i'm on vacation this day. Perhaps we can go for > the Tuesday, Feb 19, UTC 13:00? > ok, it is fine with that date, too. I will update the docuwiki pages (added users list so they get the update). Cheers, Daniel > Cheers, > > Henning > >

1 0

[OpenSER-Users] Wanted: VoIP Engineer for Switerland
by laurent schweizer 13 Feb '08

13 Feb '08

Peoplefone AG offers Voice over IP(VoIP) services with exceptional rates. Peoplefone is a certified partner of Siemens<http://www.siemens.ch/index.jsp?sdc_p=c175fi1012637lmno1012637psuz1&sdc_sid…>and AVM/FRITZ!Box <http://www.fritz-shop.ch/> . Due to our rapid growth, we are currently seeking for: VOIP SPECIALIST Place of work: Zurich *Requirements:* - Graduation from college or university with a Bachelor's degree (preferably IT) - Experience with PHP - Practical knowledge of C and C++ - Practical knowledge of Mysql and Postgresql - Linux experience - Knowledge of IP Networks, UDP, TCP - Experience with tools for Network analysis like Ethereal - VoIP basic knowledge, VoIP servers, configuration of devices - Fluency in English - Ability to interact with individuals and groups at all levels - Detail oriented and analytical - Strong verbal and written communication skills Knowledge of Perl, Java, Asterisk / SER / OPENSER, ability to configure routers, Cisco or Patton gateways, knowledge of SIP and STUN protocol, knowledge of NAT problems, of outbandProxy, knowledge of monitoring tools like Cactus, Nagios, MRTG or high availability tools like DRBD, Hearthbeat would be an additional asset. Interested individuals are requested to send their resume to: christophe.beaud(a)peoplefone.com

1 0

[OpenSER-Users] ERROR: couldn't open sequence file /var/run/radius.seq
by Iñaki Baz Castillo 13 Feb '08

13 Feb '08

I see this issue in syslog: ---------------- openser: rc_get_seqnbr: couldn't open sequence file /var/run/radius.seq: Permission denied --------------- The problem is that OpenSer run with "openser" user who has not write access to /var/run. If I change permissions to /var/run the the message doesn't appear. Anyway I'd prefer not to modify permissions and owner of a system directory as /var/run. - How important is that "radius.seq" file? - Is not possible to configure OpenSer to write it in /tmp (for example)? Thanks. -- Iñaki Baz Castillo ibc(a)in.ilimit.es

1 0

Re: [OpenSER-Users] FreeRADIUS-CDRTool Prepaid Connector 1.1 Released
by A.smith 13 Feb '08

13 Feb '08

Hi Dan, Thanks for the all the info! Ok, question on this part: 3. Accounting it is bit more accurate (you have the session total duration inside the accounting packets), so radius will be no longer responsible of calculating the session durations from timestaps. To interoperate with CDRTool you still need the data in the radacct table formatted as per normal by Freeradius, right? By accouting packet are you referring to the radius accouting packets? If you say Yate puts session times in the accouting packets how does this all stick together? Does OpenSER still do the radius accouting part, or do I need to configure Yate to do it instead? thanks a lot! Andy. --------- Original Message -------- From: Dan-Cristian Bogos <danb.lists(a)googlemail.com> To: A.smith <a.smith(a)ukgrid.net> Cc: users(a)lists.openser.org Subject: Re: [OpenSER-Users] FreeRADIUS-CDRTool Prepaid Connector 1.1 Released Date: 13/02/08 12:15 > Hi Andy,The original config was built with Yate in mind due to openser incapacity (before release 1.3) of disconnecting the calls. Since 1.3.0 the dialog module should be able to timeout the calls, in theory you should no longer need extra software like Yate. > I would still recommend using Yate combined with OpenSER in the case you are doing some sort of "Carrier business", for  the following reasons:1. It creates two different legs for your call (in and out) same as Cisco does, and hides one side from the other (eg. removes the via headers and any revealing ip information inside SDP - so your partners should not know where the traffic comes from). > 2. You have more protocols available in.3. Accounting it is bit more accurate (you have the session total duration inside the accounting packets), so radius will be no longer responsible of calculating the session durations from timestaps. > 4. Yate can work in rtp_forward mode, therefore no extra overhead given by rtp processing.So basically what the connector does (as specified in the documentation), for each call which is authorized by radius, the connector will ask permission from cdrtool. If permission is granted, it will return in a avp to openser the maximum duration allowed for the call (timeout value) plus credit available, for the case of special uas able to display that. > By receiving accounting stop packet, the connector will inform cdrtool about call disconnection therefore clearing the lock and debiting the balance inside cdrtool. The rtp stream has nothing to do with this scenario, so you don't need to touch your NAT support configuration, it's all in the signaling. > Let me know if you need further info.Cheers,DanBOn Feb 13, 2008 12:53 PM ________________________________________________ Message sent using UK Grid Webmail 2.7.9

2 1

[OpenSER-Users] Routing Problem "To Many Hops"
by Ali Jawad 13 Feb '08

13 Feb '08

Hi All I am trying to achieve the following 1. User Calls a number * If the number is 00+all numbers go to PSTN -> Else check if the user is existent in our SIP Proxy user pool and act accordingly What I achieved so far is the following 2. User Calls a number * Route checks if the number is online if yes the call is routed to him (route[1]) if not it send the call to PSTN if it is 00+[0-9] route [2]. This works fine for 00+[0-9] number however if 123456 is called and the user 123456 is not online, the call goes down through the conditional statements because it does not meet 00+[0-9] and I get an error "To Many Hops" Seems I messed up somewhere, can anyone help me fix this http://pastebin.com/m50328c12 Thanks

6 12

Re: [OpenSER-Users] OpenSER - a slow starter?
by Lars Skjærlund 13 Feb '08

13 Feb '08

Hi Klaus, > MAybe openser tries t do some DNS lookups which may take long time. > > The best would be to set debug=4 and "tail" to the logfile > (default=/var/log/syslog (or /var/log/messages on RedHat&co)). I was running at debug level 6 already, and dumping the output to screen. However, I actually found the error last night: Beeing new to all this, I had mediaproxy and proxydispatcher running on the machine - primarily as a proof to myself that they where installed and seemed to work. I assumed they wouldn't interfere with OpenSER as long as the support modules wasn't loaded, but alas, I was wrong: As soon as I stopped mediaproxy and proxydispatcher, OpenSER started working as expected. The problem is reproduceable - but I think it's a bit strange behaviour? Regards, Lars -- Lars Skjærlund Skovengen 111 2980 Kokkedal Denmark Tel.: +45 70 25 88 10 http://www.skjaerlund.dk/lars

1 0

[OpenSER-Users] Implementing Follow-me
by Cosimo Fadda 13 Feb '08

13 Feb '08

Hi, I'm very new to this list. In my setup I use openser as proxy an asterisk as pstn gateway. I want to implement a 'follow-me' service, i.e. I want users to dial a particular number and then they can enter a phone number where receive their incoming calls. So which is the best solution: use asterisk to perform a lookup in the DB and decide to which number route the call, ore use openser maybe with the 'exec_dset' command? Or there is a command that I'm missing that can implement this function? Thanks in advance, Cosimo -- *Ing. Cosimo Fadda System Engineer Klarya s.r.l.* Sede Operativa: Via Agnini 47 - 41037 Mirandola (MO) Tel +39 0535 27325 Fax +39 0535 610050 Mob +39 3316907200 Sede Legale: Via Salgari, 17 - 41100 Modena Tel +39 059 821332 Fax +39 059 821492 email: cosimo.fadda(a)klarya.it web: www.klarya.it * **Open Source IP Communications* __________________________________________________

3 2

[Serusers] Do an anonymous call
by inge 12 Feb '08

12 Feb '08

Hi all, I've implanted this feature some months ago and it no longer appears to be functional. To do that I have used a subst function to parse and replace sip:XXX| <sip:XXX> by "Anonymous" sip:|<sip:>. It follows to run on some products but not on an other one and only between them (ie. on-net between the products concerned). If someone can help me/guide me. Thanks ! Regards, Adrien

1 0

[Serusers] TLS module - memory allocation functions error - rel 2.0.0_rc6
by Tomasz Zieleniewski 12 Feb '08

12 Feb '08

HI, I encountered the following error while trying to set up tls in ser. When I start ser I get such error: Feb 12 12:40:51 venom ser[26157]: tls: _init_tls_h: compiled with openssl version "OpenSSL 0.9.8g 19 Oct 2007" (0x0090807f), kerberos support: off, compression: on Feb 12 12:40:51 venom ser[26157]: tls: init_tls_h: installed openssl library version "OpenSSL 0.9.8g 19 Oct 2007" (0x0090807f), kerberos support: off, zlib compression: on compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -O3 -Wa,--noexecstack -g -Wall -DMD32_REG_T=int -DMD5_ASM Feb 12 12:40:51 venom ser[26157]: ERROR: tls_init.c:366: Unable to set the memory allocation functions Feb 12 12:40:51 venom ser[26157]: could not initialize tls, exiting... Here is my config: # -- tls params -- modparam("tls", "config", "/home/sip/ser/2.0/hsp/ca/tls.cfg") modparam("tls", "tls_force_run", 0) modparam("tls", "tls_log",3) modparam("tls", "handshake_timeout", 10) modparam("tls", "send_timeout", 10) modparam("tls", "tls_disable_compression", 0) #modparam("tls", "private_key", "/etc/certs/key.pem") #modparam("tls", "certificate", "/etc/certs/cert.pem") #modparam("tls", "ca_list", "/etc/certs/ca_list.pem") #modparam("tls", "require_certificate", 0) #modparam("tls", "verify_certificate", 1) #modparam("tls", "tls_method", "TLSv1") and tls.cfg [server:default] method = TLSv1 verify_certificate = no require_certificate = no private_key = /home/sip/ser/2.0/hsp/ca/hsp_key.pem certificate = /home/sip/ser/2.0/hsp/ca/hsp_cert.pem ca_list = /home/sip/ser/2.0/hsp/ca/hsp_calist.pem [client:default] verify_certificate = yes require_certificate = yes Please point me what did I miss if this is the right behaviour? Kind regards Tomasz

2 1

[OpenSER-Users] Implemented RFCs
by Victor Pascual Ávila 12 Feb '08

12 Feb '08

Hi Folks, Is there any document where I can find the implemented RFCs in Openser? Creating a wiki document would be useful. Cheers, -- Victor Pascual Ávila Research Engineer Tel. +34 93 542 2906 Fax. +34 93 542 2517 Research Group on Network Technologies and Strategies (NeTS) Universitat Pompeu Fabra (UPF) Pg. de Circumval·lació, 8 Office 358 08003 Barcelona (Spain) http://nets.upf.edu/

7 7

[OpenSER-Users] next irc meeting
by Daniel-Constantin Mierla 12 Feb '08

12 Feb '08

Hello, I think is time for a new irc meeting to synchronize on the work for 1.4 and discuss 1.3.1 about release. I propose Friday, Feb 15, UTC 13:00. I created a wiki page to gather the discussion items there and have the agenda ready for that date. I added what I would like to touch. Please add yours and complete/comment on mine or others. http://www.openser.org/dokuwiki/doku.php/development:irc-meeting-agenda-next IRC meetings page: http://www.openser.org/dokuwiki/doku.php/development:irc-meetings Cheers, Daniel

1 0

[OpenSER-Users] Configuring for a UA Server
by Eric Phetteplace 11 Feb '08

11 Feb '08

Hello, A little green here, looking for guidance. I have a simple UA server that can respond to invites. It will respond with a 302 (temp. moved) to free up 5060 for the next invite. It uses only TCP for RTP transport. I am trying to use OpenSER with RTPProxy to be a, well, RTP proxy. The SIP trunk providers will map the DIDs to the OpenSER server, passing UDP for RTP. I'm assuming this is rather easy, but I'm having trouble getting through the documentation. I currently have OpenSER 1.3 and RTPProxy running. A step-by-step list of openserctl or module commands (vague is fine, I can read up on it) would be greatly appreciated. So would any other advice - anything more than RTFM ;-) Thanks! Eric

1 0

Re: [OpenSER-Users] Compilation problem on Debian Stable/SPARC architexture
by Schumann Sebastian 11 Feb '08

11 Feb '08

Hi Bogdan, sure I can, could have thought about that in the first place myself. Sorry for that, here the working output after starting make without debug mode: netra120:/usr/local/src/openser# make prefix=/usr/local all Compiling blacklists.c gcc -g -O9 -funroll-loops -Wall -mcpu=ultrasparc -mtune=ultrasparc -ftree-vectorize -DNAME='"openser"' -DVERSION='"1.3.0-notls"' -DARCH='"sparc64"' -DOS='"linux"' -DCOMPILER='"gcc 4.1.2"' -D__CPU_sparc64 -D__OS_linux -D__SMP_no -DCFG_DIR='"/usr/local/etc/openser/"' -DPKG_MALLOC -DSHM_MEM -DSHM_MMAP -DUSE_IPV6 -DUSE_MCAST -DUSE_TCP -DDISABLE_NAGLE -DHAVE_RESOLV_RES -DSTATISTICS -DCHANGEABLE_DEBUG_LEVEL -DF_MALLOC -DSVNREVISION='"2:3675"' -DFAST_LOCK -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024 -DHAVE_GETHOSTBYNAME2 -DHAVE_UNION_SEMUN -DHAVE_SCHED_YIELD -DHAVE_MSG_NOSIGNAL -DHAVE_MSGHDR_MSG_CONTROL -DHAVE_ALLOCA_H -DHAVE_TIMEGM -DHAVE_EPOLL -DHAVE_SIGIO_RT -DHAVE_SELECT -c blacklists.c -o blacklists.o Compiling core_stats.c gcc -g -O9 -funroll-loops -Wall -mcpu=ultrasparc -mtune=ultrasparc -ftree-vectorize -DNAME='"openser"' -DVERSION='"1.3.0-notls"' -DARCH='"sparc64"' -DOS='"linux"' -DCOMPILER='"gcc 4.1.2"' -D__CPU_sparc64 -D__OS_linux -D__SMP_no -DCFG_DIR='"/usr/local/etc/openser/"' -DPKG_MALLOC -DSHM_MEM -DSHM_MMAP -DUSE_IPV6 -DUSE_MCAST -DUSE_TCP -DDISABLE_NAGLE -DHAVE_RESOLV_RES -DSTATISTICS -DCHANGEABLE_DEBUG_LEVEL -DF_MALLOC -DSVNREVISION='"2:3675"' -DFAST_LOCK -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024 -DHAVE_GETHOSTBYNAME2 -DHAVE_UNION_SEMUN -DHAVE_SCHED_YIELD -DHAVE_MSG_NOSIGNAL -DHAVE_MSGHDR_MSG_CONTROL -DHAVE_ALLOCA_H -DHAVE_TIMEGM -DHAVE_EPOLL -DHAVE_SIGIO_RT -DHAVE_SELECT -c core_stats.c -o core_stats.o Compiling crc.c gcc -g -O9 -funroll-loops -Wall -mcpu=ultrasparc -mtune=ultrasparc -ftree-vectorize -DNAME='"openser"' -DVERSION='"1.3.0-notls"' -DARCH='"sparc64"' -DOS='"linux"' -DCOMPILER='"gcc 4.1.2"' -D__CPU_sparc64 -D__OS_linux -D__SMP_no -DCFG_DIR='"/usr/local/etc/openser/"' -DPKG_MALLOC -DSHM_MEM -DSHM_MMAP -DUSE_IPV6 -DUSE_MCAST -DUSE_TCP -DDISABLE_NAGLE -DHAVE_RESOLV_RES -DSTATISTICS -DCHANGEABLE_DEBUG_LEVEL -DF_MALLOC -DSVNREVISION='"2:3675"' -DFAST_LOCK -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024 -DHAVE_GETHOSTBYNAME2 -DHAVE_UNION_SEMUN -DHAVE_SCHED_YIELD -DHAVE_MSG_NOSIGNAL -DHAVE_MSGHDR_MSG_CONTROL -DHAVE_ALLOCA_H -DHAVE_TIMEGM -DHAVE_EPOLL -DHAVE_SIGIO_RT -DHAVE_SELECT -c crc.c -o crc.o make: *** [crc.o] Interrupt netra120:/usr/local/src/openser# and so on... Thanks for the help. Best regards Sebastian -----Original Message----- From: Bogdan-Andrei Iancu [mailto:bogdan@voice-system.ro] Sent: Friday, 08. February 2008 4:53 PM To: Schumann Sebastian Cc: users(a)lists.openser.org Subject: Re: [OpenSER-Users] Compilation problem on Debian Stable/SPARC architexture Hi Sebastian, Could you also post the working compile instruction (without the debug mode) ? I want do diff them . Thanks anre gards, Bogdan Schumann Sebastian wrote: > Hi Bogdan, > > one more inmportant note, I discovered this morning. This error only > appears if the option mode=debug is set. A normal # make all does > compile properly! > > Here is the output: > > netra120:/usr/local/src/openser# make mode=debug prefix=/usr/local all > bison -d -b cfg cfg.y > cfg.y: conflicts: 1 shift/reduce > flex cfg.lex > New SVN revision: 2:3654 > Compiling action.c > gcc -DNAME='"openser"' -DVERSION='"1.3.0-notls"' -DARCH='"sparc64"' > -DOS='"linux"' -DCOMPILER='"gcc 4.1.2"' -D__CPU_sparc64 -D__OS_linux > -D__SMP_no -DCFG_DIR='"/usr/local/etc/openser/"' -DPKG_MALLOC -DSHM_MEM > -DSHM_MMAP -DUSE_IPV6 -DUSE_MCAST -DUSE_TCP -DDISABLE_NAGLE > -DHAVE_RESOLV_RES -DSTATISTICS -DCHANGEABLE_DEBUG_LEVEL -DF_MALLOC > -DSVNREVISION='"2:3654"' -DEXTRA_DEBUG -DFAST_LOCK -DADAPTIVE_WAIT > -DADAPTIVE_WAIT_LOOPS=1024 -DHAVE_GETHOSTBYNAME2 -DHAVE_UNION_SEMUN > -DHAVE_SCHED_YIELD -DHAVE_MSG_NOSIGNAL -DHAVE_MSGHDR_MSG_CONTROL > -DHAVE_ALLOCA_H -DHAVE_TIMEGM -DHAVE_EPOLL -DHAVE_SIGIO_RT -DHAVE_SELECT > -c action.c -o action.o > Compiling blacklists.c > gcc -DNAME='"openser"' -DVERSION='"1.3.0-notls"' -DARCH='"sparc64"' > -DOS='"linux"' -DCOMPILER='"gcc 4.1.2"' -D__CPU_sparc64 -D__OS_linux > -D__SMP_no -DCFG_DIR='"/usr/local/etc/openser/"' -DPKG_MALLOC -DSHM_MEM > -DSHM_MMAP -DUSE_IPV6 -DUSE_MCAST -DUSE_TCP -DDISABLE_NAGLE > -DHAVE_RESOLV_RES -DSTATISTICS -DCHANGEABLE_DEBUG_LEVEL -DF_MALLOC > -DSVNREVISION='"2:3654"' -DEXTRA_DEBUG -DFAST_LOCK -DADAPTIVE_WAIT > -DADAPTIVE_WAIT_LOOPS=1024 -DHAVE_GETHOSTBYNAME2 -DHAVE_UNION_SEMUN > -DHAVE_SCHED_YIELD -DHAVE_MSG_NOSIGNAL -DHAVE_MSGHDR_MSG_CONTROL > -DHAVE_ALLOCA_H -DHAVE_TIMEGM -DHAVE_EPOLL -DHAVE_SIGIO_RT -DHAVE_SELECT > -c blacklists.c -o blacklists.o > /tmp/ccRk3oFx.s: Assembler messages: > /tmp/ccRk3oFx.s:831: Error: Architecture mismatch on "membar". > /tmp/ccRk3oFx.s:831: (Requires v9|v9a|v9b; requested architecture is > sparclite.) > /tmp/ccRk3oFx.s:847: Error: Architecture mismatch on "membar". > /tmp/ccRk3oFx.s:847: (Requires v9|v9a|v9b; requested architecture is > sparclite.) > make: *** [blacklists.o] Error 1 > netra120:/usr/local/src/openser# > > Regards > Sebastian > > -----Original Message----- > From: Bogdan-Andrei Iancu [mailto:bogdan@voice-system.ro] > Sent: Friday, 08. February 2008 11:33 AM > To: Schumann Sebastian > Cc: users(a)lists.openser.org > Subject: Re: [OpenSER-Users] Compilation problem on Debian Stable/SPARC > architexture > > Hi Schumann, > > Can you post please the compile line (as printed by make) - just to > check the compile options. > > Thanks, > Bogdan > > Schumann Sebastian wrote: > >> Dear all >> >> I am facing problems installing OpenSER 1.3 from branch on a Debian >> 4.0R2 running on a SUN UltraSPARC IIi server (sparc64). >> >> After retrieving all required files and executing # make mode=debug, >> > the > >> second file's compilation fails already: >> >> Compiling blacklist.c >> .... >> Error: Architecture mismatch on "membar". >> (Requires v9|v9a|v9b; requested architexture is sparclite.) >> >> Does anyone know what could be the reason for that. On i386 I never >> faced problems, and as OpenSER supports Solaris, it should also >> > support > >> Debian on sparc64 architecture or not? >> >> Thanks a lot in advance. >> >> Best regards >> Sebastian >> >> _______________________________________________ >> Users mailing list >> Users(a)lists.openser.org >> http://lists.openser.org/cgi-bin/mailman/listinfo/users >> >> >> > > >

2 2

[OpenSER-Users] Configuring for a UA Server
by Eric Phetteplace 11 Feb '08

11 Feb '08

Hello, A little green here, looking for guidance. I have a simple UA server that can respond to invites. It will respond with a 302 (temp. moved) to free up 5060 for the next invite. It uses only TCP for RTP transport. I am trying to use OpenSER with RTPProxy to be a, well, RTP proxy. The SIP trunk providers will map the DIDs to the OpenSER server, passing UDP for RTP. I'm assuming this is rather easy, but I'm having trouble getting through the documentation. A step-by-step list of openserctl commands would be greatly appreciated. So would any other advice. Thanks! Eric

1 0

[Serusers] Hosts on login - Serweb
by Frank Gonzalez 11 Feb '08

11 Feb '08

I have a trouble in my serweb instalation, I defined a virtual host " sip.mydomain.com" but when I am accessing via http, its logon like @ mydomain.com , and the users via openserctl add have the host on the domain in the table suscribers. how can I correct this ? -- Thanks a lot Frank Gonzalez 414-6260492 -- Saludos. Frank Gonzalez 414-6260492

2 1

[OpenSER-Users] Logon prob when username is all numbers
by Ali Jawad 11 Feb '08

11 Feb '08

Hi All When I logon using usernames with letters all is fine when I logon using usernames all numbers I get the following error and the UA does not logon Registration Error: 501 Not Implemented This is my config http://pastebin.com/md7d0de4 It used to work with this config http://pastebin.com/m10e981d2 Thx for any suggestions.

1 1

[OpenSER-Users] sigsegv in module when running imported function
by Francisco Seratti 11 Feb '08

11 Feb '08

Hello, Im coding a module for my needs, and one of them is to modify the SIP message after querying some db. I decided to use the function replace_all() exported by the textops module, using the find_export() function declared in sr_module.h. The problem is that im getting a SIGSEGV when some child exec the replace_all mapped function: Feb 11 11:29:30 [4868] DBG:core:find_cmd_export_t: found <replace_all>(2) in module textops [/usr/local/lib/openser/modules/] Feb 11 11:29:31 [4867] INFO:core:handle_sigs: child process 4868 exited by a signal 11 Feb 11 11:29:31 [4867] INFO:core:handle_sigs: core was generated Feb 11 11:29:31 [4867] INFO:core:handle_sigs: terminating due to SIGCHLD I cant find the core generated by openser. Where is the default dir where this cores are saved? I dont know if this is a correct way to modify a SIP message; is there a better o more apropiated way to do this? Thanks in advance, Francisco. Tarjeta de crédito Yahoo! de Banco Supervielle. Solicitá tu nueva Tarjeta de crédito. De tu PC directo a tu casa. www.tuprimeratarjeta.com.ar

3 2

Re: [OpenSER-Users] Mediaproxy not working (Solved)
by A.smith 11 Feb '08

11 Feb '08

Hi Iñaki, thanks alot for the pointer, did a quick search for onreply_route and found this article: http://www.voip-info.org/wiki/view/OpenSER+And+Mediaproxy By using the route from this example and fixing it to use mediaproxy in all situations I finally have my RTP routing via the mediaproxy box! :D I still have to read up on the onreply_option to fully understand it. Perhaps if this is something that is always required referenec to it should be added to the mediaproxy module documentation?? Thanks again! Cheers Andy. > I think you have not configured the "onreply_route" so SDP is not modified in 180/183/200 reply, so MediaProxy doesn't work at all. ________________________________________________ Message sent using UK Grid Webmail 2.7.9

2 1

[OpenSER-Users] OpenSer and NAT
by Ali Jawad 11 Feb '08

11 Feb '08

Hi All I was wondering about the rtpproxy and mediaproxy modules, if I do use either of them to allow clients behind NAT to do VOIP calls does that mean that I do not need to use a STUN server anymore ? Or should I use both a STUN server and the rtp proxy ? What would provide the best solution in terms of solving NAT related problems ? Thanks

2 5

[OpenSER-Users] "lookup(location)" doesn't return -5 when "Contact" in blacklist
by Iñaki Baz Castillo 11 Feb '08

11 Feb '08

Hi, I set: ------------------------------------------- dst_blacklist = gw:{( any , GW_IP, 0 , "" )} [...] t_on_branch("ON_BRANCH_TO_USER"); if (!lookup("location")) { if ($rc == -5) xlog("L_WARN", "WARN: Fraudulent Contact !!! \n"); sl_send_reply("404", "Not Registered"); exit; } t_relay(); [...] branch_route[ON_BRANCH_TO_USER] { use_blacklist("gw"); } ------------------------------------------- I do a fraudulent REGISTER for an AoR (with GW_IP in "Contact" header) and when calling that AoR I get a correct "473 Filtered destination". But I don't see the WARN, so "lookup(location)" didn't reply -5. Why not? the IP in Contact column for taht AoR is GW_IP, why "lookup(location)" doesn't realize of it? It supposed that "lookup()" returns -5 if the destination is filtered (black listed): http://www.openser.org/docs/modules/1.3.x/tm.html#AEN336 Maybe it's a bug? -- Iñaki Baz Castillo ibc(a)in.ilimit.es

2 2

[Serusers] mediaproxy server NEW FEATURE
by Gonzalo J. Sambucaro 11 Feb '08

11 Feb '08

Folks, supose that there is an established rtp connection between two endpoints and the media proxy is in the middle doing the relay of the rtp streams, let´s say (MP = mediaproxy) EP A <--------->[NAT with IP1]<-----------> MP <--------------------> EP B EP A sends rtp to MP_IP:MP_PORT passing through the NAT box. EP B sends rtp to MP_IP:MP_PORT without passing through a NAT box. The MP know that the caller = NAT_IP1:NAT_PORT1, and the called = EP_B_IP:EP_B_PORT Now, supose that the NAT box change their PUBLIC IP from IP1 to IP2, so this escenary EP A <------->[NAT with IP1]<---------> MP <-------------> EP B will change to this EP A <------->[NAT with IP2]<---------> MP <--------------> EP B so the MP should detect that change of IPs and continue relaying the rtp streams but now to IP2:PORT2 instead of IP1:PORT1. Well, that was the situation y have experienced. To fix this, I developed this solution, changing rtphandler.py file: 1) When the first rtp packet of a source arrives, save the SSRC field in the MP. - Save the SSRC of the caller. - Save the SSRC of the called. 2) If arrives a rtp packet with unknown source IP but with the same SSRC field of some of the two streams, updates the binding (with the new IP detected) between the caller and the MP or between the called and the MP according to the field SSRC previously saved. Note: SSRC (RFC 3550 RTP), (from the rfc: "The SSRC identifier carried in the RTP header and in various fields of RTCP packets is a random 32-bit number that is required to be globally unique within an RTP session ") Somebody wants to test it?, in my installation this in production without problems. Regards, -- Gonzalo J. Sambucaro Ingeniería de Software Tel: +54-341-4230504 MSLC gonzalo(a)mslc.com.ar www.mslc.com.ar Ocampo y Esmeralda - Vivero de Empresas de Base Tecnológica Ciudad Universitaria Rosario UNR, CCT CONICET Rosario - Santa Fé - Argentina

1 0

[OpenSER-Users] OpenSER 1.3 NAT Config Issues
by Ali Jawad 11 Feb '08

11 Feb '08

Hi All I am trying to configure mediaproxy to be used with OpenSER 1.3 following the tutorial from http://siprouter.onsip.org/doc/gettingstarted/ch08.html#id2660207 So far I got two errors modparam("nathelper", "rtpproxy_disable", 1) ERROR:core:set_mod_param_regex: parameter <rtpproxy_disable> not found in module <nathelper> Feb 11 14:50:13 [3207] CRITICAL:core:yyerror: parse error in config file, line 194, column 19-20: Can't set module parameter modparam("registrar", "nat_flag", 6) Feb 11 14:50:13 [3207] ERROR:core:set_mod_param_regex: parameter <nat_flag> not found in module <registrar> Feb 11 14:50:13 [3207] CRITICAL:core:yyerror: parse error in config file, line 200, column 19-20: Can't set module parameter What should I use instead of modparam("nathelper", "rtpproxy_disable", 1) and modparam("registrar", "nat_flag", 6) so that this config becomes compatible with OpenSer 1.3 Thx

2 2

[OpenSER-Users] Missing "set_blacklist()" command in 1.3?
by Iñaki Baz Castillo 11 Feb '08

11 Feb '08

Hi, I'm trying to use blacklist but don't find the function "set_blacklist()" in OpenSer 1.3. I've done a full search in the code without finding it. Has it a different name now? Thanks. -- Iñaki Baz Castillo ibc(a)in.ilimit.es

1 1

[OpenSER-Users] Start of 2 opensers with same config and mi_datagram deletes socket file
by Helmut Kuper 11 Feb '08

11 Feb '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I found that starting a 2nd openser with same config as a already running openser on same machine and using module mi_datagram deletes the socket file of the already running openser process. This is very bad when u use openser as a frontend for sems for example. :( Is this a bug or a feature? If it is a bug the check, whether there is already a openser using same network resources should be befor starting modules. Or modules should be able to handle those problematic scenarios ... My mi_datagram conif ist this: loadmodule "mi_datagram.so" modparam("mi_datagram", "socket_name", "/tmp/openser_ansagen_sock") modparam("mi_datagram", "children_count", 1) modparam("mi_datagram", "unix_socket_mode", 0660) modparam("mi_datagram", "unix_socket_group", "voip") modparam("mi_datagram", "unix_socket_user", "ruth") modparam("mi_datagram", "socket_timeout", 2000) regards Helmut -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHsBIl4tZeNddg3dwRAgzVAJwKfUdqhd8oEm5eFewAflnosmofYQCgibYC WjR2C9pf0FIxJjD5JewRPww= =0roh -----END PGP SIGNATURE-----

2 1

[OpenSER-Users] "pua_usrloc": don't replace "offline" status with "online" when REGISTER
by Iñaki Baz Castillo 11 Feb '08

11 Feb '08

Hi, this issue has been already discused, but not wure if it's supposed to work now as expected: OpenSer svn trunk version. When an UAC send PUBLISH with status "offline" it's correctly notified to a X-Lite (it appears as "offline"). But later when the "uac" sends a REGISTER forrefreshing purposes, "pua-usrloc" generates a NOTIFY that make the user again "online" in X-Lite. This is the trace: "uac" sends a PUBLISH "offline": ----------------------------------------------------------------------------------------------------------------- PUBLISH sip:uac@domain.org SIP/2.0 Via: SIP/2.0/UDP 85.58.0.144:64947;rport;branch=z9hG4bKsowasblj Max-Forwards: 70 To: "I ako" <sip:uac@domain.org> From: "I ako" <sip:uac@domain.org>;tag=ukotb Call-ID: wxahiexypsywlfd(a)85.58.0.144 CSeq: 454 PUBLISH Content-Type: application/pidf+xml Event: presence Expires: 3600 SIP-If-Match: a.1202691876.19145.8.2 User-Agent: Twinkle/1.1 Content-Length: 197 <?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" entity="sip:uac@domain.org"><tuple id="igxiox"><status><basic>closed</basic></status></tuple></presence> SIP/2.0 200 OK Via: SIP/2.0/UDP 85.58.0.144:64947;rport=64947;branch=z9hG4bKsowasblj To: "I ako" <sip:uac@domain.org>;tag=c90c2e85033c1e1931e01d1f8303e2be.93c0 From: "I ako" <sip:uac@domain.org>;tag=ukotb Call-ID: wxahiexypsywlfd(a)85.58.0.144 CSeq: 454 PUBLISH Expires: 2390 SIP-ETag: a.1202691876.19144.13.3 Server: OpenSER (1.4.0dev4-tls (i386/linux)) Content-Length: 0 ----------------------------------------------------------------------------------------------------------------- Note that it has created a tuple with id="igxiox" containing "offline" status. "presence" module sends a NOTIFY to X-Lite ----------------------------------------------------------------------------------------------------------------- NOTIFY sip:xlite@85.58.0.144:64705;transport=TCP SIP/2.0 Via: SIP/2.0/TCP OPENSER;branch=z9hG4bK0ba1.96adda2.0 To: sip:xlite@domain.org;tag=841ea920 From: sip:uac@domain.org;tag=10.19158.1202692716.19 CSeq: 4 NOTIFY Call-ID: NmU4Y2EwMTY1ODQzOTE0MDJhODUzM2JkYTM1NTBmMzQ. Content-Length: 323 User-Agent: OpenSER (1.4.0dev4-tls (i386/linux)) Max-Forwards: 70 Event: presence Contact: <sip:OPENSER> Subscription-State: active;expires=2371 Content-Type: application/pidf+xml <?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" entity="sip:uac@domain.org"><tuple id="igxiox"><status><basic>closed</basic></status></tuple> <tuple xmlns="urn:ietf:params:xml:ns:pidf" id="0x81b3aa8"> <status> <basic>open</basic> </status> </tuple> </presence> SIP/2.0 200 OK Via: SIP/2.0/TCP OPENSER;branch=z9hG4bK0ba1.96adda2.0 Contact: <sip:xlite@10.0.2.15:59680;transport=TCP> To: <sip:xlite@domain.org>;tag=841ea920 From: <sip:uac@domain.org>;tag=10.19158.1202692716.19 Call-ID: NmU4Y2EwMTY1ODQzOTE0MDJhODUzM2JkYTM1NTBmMzQ. CSeq: 4 NOTIFY User-Agent: X-Lite release 1011s stamp 41150 Content-Length: 0 ----------------------------------------------------------------------------------------------------------------- Note: I'd like to know why there apper two tupples, one "online" and other one "offline". After the test I empiet activce_watcher and watchers table and restarted openser. No other UAC's registered as "uac" user. ¿? Some time after, "uac" sends a REGISTER. After it, "pua_usrloc" generates this PUBLISH: ----------------------------------------------------------------------------------------------------------------- PUBLISH sip:uac@domain.org SIP/2.0 Via: SIP/2.0/UDP OPENSER;branch=z9hG4bKcfa7.6a5c90f.0 To: sip:uac@domain.org From: sip:uac@domain.org;tag=8e8dc05fff8d3172da4bb428a9d4a223-793a CSeq: 10 PUBLISH Call-ID: 7bfbdf3d-19145@OPENSER Content-Length: 341 User-Agent: OpenSER (1.4.0dev4-tls (i386/linux)) Max-Forwards: 70 Event: presence Expires: 1201 Content-Type: application/pidf+xml <?xml version="1.0"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid" xmlns:c="urn:ietf:params:xml:ns:pidf:cipid" entity="uac(a)domain.org"> <tuple id="0x81b36d8"> <status> <basic>open</basic> </status> </tuple> </presence> ----------------------------------------------------------------------------------------------------------------- "presence" module generates the the NOTIFY: ----------------------------------------------------------------------------------------------------------------- NOTIFY sip:xlite@85.58.0.144:64705;transport=TCP SIP/2.0 Via: SIP/2.0/TCP OPENSER;branch=z9hG4bK1ba1.9366d7e6.0 To: sip:xlite@domain.org;tag=841ea920 From: sip:uac@domain.org;tag=10.19158.1202692716.19 CSeq: 5 NOTIFY Call-ID: NmU4Y2EwMTY1ODQzOTE0MDJhODUzM2JkYTM1NTBmMzQ. Content-Length: 568 User-Agent: OpenSER (1.4.0dev4-tls (i386/linux)) Max-Forwards: 70 Event: presence Contact: <sip:OPENSER> Subscription-State: active;expires=2364 Content-Type: application/pidf+xml <?xml version="1.0"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid" xmlns:c="urn:ietf:params:xml:ns:pidf:cipid" entity="uac(a)domain.org"> <tuple id="0x81b36d8"> <status> <basic>open</basic> </status> </tuple> <tuple xmlns="urn:ietf:params:xml:ns:pidf" id="igxiox"><status><basic>closed</basic></status></tuple> <tuple xmlns="urn:ietf:params:xml:ns:pidf" id="0x81b3aa8"> <status> <basic>open</basic> </status> </tuple> </presence> ----------------------------------------------------------------------------------------------------------------- Basically, the tupple with id="igxiox" (the one with "offline" status) is not the first one so X-Lite sees "uac" again online. Is there anything I'm doing wrong? "uac" (Twinkle) issue? X-Lite issue? Or is it just impossible thist to work properly since "pua_usrloc" behaviour? Thanks for any explanation. -- Iñaki Baz Castillo

1 0

Re: [OpenSER-Users] How to avoid malicious BYE that update accounting "StopTime"?
by Jiri Kuthan 10 Feb '08

10 Feb '08

At 18:39 08/02/2008, Alex Balashov wrote: >On Fri, February 8, 2008 11:17 am, IÃ±aki Baz Castillo wrote: > >> - But now imagine that user B sends a BYE after 2 hours using the same >> From&To tags and Call-ID. This is terrible!!! OpenSer will notify a >> "Stop" action > >Why would it do that? Call-IDs are supposed to be GUIDs (Globally Unique >Identifiers) and never reused. You shouldn't really be seeing collisions >of them on a UA that properly implements the generation algorithm for them >and fulfills the requirements of the RFC on this point. You should not, but you do. Anyhow, I think the confusion is of architectural nature here. IMO, usage-based charging if placed anywhere than in the place where the charged service is actually produced and not in a proxy to it, which may not have accurate information. I.e., put CDR stuff in PSTN gateway. -jiri -- Jiri Kuthan http://iptel.org/~jiri/

1 0

[Serusers] How to enable SERWEB logs?
by Srinivas Kotamarti 10 Feb '08

10 Feb '08

Hi, I am having difficulty to enable SERWEB logs, even after enabling the logs in config.php and install PEAR Log package. Here are the settings in my config.php $config->enable_loging = true; $config->log_file = "/var/log/serweb"; $config->log_level = "PEAR_LOG_DEBUG"; This is what I installed on my PC SERWEB0.9.6 SER0.9.6 MYSQL5.1.17 php-mysql-4.3.9-3.15 Are there any other settings I need to enable or need to install other components? Thanks --Srinivas

2 1

Re: [OpenSER-Users] Mediaproxy not working
by Andy Smith 09 Feb '08

09 Feb '08

Yep, have the mediaproxy module parts configured in openser.cfg, mine looks like: loadmodule "mediaproxy.so" modparam("mediaproxy","natping_interval", 30) modparam("mediaproxy","mediaproxy_socket", "/var/run/proxydispatcher.sock") #modparam("mediaproxy","mediaproxy_socket", "/var/run/mediaproxy.sock") modparam("mediaproxy","sip_asymmetrics","/usr/local/etc/openser/sip-asymmetric-clients") modparam("mediaproxy","rtp_asymmetrics","/usr/local/etc/openser/rtp-asymmetric-clients") >From "ps" I can see: ps -aef | grep proxy root 30916 1 0 14:53 ? 00:00:00 python /usr/local/mediaproxy/mediaproxy.py root 30919 1 0 14:53 ? 00:00:00 python /usr/local/mediaproxy/proxydispatcher.py This is from my syslog, includes info written during mediaproxy startup and a test call: Feb 9 14:53:16 serbox mediaproxy[30916]: Listening for commands on local socket `/var/run/mediaproxy.sock' Feb 9 14:53:16 serbox mediaproxy[30916]: Listening for remote commands is disabled Feb 9 14:53:16 serbox mediaproxy[30916]: Using IP address `12.12.16.10' for the RTP/RTCP proxy Feb 9 14:53:16 serbox proxydispatcher[30919]: Listening for commands on local socket `/var/run/proxydispatcher.sock' Feb 9 14:53:16 serbox proxydispatcher[30919]: Listening for mediaproxy media timeout requests on 0.0.0.0:25061 Feb 9 14:53:16 serbox proxydispatcher[30919]: Default mediaproxy server is on `/var/run/mediaproxy.sock' Feb 9 14:55:15 serbox proxydispatcher[30919]: request 71fa800f7337023a178362de41fe673b(a)12.12.16.9 12.12.16.9:10220:audio 12.12.16.9 12.12.16.9 remote serbox.ukgrid.net local Asterisk=20PBX info=from:0042*001@12.12.16.9,to:0044208888888@serbox.ukgrid.net,fromtag:as145fa099,totag: Feb 9 14:55:15 serbox mediaproxy[30916]: request 71fa800f7337023a178362de41fe673b(a)12.12.16.9 12.12.16.9:10220:audio 12.12.16.9 12.12.16.9 remote serbox.ukgrid.net local Asterisk=20PBX info=totag:,to:0044208888888@serbox.ukgrid.net,from:0042*001@12.12.16.9,fromtag:as145fa099 Feb 9 14:55:15 serbox mediaproxy[30916]: session 71fa800f7337023a178362de41fe673b(a)12.12.16.9: started. listening on 12.12.16.10:60000 Feb 9 14:55:15 serbox mediaproxy[30916]: execution time: 3.73 ms Feb 9 14:55:15 serbox proxydispatcher[30919]: forwarding to mediaproxy on /var/run/mediaproxy.sock: got: '12.12.16.10 60000' Feb 9 14:55:15 serbox proxydispatcher[30919]: execution time: 7.59 ms Feb 9 14:55:24 serbox proxydispatcher[30919]: delete 71fa800f7337023a178362de41fe673b(a)12.12.16.9 info= Feb 9 14:55:24 serbox mediaproxy[30916]: delete 71fa800f7337023a178362de41fe673b(a)12.12.16.9 info= Feb 9 14:55:24 serbox mediaproxy[30916]: session 71fa800f7337023a178362de41fe673b(a)12.12.16.9: 0/0/0 packets, 0/0/0 bytes (caller/called/relayed) Feb 9 14:55:24 serbox mediaproxy[30916]: session 71fa800f7337023a178362de41fe673b(a)12.12.16.9: ended. Feb 9 14:55:24 serbox mediaproxy[30916]: execution time: 0.55 ms Feb 9 14:55:24 serbox proxydispatcher[30919]: forwarding to mediaproxy on /var/run/mediaproxy.sock: got: '' Feb 9 14:55:24 serbox proxydispatcher[30919]: execution time: 1.59 ms

2 1

Re: [OpenSER-Users] Mediaproxy not working
by Andy Smith 09 Feb '08

09 Feb '08

Hi Iñaki, yep I have ;) Sorry my config is actually with start=yes, but Id gotten so frustrated I even tried running the mediaproxy portion on a seperate server with only the dispatcher on the OpenSER system (this made no difference to my problem). In my syslog I see both the dispatcher and the mediaproxy running, and the socket files are created. Sessions are even started per call as you'd expect but at the end of the call the mediaproxy summary (in syslog) states that it has forwarded 0 bytes/packets of data :((. So it seems the OpenSER mediaproxy module is correctly making the request to the dispatcher for a proxy session, but something is not updating the SIP IP and PORT to redirect the RTP via the proxy.... Any ideas? There seems so little you can configure regarding this in the route that I feel at a dead end... >Have you really read the doc? ;) > >; start Boolean value that specifies if to start the RTP proxy server. >; Default value: Yes >Also, after setting tha parameter to "yes" do a "tail -f /var/log/syslog" to >see mediaproxy and proxydispatcher messages.

2 1

[OpenSER-Users] Mediaproxy not working
by Andy Smith 09 Feb '08

09 Feb '08

Hi list, can anyone help? I've been trying to get mediaproxy working for a week without success :( My mediaproxy config is as follows: [Dispatcher] start = yes socket = /var/run/proxydispatcher.sock group = openser defaultProxy = /var/run/mediaproxy.sock [MediaProxy] start = no socket = /var/run/mediaproxy.sock group = openser listen = None allow = Any proxyIP =x.x.x.x portRange = 60000:65000 TOS = 0xb8 idleTimeout = 60 holdTimeout = 3600 forceClose = 0 I have use_media_proxy() in the route for any INVITEs, but Im not getting any RTP data successfully routed via mediaproxy, is there anyone on the list who has got this going who can give me a little guidance or suggestions? Would be much appreciated! thanks, Andy.

2 1

[OpenSER-Users] How to avoid malicious BYE that update accounting "StopTime"?
by Iñaki Baz Castillo 09 Feb '08

09 Feb '08

Hi, I use radius accounting with MySQL backend and MediaProxy (to make fix accounting when there is no BYE). Imagine this scenario: - A calls B. This produces a "Start" acc action, so a SQL INSERT. - After 1 minute A crashes (no BYE sent and RTP stop). - After 20 secs with no RTP MediaProxy sends an "Update" action to radius server. This generates a SQL UPDATE that sets the StopTime. So finally the call duration is 80 secs (OK). - But now imagine that user B sends a BYE after 2 hours using the same From&To tags and Call-ID. This is terrible!!! OpenSer will notify a "Stop" action to radius server which will do a new SQL UPDATE query setting the StopTime to 7201 secs !!!! How to avoid it? how to avoid anyone sending a malicious BYE with From&To tags and Call-ID from any other already ended call? -- Iñaki Baz Castillo ibc(a)in.ilimit.es

7 19

[OpenSER-Users] RTP-Proxy
by Adrian Georgescu 08 Feb '08

08 Feb '08

>>>>>>> I'm really curious, could you give me a real-world example of an RTP-detection based soution providing sub-minute dead UA detection ? Hi Jerome, Freeradius/MediaProxy/CDRTool combination gives your this zero tolerance. CDRs are always correct down to the second regardless of missing BYEs, VAD and other things you have assumed in the previous postings. Regards, Adrian

3 2

[Serusers] Can mediaproxy support relaying audio between destinations on two ethernet interfaces?
by Frank Durda IV 08 Feb '08

08 Feb '08

I'm having a problem with Mediaproxy, and am wondering if this is something it simply can't do (or won't do as written). I have a SER/mediaproxy server connected to two networks that cannot be reached by other means. So the only way for a SIP phone on one network to have a conversation with the other would be for the SER/mediaproxy combination to accept the audio from one side and shove it out to the destination on the other end. Network diagram: [SIP phone]---------+ [Asterisk Server]--[ethswitch]---[interface re2 on SER box] [PSTN switch]--------------------[interface re0 on SER box] SIP phone 192.168.200.20 Asterisk box 192.168.200.10 SER re2 192.168.200.30 PSTN switch RTP 10.9.193.146 SER re0 10.9.193.148 Again, these two networks are isolated and only meet at the SER box. This layout was a prototype for later use of NAT and the fact that the Asterisk (or a similar device) and phones would be at another company, on a network likely NAT-ed at least one more time. But for the moment there is no NAT activity, just two networks that can't send SIP data to each other except by what SER and mediaproxy/rtpproxy allow. What we see is that the call originating at the SIP phone is set up, the distant POTS phone rings, POTS phone answers, the SIP phone is informed, and we see audio passing from the PSTN network to the SER box, but no audio in either direction between SER box and SIP phone. So, mediaproxy did manage to insert itself into things enough so that the PSTN gateway knows the audio should go to a port there, so that is working. The reason for no audio on the SIP-phone side appears to be that mediaproxy is only aware of a single network interface being involved, and when the call was established, it gave the SIP phone an unreachable IP address of the network interface on the PSTN side of the SER box, not the IP address of the SER server interface on the side that is facing the SIP phone. (Packet sniff as viewed leaving the SER server) # U 192.168.200.30:5060 -> 192.168.200.10:5060 SIP/2.0 200 OK. Call-ID: 7d640cca12391c1601a2d6e535c1ef2d(a)192.168.200.30. CSeq: 102 INVITE. From: "VOIP TEST 1000" <sip:3797271700@192.168.200.30>;tag=as5fc6504f. To: <sip:9613789999@192.168.200.30>;tag=13f0000-0-402969611. Via: SIP/2.0/UDP 192.168.200.10:5060;branch=z9hG4bK7d39191f;rport=5060. Server: DC-SIP/1.2. Supported: timer. Record-Route: <sip:9613789999@192.168.200.30:5060;nat=yes;ftag=as5fc6504f;lr=on> . Contact: <sip:9613789999@10.9.193.130:5060>. Content-Type: application/sdp. Content-Length: 175. . v=0 o=- 3411495426 3411495447 IN IP4 10.9.193.130 s=- c=IN IP4 10.9.193.148 t=0 0 m=audio 10004 RTP/AVP 0 a=sendrecv a=ptime:20 a=rtpmap:0 PCMU/8000 a=silenceSupp:off - - - - # U 192.168.200.10:5060 -> 192.168.200.30:5060 ACK sip:9613789999@10.9.193.130:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.200.10:5060;branch=z9hG4bK6793020d;rport. Route: <sip:9613789999@192.168.200.30:5060;nat=yes;ftag=as5fc6504f;lr=on>. From: "VOIP TEST 1000" <sip:3797271700@192.168.200.30>;tag=as5fc6504f. To: <sip:9613789999@192.168.200.30>;tag=13f0000-0-402969611. Contact: <sip:3797271700@192.168.200.10>. Call-ID: 7d640cca12391c1601a2d6e535c1ef2d(a)192.168.200.30. CSeq: 102 ACK. User-Agent: Asterisk PBX. Max-Forwards: 70. Content-Length: 0. . but because the c=IN IP4 10.9.193.148 isn't set to 192.168.200.30, the SIP phone doesn't send any audio that is addressed for the SER/mediaproxy box, and so no one or two-way audio happens. So the ten %currency_unit question is this: Is this a limitation of Mediaproxy, that all audio must enter and leave (from and to all sources) on a single interface? A look at the source code suggests that it can only cope with a single interface, but I have not written code in Python, so may not be reading this right. The second question would be is this also a restriction of rtpproxy, or can it deal with having two or more network interfaces handling audio traffic? If it can, we'll switch to rtpproxy. If neither can handle it, we have problems. It seems odd that SER supports this situation but the audio component would not. Our mediaproxy is 1.7.2 Our ser is 0.9.6 Thanks in advance, Frank

2 1

Re: [OpenSER-Users] How to avoid malicious BYE that update accounting "StopTime"?
by Alex Balashov 08 Feb '08

08 Feb '08

On Fri, February 8, 2008 11:17 am, IÃ±aki Baz Castillo wrote: > - But now imagine that user B sends a BYE after 2 hours using the same > From&To tags and Call-ID. This is terrible!!! OpenSer will notify a > "Stop" action Why would it do that? Call-IDs are supposed to be GUIDs (Globally Unique Identifiers) and never reused. You shouldn't really be seeing collisions of them on a UA that properly implements the generation algorithm for them and fulfills the requirements of the RFC on this point. -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599

2 1

[OpenSER-Users] R: How to use $fn ?
by malmic＠alice.it 08 Feb '08

08 Feb '08

________________________________ Da: malmic(a)alice.it Inviato: ven 08/02/2008 16.57 A: users-bounces(a)lists.openser.org Oggetto: How to use $fn ? Hi there, I'm running openser v1.1.1 and I'm trying to use the $fn pseudo -variable in this way: if($fn == "0123456") action(..); but when I try to start openser it gives me sintax error . What I am doing wrong? Thanks all Mik

2 1

[OpenSER-Users] AVP syntax problem in config
by Sri Rao 08 Feb '08

08 Feb '08

I get the following in the daemon.log when I try to start openser: Feb 8 08:34:46 vishnu openser[16425]: ERROR:core:pv_parse_spec: bad parameters Feb 8 08:34:46 vishnu openser[16425]: ERROR:lcr:mod_init: Malformed or non AVP definition <s:fr_inv_timer_avp> Feb 8 08:34:46 vishnu openser[16425]: ERROR:core:init_mod: failed to initialize module lcr Feb 8 08:34:46 vishnu openser[16425]: ERROR:core:main: error while initializing modules Here are the offending lines in openser.cfg: modparam("lcr", "contact_avp", "1401") modparam("lcr", "fr_inv_timer_avp", "s:fr_inv_timer_avp") Is there a different way of defining them? Thanks, Sri.

2 1

Re: [OpenSER-Users] Compilation problem on Debian Stable/SPARC architexture
by Schumann Sebastian 08 Feb '08

08 Feb '08

Hi Bogdan, one more inmportant note, I discovered this morning. This error only appears if the option mode=debug is set. A normal # make all does compile properly! Here is the output: netra120:/usr/local/src/openser# make mode=debug prefix=/usr/local all bison -d -b cfg cfg.y cfg.y: conflicts: 1 shift/reduce flex cfg.lex New SVN revision: 2:3654 Compiling action.c gcc -DNAME='"openser"' -DVERSION='"1.3.0-notls"' -DARCH='"sparc64"' -DOS='"linux"' -DCOMPILER='"gcc 4.1.2"' -D__CPU_sparc64 -D__OS_linux -D__SMP_no -DCFG_DIR='"/usr/local/etc/openser/"' -DPKG_MALLOC -DSHM_MEM -DSHM_MMAP -DUSE_IPV6 -DUSE_MCAST -DUSE_TCP -DDISABLE_NAGLE -DHAVE_RESOLV_RES -DSTATISTICS -DCHANGEABLE_DEBUG_LEVEL -DF_MALLOC -DSVNREVISION='"2:3654"' -DEXTRA_DEBUG -DFAST_LOCK -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024 -DHAVE_GETHOSTBYNAME2 -DHAVE_UNION_SEMUN -DHAVE_SCHED_YIELD -DHAVE_MSG_NOSIGNAL -DHAVE_MSGHDR_MSG_CONTROL -DHAVE_ALLOCA_H -DHAVE_TIMEGM -DHAVE_EPOLL -DHAVE_SIGIO_RT -DHAVE_SELECT -c action.c -o action.o Compiling blacklists.c gcc -DNAME='"openser"' -DVERSION='"1.3.0-notls"' -DARCH='"sparc64"' -DOS='"linux"' -DCOMPILER='"gcc 4.1.2"' -D__CPU_sparc64 -D__OS_linux -D__SMP_no -DCFG_DIR='"/usr/local/etc/openser/"' -DPKG_MALLOC -DSHM_MEM -DSHM_MMAP -DUSE_IPV6 -DUSE_MCAST -DUSE_TCP -DDISABLE_NAGLE -DHAVE_RESOLV_RES -DSTATISTICS -DCHANGEABLE_DEBUG_LEVEL -DF_MALLOC -DSVNREVISION='"2:3654"' -DEXTRA_DEBUG -DFAST_LOCK -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024 -DHAVE_GETHOSTBYNAME2 -DHAVE_UNION_SEMUN -DHAVE_SCHED_YIELD -DHAVE_MSG_NOSIGNAL -DHAVE_MSGHDR_MSG_CONTROL -DHAVE_ALLOCA_H -DHAVE_TIMEGM -DHAVE_EPOLL -DHAVE_SIGIO_RT -DHAVE_SELECT -c blacklists.c -o blacklists.o /tmp/ccRk3oFx.s: Assembler messages: /tmp/ccRk3oFx.s:831: Error: Architecture mismatch on "membar". /tmp/ccRk3oFx.s:831: (Requires v9|v9a|v9b; requested architecture is sparclite.) /tmp/ccRk3oFx.s:847: Error: Architecture mismatch on "membar". /tmp/ccRk3oFx.s:847: (Requires v9|v9a|v9b; requested architecture is sparclite.) make: *** [blacklists.o] Error 1 netra120:/usr/local/src/openser# Regards Sebastian -----Original Message----- From: Bogdan-Andrei Iancu [mailto:bogdan@voice-system.ro] Sent: Friday, 08. February 2008 11:33 AM To: Schumann Sebastian Cc: users(a)lists.openser.org Subject: Re: [OpenSER-Users] Compilation problem on Debian Stable/SPARC architexture Hi Schumann, Can you post please the compile line (as printed by make) - just to check the compile options. Thanks, Bogdan Schumann Sebastian wrote: > Dear all > > I am facing problems installing OpenSER 1.3 from branch on a Debian > 4.0R2 running on a SUN UltraSPARC IIi server (sparc64). > > After retrieving all required files and executing # make mode=debug, the > second file's compilation fails already: > > Compiling blacklist.c > .... > Error: Architecture mismatch on "membar". > (Requires v9|v9a|v9b; requested architexture is sparclite.) > > Does anyone know what could be the reason for that. On i386 I never > faced problems, and as OpenSER supports Solaris, it should also support > Debian on sparc64 architecture or not? > > Thanks a lot in advance. > > Best regards > Sebastian > > _______________________________________________ > Users mailing list > Users(a)lists.openser.org > http://lists.openser.org/cgi-bin/mailman/listinfo/users > >

2 1

Re: [OpenSER-Users] Survey for new mailing list
by Dan-Cristian Bogos 08 Feb '08

08 Feb '08

Folks, I share the same opinion that an announcements channel should be implemented in OpenSER project. Since another mailing list could be just another subject for SPAM detectors (sometimes removals) or SPAM senders, perhaps another good approach would be the presence of an RSS feed aggregator on OpenSER website where all the important news alerts could come in (security fixes, new releases) and be read by whoever is interested via RSS. It could be a supplementary effort from a person editing these news but it would benefit from the advantage of a read only channel so a trusted entity for real news. Cheers, DanB

1 0

[Serusers] Is SER doc PSTN Gateway example incomplete/incompatible with Asterisk?
by Frank Durda IV 08 Feb '08

08 Feb '08

Hello, I am working my way through the "SER - Getting Started" documentation, using the sample configurations largely unchanged, and have run up against something that apparently others have also encountered, but I have not come across an actual fix for the problem. The basic lab setup here is SIP_Phone -> Asterisk_box -> SER_box -> Telica/Lucent LCS switch -> POTS All IP addresses are 192.168.x.x or 10.x.x.x addresses, with no NATing being performed. Asterisk and SER are operating on separate computers. The goal right now is to originate a call from the SIP phone and have a POTS phone ring answer on the other side of the LCS switch. The ser.cfg is essentially the one on page 49 of the "SER Getting Started" manual, with the local IP addresses substituted. However, any message received from the Asterisk server results in a "483 Too Many Hops" error. As mentioned in lots other places that Google can find, the Asterisk system fails to include some items that the RFC say should (or must) be there, and so SER promptly fails. The question is how to work around this, as in real life I won't have control of the Asterisk boxes communicating with my SER server and so can't patch Asterisk to play well with others. So the accommodation has to be in SER, or more likely, in its config file. Here is an OPTIONS that are regularly generated by Asterisk, and what happens to it when SER sees it: OPTIONS sip:192.168.200.30 SIP/2.0 Via: SIP/2.0/UDP 192.168.200.10:5060;branch=z9hG4bK239aa8ac;rport From: "asterisk" <sip:asterisk@192.168.200.10>;tag=as0e01f6d8 To: <sip:192.168.200.30> Contact: <sip:asterisk@192.168.200.10> Call-ID: 74f1aaf801a2f3d750d053e82951e1a5(a)192.168.200.10 CSeq: 102 OPTIONS User-Agent: Asterisk PBX Max-Forwards: 70 Date: Tue, 05 Feb 2008 13:24:09 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Content-Length: 0 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: SIP Request: Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: method: <OPTIONS> Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: uri: <sip:192.168.200.30> Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: version: <SIP/2.0> Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: parse_headers: flags=1 (HDR_VIA) Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: Found param type 232, <branch> = <z9hG4bK0d36c05d>; state=6 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: Found param type 235, <rport> = <n/a>; state=17 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: end of header reached, state=5 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: parse_headers: Via found, flags=1 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: parse_headers: this is the first via Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: After parse_msg... Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: preparing to run routing scripts... Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: parse_headers: flags=128 (HDR_ROUTE) Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: end of header reached, state=9 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: DEBUG: get_hdr_field: <To> [22]; uri=[sip:192.168.200.30] Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: DEBUG: to body [<sip:192.168.200.30> ] Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: get_hdr_field: cseq <CSeq>: <102> <OPTIONS> Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: DEBUG:maxfwd:is_maxfwd_present: value = 70 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: DBG:maxfwd:process_maxfwd_header: value 70 decreased to 16 This is the first unexpected behavior. SER apparently silently overrides the hop count specified by the message source (70) down to 16. Not a big deal, but in complex networks 16 might not be enough. Anyway, on to what happens... Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: DEBUG: add_param: tag=as2f96b7fd Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: end of header reached, state=29 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: parse_headers: flags=256 (HDR_RECORDROUTE) Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: DEBUG: get_hdr_body : content_length=0 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: found end of header Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: find_first_route: No Route headers found Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: loose_route: There is no Route HF Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: is_local(): Realm '192.168.200.30' is not local Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: is_local(): Realm '192.168.200.10' is local Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: DEBUG: t_newtran: msg id=449 , global msg id=448 , T on entrance=0xffffffff Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: parse_headers: flags=-1 (HDR_EOH) Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: parse_headers: flags=60 (HDR_INVITE|HDR_INFO|HDR_CANCEL|HDR_BYE) Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: t_lookup_request: start searching: hash=3507, isACK=0 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: DEBUG: RFC3261 transaction matching failed Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: DEBUG: t_lookup_request: no transaction found Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: DEBUG: mk_proxy: doing DNS lookup... Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: check_via_address(192.168.200.10, 192.168.200.10, 0) Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: SIP Request: Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: method: <OPTIONS> Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: uri: <sip:192.168.200.30> Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: version: <SIP/2.0> Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: parse_headers: flags=1 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: Found param type 232, <branch> = <z9hG4bK3bd.ca3aab21.0>; state=16 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: end of header reached, state=5 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: parse_headers: Via found, flags=1 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: parse_headers: this is the first via Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: After parse_msg... Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: preparing to run routing scripts... Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: parse_headers: flags=128 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: Found param type 232, <branch> = <z9hG4bK0d36c05d>; state=6 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: Found param type 235, <rport> = <5060>; state=16 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: end of header reached, state=5 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: parse_headers: Via found, flags=128 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: parse_headers: this is the second via Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: end of header reached, state=9 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: DEBUG: get_hdr_field: <To> [22]; uri=[sip:192.168.200.30] Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: DEBUG: to body [<sip:192.168.200.30> ] Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: get_hdr_field: cseq <CSeq>: <102> <OPTIONS> Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: DEBUG:maxfwd:is_maxfwd_present: value = 16 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: DEBUG: add_param: tag=as2f96b7fd Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: end of header reached, state=29 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: parse_headers: flags=256 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: DEBUG: get_hdr_body : content_length=0 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: found end of header Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: find_first_route: No Route headers found Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: loose_route: There is no Route HF Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: DEBUG: add_to_tail_of_timer[4]: 0x284eb508 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: DEBUG: add_to_tail_of_timer[0]: 0x284eb518 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: SER: new transaction fwd'ed Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: DEBUG:destroy_avp_list: destroying list 0x0 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: receive_msg: cleaning up Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: is_local(): Realm '192.168.200.30' is not local Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: is_local(): Realm '192.168.200.10' is local Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: DEBUG: t_newtran: msg id=454 , global msg id=453 , T on entrance=0xffffffff Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: parse_headers: flags=-1 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: parse_headers: flags=60 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: t_lookup_request: start searching: hash=3507, isACK=0 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: DEBUG: RFC3261 transaction matching failed Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: DEBUG: t_lookup_request: no transaction found Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: DEBUG: mk_proxy: doing DNS lookup... Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: check_via_address(192.168.200.30, 192.168.200.30, 0) Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: DEBUG: add_to_tail_of_timer[4]: 0x284eccd0 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: DEBUG: add_to_tail_of_timer[0]: 0x284ecce0 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: SER: new transaction fwd'ed Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: DEBUG:destroy_avp_list: destroying list 0x0 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1041]: receive_msg: cleaning up Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: SIP Request: Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: method: <OPTIONS> Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: uri: <sip:192.168.200.30> Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: version: <SIP/2.0> Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: parse_headers: flags=1 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: Found param type 232, <branch> = <z9hG4bK3bd.da3aab21.0>; state=16 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: end of header reached, state=5 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: parse_headers: Via found, flags=1 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: parse_headers: this is the first via Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: After parse_msg... Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: preparing to run routing scripts... Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: parse_headers: flags=128 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: Found param type 232, <branch> = <z9hG4bK3bd.ca3aab21.0>; state=16 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: end of header reached, state=5 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: parse_headers: Via found, flags=128 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: parse_headers: this is the second via Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: Found param type 232, <branch> = <z9hG4bK0d36c05d>; state=6 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: Found param type 235, <rport> = <5060>; state=16 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: end of header reached, state=5 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: parse_headers: Via found, flags=128 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: end of header reached, state=9 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: DEBUG: get_hdr_field: <To> [22]; uri=[sip:192.168.200.30] Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: DEBUG: to body [<sip:192.168.200.30> ] Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: get_hdr_field: cseq <CSeq>: <102> <OPTIONS> Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: DEBUG:maxfwd:is_maxfwd_present: value = 15 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: DEBUG: add_param: tag=as2f96b7fd Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: end of header reached, state=29 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: parse_headers: flags=256 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: DEBUG: get_hdr_body : content_length=0 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: found end of header Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: find_first_route: No Route headers found Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: loose_route: There is no Route HF Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: is_local(): Realm '192.168.200.30' is not local Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: is_local(): Realm '192.168.200.10' is local Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: DEBUG: t_newtran: msg id=454 , global msg id=453 , T on entrance=0xffffffff Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: parse_headers: flags=-1 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: parse_headers: flags=60 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: t_lookup_request: start searching: hash=3507, isACK=0 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: DEBUG: RFC3261 transaction matching failed Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: DEBUG: t_lookup_request: no transaction found Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: DEBUG: mk_proxy: doing DNS lookup... Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1040]: check_via_address(192.168.200.30, 192.168.200.30, 0) ... waiting for the hop counter to decrement to zero... Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: SIP Request: Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: method: <OPTIONS> Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: uri: <sip:192.168.200.30> Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: version: <SIP/2.0> Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: parse_headers: flags=1 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: Found param type 232, <branch> = <z9hG4bK3bd.bb3aab21.0>; state=16 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: end of header reached, state=5 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: parse_headers: Via found, flags=1 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: parse_headers: this is the first via Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: After parse_msg... Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: preparing to run routing scripts... Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: parse_headers: flags=128 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: Found param type 232, <branch> = <z9hG4bK3bd.ab3aab21.0>; state=16 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: end of header reached, state=5 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: parse_headers: Via found, flags=128 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: parse_headers: this is the second via Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: Found param type 232, <branch> = <z9hG4bK3bd.9b3aab21.0>; state=16 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: end of header reached, state=5 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: parse_headers: Via found, flags=128 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: Found param type 232, <branch> = <z9hG4bK3bd.8b3aab21.0>; state=16 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: end of header reached, state=5 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: parse_headers: Via found, flags=128 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: Found param type 232, <branch> = <z9hG4bK3bd.7b3aab21.0>; state=16 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: end of header reached, state=5 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: parse_headers: Via found, flags=128 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: Found param type 232, <branch> = <z9hG4bK3bd.6b3aab21.0>; state=16 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: end of header reached, state=5 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: parse_headers: Via found, flags=128 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: Found param type 232, <branch> = <z9hG4bK3bd.5b3aab21.0>; state=16 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: end of header reached, state=5 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: parse_headers: Via found, flags=128 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: Found param type 232, <branch> = <z9hG4bK3bd.4b3aab21.0>; state=16 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: end of header reached, state=5 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: parse_headers: Via found, flags=128 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: Found param type 232, <branch> = <z9hG4bK3bd.3b3aab21.0>; state=16 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: end of header reached, state=5 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: parse_headers: Via found, flags=128 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: Found param type 232, <branch> = <z9hG4bK3bd.2b3aab21.0>; state=16 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: end of header reached, state=5 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: parse_headers: Via found, flags=128 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: Found param type 232, <branch> = <z9hG4bK3bd.1b3aab21.0>; state=16 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: end of header reached, state=5 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: parse_headers: Via found, flags=128 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: Found param type 232, <branch> = <z9hG4bK3bd.0b3aab21.0>; state=16 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: end of header reached, state=5 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: parse_headers: Via found, flags=128 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: Found param type 232, <branch> = <z9hG4bK3bd.fa3aab21.0>; state=16 Feb 5 15:02:43 ser1 /usr/local/sbin/ser[1039]: end of header reached, state=5 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: parse_headers: Via found, flags=128 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: Found param type 232, <branch> = <z9hG4bK3bd.ea3aab21.0>; state=16 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: end of header reached, state=5 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: parse_headers: Via found, flags=128 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: Found param type 232, <branch> = <z9hG4bK3bd.da3aab21.0>; state=16 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: end of header reached, state=5 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: parse_headers: Via found, flags=128 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: Found param type 232, <branch> = <z9hG4bK3bd.ca3aab21.0>; state=16 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: end of header reached, state=5 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: parse_headers: Via found, flags=128 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: Found param type 232, <branch> = <z9hG4bK0d36c05d>; state=6 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: Found param type 235, <rport> = <5060>; state=16 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: end of header reached, state=5 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: parse_headers: Via found, flags=128 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: end of header reached, state=9 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: DEBUG: get_hdr_field: <To> [22]; uri=[sip:192.168.200.30] Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: DEBUG: to body [<sip:192.168.200.30>^M ] Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: get_hdr_field: cseq <CSeq>: <102> <OPTIONS> Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: DEBUG:maxfwd:is_maxfwd_present: value = 1 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: DEBUG: add_param: tag=as2f96b7fd Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: end of header reached, state=29 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: parse_headers: flags=256 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: DEBUG: get_hdr_body : content_length=0 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: found end of header Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: find_first_route: No Route headers found Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: loose_route: There is no Route HF Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: is_local(): Realm '192.168.200.30' is not local Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: is_local(): Realm '192.168.200.10' is local Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: DEBUG: t_newtran: msg id=453 , global msg id=452 , T on entrance=0xffffffff Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: parse_headers: flags=-1 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: parse_headers: flags=60 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: t_lookup_request: start searching: hash=3507, isACK=0 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: DEBUG: RFC3261 transaction matching failed Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: DEBUG: t_lookup_request: no transaction found Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: DEBUG: mk_proxy: doing DNS lookup... Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: check_via_address(192.168.200.30, 192.168.200.30, 0) Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: DEBUG: add_to_tail_of_timer[4]: 0x28510828 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: DEBUG: add_to_tail_of_timer[0]: 0x28510838 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: SER: new transaction fwd'ed Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: DEBUG:destroy_avp_list: destroying list 0x0 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: receive_msg: cleaning up Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: SIP Reply (status): Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: version: <SIP/2.0> Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: status: <483> Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: reason: <Too Many Hops> Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: parse_headers: flags=1 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: Found param type 232, <branch> = <z9hG4bK3bd.ab3aab21.0>; state=16 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: end of header reached, state=5 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: parse_headers: Via found, flags=1 Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: parse_headers: this is the first via Feb 5 15:02:44 ser1 /usr/local/sbin/ser[1039]: After parse_msg... ... So the hop counter reaches zero and the activity ends with a 438 Too Many Hops error being returned. None of this appears to have made it past the SER system, so I don't believe the LCS (acting as PSTN gateway) got involved at all. The problem appears to circle around the lack of a Route: or Record-Route: and/or a lack or "lr" in the message. INVITE and other message types fail in the same way, so nothing gets started at all. In searching around, I came across a reference to adding this piece of code to the start of route[1] [-]# A note on when we need to call lookup("location") [-]# [-]# This was posted to serusers on 02/23/2005 by Daniel-Constantin Mierla [-]# [-]# lookup("location") has to be used for any request that has the domain [-]# part of R-URI pointing to your SIP server, should be delivered to an [-]# end-user and does not have to follow any Route header -- it does not [-]# matter the type of method. Could be said that only REGISTERs are just [-]# for servers, the others are either mixed (e.g, OPTIONS) or only for [-]# end-users. [-] [-] if (!search(^"Route:") && !search(^"Record-Route:")) { [-] lookup("location"); [-] }; but the description was not clear (might be a language translation issue) as to if this would solve this particular problem, and in testing, the addition of this code does not seem to change the outcome. In our lab network, here are the IPaddrs of interest: 192.168.200.20 SIP phone (/24 netblock) 192.168.200.10 Asterisk server (/24 netblock) 192.168.200.30 SER server (re2) (/24 netblock) 10.9.193.135 SER server (re1) (/28 netblock) 10.9.193.148 SER server (re0) (/29 netblock) 10.9.193.130 LCS Signaling port (/28 netblock) 10.9.193.146 LCS Bearer/RTP port (/29 netblock) and here is the ser.cfg, with just IPaddrs set from the published sample: # $Id: gw-pstn.cfg 51 2006-01-31 13:28:04Z /CN=Paul Hazlett/emailAddress=paul(a)onsip.org $ debug=4 fork=yes log_stderror=no listen=192.168.200.30 # INSERT YOUR IP ADDRESS HERE alias=192.168.200.30 port=5060 children=4 dns=no rev_dns=no fifo="/tmp/ser_fifo" fifo_db_url="mysql://ser:heslo@localhost/ser" loadmodule "/usr/local/lib/ser/modules/mysql.so" loadmodule "/usr/local/lib/ser/modules/sl.so" loadmodule "/usr/local/lib/ser/modules/tm.so" loadmodule "/usr/local/lib/ser/modules/rr.so" loadmodule "/usr/local/lib/ser/modules/maxfwd.so" loadmodule "/usr/local/lib/ser/modules/usrloc.so" loadmodule "/usr/local/lib/ser/modules/registrar.so" loadmodule "/usr/local/lib/ser/modules/auth.so" loadmodule "/usr/local/lib/ser/modules/auth_db.so" loadmodule "/usr/local/lib/ser/modules/uri.so" loadmodule "/usr/local/lib/ser/modules/uri_db.so" loadmodule "/usr/local/lib/ser/modules/domain.so" loadmodule "/usr/local/lib/ser/modules/mediaproxy.so" loadmodule "/usr/local/lib/ser/modules/nathelper.so" loadmodule "/usr/local/lib/ser/modules/textops.so" loadmodule "/usr/local/lib/ser/modules/avpops.so" loadmodule "/usr/local/lib/ser/modules/permissions.so" modparam("auth_db|permissions|uri_db|usrloc", "db_url", "mysql://ser:heslo@localhost/ser") modparam("auth_db", "calculate_ha1", 1) modparam("auth_db", "password_column", "password") modparam("nathelper", "rtpproxy_disable", 1) modparam("nathelper", "natping_interval", 0) modparam("mediaproxy","natping_interval", 30) modparam("mediaproxy","mediaproxy_socket", "/var/run/mediaproxy.sock") modparam("mediaproxy","sip_asymmetrics","/usr/local/etc/ser/sip-clients") modparam("mediaproxy","rtp_asymmetrics","/usr/local/etc/ser/rtp-clients") modparam("usrloc", "db_mode", 2) modparam("registrar", "nat_flag", 6) modparam("rr", "enable_full_lr", 1) modparam("tm", "fr_inv_timer", 27) modparam("tm", "fr_inv_timer_avp", "inv_timeout") modparam("permissions", "db_mode", 1) modparam("permissions", "trusted_table", "trusted") route { # ----------------------------------------------------------------- # Sanity Check Section # ----------------------------------------------------------------- if (!mf_process_maxfwd_header("10")) { sl_send_reply("483", "Too Many Hops"); break; }; if (msg:len > max_len) { sl_send_reply("513", "Message Overflow"); break; }; # ----------------------------------------------------------------- # Record Route Section # ----------------------------------------------------------------- if (method=="INVITE" && client_nat_test("3")) { # INSERT YOUR IP ADDRESS HERE record_route_preset("192.168.200.30:5060;nat=yes"); } else if (method!="REGISTER") { record_route(); }; # ----------------------------------------------------------------- # Call Tear Down Section # ----------------------------------------------------------------- if (method=="BYE" || method=="CANCEL") { end_media_session(); }; # ----------------------------------------------------------------- # Loose Route Section # ----------------------------------------------------------------- if (loose_route()) { if ((method=="INVITE" || method=="REFER") && !has_totag()) { sl_send_reply("403", "Forbidden"); break; }; if (method=="INVITE") { if (!allow_trusted()) { if (!proxy_authorize("","subscriber")) { proxy_challenge("","0"); break; } else if (!check_from()) { sl_send_reply("403", "Use From=ID"); break; }; consume_credentials(); }; if (client_nat_test("3")||search("^Route:.*;nat=yes")){ setflag(6); use_media_proxy(); }; }; route(1); break; }; # ----------------------------------------------------------------- # Call Type Processing Section # ----------------------------------------------------------------- if (!is_uri_host_local()) { if (is_from_local() || allow_trusted()) { route(4); route(1); } else { sl_send_reply("403", "Forbidden"); }; break; }; if (method=="ACK") { route(1); break; } else if (method=="CANCEL") { route(1); break; } else if (method=="INVITE") { route(3); break; } else if (method=="REGISTER") { route(2); break; }; lookup("aliases"); if (!is_uri_host_local()) { route(4); route(1); break; }; if (!lookup("location")) { sl_send_reply("404", "User Not Found"); break; }; route(1); } route[1] { # ----------------------------------------------------------------- # Default Message Handler # ----------------------------------------------------------------- #Didn't seem to fix hop count error # if (!search(^"Route:") && !search(^"Record-Route:")) { # lookup("location"); # }; t_on_reply("1"); if (!t_relay()) { if (method=="INVITE" || method=="ACK") { end_media_session(); }; sl_reply_error(); }; } route[2] { # ----------------------------------------------------------------- # REGISTER Message Handler # ----------------------------------------------------------------- sl_send_reply("100", "Trying"); if (!search("^Contact:[ ]*\*") && client_nat_test("7")) { setflag(6); fix_nated_register(); force_rport(); }; if (!www_authorize("","subscriber")) { www_challenge("","0"); break; }; if (!check_to()) { sl_send_reply("401", "Unauthorized"); break; }; consume_credentials(); if (!save("location")) { sl_reply_error(); }; } route[3] { # ----------------------------------------------------------------- # INVITE Message Handler # ----------------------------------------------------------------- if (client_nat_test("3")) { setflag(7); force_rport(); fix_nated_contact(); }; if (!allow_trusted()) { if (!proxy_authorize("","subscriber")) { proxy_challenge("","0"); break; } else if (!check_from()) { sl_send_reply("403", "Use From=ID"); break; }; consume_credentials(); }; if (uri=~"^sip:1[0-9]{10}@") { strip(1); }; lookup("aliases"); if (!is_uri_host_local()) { route(4); route(1); break; }; if (uri=~"^sip:011[0-9]*@") { # International PSTN route(4); route(5); break; }; if (!lookup("location")) { if (uri=~"^sip:[0-9]{10}@") { # Domestic PSTN route(4); route(5); break; }; sl_send_reply("404", "User Not Found"); break; }; route(4); route(1); } route[4] { # ----------------------------------------------------------------- # NAT Traversal Section # ----------------------------------------------------------------- if (isflagset(6) || isflagset(7)) { if (!isflagset(8)) { setflag(8); use_media_proxy(); }; }; } route[5] { # ----------------------------------------------------------------- # PSTN Handler # ----------------------------------------------------------------- rewritehost("10.9.193.130"); # INSERT YOUR PSTN GATEWAY IP ADDRESS avp_write("i:45", "inv_timeout"); route(1); } onreply_route[1] { if ((isflagset(6) || isflagset(7)) && (status=~"(180)|(183)|2[0-9][0-9]")) { if (!search("^Content-Length:[ ]*0")) { use_media_proxy(); }; }; if (client_nat_test("1")) { fix_nated_contact(); }; } - - - - - - - - - - - - - - - - - - - - - - - - - - - Any suggestions or ideas as to how to get around this issue are appreciated! Frank

3 10

[Serusers] Problem with nat + forward on busy
by Martina 08 Feb '08

08 Feb '08

Hi, I have the following problem when using t_relay in a failure route: - next hop is correctly set but SIP message is forwaded to a wrong IP address (specifically to the address in request uri) failure_route[failure] { if (t_check_status("486|600")) { xlog("L_ERR", "LXLOG FAILURE_ROUTE: forward busy\n"); attr2uri("$tr.forward_busy"); $tu.uid=$tu.uid_busy; route(INBOUND); } } In route[INBOUND] several actions are performed including lookup_contacts and NAT_MANGLE Finally in the route[FORWARD] if (isflagset(FLAG_FAILUREROUTE)) { xlog("L_ERR","LXLOG: FORWARD: failure flag is set"); append_branch(); } # if this is an INVITE we might try another # (forwarding or voicemail) target after receiving an error if (method=="INVITE" && !$to_gw){ xlog("L_ERR","LXLOG: FORWARD: set_failure_route"); t_on_failure("FAILURE_ROUTE"); } # send it out now; use stateful forwarding as it works reliably # even for UDP2TCP xlog("L_ERR","L_XLOG <%ru> request uri <%nh> <%ds>"); if (!t_relay()) { sl_reply_error(); xlog("L_ERR","LXLOG: FORWARD: !t_relay"); }; drop; The LOG IS: Feb 7 18:32:40 pc005 ser[11574]: LXLOG: FORWARD: set_failure_route Feb 7 18:32:40 pc005 ser[11574]: LXLOG: %ru = <sip:103@192.168.23.237> %nh = <sip:100.0.0.2:1037;dstip=100.0.0.1;dstport=5060> %ds = <Contact: <sip:103@192.168.23.237>;q=0, sip:103@192.168.23.237> but when I look at the sent packets using ethereal INVITE message is sent to 192.168.23.237 instead that 100.0.0.2. Do you have any suggestion about possible cause of this behaviour? Thanks in advance Martina

1 0

[OpenSER-Users] Compilation problem on Debian Stable/SPARC architexture
by Schumann Sebastian 08 Feb '08

08 Feb '08

Dear all I am facing problems installing OpenSER 1.3 from branch on a Debian 4.0R2 running on a SUN UltraSPARC IIi server (sparc64). After retrieving all required files and executing # make mode=debug, the second file's compilation fails already: Compiling blacklist.c .... Error: Architecture mismatch on "membar". (Requires v9|v9a|v9b; requested architexture is sparclite.) Does anyone know what could be the reason for that. On i386 I never faced problems, and as OpenSER supports Solaris, it should also support Debian on sparc64 architecture or not? Thanks a lot in advance. Best regards Sebastian

2 1

[OpenSER-Users] Tech prefix and CarrierRoute
by TCB 08 Feb '08

08 Feb '08

I need to append the callerid as tech prefix to all outgoing calls for complience with my billing Server. I'm using carrierroute model for routing. Can i do this or do i have to resort to do it from within the openser script -- TC

2 1

[OpenSER-Users] How to set a fixed string as acc "extra" field?
by Iñaki Baz Castillo 08 Feb '08

08 Feb '08

Hi, imagine I need to log two extra fields in accounting: - Source-IP - Proxy-IP "Source-IP" will be dynamic containing the value of $si. "Proxy-IP" is a fixed string value = "88.88.88.88", but... how to log this value?: * modparam("acc", "radius_extra", "Source-IP=$si; Proxy-IP=88.88.88.88") Of course the above line fails since the IP string should be a text so should be between " ": * modparam("acc", "radius_extra", "Source-IP=$si; Proxy-IP="88.88.88.88"") This fails obviously. * modparam("acc", "radius_extra", "Source-IP=$si; Proxy-IP=\"88.88.88.88\"") This fails too. * modparam("acc", "radius_extra", "Source-IP=$si; Proxy-IP='88.88.88.88' ") This fails too. Is it impossible? any suggestion? PD: Yes, I know I can do a bit "dirty" trick: modparam("acc", "radius_extra", "Source-IP=$si; Proxy-IP=$var(proxy-ip)") ... $var(proxy-ip) = "88.88.88.88"; but I'd prefer not to do it. -- Iñaki Baz Castillo

3 3

[OpenSER-Users] Local Call
by VoIP Forums www.Go4Calls.com 07 Feb '08

07 Feb '08

Hi friends, Could you please help me how i can make dialplan to call local each subscriber using some special prefix? I tried the following but it did not work. if (uri=~"sip:00[1-9][0-9]+@.*") { strip(2); rewritehostport("pstncarrier:5060"); route(1); exit; }else if (uri=~"sip:[1-9][0-9]+@.*") rewritehostport("pstncarrier:5060"); route(1); exit; }else if (uri=~"sip:01[1-9][0-9]+@.*") strip(2); if (!lookup("location")) { sl_send_reply("404", "Not Found"); exit; }; route(1); exit; }; The first two above condition is working fine but when we trying to call using 01 prefix + subscriber ID the call not going and the message comming 404 Not Found. Regards, www.Go4Calls.Com VoIP Forums _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

2 2

Re: [OpenSER-Users] How to handle messages received in WeSIP?
by Rajat Dudeja 07 Feb '08

07 Feb '08

1 0

[Serusers] How to investigate/filter the sdp contents if Content type is text/plain
by Tomasz Zieleniewski 07 Feb '08

07 Feb '08

Hi, is it possible to check message contents if they contain some sting in case of content type text/plain?? will it work if I use search('some string'); from textops module? Regards Tomasz

3 2

Re: [OpenSER-Users] newbie questions
by Doug McLetchie 07 Feb '08

07 Feb '08

Thanks for the reply Alex! I really appreciate it. I've been reading manuals & sip specs all day, and I think that I found my answer, and it really is an easy one. here's my own answer to my question, can you let me know if this sounds right? When a message is send from a user agent (on the public internet) to my gatweway & then to the proxy (on a private network), the gateway will add a via on to the message. that's how open SER (or any other proxy) can send a response message back to user agent on the public internet via the gateway. It's really the same thing as setting up a registrar, or any other kind of proxy/user agent that's going to communicate via a SBC of any kind. So, it that right? is that how the SIP via header is used? I understand the part about registrations. We're not currently doing that in our network, we're using all static IP addressing. I plan on using registrations in the future. the gateway that I'm using can act as a session border controller, but it can also act as a class 4/5 switch (TDM or IP). so it's some serious overkill for what I want to do here. :o) Thanks again for the reply, --Doug ----- Original Message ---- From: Alex Balashov <abalashov(a)evaristesys.com> To: Doug McLetchie <dougmcletchieatwork(a)yahoo.com> Cc: users(a)lists.openser.org Sent: Wednesday, February 6, 2008 1:23:51 AM Subject: Re: [OpenSER-Users] newbie questions Doug, Doug McLetchie wrote: > For inbound calls (calls coming from another carrier to my big expensive > gateway & destined for a specific PBX), I'd like my gateway to send the > call to the proxy, who will determine which PBX to send the call to, and > then send the call to to correct PBX via the Gateway. I don't > understand how to set up OpenSER to send the call via the Gateway. If I > provision the static ip address of the PBX in the proxy, won't it try to > send directly to that IP address instead of sending it to the Gateway? > I think that the feature that I'm looking for is something like an > outbound proxy, for the proxy. (does that make sense?) OpenSER can certainly do what you are trying to accomplish. SIP routing is done by URI, which consists of a "user" part and a "domain" part. The "user" part is the number (or alphanumeric identification, in the case of pure-VoIP peering) and the "domain" part is the IP "place" at which the "user" part is reachable. When you route a call to some URI, what you are really saying is, "Here, domain, you must know what to do with this 'user' part - i.e. have reachability information for it (a SIP contact bound from a registration, for example)." A proxy by itself isn't enough. If you need to reach these PBXs, you clearly need to know how to reach them. This requires a SIP registrar somewhere, so that the PBXs can register against it and say, "Here, you can reach me at such and such IP and port." Or, I suppose, you can define these contacts statically with a database interface from the proxy, in which case you don't need to use a registrar. I don't know what this Big Expensive Gateway is, but if it's something like a Session Border Controller, it should be able to forward SIP REGISTER requests to your proxy/registrar. Or do they register against the gateway? Either way, you can perform this resolution with OpenSER. The problem you *might* run into is sending the same logical call leg back to the Gateway. Depending on what it is, it may not like that and perceive a call routing loop, because the call that went through it to the proxy is the "same" call (in terms of SIP Call-ID, and other things that make up a logical call "leg") that is now being sent back around to it. This problem is often solved with the introduction of a back-to-back user agent which can re-originate a different call leg. -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599 ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

3 2

[OpenSER-Users] Accounting through Mediaproxy
by Abdul 07 Feb '08

07 Feb '08

Good Day All, I am trying to get accrue AcctSessionTime of calls. I am using Openser+Asterisk but some time asterisk CDR are not accoutered, record missing + if some one call 15 min it will come 2 hrs in cdr. Is Mediaproxy will be best choice to get trust able AcctSessionTime? If Mediaproxy AcctSessionTime is trustable, i have to use ACC module of Openser or only dbaccounting configuration will be enough to store records direct from Mediaproxy into MySQL backend? Thank You Abdul Latef --------------------------------- Never miss a thing. Make Yahoo your homepage.

2 1

[OpenSER-Users] How to handle messages received in WeSIP?
by Rajat Dudeja 06 Feb '08

06 Feb '08

Hi, I'm using SEAS module to interact with WeSIP Application Server. I'm using the version wesip-02-04-07-beta-0.1.4.tar.gz of WeSIP. I've managed to configure it and I'm also seeing that the messages are received by WeSIP. I'ld like to know: 1. Are there any special files to which WeSIP writes the received messages? 2. In case, some one wants to modify the received message then is there a possibilty to send the modified message back to OpenSER? 3. I have used the above tar file, to me it appears that this file only contains the binary form of WeSIP. So where can I get the complete source code of WeSIP? Many thanks, Rajat =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you

2 1

[OpenSER-Users] renaming of database modules
by Henning Westerholt 06 Feb '08

06 Feb '08

Hi all, the database modules and the supporting infrastrucure in the OpenSER core are heavily reworked in the trunk version at the moment. Common functionality that is present in all database modules were integrated in the core, new functionality have been added. Its planned to unify the overall behaviour and structure of all modules that are interfacing with databases, to make them more maintainable, more safe and also more bug-free. Important foundations for this changes have already been created. As part of this process the database modules names were changed. All these module names are now prefixed with 'db_'. The new names of the modules are now db_mysql, db_postgres, db_unixodbc, db_berkeley, db_text, db_flatstore. If you use one database module with the trunk version, you must change some parts of the configuration. Old module configuration: loadmodule "mysql.so" modparam("mysql", "ping_interval", 300) modparam("mysql", "auto_reconnect", 1) New module configuration: loadmodule "db_mysql.so" modparam("db_mysql", "ping_interval", 300) modparam("db_mysql", "auto_reconnect", 1) The database URLs for modules that connect to a database, e.g. usrloc don't need to be changed, if you use mysql, postgres, unixodbc or flatstore DBs. For the dbtext and db_berkeley modules the new database URLs are: modparam("usrloc", "db_url", "text://my-database-path")" modparam("usrloc", "db_url", "berkeley://my-database-path")" (you need to adapt the path to your setup, of course). If you encounter any bugs that were introduced during this change, please open a bug report on the tracker. Best regards, Henning

1 0

[Serusers] (SER + OpenXCAP) Presence Authorization problem
by Guhan P 06 Feb '08

06 Feb '08

Hi All, I am using SER 2.0 and OpenXCAP 0.9.7 and facing problem in implementing Presence Authorization using XCAP in my project. I have done the following:- User A (User_A.pcap(attachment)): 1.Registered with SER. 2.Published A's info into SER. 3.Subscribed for it's 'presence.watcher info' 4.Transferred presence_rules.xml(which contains rules to allow B to see his presence status) to OpenXcap. Following debugging messages were printed (while transferring presence_rules file ) in OpenXcap: ************************************** Feb 6 12:15:40 sips openxcap[2557]: [-] Starting factory <twisted.web.xmlrpc._QueryFactory instance at 0xb3cde68c> Feb 6 12:15:40 sips openxcap[2557]: [Uninitialized] error: Error while notifying OpenSER management interface for 'user' a@: Connection was refused by other side: 111: Connection refused. Feb 6 12:15:40 sips openxcap[2557]: [Uninitialized] a@ from 172.16.7.187 "PUT http://172.16.7.204/xcap-root/pres-rules/users/a/presence-rules.xml" 201 0 - unknown Feb 6 12:15:40 sips openxcap[2557]: [Uninitialized] Stopping factory <twisted.web.xmlrpc._QueryFactory instance at 0xb3cde68c> ************************************* User B (User_B.pcap(attachment)): 5.Registered with SER. 6.Published B's info into SER. 7.Sent Subscribe request for A's presence status to SER. 8.Received 200 ok for subscribe request. 9.Received Notify request with status as pending 10.SER intimated User A about User B's subscription. Following debugging messages were printed in SER: *************************** 5(5114) find_export_record: found <xcap_query> in module xcap [/home/ser/SER2.0/lib/ser/modules/xcap.so] 5(5114) curl error: 22 5(5114) XCAP problems for uri 'http://172.16.7.204:8000/xcap-root/pres-rules/users/a/presence-rules.xml' *************************** SER did not send User A's presence status to User B(Notify status was pending). It seems to be SER did not interact with OpenXcap server. This is my Presence Authorization configuration settings in ser.cfg ************************************************************************************************** modparam("pa", "use_db", 1) modparam("pa", "offline_winfo_timer", 600) #modparam("pa", "use_offline_winfo", 1) modparam("pa", "offline_winfo_expiration", 600) modparam("pa", "db_url", "mysql://ser:heslo@127.0.0.1:3306/ser") # mode of PA authorization: none, implicit or xcap modparam("pa", "auth", "xcap") modparam("pa", "winfo_auth", "none") modparam("pa", "use_callbacks", 1) modparam("pa", "accept_internal_subscriptions", 0) modparam("pa", "max_subscription_expiration", 120) modparam("pa", "timer_interval", 1) modparam("pa", "watcherinfo_notify", 1) modparam("pa", "async_auth_queries", 1) modparam("pa", "pres_rules_file", "presence-rules.xml") modparam("xcap", "xcap_root", "http://172.16.7.204:8000/xcap-root") modparam("usrloc", "db_mode", 1) ************************************************************************************************** Please find the attached file NW_Captures.zip which contains two ethereal captures(User_A.pcap & User_B.pcap). Could you help me to resolve this problem? Regards, Guhan

1 0

[OpenSER-Users] Call Session Time
by VoIP Forums www.Go4Calls.com 06 Feb '08

06 Feb '08

Hi all, How i can store Call Session Time in acc table? I am using Mediaproxy so i hope the call duration will be correct event if openser does not receive the BYE. I tried to use ACC but inside the table all information is storing only i cannot see the filed name for session or call duration. Could you please help me how i can figure out to get call duration to charge our customers? Regards, www.Go4Calls.Com VoIP Forums _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

1 0

Re: [OpenSER-Users] Mediaproxy listening but handling zero bytes of audio
by A.smith 06 Feb '08

06 Feb '08

Seems like this may be the same issue Im experiencing, anyone any experience of this type of issue?? Anything? :P http://www.voipuser.org/index.php?name=PNphpBB2&file=viewtopic&t=11052&high… ________________________________________________ Message sent using UK Grid Webmail 2.7.9

1 0

[OpenSER-Users] Sending Text Response from Openser to client
by Ali Jawad 06 Feb '08

06 Feb '08

Dear All I would like to change the messages that are sent back from the openser server to the client is this possible using sl_send_reply for example ? I have tried sl_send_reply in the route[1] but it pops up a dialog box and it seems to break the calls. Can anyone tell me where to get more info about such a scenario. Or suggest any solutions ? Thanks

4 7

[OpenSER-Users] Store Encypted Pwds in MySQL DB
by Ali Jawad 06 Feb '08

06 Feb '08

Hi All I am migrating a couple of thousand users from an old sip server with mysql support to openser with mysql support, the thing is that in the old server the passwords were encrypted using 3DES and stored encypted in the MySQL db ...the old SIP server received the passwords using plaintext converted them to 3DES using perl script and the compared the result to the password stored in the MySQL DB. Any ideas about how to achieve something like this in OpenSER "? I.e. hash the passwords ? Or any other solution ? I have seen some hashed entries in the MySQL db could they be used for such purposes ? Thanks

2 1

[OpenSER-Users] [OT] 1000 subscribers exceeded on the list
by Bogdan-Andrei Iancu 06 Feb '08

06 Feb '08

Hi, Just proud to announce that the users mailing list just exceeded 1000 subscribers (1001 right now). I will just take the opportunity to thanks again to all people answering on this list and providing valuable knowledge to all interested and working with openser. Regards, Bogdan

1 0

Re: [OpenSER-Users] MSILO back notify not working
by Iñaki Baz Castillo 06 Feb '08

06 Feb '08

On Monday 04 February 2008 19:02:30 Dan-Cristian Bogos wrote: > Iñaki, > > this code should do the magic: > > if (!t_reply("202", "Accepted")) > { > sl_reply_error(); > }; I use exactly that code: t_newtran(); if (m_store("$ru")) { if (!t_reply("202", "Accepted")) sl_reply_error(); } But there is not a created MESSAGE by OpenSer to the sender. I've set "debug=4" and no errors appear, the message storage is done correctly and OpenSer doesn't try to send back a new MESSAGE as notification. I'd like to insist a bit in the fact that what I'm trying to get is receiving a **new** MESSAGE generated by OpenSer as notification to the sender, not just the "202, Accept" reply (that is a reply, not a MESSAGE). Please Dan, can you confirm that MSILO module should generate and send a new MESSAGE as notification to the sender, and not just a "202 Accepted" reply? Thanks a lot. -- Iñaki Baz Castillo ibc(a)in.ilimit.es

7 12

[OpenSER-Users] can't get openser to start
by Bill Brownrigg 06 Feb '08

06 Feb '08

My openser.cfg runs and the modules load but then I get this message: "ERROR: tcp_init: bind(7, 0x811d384, 16) on 127.0.0.1:5060 : Address already in use" Environment is Red Hat and OpenSER 1.1.0 We do not need TCP as we only use UDP. Is there a simple way to remove TCP from the OpenSER environment? If not, how do we figure out what is causing the conflict? The box used to run Asterisk but it was shut down. TIA, Bill

3 2

[OpenSER-Users] newbie questions
by Doug McLetchie 06 Feb '08

06 Feb '08

Hi all, I've been reading through the documentation online fore a few days, and I've read through a lot of the user & developer artchives. I'm trying to figure out if OperSER is the right proxy solution for the problem that I'm trying to solve. I was hoping that I could get a few pointes from some more experienced users. My first question is really simple... I must have the terminology wrong, otherwise I'm sure that I would have found the answer by now. I have a big expensive gateway, but it can't do a few things that I really want to do. I'm hoping to augment my big expensive gateway with OpenSER, so that I can do some specific routing. I want my network to look something like this: -------------- (Public IP network) (Private IP network) .----------. | carriers |-----. '----------' | .-----------. '----| Big | .-------. | Expensive |----| Proxy | .------. .----| Gateway | '-------' | PBXs |---------' '-----------' '------' ---------- my solution involves customer-premise based PBXs that my company makes in house. I want the gateway to act as a session border controller. It'll take care of forwarding me media, and it'll take care of protecting my proxy from the public internet. For inbound calls (calls coming from another carrier to my big expensive gateway & destined for a specific PBX), I'd like my gateway to send the call to the proxy, who will determine which PBX to send the call to, and then send the call to to correct PBX via the Gateway. I don't understand how to set up OpenSER to send the call via the Gateway. If I provision the static ip address of the PBX in the proxy, won't it try to send directly to that IP address instead of sending it to the Gateway? I think that the feature that I'm looking for is something like an outbound proxy, for the proxy. (does that make sense?) Sorry to write such a long e-mail to the mailing list! I wanted this to be descriptive enough that you all would know what I mean. THANKS! --Doug ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

2 1

[OpenSER-Users] openser+diameter communication problem-------->kindly pay attentionusers
by bhargav.b＠renovau.com 06 Feb '08

06 Feb '08

hellow everybody, i have to authorise clients connected to openser with the help of opendiameter. can u guide me to do the needed thing. actually i have installed opendiameter,openser,xlite[soft phone].right now xlite is communicating and authorised by openser.i have added most of all modules in openser configuration file provided by openser group.even openser is communicating with open diameter client.but the problem is the user name and password are not identified by opendiameter client. could u tell me how to add user information in opendiameter[username,passwd,etc]so that server can authorise him to do further task. in clients dump i can see messages like"code not found,avp not found "sort of things. i really need u peoples help in developing a working model. your's faithfully bhargav.b

1 0

[OpenSER-Users] Is it possible to add a header to a reply?
by Iñaki Baz Castillo 05 Feb '08

05 Feb '08

Hi, it could be nice the possibility of adding headers in OpenSer replies. I mean replies generated by OpenSer with "t_reply()" or "sl_reply()". For example it could be cool adding a header: "Success: User offline, message stored" when using MSILO before: if (m_store("$ru")) t_reply("202", "Accepted")) AFAIK this is not possible, is it? If not, maybe I'd report it as feature request, what's your opinion about it? Thanks. -- Iñaki Baz Castillo

2 2

Re: [OpenSER-Users] Remote Mediaproxy Server
by Abdul 05 Feb '08

05 Feb '08

Actually i have one extra server in our Rack so i wanted to make Mediaproxy in different server then we may get better and more peformance. Currently MediaProxy is installed in my same Openser Server and it is working well in production. The Server where we need to install Mediaproxy, it is on same Network of Openser and i can ping well the difference is only that it is in NAT mode it does not have any public IP we only can connect that server through Openser or using some VPN connection --------------------------------- Never miss a thing. Make Yahoo your homepage.

1 0

[OpenSER-Users] AVPOPS question
by Mouncif Benniane 05 Feb '08

05 Feb '08

How Do I re-write the IP, Port of Request URI using avp_pushto() ?

3 4

[OpenSER-Users] Mediaproxy listening but handling zero bytes of audio
by Andy Smith 05 Feb '08

05 Feb '08

Hi, Im trying to test mediaproxy for the first time, I am forcing all traffic through mediaproxy in the openser.cfg (there's nothing wrong with that in principal is there?). I have one SIP handset hanging directly off OpenSER and another connected to Asterisk which has a channel configured to OpenSER. I can get the call answered but there is audio only in one direction and even more strangely I see that mediaproxy has not handled any data at all in the audio stream. This is what I see from mediaproxy: Feb 5 21:26:05 server proxydispatcher[13968]: request 75c5e34d0e567d5f1fa22f583ecc7af0(a)10.1.1.1 10.1.1.1:16042:audio 10.1.1.1 10.1.1.1 remote server.domain.net local Asterisk=20PBX info=from:0042*001@10.1.1.1,to:0044208888888@server.domain.net,fromtag:as1a72639d,totag: Feb 5 21:26:05 server mediaproxy[13965]: request 75c5e34d0e567d5f1fa22f583ecc7af0(a)10.1.1.1 10.1.1.1:16042:audio 10.1.1.1 10.1.1.1 remote server.domain.net local Asterisk=20PBX info=totag:,to:0044208888888@server.domain.net,from:0042*001@10.1.1.1,fromtag:as1a72639d Feb 5 21:26:05 server mediaproxy[13965]: session 75c5e34d0e567d5f1fa22f583ecc7af0(a)10.1.1.1: started. listening on 10.1.2.2:60006 Feb 5 21:26:05 server mediaproxy[13965]: execution time: 1.49 ms Feb 5 21:26:05 server proxydispatcher[13968]: forwarding to mediaproxy on /var/run/mediaproxy.sock: got: '10.1.2.2 60006' Feb 5 21:26:05 server proxydispatcher[13968]: execution time: 5.03 ms Feb 5 21:26:53 server proxydispatcher[13968]: delete 75c5e34d0e567d5f1fa22f583ecc7af0(a)10.1.1.1 info= Feb 5 21:26:53 server mediaproxy[13965]: delete 75c5e34d0e567d5f1fa22f583ecc7af0(a)10.1.1.1 info= Feb 5 21:26:53 server mediaproxy[13965]: session 75c5e34d0e567d5f1fa22f583ecc7af0(a)10.1.1.1: 0/0/0 packets, 0/0/0 bytes (caller/called/relayed) Feb 5 21:26:53 server mediaproxy[13965]: session 75c5e34d0e567d5f1fa22f583ecc7af0(a)10.1.1.1: ended. Feb 5 21:26:53 server mediaproxy[13965]: execution time: 0.60 ms Feb 5 21:26:53 server proxydispatcher[13968]: forwarding to mediaproxy on /var/run/mediaproxy.sock: got: '' Feb 5 21:26:53 server proxydispatcher[13968]: execution time: 1.51 ms This "0/0/0 packets, 0/0/0 bytes (caller/called/relayed)" being the part that I dont understand, well it proves its not handling the audio stream, but other than put a use_media_proxy command in the openser route there isnt anything else I can do to get the data stream to route via media proxy is there? My openser route is very simple: route{ if (!mf_process_maxfwd_header("15")) { sl_send_reply("483","Too Many Hops"); exit; }; if (msg:len >= max_len ) { sl_send_reply("513", "Message too big"); exit; }; if (method=="OPTIONS") { exit; }; if (method=="REGISTER") { record_route(); if (!save("location")) { sl_reply_error(); }; exit; }; if (loose_route()) { append_hf("P-hint: rr-enforced\r\n"); if(is_method("BYE")) { # log it all the time acc_rad_request("200 ok"); acc_log_request("200 ok"); end_media_session(); } route(1); }; if(is_method("INVITE") && !has_totag()) { # set the acc flags record_route(); use_media_proxy(); setflag(1); # setflag(2); $avp(s:can_uri) = $ru; }; if (!uri==myself) { append_hf("P-hint: outbound\r\n"); route(1); }; if (uri==myself) { if (!lookup("location")) { # log to acc as missed call acc_rad_request("404 Not Found"); acc_log_request("404 Not Found"); sl_send_reply("404", "Not Found"); exit; }; append_hf("P-hint: usrloc applied\r\n"); }; route(1); } # SECTION 5 - SECONDARY ROUTE BLOCKS route[1] { if (!t_relay()) { sl_reply_error(); }; exit; } Anyone any ideas what might be going on or how I can investigate the issue further? thanks for any help! Andy.

1 0

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