sr-users April 2008

sr-users@lists.kamailio.org

141 participants
187 discussions

[OpenSER-Users] uaCSTA support in openser

by Hugo Koblmueller

high.all! i'm wondering if there is any support of uaCSTA in openser (planned)? i'm just working on the integration of asterisk (*) environment to OCS 2007 environment, having openSER in the middle (mainly for TCP/UDP translation and smoothing out the protocol deficienes on both sides). in this setup the * having the openSER in front is talking to the OCS (and vice versa) via the OCS mediation server, which is moreorless sending standard SIP messages, which enables normal softphone (integration to *) of the office communicator. this configuration is already working... now i'm planning to go for the CTI integration, where there is no OCS mediation server in between OCS and openSER, doing the translation of SIP/CSTA to SIP. i'm thinking about using openSER for this task, that's why i'm looking for a CSTA module or perl programm, which is capable of this functionality. afaik for the CTI communication there isn't the full complexity of CSTA needed, just a subset mainly for call setup and call clearing. anyone having experience on this topic? thx & cheers -hugo Great Ideas for Small Devices Hugo Koblmueller Senior Staff Engineer Software Development COMNEON electronic technology GmbH & Co. OHG Freistaedter Strasse 400 4040 Linz Austria hugo.koblmueller(a)comneon.com tel: fax: mobile: Skype ID: +43 (5) 1777 - 15730 <http://www.plaxo.com/click_to_call?lang=en&src=jj_signature&To=%2B43+%285%2 9+1777+%2D+15730&Email=hugo(a)koblmueller.com> +43 (5) 1777 - 15810 +43 (676) 82051280 <http://www.plaxo.com/click_to_call?lang=en&src=jj_signature&To=%2B43+%28676 %29+82051280&Email=hugo(a)koblmueller.com> drhookson Want to always have my latest info? <https://www.plaxo.com/add_me?u=21475050628&src=client_sig_212_1_banner_join &invite=1&lang=en> Want a signature like <http://www.plaxo.com/signature?src=client_sig_212_1_banner_sig&lang=en> this?

13 years, 9 months

[OpenSER-Users] [OT] How to handle different DID's in incoming calls for a registered client?

by Iñaki Baz Castillo

Hi, maybe this question is a bit off-topic so I'm sorry for that. My question is about SIP providers using OpenSer that associate PSTN numbers to their local clients (SIP accounts): Usually the client must register to OpenSer in order to receive calls. Then it will appear in location table with "Contact=sip:clientX@IP". Suppose clientX has two PSTN numbers associated in a ENUM entry: +34999000111 +34999000222 When anyone in PSTN world calls to +34999000222 the call will arrive to the OpenSer from a gateway in an INVITE like: INVITE sip:+34999000222@gateway SIP/2.0 To: <sip:+34999000222@gateway> The OpenSer will do the lookup in location table and finally send this INVITE to the clientX: INVITE sip:clientX@IP_clientX SIP/2.0 To: <sip:+34999000222@gateway> The info about the called PSTN number is just available in "To" header, so a way to get different behaviour for each associated PSTN number is matching "To" URI. Is common to do it? which other alternatives are there? Thanks for any comment. Regards. -- Iñaki Baz Castillo ibc(a)in.ilimit.es

15 years, 9 months

[Serusers] ser-0.9.6: modules/postgres bugreport & patch

by Alexandre Snarskii

Hi! I'm running ser-0.9.6, on FreeBSD 6.1-stable, database backend is postgresql version 8.1.3. Today I got errors in logfiles, saying: messages.2.bz2:May 29 14:35:03 <XXX> /usr/local/sbin/ser[51448]: ERROR:avpops:dbrow2avp: dbrow contains NULL fields The similar problem reported in: http://lists.iptel.org/pipermail/serusers/2005-May/019681.html with much more detailed description of error, database contents and config samples. Patch is trivial, and looks more like a fix to copy'n'paste error: in mysql/val.c function str2val states: if (!_s) { memset(_v, 0, sizeof(db_val_t)); VAL_TYPE(_v) = _t; VAL_NULL(_v) = 1; return 0; } VAL_NULL(_v) = 0; and the last line mentions that 'well, that's value is not NULL'. In postgresql/db_val.c, line 182, function str2valp, the same statement is the: if (!_s) { DLOG("str2valp", "got a null value"); VAL_TYPE(_v) = _t; VAL_NULL(_v) = 1; return 0; } without explicit notification that this is not-NULL value. More than, nowhere else in this function VAL_NULL(_v) not set to 0. So, if a value _v.val contained anyting but 0 at the function start, resulting value will be threated as NULL despite the fact, that _s is NOT NULL. Patch is obvious, just add VAL_NULL(_v)=0; after cited block (line 188) and everyting will be ok. At least for me it's ok for some hours :)

16 years, 1 month

[OpenSER-Users] Problems with SerMyAdmin Installation

by Mark Koopmann

Hi everybody, does anybody has experience with installing the java tool SerMyAdmin? The Tool is running but every action ends with an runtime exception. Trying to register a new user ends with the following message: Grails Runtime Exception Error Details Message: Caused by: java.lang.NullPointerException Class: RegisterUserController At Line: [98] Code Snippet: (empty) Stack Trace org.codehaus.groovy.runtime.InvokerInvocationException: java.lang.NullPointerException at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:630) at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:436) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:374) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:302) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.jsecurity.web.servlet.WebInterceptorFilter.doFilterInternal(WebInterceptorFilter.java:106) at org.jsecurity.web.servlet.SecurityContextFilter.doFilterInternal(SecurityContextFilter.java:93) at org.jsecurity.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:106) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:595)Caused by: java.lang.NullPointerException at RegisterUser.toString(RegisterUser.groovy) at RegisterUserController$_closure8.doCall(RegisterUserController.groovy:98) at RegisterUserController$_closure8.doCall(RegisterUserController.groovy) ... 29 more Unfortunately, i dont have much experience with installing such java stuff. It would be great if one of you can give me a hint or something. I dont have any idea how to solve this problem. Thanks for any comment! Best regards Mark Koopmann

16 years, 2 months

[OpenSER-Users] presence module dialog handling

by Sigrid Thijs

