sr-users

sr-users@lists.kamailio.org

37302 discussions

[Serusers] multiple registration on one user login

by Ng, Soo Sim

Jan Janak writes: > Yes, several UAs can register with the same account and currently there > is no way in ser how to prevent it. Do you really need such a > restriction ? If you do that, users will be unable to register several > phones or user agents and utilize forking, for example. yes, i agree that allowing many uas to register the same uri is very useful. the only problem that i see in ser regarding it is that ser doesn't yet implement sequential forking based on the q value. it would we great if first my sip ua would ring and it that times out, then my mobile phone would ring. -- juha ============ I have such requirements. In providing sip-based residential ip telephony, I would like to restrict each home subsriber is only allowed to register one UA per account. This would make easy for billing purposes and for security reasons. Is there a way to achieve this requirement with SER?

21 years, 9 months

[Serusers] response function in a module

by Mario Kolberg

Hi, I'm writing a module which requires to see request messages and also responses. So I have declared a response_function. The function looks like: static int fi_response(struct sip_msg* msg, char* str1, char* str2); and I put it into the module_exports structure like this: #ifdef STATIC_FI struct module_exports fi_exports = { #else struct module_exports exports= { #endif "fi_module", (char*[]){ "fi_request", "fi_response" }, (cmd_function[]){ fi_request, fi_response }, (int[]){ 0, 0 }, (fixup_function[]){ 0 }, 2, /* Number of exported functions*/ NULL, /* Module parameter names */ NULL, /* Module parameter types */ NULL, /* Module parameter variable pointers */ 0, /* Number of module paramers */ mod_init, fi_response, (destroy_function) 0, 0, 0 }; I'm wondering if I correctly declared the function as I'm getting a warning during compilation about incompatible pointer types (4th last line in structure where the function is declared as response function). I really only need the message as parameter. What should the parameters be? This is for the CVS version of SER. Thanks very much for your help! Regards, Mario -- Mario Kolberg phone: +44 (0)1786 46 7440 Lecturer in Computing Science fax : +44 (0)1786 46 4551 email: mko(a)cs.stir.ac.uk Department of Computing Science and Mathematics University of Stirling Stirling FK9 4LA Scotland, UK -- The University of Stirling is a university established in Scotland by charter at Stirling, FK9 4LA. Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not disclose, copy or deliver this message to anyone and any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer do not consent to Internet email for messages of this kind. Opinions, conclusions and other information in this message that do not relate to the official business of the University of Stirling shall be understood as neither given nor endorsed by it.

21 years, 9 months

[Serusers] SER error message in log

by Mario Kolberg

Hi, I'm using the CVS version of SER and I found a frequent error message in the SER log. I'm not sure what this means. Mar 4 12:06:08 DISCUS /usr/local/sbin/ser[1020]: ERROR: set_kr: kill_reason reset: from=1 to=2 Mar 4 12:06:08 DISCUS /usr/local/sbin/ser[1020]: ERROR: set_kr: kill_reason reset: from=1 to=2 The error usually occurs in pairs, but the values for 'from' and 'to' vary. How can I fix it? Thanks! Mario -- Mario Kolberg phone: +44 (0)1786 46 7440 Lecturer in Computing Science fax : +44 (0)1786 46 4551 email: mko(a)cs.stir.ac.uk Department of Computing Science and Mathematics University of Stirling Stirling FK9 4LA Scotland, UK -- The University of Stirling is a university established in Scotland by charter at Stirling, FK9 4LA. Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not disclose, copy or deliver this message to anyone and any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer do not consent to Internet email for messages of this kind. Opinions, conclusions and other information in this message that do not relate to the official business of the University of Stirling shall be understood as neither given nor endorsed by it.

21 years, 9 months

[Serusers] AW: Snom phone (fwd) more fromn greg fausak

by Christian Stredicke

