sr-users November 2005

sr-users@lists.kamailio.org

245 participants
571 discussions

RE: [Users] "uri == myself" matches when port is not port is different
by Vitaly Nikolaev 01 Nov '05

01 Nov '05

I also went thought the same situation and found the best solution (fastest) to keep second application (in my case b2bua) on different IP (alias) -----Original Message----- From: users-bounces(a)openser.org [mailto:users-bounces@openser.org] On Behalf Of Tavis P Sent: Monday, October 31, 2005 7:34 PM To: users(a)openser.org Subject: [Users] "uri == myself" matches when port is not port is different This is a somewhat unique situation, but with my config i have some call features that are hosted on another SIP aware application running on the same system. In a branch_route block i am checking to see if destination is myself to avoid loops, however when i direct a message to, say "127.0.0.1:5090" and OpenSER is configured to listen on port 5060 only the "if (uri == mysql)" statment matches even though the port is different. It seems to me that this behaviour is not intuative given the use of the statment, can anyone else comment on this? _______________________________________________ Users mailing list Users(a)openser.org http://openser.org/cgi-bin/mailman/listinfo/users

2 1

[Users] Tracker system
by Bogdan-Andrei Iancu 01 Nov '05

01 Nov '05

Hi everybody, I just finished configuring and testing the project tracker hosted on SorceForge. My apologies for the "un-explained" emails on the devel list :) The purpose of the tracker will be of course to have a centralized system to keep trace of : 1) bug reports 2) support requests 3) feature requests 4) documentation reports 5) patch submission If needed, other sections can be added. All developer have admin rights on this tracker (to create new categories or groups, etc). let's use it and start registering all known pending issues (discussed so far on the mailing list) in order to avoid forgetting them and to have a big picture of the current status. All changes regarding the status of the register items will be emailed to the devel mailing list. There are couple of items already registered by me - all project developers: please review them and update them accordingly if necessary! For example, for the enum patch, I think Juha will be the best person to assign it to. regards, bogdan

1 1

Re: [Users] Detecting runaway calls
by Daryl Sanders 01 Nov '05

01 Nov '05

Thanks for the info guys! It sounds like I need to do a little reading up on cseq to determine if this will even work, or find a PSTN gateway provider that supports Session-Timers. - Daryl On 10/27/05, Bogdan-Andrei Iancu <bogdan(a)voice-system.ro> wrote: > by sending re-INVITEs from the middle of the path you will increase the > cseq number differently on each side...so you will need to synchronize > the cseq value when some in-the-dialog requests are passing through your > proxy....and that's quite complicated.... > > regards, > bogdan > > Daryl Sanders wrote: > > >Would it be possible to fake a REINVITE then check the response to > >determine if a call is still in session? Just brainstorming... > > > >- Daryl > > > > > >

7 16

[Users] lcr module
by Richard Z 01 Nov '05

01 Nov '05

Hi, I am trying to develop some features which requires to call load_gws and next_gw in a failure route. For example, in normal routing block, it forwards the call to a subscriber's ip phone locations. If nobody answer, it tries to call a pstn number. In the failure route, i called load_gws and next_gw. However it generates an error "next_gw(): No ruri_user AVP". Looking at the code, there seems to be an assumption that first time call to next_gw always happens in the normal routing block. But in my case, it calls next_gw first time in a failure route. I even tried to manually add the new uri's username to avp i:1402. It still won't work. Is it possible to call next_gw first time in a failure route? Thanks, Richard

2 3

[Users] Call not torn down when CANCEL sent before INVITE message is finished being processed
by Tavis P 01 Nov '05

01 Nov '05

