sr-users October 2007

sr-users@lists.kamailio.org

130 participants
285 discussions

Re: [OpenSER-Users] ALG error workarounds

by Phil D'Amore

Richard: Sorry if this breaks threading, I don't have the original message. In the cases where it doesn't work, can you confirm that the Contact URI in the 200 actually contains a public address as it leaves your network? What you're describing makes me think it's not, and it looks like the following to me: GW sends 200 with private address in Contact. This private address leaks out of your network. This private address happens to fall within the range of your customer's private network. The 200 hits the remote router. The ALG leaves it alone (for now). The PAP2T reads the Contact in the 200 and pulls the private address from it. It targets the ACK to this private address, and sends it. The ALG sees this, and notices the RURI contains a private address from it's own local network. It PATs this address (hence the port 2021, it just picks the next port, since 2020 was already used by your PAP2T). The ACK now contains the offending address in the RURI. When your openser instance gets it, it just relays it like it was told to do based on loose routing, and the call drops. The thing about those ALGs is that they will rewrite *anything* that matches the access list associated with the nat pool address, even if it has nothing to do with any real IP traffic flowing through the thing. Hope that gives you something useful. Phil

17 years

[OpenSER-Users] Get more data in AVPs after "lookup()"

by Iñaki Baz Castillo

Hi, I'd like to extend the "location" table with more attributes and get them as AVP's after "lookup()" function. Is it any automatic way to do that? I mean something as "auth_db" module's "load_credentials" that load AVP's with more subscriber data. I don't find it so I think I'll need to do a custom SQL query after "lookup()" (in branch_route) and get the custom fields. Anyway I ask it: is there any way I don't know to get this "easily"? Thanks. -- Iñaki Baz Castillo ibc(a)in.ilimit.es

17 years

[OpenSER-Users] use_domain param in uri_db module

by Morten Isaksen

Hi! Runing OpenSER 1.1.1. In the uri_db module I have modparam("uri_db", "use_uri_table", 1) modparam("uri_db", "use_domain", 0) But the use_domain setting seems to be ignored. When I check the mysql.log i see select username from uri where username='XX102208' AND domain='XX.61.139.21' AND uri_user='XX102208' and check_from and check_to fails if the domain part does not match. Is this a bug or am I missing something? -- Morten Isaksen http://www.misak.dk/blog/

17 years

[OpenSER-Users] Accessing From header parameters

by Andreas Granig

Hi, I've found that Linksys SPA9000 (some sort of IP PBX) signals extensions in a "ref" parameter of From-Header, like: From: <sip:line1@matrix.sipura.com>;tag=1234;ref=105 Is there a way to easily access this parameter? Seems like... $var(ext) = $(fu{uri.param,ref}); ... doesn't catch it because it's not part of $fu. Any other ways except trying to assign $hdr(From) to an AVP and extract it using avp_subst(...)? Andreas

17 years

[Serusers] lcr module question - how to implement nice routing logic?

by Tomasz Zieleniewski

Hi, Is it possible to use lcr module so that when the routing logic checks it won't change the request URI but only change the destination of the SIP message?? I would like to utilize this module to select if the outgoing message should be forwarded to boundary SIP Proxy or to SIP/PSTN Gateway. Could You Please give me some clues or point another way to do this? Thank You for any help. Cheers TOmasz

17 years

[OpenSER-Users] Cluster Setup / openser location table entries "gone"

by Brandon Armstead

Hello Guys, I'm clustering subscribers at the database level, however it seems this one specific server I added into cluster that uses usrloc, is removing location entries, completely randomly? I've turned debug=9, but all I can see is... a bunch of: "core:db_free_rows: freeing 0 rows" over and over, this is with revision 2602 and latest trunk from openser. Which is thus on a usrloc mode of (3) causing essentially inbound calls to stop working. Any ideas anyone? Anyone with similiar issue? Every other server is running just fine, just only when this SINGLE server connects / runs to the rest of the cluster (MySQL) -- it starts dropping openser's locations. Any help appreciated, thanks! P.S. Also tried with libmysqlclient libs from 5.2.0-beta and 5.0 stable. -- Brandon Armstead

17 years

Re: [OpenSER-Users] [OpenSER-Devel] PUA/PUA_MI Error:

by Schumann Sebastian