Greg, ooppss that actually changes the scene. Maybe it was too late for me last night already You are right, the 200 Ok goes to the PRACK and the phone mixes that up. I changed it in the phone code and that will be part of the next release. Thanks, Christian -----Ursprüngliche Nachricht----- Von: Robert Messer [mailto:rmesser@abpintl.com] Gesendet: Dienstag, 4. März 2003 02:25 An: cs(a)snom.de Betreff: FW: Snom phone (fwd) more fromn greg fausak FYI More from greg Robert Messer 972-745-1220 Direct ___________________ ABP International, Inc. snom technology - VoIP Phones www.abptech.com 972-745-1221 Phone 972-745-1226 Fax -----Original Message----- From: Greg Fausak [mailto:greg@august.net] Sent: Monday, March 03, 2003 6:13 PM To: 'Kevin' Cc: 'Robert Messer'; sip(a)august.net; serusers(a)lists.iptel.org Subject: RE: Snom phone (fwd) Kevin, I initially sent the packet: > > > This is that packet that came from the last 200 OK <- PROXY: > > > > > > # > > > U 2003/02/24 07:56:52.503535 216.87.144.203:5060 -> > > 216.87.145.22:5060 > > > SIP/2.0 200 OK. > > > Via: SIP/2.0/UDP 216.87.145.22:5060;branch=z9hG4bK-ng5tokyx448r. > > > From: "snom man" <sip:4695461245@augustvoice.net>;tag=8u6ju8wxuc. > > > To: <sip:2143357976@augustvoice.net;user=phone>;tag=3CBB0360-532. > > > Date: Mon, 24 Feb 2003 13:56:43 GMT. > > > Call-ID: 3c267202b6a8-lgseu8olovlp(a)216.87.145.22. > > > Server: Cisco-SIPGateway/IOS-12.x. > > > CSeq: 2 INVITE. > > > Session-Expires: 7200;refresher=uac. > > > Require: timer. > > > Allow-Events: telephone-event. > > > Contact: <sip:92143357976@216.87.144.196:5060;user=phone>. > > > Record-Route: <sip:2143357976@216.87.144.203;ftag=8u6ju8wxuc;lr>. > > > Content-Type: application/sdp. > > > Content-Length: 209. > > > . > > > v=0. > > > o=CiscoSystemsSIP-GW-UserAgent 7543 5694 IN IP4 216.87.144.196. > > > s=SIP Call. > > > c=IN IP4 216.87.144.196. > > > t=0 0. > > > m=audio 16632 RTP/AVP 0 100. > > > a=rtpmap:0 PCMU/8000. > > > a=rtpmap:100 X-NSE/8000. > > > a=fmtp:100 192-194. > > > This is the 200 OK (response to the INVITE) message as delivered to the phone. I couldn't figure out what you were saying, so I went back to the ethereal trace. After the snom phone receives a 183 status message, it sends a PRACK to the PROXY. This PRACK is OKed, without a Record-route. The next message is an OK responding to the original INVITE, which does indeed have a Record-Route. So, you are saying that the OK to your PRACK needs a record route? I can do that I think, because the OK to the INVITE does indeed have a Record-route. I don't even know what a PRACK is for... ---greg -----Original Message----- From: Kevin [mailto:kmoroz@abpintl.com] Sent: Monday, March 03, 2003 5:19 PM To: Greg Fausak Cc: 'Robert Messer' Subject: FW: Snom phone (fwd) Hi Greg, Sorry it took so long to get back to you. Normally it is faster but as I stated the SIP inter- operability was last week which caused the delay. Looks like the issue is with the SER proxy. If I knew the specification deeper I should have been able to answer it myself. Engineering ccs Jiri on their response to me so he is aware of the issue. Regards, Kevin -----Original Message----- The phone updates the route until it receives a 2xx code. The 200 Ok response does not contain such a route therefore the phone uses the last route it receives in the 200 which is empty. Therefore, the phone MUST send the ACK directly to the gateway. § 12.1.2 of the RFC3261. The dialog is NOT established by the 401-challened request. The proxy can very easily solve the problem by putting itself into the routing path of the 200 Ok.

21 years, 9 months

[Serusers] AW: Snom phone (fwd)

by Christian Stredicke