With the latest CVS build of OSER, when an INVITE is sent followed by a CANCEL, before OSER has finished processing the initial INVITE, the outbound call is not torn down, and SER routes the CANCEL message to itself. Below is an ngrep trace of the exchange. I have a development cluster of mediaproxy servers setup and one of them was taken offline but left in the loop which increased the time it took for a message to be processed which is how i came across this situation (it took some seconds before the INVITE was able to be transmitted to the nexthop_proxy) -- # U 2005/10/04 01:44:43.134010 SIP_UAC:5070 -> OSER_PROXY:15061 INVITE sip:6046946333@OSER_PROXY:15061 SIP/2.0. Via: SIP/2.0/UDP 192.168.99.66:5070;branch=z9hG4bK-34d67b8f. From: tavis <sip:200110005334@OSER_PROXY:15061>;tag=6e3e1f53c3f352efo0. To: <sip:6046946333@OSER_PROXY:15061>. Call-ID: ec5b9223-f98ffe5f(a)192.168.99.66. CSeq: 101 INVITE. Max-Forwards: 70. Contact: tavis <sip:200110005334@192.168.99.66:5070>. Expires: 240. User-Agent: Sipura/SPA3000-3.1.5(GWb). Content-Length: 287. Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER. Supported: x-sipura. Content-Type: application/sdp. . v=0. o=- 25915303 25915303 IN IP4 192.168.99.66. s=-. c=IN IP4 192.168.99.66. t=0 0. m=audio 16410 RTP/AVP 18 0 4 8 101. a=rtpmap:18 G729a/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:4 G723/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:20. a=sendrecv. # U 2005/10/04 01:44:43.135736 OSER_PROXY:15061 -> SIP_UAC:5070 SIP/2.0 407 Proxy Authentication Required. Via: SIP/2.0/UDP 192.168.99.66:5070;branch=z9hG4bK-34d67b8f;rport=5070;received=SIP_UAC. From: tavis <sip:200110005334@OSER_PROXY:15061>;tag=6e3e1f53c3f352efo0. To: <sip:6046946333@OSER_PROXY:15061>;tag=688bd636d693eb2ab143ccbaf0db2c7a.8474. Call-ID: ec5b9223-f98ffe5f(a)192.168.99.66. CSeq: 101 INVITE. Proxy-Authenticate: Digest realm="hq.galnet.ca", nonce="4341dfb7e0cfaa398a6f425c02262325f943b20e", qop="auth". Content-Length: 0. . # U 2005/10/04 01:44:43.147960 SIP_UAC:5070 -> OSER_PROXY:15061 ACK sip:6046946333@OSER_PROXY:15061 SIP/2.0. Via: SIP/2.0/UDP 192.168.99.66:5070;branch=z9hG4bK-34d67b8f. From: tavis <sip:200110005334@OSER_PROXY:15061>;tag=6e3e1f53c3f352efo0. To: <sip:6046946333@OSER_PROXY:15061>;tag=688bd636d693eb2ab143ccbaf0db2c7a.8474. Call-ID: ec5b9223-f98ffe5f(a)192.168.99.66. CSeq: 101 ACK. Max-Forwards: 70. Contact: tavis <sip:200110005334@192.168.99.66:5070>. User-Agent: Sipura/SPA3000-3.1.5(GWb). Content-Length: 0. . # U 2005/10/04 01:44:43.154728 SIP_UAC:5070 -> OSER_PROXY:15061 INVITE sip:6046946333@OSER_PROXY:15061 SIP/2.0. Via: SIP/2.0/UDP 192.168.99.66:5070;branch=z9hG4bK-249e2787. From: tavis <sip:200110005334@OSER_PROXY:15061>;tag=6e3e1f53c3f352efo0. To: <sip:6046946333@OSER_PROXY:15061>. Call-ID: ec5b9223-f98ffe5f(a)192.168.99.66. CSeq: 102 INVITE. Max-Forwards: 70. Proxy-Authorization: Digest username="200110005334",realm="hq.galnet.ca",nonce="4341dfb7e0cfaa398a6f425c02262325f943b20e",uri="sip:6046946333@OSER_PROXY:15061",algorithm=MD5,response="6867ef34181ba7cedbcbf8dd869f53ab",qop=auth,nc=00000001,cnonce="750e43e5". Contact: tavis <sip:200110005334@192.168.99.66:5070>. Expires: 240. User-Agent: Sipura/SPA3000-3.1.5(GWb). Content-Length: 287. Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER. Supported: x-sipura. Content-Type: application/sdp. . v=0. o=- 25915303 25915303 IN IP4 192.168.99.66. s=-. c=IN IP4 192.168.99.66. t=0 0. m=audio 16410 RTP/AVP 18 0 4 8 101. a=rtpmap:18 G729a/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:4 G723/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:20. a=sendrecv. # U 2005/10/04 01:44:43.648366 SIP_UAC:5070 -> OSER_PROXY:15061 INVITE sip:6046946333@OSER_PROXY:15061 SIP/2.0. Via: SIP/2.0/UDP 192.168.99.66:5070;branch=z9hG4bK-249e2787. From: tavis <sip:200110005334@OSER_PROXY:15061>;tag=6e3e1f53c3f352efo0. To: <sip:6046946333@OSER_PROXY:15061>. Call-ID: ec5b9223-f98ffe5f(a)192.168.99.66. CSeq: 102 INVITE. Max-Forwards: 70. Proxy-Authorization: Digest username="200110005334",realm="hq.galnet.ca",nonce="4341dfb7e0cfaa398a6f425c02262325f943b20e",uri="sip:6046946333@OSER_PROXY:15061",algorithm=MD5,response="6867ef34181ba7cedbcbf8dd869f53ab",qop=auth,nc=00000001,cnonce="750e43e5". Contact: tavis <sip:200110005334@192.168.99.66:5070>. Expires: 240. User-Agent: Sipura/SPA3000-3.1.5(GWb). Content-Length: 287. Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER. Supported: x-sipura. Content-Type: application/sdp. . v=0. o=- 25915303 25915303 IN IP4 192.168.99.66. s=-. c=IN IP4 192.168.99.66. t=0 0. m=audio 16410 RTP/AVP 18 0 4 8 101. a=rtpmap:18 G729a/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:4 G723/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:20. a=sendrecv. # U 2005/10/04 01:44:44.155113 SIP_UAC:5070 -> OSER_PROXY:15061 CANCEL sip:6046946333@OSER_PROXY:15061 SIP/2.0. Via: SIP/2.0/UDP 192.168.99.66:5070;branch=z9hG4bK-249e2787. From: tavis <sip:200110005334@OSER_PROXY:15061>;tag=6e3e1f53c3f352efo0. To: <sip:6046946333@OSER_PROXY:15061>. Call-ID: ec5b9223-f98ffe5f(a)192.168.99.66. CSeq: 102 CANCEL. Max-Forwards: 70. Proxy-Authorization: Digest username="200110005334",realm="hq.galnet.ca",nonce="4341dfb7e0cfaa398a6f425c02262325f943b20e",uri="sip:6046946333@OSER_PROXY:15061",algorithm=MD5,response="512097281b4fba990adf2cc6c273f033",qop=auth,nc=00000002,cnonce="750e43e5". User-Agent: Sipura/SPA3000-3.1.5(GWb). Content-Length: 0. . # U 2005/10/04 01:44:44.285994 OSER_PROXY:15061 -> SIP_UAC:5070 SIP/2.0 483 Too many hops. Via: SIP/2.0/UDP 192.168.99.66:5070;rport=5070;received=SIP_UAC;branch=z9hG4bK-249e2787. From: tavis <sip:200110005334@OSER_PROXY:15061>;tag=6e3e1f53c3f352efo0. To: <sip:6046946333@OSER_PROXY:15061>;tag=688bd636d693eb2ab143ccbaf0db2c7a.32f9. Call-ID: ec5b9223-f98ffe5f(a)192.168.99.66. CSeq: 102 CANCEL. Content-Length: 0. . # U 2005/10/04 01:44:44.648305 SIP_UAC:5070 -> OSER_PROXY:15061 INVITE sip:6046946333@OSER_PROXY:15061 SIP/2.0. Via: SIP/2.0/UDP 192.168.99.66:5070;branch=z9hG4bK-249e2787. From: tavis <sip:200110005334@OSER_PROXY:15061>;tag=6e3e1f53c3f352efo0. To: <sip:6046946333@OSER_PROXY:15061>. Call-ID: ec5b9223-f98ffe5f(a)192.168.99.66. CSeq: 102 INVITE. Max-Forwards: 70. Proxy-Authorization: Digest username="200110005334",realm="hq.galnet.ca",nonce="4341dfb7e0cfaa398a6f425c02262325f943b20e",uri="sip:6046946333@OSER_PROXY:15061",algorithm=MD5,response="11a15f9ef4fdb1c9ab05566cad92d67e",qop=auth,nc=00000002,cnonce="750e43e5". Contact: tavis <sip:200110005334@192.168.99.66:5070>. Expires: 240. User-Agent: Sipura/SPA3000-3.1.5(GWb). Content-Length: 287. Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER. Supported: x-sipura. Content-Type: application/sdp. . v=0. o=- 25915303 25915303 IN IP4 192.168.99.66. s=-. c=IN IP4 192.168.99.66. t=0 0. m=audio 16410 RTP/AVP 18 0 4 8 101. a=rtpmap:18 G729a/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:4 G723/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:20. a=sendrecv. # U 2005/10/04 01:44:44.688471 OSER_PROXY:15061 -> SIP_UAC:5070 SIP/2.0 100 trying -- your call is important to us. Via: SIP/2.0/UDP 192.168.99.66:5070;branch=z9hG4bK-249e2787;rport=5070;received=SIP_UAC. From: tavis <sip:200110005334@OSER_PROXY:15061>;tag=6e3e1f53c3f352efo0. To: <sip:6046946333@OSER_PROXY:15061>. Call-ID: ec5b9223-f98ffe5f(a)192.168.99.66. CSeq: 102 INVITE. Content-Length: 0. . # U 2005/10/04 01:44:44.689012 OSER_PROXY:15061 -> NEXTHOP_PROXY:5060 INVITE sip:16046946333@NEXTHOP_PROXY SIP/2.0. Record-Route: <sip:OSER_PROXY:15061;ftag=6e3e1f53c3f352efo0;lr=on>. Via: SIP/2.0/UDP OSER_PROXY:15061;branch=z9hG4bK11ea.6c311116.0. Via: SIP/2.0/UDP 192.168.99.66:5070;rport=5070;received=SIP_UAC;branch=z9hG4bK-249e2787. From: tavis <sip:200110005334@OSER_PROXY:15061>;tag=6e3e1f53c3f352efo0. To: <sip:6046946333@OSER_PROXY:15061>. Call-ID: ec5b9223-f98ffe5f(a)192.168.99.66. CSeq: 102 INVITE. Max-Forwards: 15. Contact: tavis <sip:200110005334@SIP_UAC:5070>. Expires: 240. User-Agent: Sipura/SPA3000-3.1.5(GWb). Content-Length: 288. Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER. Supported: x-sipura. Content-Type: application/sdp. . v=0. o=- 25915303 25915303 IN IP4 192.168.99.66. s=-. c=IN IP4 OSER_PROXY. t=0 0. m=audio 35328 RTP/AVP 18 0 4 8 101. a=rtpmap:18 G729a/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:4 G723/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:20. a=sendrecv. # U 2005/10/04 01:44:45.396833 OSER_PROXY:15061 -> NEXTHOP_PROXY:5060 INVITE sip:16046946333@NEXTHOP_PROXY SIP/2.0. Record-Route: <sip:OSER_PROXY:15061;ftag=6e3e1f53c3f352efo0;lr=on>. Via: SIP/2.0/UDP OSER_PROXY:15061;branch=z9hG4bK11ea.6c311116.0. Via: SIP/2.0/UDP 192.168.99.66:5070;rport=5070;received=SIP_UAC;branch=z9hG4bK-249e2787. From: tavis <sip:200110005334@OSER_PROXY:15061>;tag=6e3e1f53c3f352efo0. To: <sip:6046946333@OSER_PROXY:15061>. Call-ID: ec5b9223-f98ffe5f(a)192.168.99.66. CSeq: 102 INVITE. Max-Forwards: 15. Contact: tavis <sip:200110005334@SIP_UAC:5070>. Expires: 240. User-Agent: Sipura/SPA3000-3.1.5(GWb). Content-Length: 288. Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER. Supported: x-sipura. Content-Type: application/sdp. . v=0. o=- 25915303 25915303 IN IP4 192.168.99.66. s=-. c=IN IP4 OSER_PROXY. t=0 0. m=audio 35328 RTP/AVP 18 0 4 8 101. a=rtpmap:18 G729a/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:4 G723/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:20. a=sendrecv. # U 2005/10/04 01:44:46.090526 NEXTHOP_PROXY:5060 -> OSER_PROXY:15061 SIP/2.0 183 Inband Information. Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, REFER, NOTIFY, REGISTER. Via: SIP/2.0/UDP OSER_PROXY:15061;branch=z9hG4bK11ea.6c311116.0. Via: SIP/2.0/UDP 192.168.99.66:5070;rport=5070;received=SIP_UAC;branch=z9hG4bK-249e2787. Record-Route: <sip:OSER_PROXY:15061;ftag=6e3e1f53c3f352efo0;lr=on>. To: <sip:6046946333@OSER_PROXY:15061>;tag=40032033. From: tavis <sip:200110005334@OSER_PROXY:15061>;tag=6e3e1f53c3f352efo0. Call-ID: ec5b9223-f98ffe5f(a)192.168.99.66. X-SHOUT-Channel: INBOUND 1:15:21:1. CSeq: 102 INVITE. Contact: sip:anonymous@NEXTHOP_PROXY. User-Agent: SHOUT 3.3.1p3v71. Content-Type: application/sdp. Content-Length: 174. . v=0. o=- 0 0 IN IP4 NEXTHOP_PROXY. s=SIP call via SHOUT. c=IN IP4 NEXTHOP_PROXY. t=0 0. m=audio 19004 RTP/AVP 18 101. a=rtpmap:18 G729/8000. a=rtpmap:101 telephone-event/8000. # U 2005/10/04 01:44:46.104387 OSER_PROXY:15061 -> SIP_UAC:5070 SIP/2.0 183 Inband Information. Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, REFER, NOTIFY, REGISTER. Via: SIP/2.0/UDP 192.168.99.66:5070;rport=5070;received=SIP_UAC;branch=z9hG4bK-249e2787. Record-Route: <sip:OSER_PROXY:15061;ftag=6e3e1f53c3f352efo0;lr=on>. To: <sip:6046946333@OSER_PROXY:15061>;tag=40032033. From: tavis <sip:200110005334@OSER_PROXY:15061>;tag=6e3e1f53c3f352efo0. Call-ID: ec5b9223-f98ffe5f(a)192.168.99.66. X-SHOUT-Channel: INBOUND 1:15:21:1. CSeq: 102 INVITE. Contact: sip:anonymous@NEXTHOP_PROXY. User-Agent: SHOUT 3.3.1p3v71. Content-Type: application/sdp. Content-Length: 176. . v=0. o=- 0 0 IN IP4 NEXTHOP_PROXY. s=SIP call via SHOUT. c=IN IP4 OSER_PROXY. t=0 0. m=audio 35328 RTP/AVP 18 101. a=rtpmap:18 G729/8000. a=rtpmap:101 telephone-event/8000. # U 2005/10/04 01:44:46.190376 OSER_PROXY:15061 -> SIP_UAC:5070 SIP/2.0 183 Inband Information. Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, REFER, NOTIFY, REGISTER. Via: SIP/2.0/UDP 192.168.99.66:5070;rport=5070;received=SIP_UAC;branch=z9hG4bK-249e2787. Record-Route: <sip:OSER_PROXY:15061;ftag=6e3e1f53c3f352efo0;lr=on>. To: <sip:6046946333@OSER_PROXY:15061>;tag=40032033. From: tavis <sip:200110005334@OSER_PROXY:15061>;tag=6e3e1f53c3f352efo0. Call-ID: ec5b9223-f98ffe5f(a)192.168.99.66. X-SHOUT-Channel: INBOUND 1:15:21:1. CSeq: 102 INVITE. Contact: sip:anonymous@NEXTHOP_PROXY. User-Agent: SHOUT 3.3.1p3v71. Content-Type: application/sdp. Content-Length: 176. . v=0. o=- 0 0 IN IP4 NEXTHOP_PROXY. s=SIP call via SHOUT. c=IN IP4 OSER_PROXY. t=0 0. m=audio 35328 RTP/AVP 18 101. a=rtpmap:18 G729/8000. a=rtpmap:101 telephone-event/8000. ## U 2005/10/04 01:44:46.702880 OSER_PROXY:15061 -> SIP_UAC:5070 SIP/2.0 183 Inband Information. Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, REFER, NOTIFY, REGISTER. Via: SIP/2.0/UDP 192.168.99.66:5070;rport=5070;received=SIP_UAC;branch=z9hG4bK-249e2787. Record-Route: <sip:OSER_PROXY:15061;ftag=6e3e1f53c3f352efo0;lr=on>. To: <sip:6046946333@OSER_PROXY:15061>;tag=40032033. From: tavis <sip:200110005334@OSER_PROXY:15061>;tag=6e3e1f53c3f352efo0. Call-ID: ec5b9223-f98ffe5f(a)192.168.99.66. X-SHOUT-Channel: INBOUND 1:15:21:1. CSeq: 102 INVITE. Contact: sip:anonymous@NEXTHOP_PROXY. User-Agent: SHOUT 3.3.1p3v71. Content-Type: application/sdp. Content-Length: 176. . v=0. o=- 0 0 IN IP4 NEXTHOP_PROXY. s=SIP call via SHOUT. c=IN IP4 OSER_PROXY. t=0 0. m=audio 35328 RTP/AVP 18 101. a=rtpmap:18 G729/8000. a=rtpmap:101 telephone-event/8000.