Hi, we've configured OpenSER 1.3.0 on a FreeBSD server, together with OpenXCAP 0.9.9. When testing presence rules (RFC 5025) with our UA, we noticed the following behavior: - Subscription Handling is set to "block" in the presence rules: When a watcher subscribes for presence, it receives a NOTIFY with the Subscription-State set to "terminated;reason=rejected". This is as expected. When the presentity changes it's presence, the watcher doesn't receive any NOTIFY requests with the presence update (also OK). But, when the presentity changes the subscription handling to "allow" in the presence-rules document, the server sends an in-dialog NOTIFY request on the subscription dialog that was previously terminated. This is not ok. See the attached file presence_rules_01.txt. - Subscription Handling is set to "allow" in the presence rules: When the presentity changes the subscription handling to "block" in the presence-rules document, the server sends a NOTIFY with the Subscription-State set to "terminated;reason=timeout" to the watchers. When the presentity changes his presence, the presence server will still send NOTIFY requests to the watchers. See the attached file presence_rules_02.txt. kind regards, Sigrid 2008/04/14 12:10:11.167,trace,1352,sip,"sending message to 172.17.10.53:5060" 2008/04/14 12:10:11.167,trace,1352,sip,"----------------------------------------------------------------" 2008/04/14 12:10:11.167,trace,1352,sip,"SUBSCRIBE sip:test03@domain.com SIP/2.0" 2008/04/14 12:10:11.167,trace,1352,sip,"Via: SIP/2.0/UDP 172.17.10.18:5061;rport;branch=z9hG4bK1123400681" 2008/04/14 12:10:11.167,trace,1352,sip,"From: <sip:test04@domain.com>;tag=619180932" 2008/04/14 12:10:11.167,trace,1352,sip,"To: <sip:test03@domain.com>" 2008/04/14 12:10:11.167,trace,1352,sip,"Call-ID: 171821901(a)172.17.10.18" 2008/04/14 12:10:11.167,trace,1352,sip,"CSeq: 1 SUBSCRIBE" 2008/04/14 12:10:11.167,trace,1352,sip,"Contact: <sip:test04@172.17.10.18:5061>" 2008/04/14 12:10:11.167,trace,1352,sip,"Max-Forwards: 70" 2008/04/14 12:10:11.167,trace,1352,sip,"User-Agent: Intellivic SDK/4.1.0.401" 2008/04/14 12:10:11.167,trace,1352,sip,"Expires: 3600" 2008/04/14 12:10:11.167,trace,1352,sip,"Event: presence" 2008/04/14 12:10:11.167,trace,1352,sip,"Accept: application/cpim-pidf+xml, application/pidf+xml, application/xpidf+xml" 2008/04/14 12:10:11.167,trace,1352,sip,"Content-Length: 0" 2008/04/14 12:10:11.167,trace,1352,sip,"" 2008/04/14 12:10:11.167,trace,1352,sip,"" 2008/04/14 12:10:11.167,trace,1352,sip,"----------------------------------------------------------------" 2008/04/14 12:10:11.167,trace,2004,sip,"received message from 172.17.10.53:5060" 2008/04/14 12:10:11.167,trace,2004,sip,"----------------------------------------------------------------" 2008/04/14 12:10:11.167,trace,2004,sip,"SIP/2.0 202 OK" 2008/04/14 12:10:11.167,trace,2004,sip,"Via: SIP/2.0/UDP 172.17.10.18:5061;rport;branch=z9hG4bK1123400681" 2008/04/14 12:10:11.167,trace,2004,sip,"From: <sip:test04@domain.com>;tag=619180932" 2008/04/14 12:10:11.167,trace,2004,sip,"To: <sip:test03@domain.com>;tag=10.74166.1208167811.54" 2008/04/14 12:10:11.167,trace,2004,sip,"Call-ID: 171821901(a)172.17.10.18" 2008/04/14 12:10:11.167,trace,2004,sip,"CSeq: 1 SUBSCRIBE" 2008/04/14 12:10:11.167,trace,2004,sip,"Expires: 3600" 2008/04/14 12:10:11.167,trace,2004,sip,"Contact: <sip:172.17.10.53:5060>" 2008/04/14 12:10:11.167,trace,2004,sip,"Server: OpenSER (1.3.0-tls (i386/freebsd))" 2008/04/14 12:10:11.167,trace,2004,sip,"Content-Length: 0" 2008/04/14 12:10:11.167,trace,2004,sip,"" 2008/04/14 12:10:11.167,trace,2004,sip,"" 2008/04/14 12:10:11.167,trace,2004,sip,"----------------------------------------------------------------" 2008/04/14 12:10:11.167,trace,2004,sip,"received message from 172.17.10.53:5060" 2008/04/14 12:10:11.167,trace,2004,sip,"----------------------------------------------------------------" 2008/04/14 12:10:11.167,trace,2004,sip,"NOTIFY sip:test04@172.17.10.18:5061 SIP/2.0" 2008/04/14 12:10:11.167,trace,2004,sip,"Via: SIP/2.0/UDP 172.17.10.53:5060;branch=z9hG4bKf06f.1f19a641.0" 2008/04/14 12:10:11.167,trace,2004,sip,"To: sip:test04@domain.com;tag=619180932" 2008/04/14 12:10:11.167,trace,2004,sip,"From: sip:test03@domain.com;tag=10.74166.1208167811.54" 2008/04/14 12:10:11.167,trace,2004,sip,"CSeq: 1 NOTIFY" 2008/04/14 12:10:11.167,trace,2004,sip,"Call-ID: 171821901(a)172.17.10.18" 2008/04/14 12:10:11.177,trace,2004,sip,"Content-Length: 0" 2008/04/14 12:10:11.177,trace,2004,sip,"User-Agent: OpenSER (1.3.0-tls (i386/freebsd))" 2008/04/14 12:10:11.177,trace,2004,sip,"Max-Forwards: 70" 2008/04/14 12:10:11.177,trace,2004,sip,"Event: presence" 2008/04/14 12:10:11.177,trace,2004,sip,"Contact: <sip:172.17.10.53:5060>" 2008/04/14 12:10:11.177,trace,2004,sip,"Subscription-State: terminated;reason=rejected" 2008/04/14 12:10:11.177,trace,2004,sip,"" 2008/04/14 12:10:11.177,trace,2004,sip,"" 2008/04/14 12:10:11.177,trace,2004,sip,"----------------------------------------------------------------" 2008/04/14 12:10:11.267,trace,1352,sip,"sending message to 172.17.10.53:5060" 2008/04/14 12:10:11.267,trace,1352,sip,"----------------------------------------------------------------" 2008/04/14 12:10:11.267,trace,1352,sip,"SIP/2.0 200 OK" 2008/04/14 12:10:11.267,trace,1352,sip,"Via: SIP/2.0/UDP 172.17.10.53:5060;branch=z9hG4bKf06f.1f19a641.0" 2008/04/14 12:10:11.267,trace,1352,sip,"From: <sip:test03@domain.com>;tag=10.74166.1208167811.54" 2008/04/14 12:10:11.267,trace,1352,sip,"To: <sip:test04@domain.com>;tag=619180932" 2008/04/14 12:10:11.267,trace,1352,sip,"Call-ID: 171821901(a)172.17.10.18" 2008/04/14 12:10:11.267,trace,1352,sip,"CSeq: 1 NOTIFY" 2008/04/14 12:10:11.267,trace,1352,sip,"Content-Length: 0" 2008/04/14 12:10:11.267,trace,1352,sip,"" 2008/04/14 12:10:11.267,trace,1352,sip,"" 2008/04/14 12:10:11.267,trace,1352,sip,"----------------------------------------------------------------" 2008/04/14 12:12:41.413,trace,2004,sip,"received message from 172.17.10.53:5060" 2008/04/14 12:12:41.413,trace,2004,sip,"----------------------------------------------------------------" 2008/04/14 12:12:41.413,trace,2004,sip,"NOTIFY sip:test04@172.17.10.18:5061 SIP/2.0" 2008/04/14 12:12:41.413,trace,2004,sip,"Via: SIP/2.0/UDP 172.17.10.53:5060;branch=z9hG4bKc06f.00085e42.0" 2008/04/14 12:12:41.413,trace,2004,sip,"To: sip:test04@domain.com;tag=619180932" 2008/04/14 12:12:41.413,trace,2004,sip,"From: sip:test03@domain.com;tag=10.74166.1208167811.54" 2008/04/14 12:12:41.413,trace,2004,sip,"CSeq: 2 NOTIFY" 2008/04/14 12:12:41.413,trace,2004,sip,"Call-ID: 171821901(a)172.17.10.18" 2008/04/14 12:12:41.413,trace,2004,sip,"Content-Length: 434" 2008/04/14 12:12:41.413,trace,2004,sip,"User-Agent: OpenSER (1.3.0-tls (i386/freebsd))" 2008/04/14 12:12:41.413,trace,2004,sip,"Max-Forwards: 70" 2008/04/14 12:12:41.413,trace,2004,sip,"Event: presence" 2008/04/14 12:12:41.413,trace,2004,sip,"Contact: <sip:172.17.10.53:5060>" 2008/04/14 12:12:41.413,trace,2004,sip,"Subscription-State: active;expires=3450" 2008/04/14 12:12:41.413,trace,2004,sip,"Content-Type: application/pidf+xml" 2008/04/14 12:12:41.413,trace,2004,sip,"" 2008/04/14 12:12:41.413,trace,2004,sip,"<?xml version="1.0" encoding="UTF-8"?>" 2008/04/14 12:12:41.413,trace,2004,sip,"<presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:ep="urn:ietf:params:xml:ns:pidf:status:rpid-status" xmlns:et="urn:ietf:params:xml:ns:pidf:rpid-tuple" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" entity="sip:test03@domain.com"> " 2008/04/14 12:12:41.413,trace,2004,sip," <tuple id="2754173985">" 2008/04/14 12:12:41.413,trace,2004,sip," <status>" 2008/04/14 12:12:41.413,trace,2004,sip," <basic>open</basic>" 2008/04/14 12:12:41.413,trace,2004,sip," <ep:activity>permanent-absence</ep:activity>" 2008/04/14 12:12:41.413,trace,2004,sip," </status>" 2008/04/14 12:12:41.413,trace,2004,sip," </tuple>" 2008/04/14 12:12:41.413,trace,2004,sip,"</presence>" 2008/04/14 12:12:41.413,trace,2004,sip,"" 2008/04/14 12:12:41.413,trace,2004,sip,"----------------------------------------------------------------" ... 2008/04/14 12:42:55.271,trace,1352,sip,"sending message to 172.17.10.53:5060" 2008/04/14 12:42:55.271,trace,1352,sip,"----------------------------------------------------------------" 2008/04/14 12:42:55.271,trace,1352,sip,"SUBSCRIBE sip:test03@domain.com SIP/2.0" 2008/04/14 12:42:55.271,trace,1352,sip,"Via: SIP/2.0/UDP 172.17.10.18:5061;rport;branch=z9hG4bK3796069995" 2008/04/14 12:42:55.271,trace,1352,sip,"From: <sip:test04@domain.com>;tag=823554229" 2008/04/14 12:42:55.271,trace,1352,sip,"To: <sip:test03@domain.com>" 2008/04/14 12:42:55.271,trace,1352,sip,"Call-ID: 2865051670(a)172.17.10.18" 2008/04/14 12:42:55.271,trace,1352,sip,"CSeq: 1 SUBSCRIBE" 2008/04/14 12:42:55.271,trace,1352,sip,"Contact: <sip:test04@172.17.10.18:5061>" 2008/04/14 12:42:55.271,trace,1352,sip,"Max-Forwards: 70" 2008/04/14 12:42:55.271,trace,1352,sip,"User-Agent: Intellivic SDK/4.1.0.401" 2008/04/14 12:42:55.271,trace,1352,sip,"Expires: 3600" 2008/04/14 12:42:55.271,trace,1352,sip,"Event: presence" 2008/04/14 12:42:55.271,trace,1352,sip,"Accept: application/cpim-pidf+xml, application/pidf+xml, application/xpidf+xml" 2008/04/14 12:42:55.271,trace,1352,sip,"Content-Length: 0" 2008/04/14 12:42:55.271,trace,1352,sip,"" 2008/04/14 12:42:55.271,trace,1352,sip,"" 2008/04/14 12:42:55.271,trace,1352,sip,"----------------------------------------------------------------" 2008/04/14 12:42:55.301,trace,2004,sip,"received message from 172.17.10.53:5060" 2008/04/14 12:42:55.301,trace,2004,sip,"----------------------------------------------------------------" 2008/04/14 12:42:55.301,trace,2004,sip,"SIP/2.0 202 OK" 2008/04/14 12:42:55.301,trace,2004,sip,"Via: SIP/2.0/UDP 172.17.10.18:5061;rport;branch=z9hG4bK3796069995" 2008/04/14 12:42:55.301,trace,2004,sip,"From: <sip:test04@domain.com>;tag=823554229" 2008/04/14 12:42:55.301,trace,2004,sip,"To: <sip:test03@domain.com>;tag=10.74166.1208169775.67" 2008/04/14 12:42:55.301,trace,2004,sip,"Call-ID: 2865051670(a)172.17.10.18" 2008/04/14 12:42:55.301,trace,2004,sip,"CSeq: 1 SUBSCRIBE" 2008/04/14 12:42:55.301,trace,2004,sip,"Expires: 3600" 2008/04/14 12:42:55.301,trace,2004,sip,"Contact: <sip:172.17.10.53:5060>" 2008/04/14 12:42:55.301,trace,2004,sip,"Server: OpenSER (1.3.0-tls (i386/freebsd))" 2008/04/14 12:42:55.301,trace,2004,sip,"Content-Length: 0" 2008/04/14 12:42:55.301,trace,2004,sip,"" 2008/04/14 12:42:55.301,trace,2004,sip,"" 2008/04/14 12:42:55.301,trace,2004,sip,"----------------------------------------------------------------" 2008/04/14 12:42:55.301,trace,2004,sip,"received message from 172.17.10.53:5060" 2008/04/14 12:42:55.301,trace,2004,sip,"----------------------------------------------------------------" 2008/04/14 12:42:55.301,trace,2004,sip,"NOTIFY sip:test04@172.17.10.18:5061 SIP/2.0" 2008/04/14 12:42:55.301,trace,2004,sip,"Via: SIP/2.0/UDP 172.17.10.53:5060;branch=z9hG4bK5f77.0e99e1a5.0" 2008/04/14 12:42:55.301,trace,2004,sip,"To: sip:test04@domain.com;tag=823554229" 2008/04/14 12:42:55.301,trace,2004,sip,"From: sip:test03@domain.com;tag=10.74166.1208169775.67" 2008/04/14 12:42:55.301,trace,2004,sip,"CSeq: 1 NOTIFY" 2008/04/14 12:42:55.301,trace,2004,sip,"Call-ID: 2865051670(a)172.17.10.18" 2008/04/14 12:42:55.301,trace,2004,sip,"Content-Length: 383" 2008/04/14 12:42:55.301,trace,2004,sip,"User-Agent: OpenSER (1.3.0-tls (i386/freebsd))" 2008/04/14 12:42:55.301,trace,2004,sip,"Max-Forwards: 70" 2008/04/14 12:42:55.301,trace,2004,sip,"Event: presence" 2008/04/14 12:42:55.301,trace,2004,sip,"Contact: <sip:172.17.10.53:5060>" 2008/04/14 12:42:55.301,trace,2004,sip,"Subscription-State: active;expires=3600" 2008/04/14 12:42:55.301,trace,2004,sip,"Content-Type: application/pidf+xml" 2008/04/14 12:42:55.301,trace,2004,sip,"" 2008/04/14 12:42:55.301,trace,2004,sip,"<?xml version="1.0" encoding="UTF-8"?>" 2008/04/14 12:42:55.301,trace,2004,sip,"<presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:ep="urn:ietf:params:xml:ns:pidf:status:rpid-status" xmlns:et="urn:ietf:params:xml:ns:pidf:rpid-tuple" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" entity="sip:test03@domain.com"> " 2008/04/14 12:42:55.301,trace,2004,sip," <tuple id="2754173985">" 2008/04/14 12:42:55.301,trace,2004,sip," <status>" 2008/04/14 12:42:55.301,trace,2004,sip," <basic>open</basic>" 2008/04/14 12:42:55.301,trace,2004,sip," </status>" 2008/04/14 12:42:55.301,trace,2004,sip," </tuple>" 2008/04/14 12:42:55.301,trace,2004,sip,"</presence>" 2008/04/14 12:42:55.301,trace,2004,sip,"" 2008/04/14 12:42:55.301,trace,2004,sip,"----------------------------------------------------------------" 2008/04/14 12:42:55.441,trace,1352,sip,"sending message to 172.17.10.53:5060" 2008/04/14 12:42:55.441,trace,1352,sip,"----------------------------------------------------------------" 2008/04/14 12:42:55.441,trace,1352,sip,"SIP/2.0 200 OK" 2008/04/14 12:42:55.441,trace,1352,sip,"Via: SIP/2.0/UDP 172.17.10.53:5060;branch=z9hG4bK5f77.0e99e1a5.0" 2008/04/14 12:42:55.441,trace,1352,sip,"From: <sip:test03@domain.com>;tag=10.74166.1208169775.67" 2008/04/14 12:42:55.441,trace,1352,sip,"To: <sip:test04@domain.com>;tag=823554229" 2008/04/14 12:42:55.441,trace,1352,sip,"Call-ID: 2865051670(a)172.17.10.18" 2008/04/14 12:42:55.441,trace,1352,sip,"CSeq: 1 NOTIFY" 2008/04/14 12:42:55.441,trace,1352,sip,"Content-Length: 0" 2008/04/14 12:42:55.441,trace,1352,sip,"" 2008/04/14 12:42:55.441,trace,1352,sip,"" 2008/04/14 12:42:55.441,trace,1352,sip,"----------------------------------------------------------------" 2008/04/14 12:43:12.285,trace,2004,sip,"received message from 172.17.10.53:5060" 2008/04/14 12:43:12.285,trace,2004,sip,"----------------------------------------------------------------" 2008/04/14 12:43:12.285,trace,2004,sip,"NOTIFY sip:test04@172.17.10.18:5061 SIP/2.0" 2008/04/14 12:43:12.285,trace,2004,sip,"Via: SIP/2.0/UDP 172.17.10.53:5060;branch=z9hG4bK2f77.31f65dd6.0" 2008/04/14 12:43:12.285,trace,2004,sip,"To: sip:test04@domain.com;tag=823554229" 2008/04/14 12:43:12.285,trace,2004,sip,"From: sip:test03@domain.com;tag=10.74166.1208169775.67" 2008/04/14 12:43:12.285,trace,2004,sip,"CSeq: 2 NOTIFY" 2008/04/14 12:43:12.285,trace,2004,sip,"Call-ID: 2865051670(a)172.17.10.18" 2008/04/14 12:43:12.285,trace,2004,sip,"Content-Length: 421" 2008/04/14 12:43:12.285,trace,2004,sip,"User-Agent: OpenSER (1.3.0-tls (i386/freebsd))" 2008/04/14 12:43:12.285,trace,2004,sip,"Max-Forwards: 70" 2008/04/14 12:43:12.285,trace,2004,sip,"Event: presence" 2008/04/14 12:43:12.285,trace,2004,sip,"Contact: <sip:172.17.10.53:5060>" 2008/04/14 12:43:12.285,trace,2004,sip,"Subscription-State: active;expires=3583" 2008/04/14 12:43:12.285,trace,2004,sip,"Content-Type: application/pidf+xml" 2008/04/14 12:43:12.285,trace,2004,sip,"" 2008/04/14 12:43:12.285,trace,2004,sip,"<?xml version="1.0" encoding="UTF-8"?>" 2008/04/14 12:43:12.285,trace,2004,sip,"<presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:ep="urn:ietf:params:xml:ns:pidf:status:rpid-status" xmlns:et="urn:ietf:params:xml:ns:pidf:rpid-tuple" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" entity="sip:test03@domain.com"> " 2008/04/14 12:43:12.285,trace,2004,sip," <tuple id="2754173985">" 2008/04/14 12:43:12.285,trace,2004,sip," <status>" 2008/04/14 12:43:12.285,trace,2004,sip," <basic>open</basic>" 2008/04/14 12:43:12.285,trace,2004,sip," <ep:activity>meal</ep:activity>" 2008/04/14 12:43:12.285,trace,2004,sip," </status>" 2008/04/14 12:43:12.285,trace,2004,sip," </tuple>" 2008/04/14 12:43:12.285,trace,2004,sip,"</presence>" 2008/04/14 12:43:12.285,trace,2004,sip,"" 2008/04/14 12:43:12.285,trace,2004,sip,"----------------------------------------------------------------" 2008/04/14 12:43:12.315,trace,1352,sip,"sending message to 172.17.10.53:5060" 2008/04/14 12:43:12.315,trace,1352,sip,"----------------------------------------------------------------" 2008/04/14 12:43:12.305,trace,1352,sip,"SIP/2.0 200 OK" 2008/04/14 12:43:12.305,trace,1352,sip,"Via: SIP/2.0/UDP 172.17.10.53:5060;branch=z9hG4bK0a3.8cb82654.0" 2008/04/14 12:43:12.305,trace,1352,sip,"From: <sip:test03@domain.com>;tag=10.74167.1208169449.68" 2008/04/14 12:43:12.305,trace,1352,sip,"To: <sip:test04@domain.com>;tag=2701925734" 2008/04/14 12:43:12.305,trace,1352,sip,"Call-ID: 891393650(a)172.17.10.18" 2008/04/14 12:43:12.305,trace,1352,sip,"CSeq: 4 NOTIFY" 2008/04/14 12:43:12.305,trace,1352,sip,"Content-Length: 0" 2008/04/14 12:43:12.315,trace,1352,sip,"" 2008/04/14 12:43:12.315,trace,1352,sip,"" 2008/04/14 12:43:12.315,trace,1352,sip,"----------------------------------------------------------------" 2008/04/14 12:44:10.840,trace,2004,sip,"received message from 172.17.10.53:5060" 2008/04/14 12:44:10.840,trace,2004,sip,"----------------------------------------------------------------" 2008/04/14 12:44:10.840,trace,2004,sip,"NOTIFY sip:test04@172.17.10.18:5061 SIP/2.0" 2008/04/14 12:44:10.840,trace,2004,sip,"Via: SIP/2.0/UDP 172.17.10.53:5060;branch=z9hG4bK3f77.ab08f675.0" 2008/04/14 12:44:10.840,trace,2004,sip,"To: sip:test04@domain.com;tag=823554229" 2008/04/14 12:44:10.840,trace,2004,sip,"From: sip:test03@domain.com;tag=10.74166.1208169775.67" 2008/04/14 12:44:10.840,trace,2004,sip,"CSeq: 3 NOTIFY" 2008/04/14 12:44:10.840,trace,2004,sip,"Call-ID: 2865051670(a)172.17.10.18" 2008/04/14 12:44:10.840,trace,2004,sip,"Content-Length: 0" 2008/04/14 12:44:10.840,trace,2004,sip,"User-Agent: OpenSER (1.3.0-tls (i386/freebsd))" 2008/04/14 12:44:10.840,trace,2004,sip,"Max-Forwards: 70" 2008/04/14 12:44:10.840,trace,2004,sip,"Event: presence" 2008/04/14 12:44:10.840,trace,2004,sip,"Contact: <sip:172.17.10.53:5060>" 2008/04/14 12:44:10.840,trace,2004,sip,"Subscription-State: terminated;reason=timeout" 2008/04/14 12:44:10.840,trace,2004,sip,"" 2008/04/14 12:44:10.840,trace,2004,sip,"" 2008/04/14 12:44:10.840,trace,2004,sip,"----------------------------------------------------------------" 2008/04/14 12:44:10.900,trace,1352,sip,"sending message to 172.17.10.53:5060" 2008/04/14 12:44:10.900,trace,1352,sip,"----------------------------------------------------------------" 2008/04/14 12:44:10.900,trace,1352,sip,"SIP/2.0 200 OK" 2008/04/14 12:44:10.900,trace,1352,sip,"Via: SIP/2.0/UDP 172.17.10.53:5060;branch=z9hG4bK3f77.ab08f675.0" 2008/04/14 12:44:10.900,trace,1352,sip,"From: <sip:test03@domain.com>;tag=10.74166.1208169775.67" 2008/04/14 12:44:10.900,trace,1352,sip,"To: <sip:test04@domain.com>;tag=823554229" 2008/04/14 12:44:10.900,trace,1352,sip,"Call-ID: 2865051670(a)172.17.10.18" 2008/04/14 12:44:10.900,trace,1352,sip,"CSeq: 3 NOTIFY" 2008/04/14 12:44:10.900,trace,1352,sip,"Content-Length: 0" 2008/04/14 12:44:10.900,trace,1352,sip,"" 2008/04/14 12:44:10.900,trace,1352,sip,"" 2008/04/14 12:44:10.900,trace,1352,sip,"----------------------------------------------------------------" 2008/04/14 12:45:06.470,trace,2004,sip,"received message from 172.17.10.53:5060" 2008/04/14 12:45:06.470,trace,2004,sip,"----------------------------------------------------------------" 2008/04/14 12:45:06.470,trace,2004,sip,"NOTIFY sip:test04@172.17.10.18:5061 SIP/2.0" 2008/04/14 12:45:06.470,trace,2004,sip,"Via: SIP/2.0/UDP 172.17.10.53:5060;branch=z9hG4bK2f77.41f65dd6.0" 2008/04/14 12:45:06.470,trace,2004,sip,"To: sip:test04@domain.com;tag=823554229" 2008/04/14 12:45:06.470,trace,2004,sip,"From: sip:test03@domain.com;tag=10.74166.1208169775.67" 2008/04/14 12:45:06.470,trace,2004,sip,"CSeq: 2 NOTIFY" 2008/04/14 12:45:06.470,trace,2004,sip,"Call-ID: 2865051670(a)172.17.10.18" 2008/04/14 12:45:06.470,trace,2004,sip,"Content-Length: 383" 2008/04/14 12:45:06.470,trace,2004,sip,"User-Agent: OpenSER (1.3.0-tls (i386/freebsd))" 2008/04/14 12:45:06.470,trace,2004,sip,"Max-Forwards: 70" 2008/04/14 12:45:06.470,trace,2004,sip,"Event: presence" 2008/04/14 12:45:06.470,trace,2004,sip,"Contact: <sip:172.17.10.53:5060>" 2008/04/14 12:45:06.470,trace,2004,sip,"Subscription-State: active;expires=3469" 2008/04/14 12:45:06.470,trace,2004,sip,"Content-Type: application/pidf+xml" 2008/04/14 12:45:06.470,trace,2004,sip,"" 2008/04/14 12:45:06.470,trace,2004,sip,"<?xml version="1.0" encoding="UTF-8"?>" 2008/04/14 12:45:06.470,trace,2004,sip,"<presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:ep="urn:ietf:params:xml:ns:pidf:status:rpid-status" xmlns:et="urn:ietf:params:xml:ns:pidf:rpid-tuple" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" entity="sip:test03@domain.com"> " 2008/04/14 12:45:06.470,trace,2004,sip," <tuple id="2754173985">" 2008/04/14 12:45:06.470,trace,2004,sip," <status>" 2008/04/14 12:45:06.470,trace,2004,sip," <basic>open</basic>" 2008/04/14 12:45:06.470,trace,2004,sip," </status>" 2008/04/14 12:45:06.470,trace,2004,sip," </tuple>" 2008/04/14 12:45:06.470,trace,2004,sip,"</presence>" 2008/04/14 12:45:06.470,trace,2004,sip,"" 2008/04/14 12:45:06.470,trace,2004,sip,"----------------------------------------------------------------" ...