Robert, the gateway mandates PRACK, that cant be turned off. The OPTIONS can be avoided if the phone is set to use REFER explicitly. CS -----Ursprüngliche Nachricht----- Von: Robert Messer [mailto:rmesser@abpintl.com] Gesendet: Dienstag, 4. März 2003 05:58 An: cs(a)snom.de Betreff: RE: Snom phone (fwd) Kevin, I will try to modify the code accordingly, however, I've been looking at the OPTIONS tag. Perhaps I can tell the snom phone not to use PRACK? I'll look into that. Thanks, ---greg -----Original Message----- From: Kevin [mailto:kmoroz@abpintl.com] Sent: Monday, March 03, 2003 8:09 PM To: 'Greg Fausak' Cc: 'Robert Messer'; sip(a)august.net; serusers(a)lists.iptel.org Subject: RE: Snom phone (fwd) Greg, According to snom engineering you should put the routing information in the first 200 OK we receive. Can you do that and try it? You can test against my proxy if you like to see how it should work. Regards, Kevin -----Original Message----- From: Greg Fausak [mailto:greg@august.net] Sent: Monday, March 03, 2003 7:13 PM To: 'Kevin' Cc: 'Robert Messer'; sip(a)august.net; serusers(a)lists.iptel.org Subject: RE: Snom phone (fwd) Kevin, I initially sent the packet: > > > This is that packet that came from the last 200 OK <- PROXY: > > > > > > # > > > U 2003/02/24 07:56:52.503535 216.87.144.203:5060 -> > > 216.87.145.22:5060 > > > SIP/2.0 200 OK. > > > Via: SIP/2.0/UDP 216.87.145.22:5060;branch=z9hG4bK-ng5tokyx448r. > > > From: "snom man" <sip:4695461245@augustvoice.net>;tag=8u6ju8wxuc. > > > To: <sip:2143357976@augustvoice.net;user=phone>;tag=3CBB0360-532. > > > Date: Mon, 24 Feb 2003 13:56:43 GMT. > > > Call-ID: 3c267202b6a8-lgseu8olovlp(a)216.87.145.22. > > > Server: Cisco-SIPGateway/IOS-12.x. > > > CSeq: 2 INVITE. > > > Session-Expires: 7200;refresher=uac. > > > Require: timer. > > > Allow-Events: telephone-event. > > > Contact: <sip:92143357976@216.87.144.196:5060;user=phone>. > > > Record-Route: <sip:2143357976@216.87.144.203;ftag=8u6ju8wxuc;lr>. > > > Content-Type: application/sdp. > > > Content-Length: 209. > > > . > > > v=0. > > > o=CiscoSystemsSIP-GW-UserAgent 7543 5694 IN IP4 216.87.144.196. > > > s=SIP Call. > > > c=IN IP4 216.87.144.196. > > > t=0 0. > > > m=audio 16632 RTP/AVP 0 100. > > > a=rtpmap:0 PCMU/8000. > > > a=rtpmap:100 X-NSE/8000. > > > a=fmtp:100 192-194. > > > This is the 200 OK (response to the INVITE) message as delivered to the phone. I couldn't figure out what you were saying, so I went back to the ethereal trace. After the snom phone receives a 183 status message, it sends a PRACK to the PROXY. This PRACK is OKed, without a Record-route. The next message is an OK responding to the original INVITE, which does indeed have a Record-Route. So, you are saying that the OK to your PRACK needs a record route? I can do that I think, because the OK to the INVITE does indeed have a Record-route. I don't even know what a PRACK is for... ---greg -----Original Message----- From: Kevin [mailto:kmoroz@abpintl.com] Sent: Monday, March 03, 2003 5:19 PM To: Greg Fausak Cc: 'Robert Messer' Subject: FW: Snom phone (fwd) Hi Greg, Sorry it took so long to get back to you. Normally it is faster but as I stated the SIP inter- operability was last week which caused the delay. Looks like the issue is with the SER proxy. If I knew the specification deeper I should have been able to answer it myself. Engineering ccs Jiri on their response to me so he is aware of the issue. Regards, Kevin -----Original Message----- The phone updates the route until it receives a 2xx code. The 200 Ok response does not contain such a route therefore the phone uses the last route it receives in the 200 which is empty. Therefore, the phone MUST send the ACK directly to the gateway. § 12.1.2 of the RFC3261. The dialog is NOT established by the 401-challened request. The proxy can very easily solve the problem by putting itself into the routing path of the 200 Ok.

21 years, 9 months

[Serusers] RE: Snom phone (fwd)

by Greg Fausak