Hello Anca With the current release 2993 this works. In general I use no etag param. I know what you mean by that it changes (for re-updates initiated by PUA, last numbers change e.g. from 1.0 to 2.1). I have now a different error though, even worse: First sending publish with infinite Expires: -1 works, also Expires: 0 afterwards deletes the entry in the presentity table (works as well). But if I wanna do another publish after this scenario, the whole OpenSER PUA gets stuck. It doesn't accept anymore MI publication. Also DEBUG log stops. The last lines I see in the debug are DBG:pua_mi:mi_pua_publish: send publish DPG: pua:send_publish: pres_uri=test(a)10.96.115.125 And then it freezes, no more debug information and MI request acceptance (also no reply in MI output FIFO) SIP messagesd for first publishs with Expires: -1 and 0 are exchanged (Publish/200 OK and Publish/200 OK) but for sending a Expires: -1 request again, no SIP message is created as well. What can be the error here? Stange it works once but afterwards not. Can it be that Expires: 0 deletes the presentity table entry but pua table entry is still there? I tried as well to delete that one manually before performing second publish with Expires: -1 but it doesn't work either. Regards Sebastian -----Original Message----- From: Anca Vamanu [mailto:anca@voice-system.ro] Sent: Monday, October 29, 2007 4:04 PM To: Schumann Sebastian Cc: users(a)openser.org; devel(a)openser.org Subject: Re: [OpenSER-Devel] PUA/PUA_MI Error: Hello, If you set the etag parameter when sending the "Expires: 0 " command, it might be that it is no longer valid. This happens if you first give a command with Expires value grater than the maximum accepted value by presence module. Then, the pua will generate itself updates such that the cumulated period of validity to equal the Expires in the first request. And for each new publish a different etag is replied.This is especially true if you have previously used an Expires: -1. On the other hand, if you do not set the etag param, there was a bug in the hash table searching function that was fixed in version 2993, that applied for the commands with no etag. Have you tested with this version? regards, Anca Vamanu Schumann Sebastian wrote: > Dear all > > After long evaluation I still have the following error and no solution > yet to solve it. > > I am using OpenSER current trunk version, but also with older versions > (e.g. 2597, 2619) I am having the problem. > > With version 2404 it seems to work, although I cannot use that version > and have to upgrade OpenSER to a newer release due to table consistencies. > > When I use PUA_MI to create a Publish, everything works fine. > "Expires: -1" works for infinite state. But when I want to expire this > state ("Expires: 0"), the PUA replies: > search_htable: record not found and later > send_publish: request for a publish with expires 0 and no record found > > There is most likely a problem in pua/hash.c or pua/send_publish.c but > I cannot find it. > > Can anyone help? > > Regards > Sebastian > ------------------------------------------------------------------------ > > _______________________________________________ > Devel mailing list > Devel(a)lists.openser.org > http://lists.openser.org/cgi-bin/mailman/listinfo/devel >

17 years

[Serusers] SERCTL Utility for SER Release 2.0.0-rc1

by Piyush.Bansal＠relianceada.com

hi All, We've downloaded the SERCTL Utility from http://www.iptel.org/ser_2_0_0_release_candidate_1. It seems that the Makefile of this utility is written for Linux. Can we have the same which runs on Unix platform (Solaris 10 OS). Can anybody tell me that whether we can use the serctl utility which is there in default installation (/PREFIX_PATH/sbin/serctl). The default script seems to be the same as that of SER-0.9.6 i.e. it expects the subscriber and uri_db table which is not the part of Release-2.0.0-rc1. plz reply ASAP.... thanx 'n' regds, --Piyush Bansal The information contained in this e-mail message is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you should return it to the sender immediately. Please note that while we scan all e-mails for viruses we cannot guarantee that any e-mail is virus-free and accept no liability for any damage caused by any virus transmitted by this email.

17 years

Re: [OpenSER-Users] Acc module question

by [ACTIVENDY] NOC

[ACTIVENDY] NOC wrote: > Hi Bodgan > > I got INVITEs in my db, but OpenSER insert the INVITE message into > my db when get a 200 code response to this INVITE. I would like to > insert this INVITE before it, when the phone is still ringing, cause i > need to know the setup time and when there is a call attempt in my > system. Is this possible? > > Thanks, > > Sergi > > Bogdan-Andrei Iancu wrote: >> Hi Sergi, >> >> The START acc event (corresponding to INVITE) has no dependency to >> the ACK. Do you get any INVITE acc in your DB? >> >> regards, >> Bogdan >> >> [ACTIVENDY] NOC wrote: >>> Hi, >>> >>> I need to know when a channel of my media gateway is busy >>> (included when the call is still ringing, etc). I have my Openser >>> working with acc module storing in a mysql database. I don't use >>> media proxy server. >>> I can see the media gateway active calls in the acc table >>> calculating the INVITEs whithout BYEs call registers. But I see >>> Openser doesn't insert the INVITE register still and ACK arrives. It >>> means I just can view in my database the number of active calls but >>> i cannot know how many call attempts there's in the media gateway. >>> How can I do to Openser insert the INVITE register to my database >>> when an INVITE messages arrives and don't wait for the ACK message? >>> >>> Thanks in advance, >>> >>> Sergi >>> >>> _______________________________________________ >>> Users mailing list >>> Users(a)openser.org >>> http://openser.org/cgi-bin/mailman/listinfo/users >>> >> >> >