16 years, 4 months

[OpenSER-Users] Acceptor peer failed establishing state[3003], closing

by bhargav.b＠renovau.com

actually i am authenticating a user using openser and opendiameters NASREQ application as the client and server.at present the openser is sending the all needed avp's to opendiameter client.i can see all the avp code and avp data on the client side. my problem is that the on the diameter server side the avp,s are not transferred by the client. the client is giving something like (6372|1698151312) Acceptor peer failed establishing state [3003], closing i am confused about it.by reading some drafts i came to know that the error is due to realm mismatch.but i am sending the same realm as the opendiameter's realm.in both the cases it is [bhargav.s]. before i sent the avp's from openser side there was no such problem showing on the client side.if anybody know the solution please help me regards bhargav.b(a)renovau.com

16 years, 6 months

[OpenSER-Users] UDP Buffer Size / OpenSER / Linux

by Carsten Bock

Hi, short question: Can anybody give me a hint regarding the Linux UDP-Buffer size? Are there any known good values for this or is the default value (128k) of Linux sufficient? I've read, regarding other SIP-Systems (namely IBM SIP Servlets and Communigate pro), the recommendation to increase the UDP-Buffer-size to 3 or even 4 MByte.... Are there any recommended / known best values for heavy load OpenSER Installations? Thanks in advance, Carsten Reference: http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.…