Kevin, I initially sent the packet: > > > This is that packet that came from the last 200 OK <- PROXY: > > > > > > # > > > U 2003/02/24 07:56:52.503535 216.87.144.203:5060 -> > > 216.87.145.22:5060 > > > SIP/2.0 200 OK. > > > Via: SIP/2.0/UDP 216.87.145.22:5060;branch=z9hG4bK-ng5tokyx448r. > > > From: "snom man" <sip:4695461245@augustvoice.net>;tag=8u6ju8wxuc. > > > To: <sip:2143357976@augustvoice.net;user=phone>;tag=3CBB0360-532. > > > Date: Mon, 24 Feb 2003 13:56:43 GMT. > > > Call-ID: 3c267202b6a8-lgseu8olovlp(a)216.87.145.22. > > > Server: Cisco-SIPGateway/IOS-12.x. > > > CSeq: 2 INVITE. > > > Session-Expires: 7200;refresher=uac. > > > Require: timer. > > > Allow-Events: telephone-event. > > > Contact: <sip:92143357976@216.87.144.196:5060;user=phone>. > > > Record-Route: <sip:2143357976@216.87.144.203;ftag=8u6ju8wxuc;lr>. > > > Content-Type: application/sdp. > > > Content-Length: 209. > > > . > > > v=0. > > > o=CiscoSystemsSIP-GW-UserAgent 7543 5694 IN IP4 216.87.144.196. > > > s=SIP Call. > > > c=IN IP4 216.87.144.196. > > > t=0 0. > > > m=audio 16632 RTP/AVP 0 100. > > > a=rtpmap:0 PCMU/8000. > > > a=rtpmap:100 X-NSE/8000. > > > a=fmtp:100 192-194. > > > This is the 200 OK (response to the INVITE) message as delivered to the phone. I couldn't figure out what you were saying, so I went back to the ethereal trace. After the snom phone receives a 183 status message, it sends a PRACK to the PROXY. This PRACK is OKed, without a Record-route. The next message is an OK responding to the original INVITE, which does indeed have a Record-Route. So, you are saying that the OK to your PRACK needs a record route? I can do that I think, because the OK to the INVITE does indeed have a Record-route. I don't even know what a PRACK is for... ---greg -----Original Message----- From: Kevin [mailto:kmoroz@abpintl.com] Sent: Monday, March 03, 2003 5:19 PM To: Greg Fausak Cc: 'Robert Messer' Subject: FW: Snom phone (fwd) Hi Greg, Sorry it took so long to get back to you. Normally it is faster but as I stated the SIP inter- operability was last week which caused the delay. Looks like the issue is with the SER proxy. If I knew the specification deeper I should have been able to answer it myself. Engineering ccs Jiri on their response to me so he is aware of the issue. Regards, Kevin -----Original Message----- The phone updates the route until it receives a 2xx code. The 200 Ok response does not contain such a route therefore the phone uses the last route it receives in the 200 which is empty. Therefore, the phone MUST send the ACK directly to the gateway. § 12.1.2 of the RFC3261. The dialog is NOT established by the 401-challened request. The proxy can very easily solve the problem by putting itself into the routing path of the 200 Ok.

21 years, 9 months

[Serusers] New known problems with radius_auth module

by Bjoern Zuelch

Hi all, i have found some probs with the radius_auth module in ser. the ane in the function authorize() in file authorize.c : when calling the function check_nonce this function returns always that the two nonce's (given and new generated one are not the same. But if we compare the two nonce's manually both are the same. I replaced the memcmp function with the strcmp funtion,but nothings changes. So there is may a missing \0 at the end of the strings. Next problem is in the function check_response: On Solaris we have no freeradiusd ,so I replaced it through radius_authorize(...). If the function radius_authorize is called, the radiusmessage will be created through calling the function rc_avpair_add(...). All is fine if it will be standard radius-attributes. when the first sip-specific attribute is comming the rc_avpair_add funtions returns -1. I followed this problem and find out that in the radiusclient-lib. in function rc_avpair_assign(avpair.c)/rc_avpair_new(avpair.c) only attributes of the types PW_TYPE_STRING, PW_TYPE_DATE, PW_TYPE_INTEGER, PW_TYPE_IPADDR are reccognised. If a PW_SIP_USER_ID attribute or other specific Sip attributes will be added to the radiusmessage, this function returns with error message "UNKNOWN ATTIBUTE TYPE" and no radius-authentification is done.... .... RADIUS: rc_avpair_new MALLOC erfolgreich RADIUS: rc_avpair_assign type=0 RADIUS rc_avpair_assign result=0 RADIUS: rc_avpair_new unknown attribute 110 RADIUS: VALUEPAIR insert fehgeschlagen.!!! check_cred(): returnvalue of radius_authorize()=-1 .... One possibility is that, I add the PW_SIP_* attributes to the radiusclient and look, if it run. The next Problem may be, that the radius server does not understand the sip specific attributes, if we not use freeradius. Gruß Bjoern

21 years, 9 months

[Serusers] Problems with radius_auth(2)

by Bjoern Zuelch