3 9

Re: [Users] Insert name into from header of SIP messages
by Brandon Price 01 Nov '05

01 Nov '05

Following that logic should I not be able to just replace the display and leave the uri as is with... uac_replace_from("$avp(s:cnam)",""); I have of coarse already trid that with no success. On Oct 28, 2005, at 3:38 PM, Norman Brandinger wrote: > If you break your callerid into 2 parts, you should be able to use > something like the following: > > AVP display: "John Doe" > AVP uri: "sip:18005551212@example.com" > > uac_replace_from("$avp(s:display)","$avp(s:uri)"); > > The above information has been documented at http://www.openser.org/ > docs/modules/1.0.x/uac.html > > Regards, > Norm > > Brandon Price wrote: > >> We are storing cnam (callerid name) values in a mysql database for >> use with openser. I have openser pulling the values from the >> database using avpops but I need to know how to insert the value >> into the from so that it will be passed to my sip user agents. >> Related code posed below >> >> modparam >> ("avpops","db_scheme","cnam_scheme:username_col=phonenumber;table=cna >> m_cache;value_col=cnam;value_type=string") >> modparam("avpops", "avp_aliases", "cnam=s:cnam") >> >> avp_db_load("$from/cnam_scheme","cnam/$cnam_scheme"); #sample >> query -- select cnam from cnam_cache where phonenumber='13143212222' >> >> this should now store that value in $cnam. >> now how do I put that value for example "John Smith" in the from >> portion of sip messaging so that it displays on the users sip >> phone, or phone attached to an ata? >> >> >> >> _______________________________________________ >> Users mailing list >> Users(a)openser.org >> http://openser.org/cgi-bin/mailman/listinfo/users >> >> >> > >