16 years, 6 months

[OpenSER-Users] recover from previous strict routing triggered incorrectly in ALG scenario

by Andrew Pogrebennyk

Hi, Im'm cross-posting this from OpenSER-Devel because I am not 100% sure this is a bug. I am trying to create openser configuration for proxy that connects private (VPN) network with public network. I started with a config similar to http://voipembedded.com/resources/openser_cr.cfg, added a call to force_send_socket() to send from public IP and rtpproxy/nathelper in bridge mode. As per config loose_route() is called from openser.cfg to route a sequential request within a dialog through record-routing. Now when a BYE from callee comes in, it contains two Route headers: Route: <a.b.c.d;r2=on;lr;ftag=...> where a.b.c.d is server's public IP, Route: <10.0.0.100;r2=on;lr;ftag=...> where 10.0.0.100 is a private IP and username(a)a.b.c.d in Request-URI. Take a look at loose_route(): /* * Do loose routing as defined in RFC3261 */ int loose_route(struct sip_msg* _m, char* _s1, char* _s2) { int ret; if (find_first_route(_m) != 0) { LM_DBG("There is no Route HF\n"); return -1; } if (parse_sip_msg_uri(_m)<0) { LM_ERR("failed to parse Request URI\n"); return -1; } ret = is_preloaded(_m); if (ret < 0) { return -1; } else if (ret == 1) { return after_loose(_m, 1); } else { #ifdef ENABLE_USER_CHECK if (is_myself(&_m->parsed_uri.user, &_m->parsed_uri.host, _m->parsed_uri.port_no)) { #else if (is_myself(&_m->parsed_uri.host, _m->parsed_uri.port_no)) { #endif return after_strict(_m); } else { return after_loose(_m, 0); } } } Obviously, is_myself() check passes and after_strict() is called. when after_strict() is called, it looks if the URI given in Route contains lr parameter which marks loose routers, if so this block of code is executed: { LM_DBG("Next hop: '%.*s' is loose router\n", uri.len, ZSW(uri.s)); if(get_maddr_uri(&uri, &puri)!=0) { LM_ERR("failed to check maddr\n"); return RR_ERROR; } if (set_dst_uri(_m, &uri) < 0) { LM_ERR("failed to set dst_uri\n"); return RR_ERROR; } /* Next hop is a loose router - Which means that is is not endpoint yet * In This case we have to recover from previous strict routing, that * means we have to find the last Route URI and put in in R-URI and * remove the last Route URI. */ if (rt != hdr->parsed) { /* There is a previous route uri which was 2nd uri of mine * and must be removed here */ rem_off = hdr->body.s; rem_len = rt->nameaddr.name.s - hdr->body.s; if (!del_lump(_m, rem_off - _m->buf, rem_len, 0)) { LM_ERR("failed to remove Route HF\n"); return RR_ERROR; } } res = find_rem_target(_m, &hdr, &rt, &prev); if (res < 0) { LM_ERR("searching for last Route URI failed\n"); return RR_ERROR; } else if (res > 0) { /* No remote target is an error */ return RR_ERROR; } uri = rt->nameaddr.uri; if(get_maddr_uri(&uri, 0)!=0) { LM_ERR("checking maddr failed\n"); return RR_ERROR; } if (rewrite_uri(_m, &uri) < 0) { LM_ERR("failed to rewrite R-URI\n"); return RR_ERROR; } /* The first character if uri will be either '<' when it is the * only URI in a Route header field or ',' if there is more than * one URI in the header field */ LM_DBG("The last route URI: '%.*s'\n", rt->nameaddr.uri.len, ZSW(rt->nameaddr.uri.s)); if (prev) { rem_off = prev->nameaddr.name.s + prev->len; rem_len = rt->nameaddr.name.s + rt->len - rem_off; } else { rem_off = hdr->name.s; rem_len = hdr->len; } if (!del_lump(_m, rem_off - _m->buf, rem_len, 0)) { LM_ERR("failed to remove Route HF\n"); return RR_ERROR; } } Therefore recover from previous strict routing is triggered: contents of request line is destroyed and 10.0.0.100 is put instead: Apr 15 16:16:24 vpn-proxy oser[11027]: DBG:core:rewrite_uri: rewriting Request-URI with 'sip:10.0.0.100;r2=on;lr;ftag=aa40c2a5-54fb-1810-970d-0015c5bf2da5' Apr 15 16:16:24 vpn-proxy oser[11032]: [1] Got in dialog request not catched by loose_route(): BYE sip:10.0.0.100;r2=on;lr;ftag=aa40c2a5-54fb-1810-970d-0015c5bf2da5 SIP/2.0^M Via:... And we respond with 404 to in-dialog requests not caught by loose_route(). Previous hop is SER and I don't know why OpenSER considered it a strict router. Looks like a peculiarity of ALG mode. Please advice what should I do to solve this problem. Is it a configuration issue or perhaps loose_route() should not call after_strict() in case of double record-routing? -- Thank you, Andrew Pogrebennyk

16 years, 6 months

[OpenSER-Users] Increase MAX_BRANCHES value?

by Zappasodi Daniele

Hello, I'm interested in this question too. I have tried to modify the tm module and I have found a solution that extends the maximum number of branches and it seems to work, but I'm still testing it. Can anyone, more expert than me on the tm module, give a look to the attached file with my patch? Bye Daniele Hi, thanks for your answer... I increased the SHM_MEM_SIZE to 64 and left KG_MEM_POOL_SIZE 4*1024*1024 . Anyway i found that is not possible to raise MAX_BRANCHES to values higher than 30 due to tm module internal limitation. Bye, Marcello ********************************************************************** The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, or distribution of the message, or any action or omission taken by you in reliance on it, is prohibited and may be unlawful. Please immediately contact the sender if you have received this message inerror. **********************************************************************

16 years, 6 months

[OpenSER-Users] 200 OK retransmissions on missing ACK can cause subsequent calls to fail

by Sean O'Donnell

Hi all, Im using openser as a call distributor/proxy between a soft-switch/SBC and voicemail platform. Im seeing a problem with openser in that it is sometimes cancels an in-progress call (fr_inv_timer firing) because it didnt match the 200/OK with the call. After some investigation, I noticed that this was happening after a missing ACK on a previous call caused the voicemail platform to retransmit 200/OK responses beyond the TM wt_timer expiration, which in turn left several openser child processes (those that received a 200 after wt_timer expiration) in a state such that they might not properly match transactions on subsequent calls. My setup: I have openser 1.2.0 operating on a linux box with two network interfaces, with one interface (call it the outside interface) taking incoming calls from the soft-switch, and the other (inside) connected to the VM platform. I have openser configured to use both interfaces (see config below) and the TM wt_timer set to 5 seconds (default). As this is a voicemail system, all of the call traffic is inbound from the soft-switch. Given the traffic flow, for the most part the openser child processes servicing the inside interface are handling responses (180,183,200) from the VM platform. Call scenario: When an INVITE arrives from the soft-switch, openser forwards it to the VM platform. The VM platform responds with a 180 and then a 200. I've noticed several instances where the soft-switch did not respond with an ACK. This caused the VM platform to retransmit the 200 several times over a 10 second period. These were absorbed correctly by openser for the duration of wt_timer. After the timer expired, however, each openser child process that received a retransmitted 200 logged something like this: 4(2715) DEBUG: t_reply_matching: hash 45870 label 727647196 branch 0 4(2715) DEBUG: t_reply_matching: no matching transaction exists 4(2715) DEBUG: t_reply_matching: failure to match a transaction 4(2715) DEBUG: t_check: end=(nil) When I look at the TM code, the static variable T in t_lookup.c is now NULL for this child process. On a subsequent inbound call, the INVITE is passed to the VM correctly, and the 180 transaction matches (causing the fr_inv_timer to be armed). If the 200 is read by child proc 2715, I see: 4(2715) DEBUG: t_check: start=(nil) 4(2715) DEBUG: t_check: T previously sought and not found The 200 is forwarded back to the soft-switch, which responds with an ACK. Both end-points think the call is up, but since openser never matched the 200 with the call, the fr_inv_timer fires and cancels the call. Basically, child proc 2715 wont match any transaction after this unless it happens to process a request. I think this problem is made worse by the fact that Im using two network interfaces, and that the openser children on the inside interface handle (for the most part) only responses. This problem was touched on here: http://lists.openser.org/pipermail/users/2007-November/014188.html but I didnt see any follow up. Also, Ive checked openser 1.2.3 and 1.3.1 for fixes, but I dont think this has been addressed. I have a work around, I think, by upping the wt_timer to something like 15 seconds, but I was wondering if there is any scenario in which leaving T=NULL is desirable. Thanks in advance Sean ==== CONFIG ===== # # VMPROXY-PROXY - route between softswitch and media servers # # ----------- global configuration parameters ------------------------ check_via=yes # (cmd. line: -v) dns=no # (cmd. line: -r) rev_dns=no # (cmd. line: -R) children=8 # multi-homed (i.e. listen on two or more interfaces) mhomed=1 alias=sipproxy1 alias=sipproxy1.vmproxy.com port=5060 #inside address listen=192.168.1.100 #outside address listen=10.55.2.100 disable_dns_blacklist=yes # ------------------ module loading ---------------------------------- # Uncomment this if you want to use SQL database #loadmodule "/usr/local/openser/lib/openser/modules/mysql.so" mpath="/usr/local/openser/lib/openser/modules" loadmodule "sl.so" loadmodule "tm.so" loadmodule "rr.so" loadmodule "maxfwd.so" loadmodule "usrloc.so" loadmodule "registrar.so" loadmodule "exec.so" loadmodule "xlog.so" loadmodule "textops.so" loadmodule "options.so" loadmodule "mi_fifo.so" # Uncomment this if you want digest authentication # mysql.so must be loaded ! #loadmodule "/usr/local/openser/lib/openser/modules/auth.so" #loadmodule "/usr/local/openser/lib/openser/modules/auth_db.so" # ----------------- setting module-specific parameters --------------- # -- usrloc params -- # local memory #modparam("usrloc", "db_mode", 0) # -- rr params -- # add value to ;lr param to make some broken UAs happy modparam("rr", "enable_full_lr", 1) # uncomment this for multiple record routes #modparam("rr", "enable_double_rr", 1) # -- tm params -- modparam("tm", "fr_timer", 5) modparam("tm", "fr_inv_timer", 60) # -- mi_fifo parms modparam("mi_fifo", "fifo_name", "/tmp/openser_fifo_proxy") # ------------------------- request routing logic ------------------- # main routing logic route{ # initial sanity checks -- messages with # max_forwards==0, or excessively long requests if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); return; }; if ( msg:len > max_len ) { sl_send_reply("513", "Message too big"); return; }; xlog("L_INFO","$Tf VMPROXY: <$rm> message From:<$fu> To:<$tu> srcip:<$si>\n"); # # we record-route all messages -- to make sure that # subsequent messages will go through our proxy; that's # particularly good if upstream and downstream entities # use different transport protocol # record_route(); # # loose-route processing # messages that already have routes on them are proxied here # if (loose_route()) { t_relay(); return; }; # # message not for us, route it through # if ( !(uri==myself) ) { if (!t_relay()) { sl_reply_error(); }; return; }; xlog("L_DBG","$Tf VMPROXY: <$rm> for me\n"); # handle options meant for me if( method == "OPTIONS" ) { options_reply(); return; }; if( method == "REGISTER" || method == "PUBLISH" || method == "SUBSCRIBE" || method == "MESSAGE" ) { sl_send_reply("405","Method Not Allowed"); return; }; # route INVITE based on source if( method == "INVITE" ) { exec_dset("/usr/local/vmproxy/bin/routeINVITE.sh"); xlog("L_DBG","$Tf VMPROXY: <$rm> after routeINVITE: new destination <$ru>\n"); t_on_failure("1"); }; # route NOTIFY to softswitch if( method == "NOTIFY" ) { exec_dset("/usr/local/vmproxy/bin/routeNOTIFY.sh"); xlog("L_DBG","$Tf VMPROXY: <$rm> after routeNOTIFY: new destination <$ru>\n"); t_on_failure("2"); }; # # NOTE: this logic is only executed if the request didn't have # a route on it (tsk,tsk). If it did, it would have been handed via # loose route function above. if( method == "ACK" || method == "BYE" || method == "CANCEL" || method == "PRACK" ) { exec_dset("/usr/local/vmproxy/bin/routeACK.sh"); xlog("L_DBG","$Tf VMPROXY: <$rm> after routeACK: new destination <$ru>\n"); }; # routing script error? if( uri=="sip:err@127.0.0.1" ) { sl_reply_error(); return; }; # forward to current uri if (!t_relay()) { sl_reply_error(); }; } # # Initial INVITE route failed, retry # failure_route[1] { # endpoint canceled call if( t_was_cancelled()) { xlog("L_DBG", "$Tf VMPROXY: call <id:$ci> cancelled\n"); return; } # don't retry on 40[0-7|5xx failures if( !t_check_status("40[0-7]|420|487|488|5[0-9][0-9]")) { xlog("L_ERR","$Tf VMPROXY: ERROR routing call <$rm> from <$fu> to <$ru>\n"); exec_dset("/usr/local/vmproxy/bin/routeINVITE2.sh"); xlog("L_ERR","$Tf VMPROXY: Rerouting call <$rm> to <$ru>\n"); append_branch(); t_relay(); } } # # Initial NOTIFY route failed, retry # failure_route[2] { # endpoint canceled call if( t_was_cancelled()) { xlog("L_DBG", "$Tf VMPROXY: call <id:$ci> cancelled\n"); return; } # don't retry on 40[0-7|5xx failures if( !t_check_status("40[0-7]|5[0-9][0-9]")) { xlog("L_ERR","$Tf VMPROXY: ERROR routing <$rm> from <$fu> to <$ru>\n"); exec_dset("/usr/local/vmproxy/bin/routeNOTIFY2.sh"); xlog("L_ERR","$Tf VMPROXY: Rerouting <$rm> to <$ru>\n"); append_branch(); t_relay(); } }

16 years, 6 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 April 2008