Hi all, ich added following lines in avpair.c function rc_avpair_assign before "case PW_TYPE_STRING:": case PW_SIP_USER_ID: case PW_SIP_USER_REALM: case PW_SIP_USER_NONCE: case PW_SIP_USER_METHOD: case PW_SIP_USER_DIGEST_URI: case PW_SIP_USER_NONCE_COUNT: case PW_SIP_USER_QOP: case PW_SIP_USER_OPAQUE: case PW_SIP_USER_RESPONSE: case PW_SIP_USER_CNONCE: case PW_TYPE_STRING: this should help to build the radius-message. Bjoern

21 years, 9 months

[Serusers] threading weirdness?

by lgfausak＠august.net

Hi, I've been working on a problem which I thought was a postgres driver problem, but now I'm not so sure. I put a bunch of debug statements in the driver functions. I've grepped the debugs for db_init|db_close|connect_db|disconnect_db and here is what I have: -----------cut------------ Mar 1 23:59:49 rave ser[1803]: db_init(): sql://USER:PASSWORD@humpty.august.net:5432/THEDBNAME Mar 1 23:59:49 rave ser[1803]: connect_db(): here we go Mar 1 23:59:49 rave ser[1803]: connect_db(): we are connected /tmp/debug.1803.out Mar 1 23:59:49 rave ser[1804]: db_close(): disconnect_db() Mar 1 23:59:49 rave ser[1804]: disconnect_db(): entry Mar 1 23:59:49 rave ser[1804]: disconnect_db(): PQfinish() Mar 1 23:59:49 rave ser[1804]: db_close(): free self Mar 1 23:59:49 rave ser[1804]: db_init(): sql://USER:PASSWORD@humpty.august.net:5432/THEDBNAME Mar 1 23:59:49 rave ser[1804]: connect_db(): here we go Mar 1 23:59:49 rave ser[1805]: db_close(): disconnect_db() Mar 1 23:59:49 rave ser[1805]: disconnect_db(): entry Mar 1 23:59:49 rave ser[1805]: disconnect_db(): PQfinish() Mar 1 23:59:49 rave ser[1805]: db_close(): free self Mar 1 23:59:49 rave ser[1805]: db_init(): sql://USER:PASSWORD@humpty.august.net:5432/THEDBNAME Mar 1 23:59:49 rave ser[1805]: connect_db(): here we go Mar 1 23:59:49 rave ser[1806]: db_close(): disconnect_db() Mar 1 23:59:49 rave ser[1806]: disconnect_db(): entry Mar 1 23:59:49 rave ser[1806]: disconnect_db(): PQfinish() Mar 1 23:59:49 rave ser[1806]: db_close(): free self Mar 1 23:59:49 rave ser[1804]: connect_db(): we are connected /tmp/debug.1804.out Mar 1 23:59:49 rave ser[1806]: db_init(): sql://USER:PASSWORD@humpty.august.net:5432/THEDBNAME Mar 1 23:59:49 rave ser[1804]: db_init(): sql://USER:PASSWORD@humpty.august.net:5432/THEDBNAME Mar 1 23:59:49 rave ser[1806]: connect_db(): here we go Mar 1 23:59:49 rave ser[1804]: connect_db(): here we go Mar 1 23:59:49 rave ser[1805]: connect_db(): we are connected /tmp/debug.1805.out Mar 1 23:59:49 rave ser[1805]: db_init(): sql://USER:PASSWORD@humpty.august.net:5432/THEDBNAME Mar 1 23:59:49 rave ser[1805]: connect_db(): here we go Mar 1 23:59:49 rave ser[1804]: connect_db(): we are connected /tmp/debug.1804.out Mar 1 23:59:50 rave ser[1805]: connect_db(): we are connected /tmp/debug.1805.out Mar 1 23:59:50 rave ser[1806]: connect_db(): we are connected /tmp/debug.1806.out Mar 1 23:59:50 rave ser[1806]: db_init(): sql://USER:PASSWORD@humpty.august.net:5432/THEDBNAME Mar 1 23:59:50 rave ser[1806]: connect_db(): here we go Mar 1 23:59:50 rave ser[1806]: connect_db(): we are connected /tmp/debug.1806.out Mar 2 00:00:50 rave ser[1807]: begin_transaction(): BEGIN error server closed the connection unexpectedly ^IThis probably means the server terminated abnormally ^Ibefore or while processing the request. -----------------cut-------------- The current processes that are running are: [root@rave sip_router]# ps -ax | grep ser 30060 ? S 0:00 /bin/sh bin/safe_mysqld --user=mysql 1803 ? S 0:00 ser -f /usr/local/etc/ser/serpost.cfg 1804 ? S 0:00 ser -f /usr/local/etc/ser/serpost.cfg 1805 ? S 0:00 ser -f /usr/local/etc/ser/serpost.cfg 1806 ? S 0:00 ser -f /usr/local/etc/ser/serpost.cfg 1807 ? S 0:00 ser -f /usr/local/etc/ser/serpost.cfg 1808 ? S 0:00 ser -f /usr/local/etc/ser/serpost.cfg -----------------cut------------------ Here is the top of my ser.cfg file: ---------------- debug=2 # debug level (cmd line: -dddddddddd) fork=yes log_stderror=no # (cmd line: -E) check_via=no # (cmd. line: -v) dns=no # (cmd. line: -r) rev_dns=no # (cmd. line: -R) listen=216.87.144.203 port=5060 children=2 fifo="/tmp/ser_fifo" alias="augustvoice.net" loadmodule "/usr/local/lib/ser/modules/sl.so" loadmodule "/usr/local/lib/ser/modules/tm.so" loadmodule "/usr/local/lib/ser/modules/acc.so" loadmodule "/usr/local/lib/ser/modules/rr.so" loadmodule "/usr/local/lib/ser/modules/maxfwd.so" loadmodule "/usr/local/lib/ser/modules/postgres.so" loadmodule "/usr/local/lib/ser/modules/usrloc.so" loadmodule "/usr/local/lib/ser/modules/registrar.so" loadmodule "/usr/local/lib/ser/modules/exec.so" loadmodule "/usr/local/lib/ser/modules/auth.so" loadmodule "/usr/local/lib/ser/modules/textops.so" modparam("usrloc","db_mode",2) modparam("usrloc","db_url", "sql://USER:PASSWORD@humpty.august.net:5432/THEDBNAME") modparam("tm","retr_timer1p1", 2) # increase retry timeout modparam("tm","retr_timer1p2", 3) # increase retry timeout modparam("tm","retr_timer1p3", 6) # increase retry timeout modparam("acc", "log_level", 1) modparam("acc", "acc_flag", 1 ) modparam("acc", "report_ack", 0 ) modparam("auth","db_url", "sql://USER:PASSWORD@humpty.august.net:5432/THEDBNAME") # # this is the main routing block for augustvoice.net # this block can handle any routing request, local or foreign # route { # ... --------------------------- A couple of questions: 1) I state 'children=2', but I see 6 'processes'. I think linux does threads with processes, so am I seeing 2 'processes' with 3 threads per process??? 2) the debug output has the process ID and the action being performed. Either it is way out of order, or the postgres db driver is being asked to do things out of order. 3) Why is there all of the db_init(), db_close() stuff?? All of this stuff happens in the first second on startup. Surely that many opens and closes aren't really needed are they? 4) select statements seem to happen in one thread, and insert/delete statements seem to happen in another thread. What is that about? ---greg Greg Fausak