4 5

[Serusers] Fwd: DIDX.org - DIDXchange
by Rehan Ahmed 01 Nov '05

01 Nov '05

---------- Forwarded message ---------- From: Rehan Ahmed <rehan33(a)gmail.com> Date: Nov 1, 2005 8:02 AM Subject: DIDX.org - DIDXchange To: serusers(a)lists.iptel.org Hello All, I wanted to know if someone here is using did numbers from DIDX.org and able to make them work on SER yet. Rehan

1 0

[Serusers] when I include mysql module in ser.cfg, UA receive "483, too many hops", any advice?
by fishman7788 01 Nov '05

01 Nov '05

I have use ser_mysql create to setup database,and can connect to ser,can add a user using serctl add,but UA just can't receive correct register message,any suggestion? Thanks regargs free

1 0

[Serusers] ser.cfg parse error
by Ma Zhiyong 01 Nov '05

01 Nov '05

Hi All, After I installed the latest CVS version, I found SER could't be started by serctl utility. It shows # serctl start Starting SER : 0(14877) read 3820494812 from /dev/urandom 0(14877) seeding PRNG with 656407867 0(14877) test random number 38195676 # 0(14877) parse error (1,1-2): parse error .......... It seems that my ser.cfg file has wrong format or other problem. Any one has the same matther before? Does that mean my ser.cfg file encounters "parse error" at line 1 and coloum 1 to 2? Thanks.