17 years

Re: [OpenSER-Users] transaction flags not visible in CANCEL

by Papadopoulos Georgios

Hi Bogdan, Flag inheritance by the replies works. I did not know that it was not supposed to work for the CANCEL. It is good to know because I was starting to loose my mind... Maybe a note somewhere in the project's site would be useful. It is very strange behaviour because t_check_trans() returns true which means that the CANCEL belongs to an existing transaction, but the flags are not the same as the original. Last question: What about Re-INVITEs? The flags are not working there either? If this is true, then the only way to save some information about the transaction is to add it as a parameter in the contact? Or is there some other way? Thank you. Best regards George > -----Original Message----- > From: Bogdan-Andrei Iancu [mailto:bogdan@voice-system.ro] > Sent: Tuesday, October 30, 2007 6:07 AM > To: Papadopoulos Georgios > Cc: users(a)lists.openser.org > Subject: Re: [OpenSER-Users] transaction flags not visible in CANCEL > > Hi George, > > There are two cases you are referring at: > > 1) flags inheritance by the replies (set flag in INVITE and see it in > replies) - is this working? > > 2) flags inheritance by the CANCEL (set flag in INVITE and > see it in CANCEL req/reply) - this is know not to work as so > far the CANCEL was a different transaction then the INVITE, > but starting with 1.3 it is the same, so it should be fixed. > > Regards, > Bogdan > > Papadopoulos Georgios wrote: > > Hello all, > > > > I am running into a strange problem with message (or transaction) > > flags. I set a message flag while processing the INVITE, > but this flag > > does not appear in any messages that belong to the same > transaction. I > > discovered this while trying to resolved an issue with > Re-INVITEs. Now > > I am testing it with a simple INVITE-CANCEL senario and I see that > > again the flag does not appear when processing the CANCEL. > My script > > is pretty basic, at least for the CANCEL processing. The > debug output > > is at the end of the email. > > > > if (is_method("CANCEL")) { > > if (!t_check_trans()) { > > # Must be a CANCEL for a > transaction that has > > not been established. > > # Drop it and the client will resend it. > > exit; > > } > > else xlog("L_ERR","$rm: tran found flags=0x$mF > > bflags=0x$bF\n"); > > .... > > t_relay(); > > } > > Searching on the internet I came across this > > > http://openser.org/dokuwiki/doku.php/modules:1.2.x:t_check_trans_comme > > nts > > > http://caravan5.webcrossing.com/People/emin-gabrielyan/public/070413-o > > penser-transactions/ > > > > So what is the story? Am I doing something wrong? > > > > thank you for any help > > > > George > > > > > > 1(18475) SIP Request: > > 1(18475) method: <CANCEL> > > 1(18475) uri: <sip:2116872933@altecnet.gr;user=phone> > > 1(18475) version: <SIP/2.0> > > 1(18475) parse_headers: flags=2 > > 1(18475) Found param type 232, <branch> = <z9hG4bK-mcodgtqb0696>; > > state=6 > > 1(18475) Found param type 235, <rport> = <n/a>; state=17 > > 1(18475) end of header reached, state=5 > > 1(18475) parse_headers: Via found, flags=2 > > 1(18475) parse_headers: this is the first via > > 1(18475) After parse_msg... > > 1(18475) preparing to run routing scripts... > > 1(18475) parse_headers: flags=100 > > 1(18475) DEBUG:parse_to:end of header reached, state=10 > > 1(18475) DBUG:parse_to: display={}, > > ruri={sip:2116872933@altecnet.gr;user=phone} > > 1(18475) DEBUG: get_hdr_field: <To> [41]; > > uri=[sip:2116872933@altecnet.gr;user=phone] > > 1(18475) DEBUG: to body [<sip:2116872933@altecnet.gr;user=phone> > > ] > > 1(18475) get_hdr_field: cseq <CSeq>: <2> <CANCEL> > > 1(18475) DEBUG:maxfwd:is_maxfwd_present: value = 70 > > 1(18475) DBG:maxfwd:process_maxfwd_header: value 70 decreased to 10 > > 1(18475) check_via_address(213.5.17.236, 213.5.17.236, 0) > > 1(18475) parse_headers: flags=80 > > 1(18475) DEBUG: add_param: tag=b59u54s6kf > > 1(18475) DEBUG:parse_to:end of header reached, state=29 > > 1(18475) DBUG:parse_to: display={"snom"}, > > ruri={sip:demo2@altecnet.gr} > > 1(18475) parse_headers: flags=200 > > 1(18475) DEBUG: get_hdr_body : content_length=0 > > 1(18475) found end of header > > 1(18475) find_first_route: No Route headers found > > 1(18475) loose_route: There is no Route HF > > 1(18475) grep_sock_info - checking if host==us: 11==10 && > > [altecnet.gr] == [213.5.43.4] > > 1(18475) grep_sock_info - checking if port 5060 matches port 5060 > > 1(18475) grep_sock_info - checking if host==us: 11==10 && > > [altecnet.gr] == [213.5.43.7] > > 1(18475) grep_sock_info - checking if port 5060 matches port 5060 > > 1(18475) grep_sock_info - checking if host==us: 11==10 && > > [altecnet.gr] == [213.5.43.8] > > 1(18475) grep_sock_info - checking if port 5060 matches port 5060 > > 1(18475) grep_sock_info - checking if host==us: 11==10 && > > [altecnet.gr] == [213.5.43.9] > > 1(18475) grep_sock_info - checking if port 5060 matches port 5060 > > 1(18475) grep_sock_info - checking if host==us: 11==12 && > > [altecnet.gr] == [172.31.100.5] > > 1(18475) grep_sock_info - checking if port 5060 matches port 5060 > > 1(18475) parse_headers: flags=78 > > 1(18475) DEBUG: t_lookupOriginalT: searching on hash entry 13236 > > 1(18475) DEBUG: RFC3261 transaction matched, tid=-mcodgtqb0696 > > 1(18475) DEBUG: t_lookupOriginalT: canceled transaction found > > (0xb616b3d8)! > > 1(18475) DEBUG:tm:REF_UNSAFE: after is 1 > > 1(18475) DEBUG: t_lookupOriginalT completed > > 1(18475) CANCEL: tran found flags=0x00000000 bflags=0x00000000 > > 1(18475) route9: CANCEL > sip:2116872933@altecnet.gr;user=phone <null> > > fl=0x00000000 bfl=0x00000000 branch_id=0 > > 1(18475) DEBUG: t_newtran: T on entrance=0xffffffff > > 1(18475) parse_headers: flags=ffffffffffffffff > > 1(18475) parse_headers: flags=78 > > 1(18475) t_lookup_request: start searching: hash=13236, isACK=0 > > 1(18475) DEBUG: RFC3261 transaction matching failed > > 1(18475) DEBUG: t_lookup_request: no transaction found > > 1(18475) DBG: trans=0xb616fc50, callback type 1, id 0 entered > > 1(18475) check_via_address(213.5.17.236, 213.5.17.236, 0) > > 1(18475) DEBUG:tm:set_timer: relative timeout is 1000000 > > 1(18475) DEBUG: add_to_tail_of_timer[4]: 0xb616fd9c (5200000) > > 1(18475) DEBUG:tm:set_timer: relative timeout is 3 > > 1(18475) DEBUG: add_to_tail_of_timer[0]: 0xb616fdb8 (7) > > 1(18475) DEBUG: e2e_cancel: e2e cancel proceeding > > 1(18475) parse_headers: flags=ffffffffffffffff > > 1(18475) check_via_address(213.5.17.236, 213.5.17.236, 0) > > 1(18475) WARNING:vqm_resize: resize(0) called > > 1(18475) DEBUG:tm:_reply_light: reply sent out. buf=0x817a358: > > SIP/2.0 2..., shmem=0xb6171780: SIP/2.0 2 > > 1(18475) DEBUG:tm:_reply_light: finished > > 1(18475) DEBUG:tm:t_relay_to: new transaction fwd'ed > > 1(18475) DEBUG:tm:UNREF_UNSAFE: after is 0 > > 1(18475) DEBUG:tm:UNREF_UNSAFE: after is 0 > > 1(18475) DEBUG:destroy_avp_list: destroying list (nil) > > 1(18475) receive_msg: cleaning up > > > > > > Disclaimer > > > > The information in this e-mail and any attachments is > confidential. It > > is intended solely for the attention and use of the named > > addressee(s). If you are not the intended recipient, or person > > responsible for delivering this information to the intended > recipient, > > please notify the sender immediately. Unless you are the intended > > recipient or his/her representative you are not authorized to, and > > must not, read, copy, distribute, use or retain this message or any > > part of it. E-mail transmission cannot be guaranteed to be > secure or > > error-free as information could be intercepted, corrupted, lost, > > destroyed, arrive late or incomplete, or contain viruses. > > > > > ---------------------------------------------------------------------- > > -- > > > > _______________________________________________ > > Users mailing list > > Users(a)lists.openser.org > > http://lists.openser.org/cgi-bin/mailman/listinfo/users > > > >

17 years

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 October 2007