21 years, 9 months

[Serusers] Some Module Questions

by Stephan Reiff-Marganiec

Hi, Context: I am currently writing a module that allows me to connect to a policy server -- not unlike CPL. It essentially routes the message out to the server and then receives a response. I get the message out ok, and will receive a complete sip message back. The module main function is called in the ser.cfg. Here are my questions: 1) how do I get a message that I have received -- say in char *msg_buf -- to be the message that is used for further routing? The policy server might have changed any header fields or even created a (or several) completely new message(s). 2) can the module send back intermediate messages, such as 1xx info, while it is still continuing its work? This is to provide the user with feedback should things take while ... 3) I also want the module to react to SIP response messages (4xx and so). I assumed providing a response_function would do this, but apparently not (I had a simple one which was just LOGging some text to the system log, but it never did create any entries). So how can I do this? thanks, Stephan -- Dr Stephan Reiff-Marganiec Research Fellow Department of Computing Science; University of Stirling email: srm(a)cs.stir.ac.uk tel: 01786 46 7448 -- The University of Stirling is a university established in Scotland by charter at Stirling, FK9 4LA. Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not disclose, copy or deliver this message to anyone and any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer do not consent to Internet email for messages of this kind. Opinions, conclusions and other information in this message that do not relate to the official business of the University of Stirling shall be understood as neither given nor endorsed by it.

21 years, 9 months

Jump to page:

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