1 0

Re: [Serusers] Error with acc.so and db funtions
by zhangshuai 01 Nov '05

01 Nov '05

Dear Antonio Membrives, Did you see the makefile of acc module and recompile acc.so? >Hi again i have this lines in ser.cfg > >modparam("acc", "log_flag", 1) >modparam("acc", "log_level", 2) >modparam("acc", "db_flag", 1) >modparam("acc", "db_missed_flag", 3) >modparam("acc", "log_missed_flag", 3) >modparam("acc", "db_url", "mysql://ser:heslo@localhost/ser") >modparam("acc", "report_ack", 0) >modparam("acc", "log_fmt", "miocfsp") > >for store missing calls in serweb, but when I launch the ser services >received 3 errors and see this in /var/log/messages > >Oct 31 13:50:00 dns2 ser: set_mod_param_regex: parameter <db_flag> not found >in module <acc> >Oct 31 13:50:00 dns2 ser: parse error (73,19-20): Can't set module parameter > >Oct 31 13:50:00 dns2 ser: set_mod_param_regex: parameter <db_missed_flag> >not found in module <acc> >Oct 31 13:50:00 dns2 ser: parse error (74,19-20): Can't set module parameter > >Oct 31 13:50:00 dns2 ser: set_mod_param_regex: parameter <db_url> not found >in module <acc> >Oct 31 13:50:00 dns2 ser: parse error (76,20-21): Can't set module parameter > >I have fedora 3+ser 0.9.3 , any idea of this. > >Thanks. > >Antonio Membrives > > >_______________________________________________ >Serusers mailing list >serusers(a)lists.iptel.org >http://lists.iptel.org/mailman/listinfo/serusers > = = = = = = = = = = = = = = = = = = = =

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users November 2005