- sr-users - kamailio.org

[Serusers] How to make exec_dset() return false?
by John G. Rose 12 Dec '08

12 Dec '08

How do I make exec_dset() return a false? As in: if (!(exec_dset('some shell scripting stuff')) { do this....; } Thanks, John

1 0

Re: [Serusers] REGISTER control based on UA
by inge 12 Dec '08

12 Dec '08

Hi all, I'm still working on without success for the moment. I don't have an idea on the means to use AVP/DB etc. with this purpose. Someone can help me ? Regards Le lundi 24 novembre 2008 à 12:20 +0100, Atle Samuelsen a écrit : > if(search("Asterisk")){ > sl_reply("403","Go away ugly asterisk"); > break; > }else if(search("my_other_ua_i_dont_like"){ > sl_reply("403","I do not like you either"); > break; > } > > > On Mon, Nov 24, 2008 at 12:16 PM, inge <inge(a)legos.fr> wrote: > > Someone else has an idea ? I think about how to implement this kind of > > filtering with functions included in SER 0.9.6, but I still in trouble. > > > > Thanks. > > > > Le jeudi 13 novembre 2008 à 16:44 +0100, inge a écrit : > >> Hi Alexandre, > >> > >> Great workaround !! > >> > >> Maybe I can use it with Redhat if the module is compiled with x86 > >> architecture ? > >> > >> What about the "flag" field in table description ? > >> > >> Regards, > >> > >> A. LEMOINE > >> > >> Le mercredi 12 novembre 2008 à 20:59 +0300, Alexandre Snarskii a écrit : > >> > On Wed, Nov 12, 2008 at 12:59:35PM +0100, inge wrote: > >> > > Hi all, > >> > > > >> > > I look for a workaround to use a white list in addition of > >> > > authentification proces, based on User-Agent (ie. for example : deny > >> > > "Asterisk IPBX" permit "Cisco IPhone...") > >> > > >> > There is (unofficial) check_ua module added as a patch in FreeBSD port, > >> > which works exactly as 'additional UA check'. > >> > > >> > Setup is not too complicated: you must create and populate some table > >> > in your database. In my example, DB is postgresql, exact create/populate > >> > commands is the next: > >> > > >> > CREATE TABLE check_ua ( > >> > rexx VARCHAR(256) NOT NULL UNIQUE, > >> > flag INTEGER NOT NULL DEFAULT(0) > >> > ); > >> > -- main goal is to disallow user-agents with invalid symbols: > >> > INSERT INTO check_ua VALUES('^[0-9A-Za-z/.() _-]{1,64}$',1); > >> > -- in your case it should be something like > >> > INSERT INTO check_ua VALUES('^Cisco IP Phone.*',1); > >> > > >> > Then, add to global configuration: > >> > > >> > loadmodule "/usr/local/lib/ser/modules/check_ua.so" > >> > modparam("check_ua", "db_url", "postgres://<username>:<password>@<host>/<db>") > >> > modparam("check_ua", "db_table", "check_ua") > >> > > >> > and somewhere in route section: > >> > > >> > if(!check_ua()) { > >> > xlog("L_ERR","Invalid UA DENIED: %fu, %is, %ua\n"); > >> > sl_send_reply("403", "Forbidden (Invalid UA)"); > >> > break; > >> > }; > >> > > >> > Voila. Until your Asterisk users will not find correct User-Agent > >> > they must use in their sip.conf - it will work... :) In my case - > >> > protection against bad symbols - it works even with asterisk... :) > >> > > >> > PS: not sure is that module can be found somewhere outside FreeBSD port, > >> > at least my google skills is not enough to ... > >> > However, both authors (Valentin Nechayev and Maxim Sobolev) read this list. > >> > > >> > >> _______________________________________________ > >> Serusers mailing list > >> Serusers(a)lists.iptel.org > >> http://lists.iptel.org/mailman/listinfo/serusers > > > > _______________________________________________ > > Serusers mailing list > > Serusers(a)lists.iptel.org > > http://lists.iptel.org/mailman/listinfo/serusers > >

1 1

[Kamailio-Users] Having some issues with openser 1.2.3
by Krunal Patel 12 Dec '08

12 Dec '08

We are having setup like openser+radius+mediaproxy. Openser version is 1.2.3. When we started to send high volume calls , we get below mentioned ERRORs & WARNINGs. 1. /usr/local/sbin/openser[29869]: ERROR:tm:t_forward_nonack: discarding fwd for a cancelled transaction /usr/local/sbin/openser[29869]: ERROR:tm:w_t_relay: t_forward_nonack failed WARNING: script writer didn't release transaction 2. WARNING:tm:run_failure_handlers: no UAC or CANCEL support (1, 0) 3. /usr/local/sbin/openser[29870]: ERROR:nathelper:nh_timer: out of memory 4. /usr/local/sbin/openser[29870]: convert_rows: No memory left (openser crashed) As we were using default shared memory for openser, we increased shared memory to maximum(2GB) to fix out of bound issue. We checked openser script for memory leacks using valgrind, but did not find any memory leack. During doing relay of CANCEL,in relay route t_on_failure was added. So we removed t_on_failure in relay route for CANCEL. So WARNING:tm:run_failure_handlers: no UAC or CANCEL support (1, 0) was fixed. Still we are facing, 1. /usr/local/sbin/openser[29869]: ERROR:tm:t_forward_nonack: discarding fwd for a cancelled transaction /usr/local/sbin/openser[29869]: ERROR:tm:w_t_relay: t_forward_nonack failed WARNING: script writer didn't release transaction 2. /usr/local/sbin/openser[29870]: ERROR:nathelper:nh_timer: out of memory 3. ERROR:usrloc:get_all_db_ucontacts: raw_query failed 4. rc_avpair_gen: received unknown attribute 80 of length 18: 0xA40AA6A78F04D67B03C75F8CA233F008 Will increasing private memory will solve all issues? Thanks in advance!! -- Krunal Patel

2 1

[Serusers] new_connection(): Access denied for user 'serro'
by caio 12 Dec '08

12 Dec '08

Hi all, I have this error when start ser (v0.9.7): 0(0) find_mod_export: found <db_update> in module mysql [/usr/local/lib/ser/modules/mysql.so] 0(0) get_connection(): Connection not found in the pool 0(0) release_connection(): Removing connection from the pool 0(0) get_connection(): Connection not found in the pool 0(0) release_connection(): Removing connection from the pool 0(0) DEBUG: init_mod: domain 0(0) domain - initializing 0(0) find_mod_export: found <db_use_table> in module mysql [/usr/local/lib/ser/modules/mysql.so] 0(0) find_mod_export: found <db_init> in module mysql [/usr/local/lib/ser/modules/mysql.so] 0(0) find_mod_export: found <db_close> in module mysql [/usr/local/lib/ser/modules/mysql.so] 0(0) find_mod_export: found <db_query> in module mysql [/usr/local/lib/ser/modules/mysql.so] 0(0) find_mod_export: found <db_raw_query> in module mysql [/usr/local/lib/ser/modules/mysql.so] 0(0) find_mod_export: found <db_free_result> in module mysql [/usr/local/lib/ser/modules/mysql.so] 0(0) find_mod_export: found <db_insert> in module mysql [/usr/local/lib/ser/modules/mysql.so] 0(0) find_mod_export: found <db_delete> in module mysql [/usr/local/lib/ser/modules/mysql.so] 0(0) find_mod_export: found <db_update> in module mysql [/usr/local/lib/ser/modules/mysql.so] 0(0) get_connection(): Connection not found in the pool 0(0) new_connection(): Access denied for user 'serro'@'localhost' to database 'ser' 0(0) db_init(): Could not create a connection 0(0) ERROR:domain_db_init: cannot initialize database connection 0(0) init_mod(): Error while initializing module domain ERROR: error while initializing modules 0(0) XLOG: destroy module ... Couriously, database name is not 'ser', i've changed its name on ser_mysql.sh. I also change on ser_mysql.sh DBNAME, USERNAME, and DEFAULT_PW. User 'serro' at this instance has its default password RO_PW (47serro11). The "ser_mysql.sh create" works, but then whan I run "ser -D -E" it fails. If I change 'serro' default password and run again ser_mysql (after deleting previous db installation), the failure is the the following: 0(0) get_connection(): Connection not found in the pool 0(0) new_connection(): Access denied for user 'serro'@'localhost' (using password: YES) 0(0) db_init(): Could not create a connection 0(0) ERROR:domain_db_init: cannot initialize database connection Here, access is denied, but seem to found correctly the new db name. Is it possible that 'serro', 'heslo', default password of serro, ser default db names, an similar values be hardcoded on ser binary? Any comments will be apreciatted.., thanks. caiogf

1 0

[Serusers] new_connection(): Access denied for user 'serro'
by caio 12 Dec '08

12 Dec '08

Hi all, I have this error when start ser (v0.9.7): 0(0) find_mod_export: found <db_update> in module mysql [/usr/local/lib/ser/modules/mysql.so] 0(0) get_connection(): Connection not found in the pool 0(0) release_connection(): Removing connection from the pool 0(0) get_connection(): Connection not found in the pool 0(0) release_connection(): Removing connection from the pool 0(0) DEBUG: init_mod: domain 0(0) domain - initializing 0(0) find_mod_export: found <db_use_table> in module mysql [/usr/local/lib/ser/modules/mysql.so] 0(0) find_mod_export: found <db_init> in module mysql [/usr/local/lib/ser/modules/mysql.so] 0(0) find_mod_export: found <db_close> in module mysql [/usr/local/lib/ser/modules/mysql.so] 0(0) find_mod_export: found <db_query> in module mysql [/usr/local/lib/ser/modules/mysql.so] 0(0) find_mod_export: found <db_raw_query> in module mysql [/usr/local/lib/ser/modules/mysql.so] 0(0) find_mod_export: found <db_free_result> in module mysql [/usr/local/lib/ser/modules/mysql.so] 0(0) find_mod_export: found <db_insert> in module mysql [/usr/local/lib/ser/modules/mysql.so] 0(0) find_mod_export: found <db_delete> in module mysql [/usr/local/lib/ser/modules/mysql.so] 0(0) find_mod_export: found <db_update> in module mysql [/usr/local/lib/ser/modules/mysql.so] 0(0) get_connection(): Connection not found in the pool 0(0) new_connection(): Access denied for user 'serro'@'localhost' to database 'ser' 0(0) db_init(): Could not create a connection 0(0) ERROR:domain_db_init: cannot initialize database connection 0(0) init_mod(): Error while initializing module domain ERROR: error while initializing modules 0(0) XLOG: destroy module ... Couriously, database name is not 'ser', i've changed its name on ser_mysql.sh. I also change on ser_mysql.sh DBNAME, USERNAME, DEFAULT_PW. User 'serro' at this instance has its default password RO_PW (47serro11). The "ser_mysql.sh create" works, but then whan I run "ser -D -E" if fails. If I change 'serro' default password and run again ser_mysql (after deleting previous db installation), the failure is the the following: 0(0) get_connection(): Connection not found in the pool 0(0) new_connection(): Access denied for user 'serro'@'localhost' (using password: YES) 0(0) db_init(): Could not create a connection 0(0) ERROR:domain_db_init: cannot initialize database connection Access is denied, but seem to found correctly the new db name. Is it possible that 'serro', 'heslo', default password of serro, ser default db names, an similar values be hardcoded on ser binary? Any comments will be apreciatted.., thanks. caiogf

1 0

Re: [Kamailio-Users] Kamalio Support for RFC 3323 " Privacy"
by ingdavidcespedes＠cable.net.co 12 Dec '08

12 Dec '08

----- Mensaje original ----- De: Iñaki Baz Castillo <ibc(a)aliax.net> Fecha: Jueves, Diciembre 11, 2008 4:52 pm Asunto: Re: [Kamailio-Users] Kamalio Support for RFC 3323 " Privacy" > El Jueves, 11 de Diciembre de 2008, ingdavidcespedes(a)cable.net.co > escribió:> SORRYYYYYYY, you were right. What i'm trying to say is > that if the UA > > insert the p-p-i and privacy headers, the proxy should understand > this and > > do what I say above. > > The user sends the request with: > From: Anonymous <sip:anonymous@XXXXXx> > P-Preferred-Identity: <sip:alice@domain.com> > Privacy: id > > Then the proxy knows who is by checking PPI header and could ask > for > credentiales. After it, the proxy would remove PPI before routing > the > request. > > If the proxy sends the request to a trusted node, it could add PAI > header: P-Asserted-Identity: <sip:alice@domain.com> > Privacy: id > > And the next element would remove it if it routes to an untrusted > node/endpoint. > > Agree with all that you say. Only that the "P-Preferred-Identity:" is optional. If it is not present, the proxy should add a predefined P-Asserted-Identity: header field, if it is going to send the request to a trusted node. But as you can see, this implies different possible cases. So it would be very nice if we can do all of this using some module or something like that, don't you think so? > -- > Iñaki Baz Castillo > > _______________________________________________ > Users mailing list > Users(a)lists.kamailio.org > http://lists.kamailio.org/cgi-bin/mailman/listinfo/users >

4 3

[Kamailio-Users] CDRtool newbie
by BERGANZ François 12 Dec '08

12 Dec '08

Hello, Is there a simple doc to install CDRTool ? I need to install a simple prepaid system, but I dont really understand how to do! Thank you Cordialement, BERGANZ François P Pensez à l'Environnement, n'imprimez ce mail que si nécessaire.

2 2

Re: [Serusers] Issue with auth_identity
by jerome.herve＠orange-ftgroup.com 12 Dec '08

12 Dec '08

hello everyone, I still have an issue with auth_identity : I have this error: AUTH_IDENTITY VERIFIER: common name of certificate doesn't match host name The common name of my certificate is the name of my domain (used in Identity Info URL). I believe I've done the correct thing... Any idea guys ? Cheers, Jérôme HERVE -----Message d'origine----- De : Kovács Gergely [mailto:kg@testbike.hu] Envoyé : jeudi 11 décembre 2008 22:23 À : zze-HERVE Jerome RD-CORE-LAN Objet : Re: [Serusers] Issue with auth_identity Hi Jerome, I'm the one who developed auth_identity few years ago. I checked the source and it seems that your auth_identity was unable to decode the certificate that it had been successfully downloaded. How did you generate the certificates? Auth_identity supports only openssl! Of course I had it working :) You can find SER config snippets in the manual of the module: http://www.iptel.org/auth_identity_0 Shall I write you the openssl command line switches I used for generating certificates? Cheers, Gergo > -------- Original Message -------- > Subject: Re: [Serusers] Issue with auth_identity > Date: Wed, 10 Dec 2008 16:06:08 +0100 > From: <jerome.herve(a)orange-ftgroup.com> > To: <victor.pascual.avila(a)gmail.com> > CC: serusers(a)lists.iptel.org > > Hi, > Yes I've tried again with other certificates. > It happens before the vrfy_check_certificate... > During the function vrfy_get_certificate. > I really don't understand it. > If I put a wrong certificate name, I have a 404 Not Found so I believe > it sees the certificate. > But maybe it doesn't manage to download it. > Did you manage to make this working? > > > Jérôme HERVE > FT/NSM/RD/CORE/M2V/SID > tél. 02 96 05 27 41 > mob. 06 76 15 18 49 > jerome.herve(a)orange-ftgroup.com > > > -----Message d'origine----- > De : Victor Pascual Ávila [mailto:victor.pascual.avila@gmail.com] > Envoyé : mercredi 10 décembre 2008 14:13 À : zze-HERVE Jerome > RD-CORE-LAN Cc : serusers(a)lists.iptel.org Objet : Re: [Serusers] Issue > with auth_identity > > Hi Jerome, > I'm not sure about this but have you tried using other certificates? > > Cheers, > -Victor > > On Wed, Dec 10, 2008 at 11:30 AM, <jerome.herve(a)orange-ftgroup.com> wrote: >> Hello, >> >> I am trying to put in place auth_identity between 2 SER proxies and it >> doesn't work well. >> The first one manages to add identity and identity_info fields and to >> send the INVITE to the other proxy. >> But when the other proxy receive the message and does his tests there >> is an issue. >> It sends back a 436 Bad Identity Info. The error happens during the >> "vrfy_get_certificate" function (function which downloads the >> certificate thanks to identity_info URL). >> >> On my proxy logs, I can see this : AUTH_IDENTITY:retrieve_x509: DER >> Certificate error:0D0680A8:asn1 encoding >> routines:ASN1_CHECK_TLEN:wrong tag >> >> I really don't know what to do, do you have any idea? >> Thanks, >> Regards, >> >> Jérôme HERVE >> >> _______________________________________________ >> Serusers mailing list >> Serusers(a)lists.iptel.org >> http://lists.iptel.org/mailman/listinfo/serusers >> >> > > > > -- > Victor Pascual Ávila > _______________________________________________ > Serusers mailing list > Serusers(a)lists.iptel.org > http://lists.iptel.org/mailman/listinfo/serusers

1 0

Re: [Kamailio-Users] Kamalio Support for RFC 3323 " Privacy"
by ingdavidcespedes＠cable.net.co 12 Dec '08

12 Dec '08

----- Mensaje original ----- De: ingdavidcespedes(a)cable.net.co Fecha: Jueves, Diciembre 11, 2008 4:43 pm Asunto: Re: [Kamailio-Users] Kamalio Support for RFC 3323 " Privacy" > > > ----- Mensaje original ----- > De: Alexandr Dubovikov <voip(a)start4.info> > Fecha: Viernes, Diciembre 5, 2008 1:13 pm > Asunto: Re: [Kamailio-Users] Kamalio Support for RFC 3323 " Privacy" > > > Iñaki Baz Castillo пишет: > > > El Viernes, 5 de Diciembre de 2008, Juha Heinanen escribió: > > > > > >> if caller needs privacy, then it is up to the UA to send > > anonymous from > > >> header together with p-p-i and privacy headers. > > >> > I Think this is wrong. The UA should ask for the privacy services, > an the proxy must offer this services. This means it must rewrite > the information that the UA is willing to keep private with > anonymous information, and keep track of it, so it can be replaced > when the response is received. SORRYYYYYYY, you were right. What i'm trying to say is that if the UA insert the p-p-i and privacy headers, the proxy should understand this and do what I say above. > > > > > > That would be so cool... Unfortunatelly I just know a SIP phone > > implementing > > > it: Twinkle. > > > > > > Other phones (as Linksys) when the user enables privacy during > a > > call, just > > > set the From Display-Name with "Anonymous" value, while the > From > > username > > > remains the real :( > > > > > > > > Yep, some UAC set "Anonymous" only in Display Name. But u can fix > > it > > using this code: > > > > $var(url) = $fu; > > if(is_present_hf("Privacy") && ($hdr(Privacy)=="id" || > > $hdr(Privacy)=="user") && search("(From|f):\s*\"?anonymous")) { > > uac_replace_from("Anonymous","sip:anonymous@anonymous.invalid"); > > if(!is_present_hf("P-Asserted-Identity")) { > > append_hf("P-Asserted-Identity: <$var(url)>\r\n"); }; > > } > > This is what i'm talking about!!!!, but you should check also if > the message already have a P-Asserted-Identity that was generated > before and remove it. > > And how it will know to which transaction it corresponds when the > response message comes. It will use the branch id, and the tags? It > doesn't matter that some URIs have been replaced with anonymous > information? > There should be an easier way to do this. > > > > > > With best regards, > > > > -- > > > > Alexandr Dubovikov * baron@iRC RusNet * shurik(a)start4.info > > AD1-UANIC * ICQ: 122351182 * http://www.start4.info > > > > > > > > _______________________________________________ > > Users mailing list > > Users(a)lists.kamailio.org > > http://lists.kamailio.org/cgi-bin/mailman/listinfo/users > > > > > _______________________________________________ > Users mailing list > Users(a)lists.kamailio.org > http://lists.kamailio.org/cgi-bin/mailman/listinfo/users >

3 5

Re: [Kamailio-Users] Kamalio Support for RFC 3323 " Privacy"
by ingdavidcespedes＠cable.net.co 12 Dec '08

12 Dec '08

> > Unfortunatelly I just know two implementations using PPI when > asking for > > privacy: Twinkle and Sofia stack. > > Do you know any hardphones that implement this? > > Regards. > > > > > > > _______________________________________________ > Users mailing list > Users(a)lists.kamailio.org > http://lists.kamailio.org/cgi-bin/mailman/listinfo/users >

2 1

Re: [Kamailio-Users] Kamalio Support for RFC 3323 " Privacy"
by ingdavidcespedes＠cable.net.co 12 Dec '08

12 Dec '08

----- Mensaje original ----- De: Iñaki Baz Castillo <ibc(a)aliax.net> Fecha: Jueves, Diciembre 11, 2008 6:17 pm Asunto: Re: [Kamailio-Users] Kamalio Support for RFC 3323 " Privacy" > El Jueves, 11 de Diciembre de 2008, ingdavidcespedes(a)cable.net.co > escribió:> Agree with all that you say. Only that the "P-Preferred- > Identity:" is > > optional. If it is not present, the proxy should add a predefined > > P-Asserted-Identity: header field, if it is going to send the > request to a > > trusted node. > > Well, PPI is just used by the client if it wants to tell him proxy > who he is > (and doesn't want to indicate it in the From since theorically the > From > shouldn't be changed by the proxy). > > > > But as you can see, this implies different possible cases. So it > would be > > very nice if we can do all of this using some module or something > like> that, don't you think so? > > I already implement this exactly behaviour by examining the PPI > header instead > of From when PPI is present. Perhaps you mean a specific > module/functions for > this task? Could you describe these functions? > I don't know, something that makes this process easier. Maybe there is a need to create a module that can handle this. But meanwhile we can make a HowTo with the code and put it in the Wiki, I don't know!!!. > Regards. > > > -- > Iñaki Baz Castillo > > _______________________________________________ > Users mailing list > Users(a)lists.kamailio.org > http://lists.kamailio.org/cgi-bin/mailman/listinfo/users >

1 0

Re: [Kamailio-Users] Kamalio Support for RFC 3323 " Privacy"
by ingdavidcespedes＠cable.net.co 11 Dec '08

11 Dec '08

----- Mensaje original ----- De: Alexandr Dubovikov <voip(a)start4.info> Fecha: Viernes, Diciembre 5, 2008 1:13 pm Asunto: Re: [Kamailio-Users] Kamalio Support for RFC 3323 " Privacy" > Iñaki Baz Castillo пишет: > > El Viernes, 5 de Diciembre de 2008, Juha Heinanen escribió: > > > >> if caller needs privacy, then it is up to the UA to send > anonymous from > >> header together with p-p-i and privacy headers. > >> I Think this is wrong. The UA should ask for the privacy services, an the proxy must offer this services. This means it must rewrite the information that the UA is willing to keep private with anonymous information, and keep track of it, so it can be replaced when the response is received. > > > > That would be so cool... Unfortunatelly I just know a SIP phone > implementing > > it: Twinkle. > > > > Other phones (as Linksys) when the user enables privacy during a > call, just > > set the From Display-Name with "Anonymous" value, while the From > username > > remains the real :( > > > > > Yep, some UAC set "Anonymous" only in Display Name. But u can fix > it > using this code: > > $var(url) = $fu; > if(is_present_hf("Privacy") && ($hdr(Privacy)=="id" || > $hdr(Privacy)=="user") && search("(From|f):\s*\"?anonymous")) { > uac_replace_from("Anonymous","sip:anonymous@anonymous.invalid"); > if(!is_present_hf("P-Asserted-Identity")) { > append_hf("P-Asserted-Identity: <$var(url)>\r\n"); }; > } This is what i'm talking about!!!!, but you should check also if the message already have a P-Asserted-Identity that was generated before and remove it. And how it will know to which transaction it corresponds when the response message comes. It will use the branch id, and the tags? It doesn't matter that some URIs have been replaced with anonymous information? There should be an easier way to do this. > > > With best regards, > > -- > > Alexandr Dubovikov * baron@iRC RusNet * shurik(a)start4.info > AD1-UANIC * ICQ: 122351182 * http://www.start4.info > > > > _______________________________________________ > Users mailing list > Users(a)lists.kamailio.org > http://lists.kamailio.org/cgi-bin/mailman/listinfo/users >

1 0

Re: [Kamailio-Users] Kamailio in Red Hat 4 with mysql and carrierroute]
by ingdavidcespedes＠cable.net.co 11 Dec '08

11 Dec '08

Yes. You should download kamailio-1.4.1-notls_src.tar.gz, and when you compile it, you should write make all include_modules="db_mysql" instead of make all include_modules="mysql". It has changed for Kamailio. ----- Mensaje original ----- De: Juan Asencio <juan(a)asencio.dk> Fecha: Lunes, Diciembre 8, 2008 4:15 pm Asunto: Re: [Kamailio-Users] Kamailio in Red Hat 4 with mysql and carrierroute] > Juan Asencio wrote: > > Henning Westerholt wrote: > > > >> On Monday 08 December 2008, Juan Asencio wrote: > >> > >> > >>> Hi, I'm trying to install from source Kamailio on Red Hat 4, > and I need > >>> to include mysql as a database and carrierroute. > >>> > >>> When I check on the directory of modules, I can't see mysql.so or > >>> carrierroute.so, how can I include them? > >>> > >>> Best regards, > >>> > >>> > >> Hi Juan, > >> > >> have you compiled and installed the db_mysql and the > carrierroute module? > >> There excluded in the default installation, because they need > some extra > >> libraries. > >> > >> Cheers, > >> > >> Henning > >> > >> > > Hi again, I have another question :) > > > > I have download the kamailio-1.4.1-notls_linux_i386.tar.gz > > Put it on the directory: /usr/src and there I did: tar zxvf > kamai...tar.gz> A list of directories and files are created, but I > can't find the > > Makefile and I can't "make all" or "make" anything. > > > > In my small Linux experience, when I tar xvf... something.tar.gz > a > > directory of something is created and then I usually can find the > > makefile there. > > > > Why I can't find it now? I'm trying to follow the instructions on > > http://www.kamailio.org/mos/view/Installation-Notes/ but I can't > do it. > > > > Can anyone please give some suggestions? > > > > Thanks in advance, > > > > Juan.- > > > > > > > > _______________________________________________ > > Users mailing list > > Users(a)lists.kamailio.org > > http://lists.kamailio.org/cgi-bin/mailman/listinfo/users > > > Hi everybody, > > I figure it out :D sorry for the trouble. I was downloading the > wrong file. > > Cheers!!! > > Juan.- > > _______________________________________________ > Users mailing list > Users(a)lists.kamailio.org > http://lists.kamailio.org/cgi-bin/mailman/listinfo/users >

1 0

[Serusers] Help with SIPSAK
by Steven C. Blair 11 Dec '08

11 Dec '08

I currently use sipsak 0.8.8 for a variety of tasks however I now need to use sipsak to start, maintain and end a SIP session. I'd like to send an INVITE, authenticate, check for a 200 OK, send a refer then a bye to remove myself from the call. I cannot get this to work. I've tried sipsak with the -l, -G, -u, -a and -s options in various combinations without success. Does anyone have any thoughts on how I can accomplish this task? Thanks,Steve Senior Network Engineer, Information Systems and Computing Networking and Telecommunications , Suite 221A /6228 University of Pennsylvania Voice:215-573-8396 FAX:215-898-9348

2 2

[Serusers] Help with SIPSAK
by Steven C. Blair 11 Dec '08

11 Dec '08

I currently use sipsak 0.8.8 for a variety of tasks however I now need to use sipsak to start, maintain and end a SIP session. I'd like to send an INVITE, authenticate, check for a 200 OK, send a refer then a bye to remove myself from the call. I cannot get this to work. I've tried sipsak with the -l, -G, -u, -a and -s options in various combinations without success. Does anyone have any thoughts on how I can accomplish this task? Thanks,Steve Senior Network Engineer, Information Systems and Computing Networking and Telecommunications , Suite 221A /6228 University of Pennsylvania Voice:215-573-8396 FAX:215-898-9348

1 0

[Serusers] ser routing
by Netadmin 11 Dec '08

11 Dec '08

Hello, I want to route a phone number to different routes on different hours. If the time is later then 17 i'll route to route(1), else route to route(2). How can i do this? is there a way to get time in ser.cfg? Or i need to make a separate module? Thanks.

5 6

[Kamailio-Users] is_present_hf function
by Antonio Reale 10 Dec '08

10 Dec '08

Hi all, I have a problem with the is_present_hf function from TEXTOPS module. In the script (openser 1.2.3-notls) I have: --- if(is_present_hf("Proxy-Authorization")) { xlog("L_ERR", "Proxy-Authorization header present\n"); consume_credentials(); } --- When the proxy receives the BYE message I see in the log: Dec 10 16:00:54 sipsvr /usr/sbin/openser[12846]: Proxy-Authorization header present Dec 10 16:00:54 sipsvr /usr/sbin/openser[12846]: consume_credentials(): No authorized credentials found (error in scripts) Tracing the call I don't see any Proxy-Authorization header in the BYE message. Why the function is_present_hf returns true? Attached you will find debug messages from Openser/Kamailio and the BYE. I see the problem using Kapanga softphone, but the same problem occurs in production environment with different CPEs (for instance Linksys SPA2102). The strange thing is that it occurs only when kapanga is the caller (and hungup) and not when it is the callee (and hungup). Using wireshark I see that the BYE is the same in both situation. How can I debug this problem? Thanks a lot. Regards, Antonio.

3 2

[Serusers] Issue with auth_identity
by jerome.herve＠orange-ftgroup.com 10 Dec '08

10 Dec '08

Hello, I am trying to put in place auth_identity between 2 SER proxies and it doesn't work well. The first one manages to add identity and identity_info fields and to send the INVITE to the other proxy. But when the other proxy receive the message and does his tests there is an issue. It sends back a 436 Bad Identity Info. The error happens during the "vrfy_get_certificate" function (function which downloads the certificate thanks to identity_info URL). On my proxy logs, I can see this : AUTH_IDENTITY:retrieve_x509: DER Certificate error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag I really don't know what to do, do you have any idea? Thanks, Regards, Jérôme HERVE

2 2

[Kamailio-Users] preparing kamailio-1.4.3, planning for 1.5.0
by Henning Westerholt 10 Dec '08

10 Dec '08

Hi, according to our last IRC meeting [1] we want to release a minor release for the 1.4 branch in the next days. We've did already over 40 changes in this branch, many of them for important bugs, so i propose the next thursday, the 11th december as the date for 1.4.3. So if you have any important backports or other fixes that should go into this release, please commit them until this day. While already on the release topic, the code freeze period for the 1.5.0 release will be start in the mid of Januar, roughly in about 6 weeks from now. So if you like to contribute something that should be included in this release, please commit it to our repository or upload the patch to the tracker for review. Already finished features and the roadmap can be found as usual in our wiki at [2, 3]. If you like to give the new features a try, then you find prebuild packages for several debian releases here [4]. Please report any bugs you find to our developer list. Best regards, Henning [1] http://www.kamailio.org/mos/view/News/NewsItem/IRC-Devel-Meeting-Summary---… [2] http://www.kamailio.org/dokuwiki/doku.php/features:new-in-1.5.x [3] http://www.kamailio.org/dokuwiki/doku.php/roadmap:1.5.x [4] devel.kamailio.org

5 8

[Kamailio-Users] important: gflags, options, uri module functionality moved
by Henning Westerholt 09 Dec '08

09 Dec '08

Hi, in order to reduce the number of modules that needs to be maintained we integrated several small modules into existing ones. This applies only to the devel (trunk) version. No functionality was removed, it can be now just found in a different place. 1. gflags module The functionality of this module was integrated into the cfgutils module. The internal functionality, function names and MI commands are the same, the parameter “initial” was renamed to “initial_gflags”. 2. options module The functionality of this module was integrated into the siputils module. The function name was not changed, all parameters were prefixed with the "options_” string. 3. uri module The functionality of this module was integrated into the siputils module. The function names were not changed, internal functionality is the same. So starting from the release 1.5 you'll need to fix your "loadmodule" statements and some parameter prefixes in your config if you use one of the mentioned modules. Documentation for the functions can be found in the usual place [1, 2]. Cheers, Henning [1] http://www.kamailio.org/docs/modules/devel/cfgutils.html [2] http://www.kamailio.org/docs/modules/devel/siputils.html

4 10

[Kamailio-Users] no free tcp receiver
by Gawith 09 Dec '08

09 Dec '08

Hi all, My OpenSER system seems to run out of TCP handlers all the time. It looks to me that I need two child processes for each local IP and peer combination, because to and back communication do not use the same TCP channel. I have a lot of TCP clients which would lead to more than 100 child processes. Does it make sense to reduce tcp_connection_lifetime? This would increase TCP overhead, but would allow me to have fewer child processes, right? Any help is welcome. Thanks guys! Regards

2 8

[Kamailio-Users] Xcap-diff publishing?
by John Stalh 09 Dec '08

09 Dec '08

Hello, I am trying to setup Kamailio to publish xcap-diff payload to a client. However, the xcap-diff event is not supported (receives a SIP 489 answer), even though it says Kamailio supports it. What am I missing? How does the mi_xmlrpc module works? For reference, I use Openxcap and it is correctly (theorically at least) set to use Kamailio. Best regards, John

2 1

[Kamailio-Users] new features: $T_req(pv) and $T_rpl(pv)
by Daniel-Constantin Mierla 09 Dec '08

09 Dec '08

Hello, the TM module introduces two new features: - access to SIP request attributes while processing a reply belonging to same transaction - access to SIP reply attributes while processing a request belonging to same transaction Functionalities come as pseudo-variables, $T_req(pv) and $T_rpl(pv) - where pv can be any pseudo-variable, check documents at: http://www.kamailio.org/dokuwiki/doku.php/pseudovariables:devel#tm_module_p… The new pseudo-variables can be used: - in failure_route to get the attributes of the reply causing the failure route. You can take decisions what to do with the request based on reply details - in onreply_route to get the attributes of the request. you can take decision what to do with the reply based on request attributes. - in acc to store data from reply - in C code (modules) Note that couple of PV are disabled for these cases (PV will return null) - these are the PV that alter/depend on the context of the processed message, like $Ts, $Tf (but you can use $TS and $TF), $time, destination set attributes. The $avp() will be current avps, as they are stored in a global list. Also, in case there is a timeout or other reply generated by kamailio itself, $T_rpl(pv) will return null as there is no real reply structure behind. Example, print the source ip of the reply in failure route: failure_route[1] { xlog("reply received from: $T_rpl($si)\n"); } Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

1 0

[Serusers] How to use the variable "src_ip"?
by Raman Chan 09 Dec '08

09 Dec '08

In the ser.cfg, we can output src_ip(%is) with "xlog" but how can I import this variable into the module of myself? Thanks, Raman

1 0

[Serusers] SEMS 1.1.0 rc1 available
by Stefan Sayer 08 Dec '08

08 Dec '08

Hello, as promised there is a first release candidate for the 1.1 release of the SIP Express Media Server available: Source: http://ftp.iptel.org/pub/sems/1.1/rc1/src/sems-1.1.0-rc1.tar.gz Debian packages: http://ftp.iptel.org/pub/sems/1.1/rc1/packages/debian/ This RC1 was created from SVN rev 1193. With the version 1.1 SEMS gets - DSM state machine scripting (it's cool!) - an (experimental) ISDN gateway module - binrpc: MT (SER->) and connection pool (->SER) - MT xmlrpc server - controlled server shutdown - improved logging - g722 in 8khz compat mode - out of dialog request handling for modules & dialogs without sessions - audio file autorewind, AmAudio mixing - SIP and media IP separately configurable - UID/DID support for voicemail/-box/annrecorder - and quite some bugs and mem leaks fixed, documentation, etc. You are welcome to test this release candidate, and give feedback on the SEMS mailing list (sems(a)iptel.org), the semsdev list (semsde(a)iptel.org), or the bug tracker: http://tracker.iptel.org. Thanks to all contributions and patches, this time from Stefan Sayer, Raphael Coeffic, Grzegorz Stanislawski, Bogdan Pintea, Greger Teigre, Rui Jin Zheng, Alfred E Heggestad, Juha Heinanen, Peter Lemenkov, Robert Szokovacs, Jeremy A, Alex Gradinar Best Regards Stefan Sayer -- Stefan Sayer VoIP Services stefan.sayer(a)iptego.com www.iptego.com IPTEGO GmbH Am Borsigturm 40 13507 Berlin Germany Amtsgericht Charlottenburg, HRB 101010 Geschaeftsfuehrer: Alexander Hoffmann

1 0

Re: [Kamailio-Users] Kamailio in Red Hat 4 with mysql and carrierroute]
by Juan Asencio 08 Dec '08

08 Dec '08

Henning Westerholt wrote: > On Monday 08 December 2008, Juan Asencio wrote: > >> Hi, I'm trying to install from source Kamailio on Red Hat 4, and I need >> to include mysql as a database and carrierroute. >> >> When I check on the directory of modules, I can't see mysql.so or >> carrierroute.so, how can I include them? >> >> Best regards, >> > > Hi Juan, > > have you compiled and installed the db_mysql and the carrierroute module? > There excluded in the default installation, because they need some extra > libraries. > > Cheers, > > Henning > Hi again, I have another question :) I have download the kamailio-1.4.1-notls_linux_i386.tar.gz Put it on the directory: /usr/src and there I did: tar zxvf kamai...tar.gz A list of directories and files are created, but I can't find the Makefile and I can't "make all" or "make" anything. In my small Linux experience, when I tar xvf... something.tar.gz a directory of something is created and then I usually can find the makefile there. Why I can't find it now? I'm trying to follow the instructions on http://www.kamailio.org/mos/view/Installation-Notes/ but I can't do it. Can anyone please give some suggestions? Thanks in advance, Juan.-

1 1

[Kamailio-Users] Kamailio in Red Hat 4 with mysql and carrierroute
by Juan Asencio 08 Dec '08

08 Dec '08

Hi, I'm trying to install from source Kamailio on Red Hat 4, and I need to include mysql as a database and carrierroute. When I check on the directory of modules, I can't see mysql.so or carrierroute.so, how can I include them? Best regards, Juan.-

2 1

[Kamailio-Users] using "substr()" function from TEXTOPS in "onreply_route" block
by Alex R.S.M 08 Dec '08

08 Dec '08

Hi, I was wondering if anyone has used "substr()" function from TEXTOPS in "onreply_route" block. This function works fine in "route" and "branch_route" blocks. However, it creates duplicate fields (instead of substituting) when being used in "onreply_route" blocks. I need to modify FROM field in "onreply_route" block. As far as I know, "uac_replace_from()" function works only in request_route block, so my only option is to use "substr()". Thanks, Alex R _________________________________________________________________ Proud to be a PC? Show the world. Download the “I’m a PC” Messenger themepack now. hthttp://clk.atdmt.com/MRT/go/119642558/direct/01/

3 3

[Kamailio-Users] Route-problem, no 487 sent
by Magnus Burman 08 Dec '08

08 Dec '08

Something fishy is going on with my routing. If my SIP UA (91.XXX.XXX.80) hangs up before the receiving end (pstn on 212.YYY.YYY.84) answers, it keeps ringing forever. Below is my routing in regards to CANCEL and the ngrep output. If I understand things correctly, I should send a 487 Request Terminated back to the initiating UA (sip), and I would get a 487 Request Terminated from the pstn provider. I'm not sending the 487 to the UA, and I'm guessing I close the session before my pstn provider sends one to me, so I don't see it with ngrep? The big question is ofcourse what I need to do to get on track, sending the appropriate 487? route: -- #CANCEL processing if (is_method("CANCEL") || is_method("ACK")) { if (t_check_trans()) { setflag(1); if(!t_relay()) { sl_reply_error(); } } exit; }; ngrep output, comments starting with #: -- U 91.XXX.XXX.80:5060 -> 91.ZZZ.ZZZ.9:5060 CANCEL sip:6--------@91.ZZZ.ZZZ.9 SIP/2.0 Via: SIP/2.0/UDP 91.XXX.XXX.80:5060;branch=z9hG4bK1e22091bbd2d0a9b9e0f8de6553d2c27 From: "349--------"<sip:user1@91.ZZZ.ZZZ.9>;tag=XG6525p2-b915854d-1373157639 To: <sip:6--------@91.ZZZ.ZZZ.9> Call -ID: 6C8F-F261-374702698-E353C7B05C17-0006(a)91.XXX.XXX.80 CSeq: 10 CANCEL Max-Forwards: 70 User-Agent: XAVi/XG6525p2-1.6.7 Content-Length: 0 U 91.ZZZ.ZZZ.9:5060 -> 91.XXX.XXX.80:5060 SIP/2.0 200 canceling Via: SIP/2.0/UDP 91.XXX.XXX.80:5060;branch=z9hG4bK1e22091bbd2d0a9b9e0f8de6553d2c27 From: "349--------"<sip:user1@91.ZZZ.ZZZ.9>;tag=XG6525p2-b915854d-1373157639 To: <sip:6--------@91.ZZZ.ZZZ.9>;tag=bbd8f31c58bc6a3266ec5509a254d55b-cb96 Call-ID: 6C8F-F261-374702698-E353C7B05C17-0006(a)91.XXX.XXX.80 CSeq: 10 CANCEL Server: Kamailio (1.4.1-notls (i386/linux)) Content-Length: 0 # 487 Request Terminated from 91.ZZZ.ZZZ.9 to 91.XXX.XXX.80 ?? U 91.ZZZ.ZZZ.9:5060 -> 212.YYY.YYY.84:5060 CANCEL sip:346--------@212.YYY.YYY.84 SIP/2.0 Via: SIP/2.0/UDP 91.ZZZ.ZZZ.9;branch=z9hG4bKe214.208c19e6.0 From: "349--------"<sip:user1@91.ZZZ.ZZZ.9>;tag=XG6525p2-b915854d-1373157639 Call-ID: 6C8F-F261-374702698-E353C7B05C17-0006(a)91.XXX.XXX.80 To: <sip:6--------@91.ZZZ.ZZZ.9> CSeq: 10 CANCEL Max-Forwards: 70 User-Agent: Kamailio (1.4.1-notls (i386/linux)) Content-Length: 0 U 212.YYY.YYY.84:5060 -> 91.ZZZ.ZZZ.9:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 91.ZZZ.ZZZ.9:5060;branch=z9hG4bKe214.208c19e6.0 To: <sip:6--------@91.ZZZ.ZZZ.9>;tag=a439d513 From: "349--------" <sip:user1@91.ZZZ.ZZZ.9>;tag=XG6525p2-b915854d-1373157639 Call-ID: 6C8F-F261-374702698-E353C7B05C17-0006(a)91.XXX.XXX.80 CSeq: 10 CANCEL User-Agent: ENS2.2.122-IS2 Content-Length: 0 # 487 Request Terminated from 212.YYY.YYY.84 to 91.ZZZ.ZZZ.9 ?? Best Regards, Magnus

1 0

[Kamailio-Users] new feature: re.subst transformation
by Daniel-Constantin Mierla 08 Dec '08

08 Dec '08

Hello, using the latest development work and the newest pseudo-variable&transformation framework (http://lists.kamailio.org/pipermail/users/2008-December/020918.html), the textops module offers a new class of transformation for regular expressions. By now, it implements {re.subst,expression} - ability to do Perl-like substitution of string value pseudo-variables: http://www.kamailio.org/dokuwiki/doku.php/transformations:devel#re.subst_ex… Here is an example to extract username part from R-URI using this transformation: $var(user) = $(ru{re.subst,/^sip:(.*)@(.*)/\1/}); Now, the subst operation becomes very handy, old tricks to copy in R-URI and use subst*() functions from textops module, or copy in avps and use avpops module are no longer required. This implementation can be used as example by developers to learn how to export new transformations from other modules. Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

1 0

[Kamailio-Users] important: transformations moved from core to pv module
by Daniel-Constantin Mierla 08 Dec '08

08 Dec '08

Hello, the pseudo-variable and transformation framework in core has been completed for upcoming v1.5.0 of Kamailio (OpenSER). The core has now only API to register, parse name, evaluate and set values for PV&T. All specific implementations have moved to PV module: http://kamailio.org/docs/modules/devel/pv.html The current architecture provides a flexible way to enhance the number PV&T available in config file without affecting the stability and the performance of core and main modules. As this number increased a lot, and will grow more, the API changed the indexing from a list to a hash table, offering faster lookup and quicker shorter up time. With this work done, a new functionality is available for developers: - they can export new transformations from their module. As example, check the pv or textops (new transformation to be announced in separate message) modules. The system is simple, you have to implement a function to parse the name of transformation and its parameter, plus a function to evaluate a transformation. Now core got some clean up, not that fat anymore, implementation of about 100 pseudo-variables and over 30 transformations was moved out (couple of thousands lines of code). This work is part of the efforts to increase the stability, performance and flexibility of the core, so that specific implementations do not affect typical use cases. As final note, remember to load the pv module from now on if you work with/need old core pseudo-variables or transformations. Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

1 0

[Kamailio-Users] new module: sqlops - sql operations
by Daniel-Constantin Mierla 08 Dec '08

08 Dec '08

Hello, the devel version (to be released as 1.5.0 in Q1 2009) includes now a new module: sqlops. It can be used to do raw sql queries in config file and play with the result data. Key features: * /many DB connections/ - the module can connect to many databases on different servers using different DB driver modules (mysql, postgres, ...) at the same time. * /many DB results/ - the module can store many results of different SQL queries in separate structures at the same time. Thus is possible to work in parallel with several DB results. * /access via pseudo-variables/ - the content of SQL query result is accessible via pseudo-variables. * /array indexes/ - fast access to result values via array possition: [row,column]. * /persistence in process space/ - a result can be used many times in same worker process. Query once, use many times. Here is an example of fetching and printing the content of a table: ... modparam("sqlops","sqlcon","ca=>mysql://openser:abc@localhost/openser") ... sql_query("ca", "select * from domain", "ra"); xlog("rows: $dbr(ra=>rows) cols: $dbr(ra=>cols)\n"); if($dbr(ra=>rows)>0) { $var(i) = 0; while($var(i)<$dbr(ra=>cols)) { xlog("--- SCRIPT: column[$var(i)] = $dbr(ra=>colname[$var(i)])\n"); $var(i) = $var(i) + 1; } $var(i) = 0; while($var(i)<$dbr(ra=>rows)) { $var(j) = 0; while($var(j)<$dbr(ra=>cols)) { xlog("[$var(i),$var(j)] = $dbr(ra=>[$var(i),$var(j)])\n"); $var(j) = $var(j) + 1; } $var(i) = $var(i) + 1; } } sql_result_free("ra"); ... Other advantages than the ones listed above against avp_db_query(): - does not mess up fields position if the value in db is null - use private memory, no locking - does not iterate through linked (avp) list to get each field, direct reference to each data structure in result array, thus much faster. More info at: http://kamailio.org/docs/modules/devel/sqlops.html Testing and feedback is appreciated. Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

1 0

Re: [Serusers] Deadly embrace with rtpproxy - Is it necessary? Can it be turned off?
by Frank Durda IV 06 Dec '08

06 Dec '08

Greger Viken Teigre wrote: > Hi Frank, the behavior of rtpproxy is like that because you want to send > rtp back on source port if it has changed from the sdp, which often > happens > behind a nat. > Have you tried changing active media in sdp? The gateway has the same > active media mode as rtpproxy. > g-) I don't believe I understand what you are asking re: active media. Are you talking about some control I can set in SER or rtpproxy? Because those are the only knobs available to me. The company sending the call to us doesn't want to change settings on their equipment to accomodate what they consider to be our incompatibility (what rtpproxy is doing), as what they are doing (not sending audio until they receive audio from us) isn't a problem when they send calls to other carriers. If you are suggesting something I have SER patch into the 183/200 SDP payload to trick the calling system to send audio without waiting to see some audio from us, what exactly are you suggesting be added and how would that be done? As a FYI, the PSTN gateway switch behind our SER system has virtually no SIP controls, as the first thing it does is make the call look as much like a TDM call as possible, right down to assigning a pseudo trunk number for the call to be carried in. Of course, this is the device that is happily sending RTP audio which rtpproxy is throwing away, so I don't think I can fix the problem from that side even if there was a knob to change something since this side is already working. And yes, you can create this same problem that I am reporting by having the audio for a call pass between two SER systems with rtpproxy on both with no NAT present whatsoever (no re-routing of audio, just bridging isolated networks). Neither rtpproxy daemon will blink until the other does, and so audio never works. This has got to be wrong. I'll point out that when I reported this a month of two ago, someone on the list came out and said rtpproxy does not do what I was reporting, can't do this, always passes audio in a given direction the instant the SDP payload for that direction passes through SER. I don't find that to be the case and the demonstration proves that the behavior is different. I also don't understand the comment above about sending back to the source port. From what I can see, rtpproxy opens four separate ports, two on each interface, one for incoming and one for outgoing on each I would assume. If not, then that would be a different bug as rtpproxy is opening twice the number of ports it actually needs. (I think it is using all four in the two-interface mode.) Please clarify what you are saying/suggesting if you can. Examples appreciated. Thanks.

2 1

[Kamailio-Users] Kamalio Support for RFC 3323 " Privacy"
by ingdavidcespedes＠cable.net.co 05 Dec '08

05 Dec '08

Hi Is there any way (special module, or something like that) to implement RFC 3323 in Kamailio. Or do I have to do it manually, by changing the header fields that require privacy and change them for something like ("Anonymous" <sip:anonymous@anonymous.invalid>) and keep the relation of this new URI with the original one, in a separate table of my database?. How can I do this in a more easy way?. David Cespedes

4 4

[Kamailio-Users] Interfacing error with textdb module
by Dhaval Shah 05 Dec '08

05 Dec '08

Hi, I am new to SIP - Kamailio. I am trying to run Kamailion (version 1.4.2 Latest) SIP server with authantication using dbtext module. I have compiled and installed Kamalio and required modules sucessfully. When I run the Kamalio after configuration I received error from "find_mod_export". ---------------------------------------------------------------------------------------------------------------------------------------------------------- "Debug log" Dec 5 19:33:42 [24301] DBG:core:yyparse: loading module //lib/kamailio/modules/db_text.so Dec 5 19:33:42 [24301] DBG:core:yyparse: loading module //lib/kamailio/modules/sl.so Dec 5 19:33:42 [24301] DBG:core:yyparse: loading module //lib/kamailio/modules/tm.so Dec 5 19:33:42 [24301] DBG:core:register_module: register_pv: tm Dec 5 19:33:42 [24301] DBG:core:pv_add_extra: extra items list is not initialized Dec 5 19:33:42 [24301] DBG:core:yyparse: loading module //lib/kamailio/modules/rr.so Dec 5 19:33:42 [24301] DBG:core:yyparse: loading module //lib/kamailio/modules/maxfwd.so Dec 5 19:33:42 [24301] DBG:core:yyparse: loading module //lib/kamailio/modules/usrloc.so Dec 5 19:33:42 [24301] DBG:core:yyparse: loading module //lib/kamailio/modules/registrar.so Dec 5 19:33:42 [24301] DBG:core:yyparse: loading module //lib/kamailio/modules/textops.so Dec 5 19:33:42 [24301] DBG:core:yyparse: loading module //lib/kamailio/modules/mi_fifo.so Dec 5 19:33:42 [24301] DBG:core:yyparse: loading module //lib/kamailio/modules/uri_db.so Dec 5 19:33:42 [24301] DBG:core:yyparse: loading module //lib/kamailio/modules/uri.so Dec 5 19:33:42 [24301] DBG:core:yyparse: loading module //lib/kamailio/modules/xlog.so Dec 5 19:33:42 [24301] DBG:core:register_module: register_pv: xlog Dec 5 19:33:42 [24301] DBG:core:yyparse: loading module //lib/kamailio/modules/acc.so Dec 5 19:33:42 [24301] DBG:core:yyparse: loading module //lib/kamailio/modules/auth.so Dec 5 19:33:42 [24301] DBG:core:yyparse: loading module //lib/kamailio/modules/auth_db.so Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: db_text matches module db_text Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: found <db_mode> in module db_text [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: mi_fifo matches module mi_fifo Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: found <fifo_name> in module mi_fifo [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: rr matches module rr Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: found <enable_full_lr> in module rr [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: rr matches module rr Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: found <append_fromtag> in module rr [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: registrar matches module registrar Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: found <method_filtering> in module registrar [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: uri_db matches module uri_db Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: found <use_uri_table> in module uri_db [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: uri_db matches module uri_db Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: found <db_url> in module uri_db [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: acc matches module acc Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: found <early_media> in module acc [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: acc matches module acc Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: found <report_ack> in module acc [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: acc matches module acc Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: found <report_cancels> in module acc [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: acc matches module acc Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: found <detect_direction> in module acc [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: acc matches module acc Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: found <failed_transaction_flag> in module acc [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: acc matches module acc Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: found <log_flag> in module acc [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: acc matches module acc Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: found <log_missed_flag> in module acc [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: acc matches module acc Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: found <db_flag> in module acc [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: acc matches module acc Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: found <db_missed_flag> in module acc [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: usrloc matches module usrloc Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: found <db_mode> in module usrloc [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: usrloc matches module usrloc Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: found <db_mode> in module usrloc [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: usrloc matches module usrloc Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: found <db_url> in module usrloc [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: auth_db matches module auth_db Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: found <calculate_ha1> in module auth_db [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: auth_db matches module auth_db Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: found <password_column> in module auth_db [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: auth_db matches module auth_db Dec 5 19:33:42 [24301] DBG:core:set_mod_param_regex: found <db_url> in module auth_db [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <mf_process_maxfwd_header>(1) in module maxfwd [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <sl_send_reply>(2) in module sl [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <has_totag>(0) in module uri [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <loose_route>(0) in module rr [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <is_method>(1) in module textops [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <is_method>(1) in module textops [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <t_check_trans>(0) in module tm [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <t_relay>(0) in module tm [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <sl_send_reply>(2) in module sl [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <is_method>(1) in module textops [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <t_check_trans>(0) in module tm [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <t_relay>(0) in module tm [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <t_check_trans>(0) in module tm [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <proxy_authorize>(2) in module auth_db [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <proxy_challenge>(2) in module auth [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <check_from>(0) in module uri_db [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <sl_send_reply>(2) in module sl [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <consume_credentials>(0) in module auth [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <is_method>(1) in module textops [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <record_route>(0) in module rr [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <is_method>(1) in module textops [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <append_hf>(1) in module textops [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <is_method>(1) in module textops [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <sl_send_reply>(2) in module sl [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <is_method>(1) in module textops [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <www_authorize>(2) in module auth_db [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <www_challenge>(2) in module auth [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <check_to>(0) in module uri_db [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <sl_send_reply>(2) in module sl [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <save>(1) in module registrar [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <sl_reply_error>(0) in module sl [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <sl_send_reply>(2) in module sl [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <lookup>(1) in module registrar [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <t_newtran>(0) in module tm [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <t_reply>(2) in module tm [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <sl_send_reply>(2) in module sl [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <is_method>(1) in module textops [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <t_on_branch>(1) in module tm [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <t_on_reply>(1) in module tm [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <t_on_failure>(1) in module tm [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <t_relay>(0) in module tm [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <sl_reply_error>(0) in module sl [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <xlog>(1) in module xlog [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <xlog>(1) in module xlog [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:find_cmd_export_t: found <t_was_cancelled>(0) in module tm [//lib/kamailio/modules/] Dec 5 19:33:42 [24301] DBG:core:socket2str: <udp:127.0.0.1:5060> Dec 5 19:33:42 [24301] WARNING:core:fix_socket_list: could not rev. resolve 192.168.40.35 Dec 5 19:33:42 [24301] DBG:core:socket2str: <udp:192.168.40.35:5060> Dec 5 19:33:42 [24301] DBG:core:socket2str: <tcp:127.0.0.1:5060> Dec 5 19:33:42 [24301] WARNING:core:fix_socket_list: could not rev. resolve 192.168.40.35 Dec 5 19:33:42 [24301] DBG:core:socket2str: <tcp:192.168.40.35:5060> Listening on udp: 127.0.0.1 [127.0.0.1]:5060 udp: 192.168.40.35 [192.168.40.35]:5060 tcp: 127.0.0.1 [127.0.0.1]:5060 tcp: 192.168.40.35 [192.168.40.35]:5060 Aliases: tcp: localhost:5060 udp: localhost:5060 Dec 5 19:33:42 [24301] WARNING:core:main: no fork mode and more than one listen address found(will use only the first one) Dec 5 19:33:42 [24301] DBG:core:fm_malloc_init: F_OPTIMIZE=16384, /ROUNDTO=2048 Dec 5 19:33:42 [24301] DBG:core:fm_malloc_init: F_HASH_SIZE=2067, fm_block size=16560 Dec 5 19:33:42 [24301] DBG:core:fm_malloc_init: params (0xb5fdc000, 33554432), start=0xb5fdc000 Dec 5 19:33:42 [24301] DBG:core:shm_mem_init_mallocs: success Dec 5 19:33:42 [24301] INFO:core:init_tcp: using epoll_lt as the TCP io watch method (auto detected) Dec 5 19:33:42 [24301] DBG:core:set_core_dump: core dump limits set to 4294967295 Dec 5 19:33:42 [24301] NOTICE:core:main: version: kamailio 1.4.2-notls (i386/linux) Dec 5 19:33:42 [24301] INFO:core:main: using 32 Mb shared memory Dec 5 19:33:42 [24301] INFO:core:main: using 1 Mb private memory per process Dec 5 19:33:42 [24301] DBG:core:add_avp_galias: registering <serial_branch> for avp id <16725044> Dec 5 19:33:42 [24301] DBG:core:init_stats_collector: statistics manager successfully initialized Dec 5 19:33:42 [24301] DBG:core:init_mod: initializing module db_text Dec 5 19:33:42 [24301] DBG:core:init_mod: initializing module sl Dec 5 19:33:42 [24301] INFO:sl:mod_init: Initializing StateLess engine Dec 5 19:33:42 [24301] DBG:core:MD5StringArray: MD5 calculated: f8f2ab2c1295e90ed7dbb499b30f44b2 Dec 5 19:33:42 [24301] DBG:core:init_mod: registering stats for sl Dec 5 19:33:42 [24301] DBG:core:init_mod: initializing module tm Dec 5 19:33:42 [24301] INFO:tm:mod_init: TM - initializing... Dec 5 19:33:42 [24301] DBG:tm:init_callid: Call-ID initialization: '35cb5f3b' Dec 5 19:33:42 [24301] DBG:tm:lock_initialize: lock initialization started Dec 5 19:33:42 [24301] DBG:core:MD5StringArray: MD5 calculated: 533cb9e91f4b999cf76861cbb9ed54ed Dec 5 19:33:42 [24301] DBG:core:MD5StringArray: MD5 calculated: bbd8f31c58bc6a3266ec5509a254d55b Dec 5 19:33:42 [24301] DBG:core:init_mod: registering stats for tm Dec 5 19:33:42 [24301] DBG:core:init_mod: register MI for tm Dec 5 19:33:42 [24301] DBG:core:init_mod: initializing module rr Dec 5 19:33:42 [24301] DBG:rr:mod_init: rr - initializing Dec 5 19:33:42 [24301] DBG:core:init_mod: initializing module maxfwd Dec 5 19:33:42 [24301] INFO:maxfwd:mod_init: initializing... Dec 5 19:33:42 [24301] DBG:core:init_mod: initializing module usrloc Dec 5 19:33:42 [24301] DBG:usrloc:mod_init: initializing Dec 5 19:33:42 [24301] INFO:usrloc:ul_init_locks: locks array size 512 Dec 5 19:33:42 [24301] DBG:core:find_mod_export: <db_bind_api> in module db_dbtext not found Dec 5 19:33:42 [24301] DBG:core:db_bind_mod: using export interface to bind db_dbtext Dec 5 19:33:42 [24301] DBG:core:find_mod_export: <db_use_table> in module db_dbtext not found Dec 5 19:33:42 [24301] DBG:core:find_mod_export: <db_init> in module db_dbtext not found Dec 5 19:33:42 [24301] DBG:core:find_mod_export: <db_close> in module db_dbtext not found Dec 5 19:33:42 [24301] DBG:core:find_mod_export: <db_query> in module db_dbtext not found Dec 5 19:33:42 [24301] DBG:core:find_mod_export: <db_fetch_result> in module db_dbtext not found Dec 5 19:33:42 [24301] DBG:core:find_mod_export: <db_raw_query> in module db_dbtext not found Dec 5 19:33:42 [24301] DBG:core:find_mod_export: <db_free_result> in module db_dbtext not found Dec 5 19:33:42 [24301] DBG:core:find_mod_export: <db_insert> in module db_dbtext not found Dec 5 19:33:42 [24301] DBG:core:find_mod_export: <db_delete> in module db_dbtext not found Dec 5 19:33:42 [24301] DBG:core:find_mod_export: <db_update> in module db_dbtext not found Dec 5 19:33:42 [24301] DBG:core:find_mod_export: <db_replace> in module db_dbtext not found Dec 5 19:33:42 [24301] DBG:core:find_mod_export: <db_last_inserted_id> in module db_dbtext not found Dec 5 19:33:42 [24301] DBG:core:find_mod_export: <db_insert_update> in module db_dbtext not found Dec 5 19:33:42 [24301] ERROR:core:db_check_api: module db_dbtext does not export db_use_table function Dec 5 19:33:42 [24301] ERROR:usrloc:mod_init: failed to bind database module Dec 5 19:33:42 [24301] ERROR:core:init_mod: failed to initialize module usrloc Dec 5 19:33:42 [24301] ERROR:core:main: error while initializing modules Dec 5 19:33:42 [24301] DBG:xlog:destroy: destroy module... Dec 5 19:33:42 [24301] DBG:tm:tm_shutdown: tm_shutdown : start Dec 5 19:33:42 [24301] DBG:tm:unlink_timer_lists: emptying DELETE list Dec 5 19:33:42 [24301] DBG:tm:tm_shutdown: emptying hash table Dec 5 19:33:42 [24301] DBG:tm:tm_shutdown: releasing timers Dec 5 19:33:42 [24301] DBG:tm:tm_shutdown: removing semaphores Dec 5 19:33:42 [24301] DBG:tm:tm_shutdown: destroying callback lists Dec 5 19:33:42 [24301] DBG:tm:tm_shutdown: tm_shutdown : done Dec 5 19:33:42 [24301] DBG:db_text:destroy: destroy ... Dec 5 19:33:42 [24301] DBG:core:shm_mem_destroy: Dec 5 19:33:42 [24301] DBG:core:shm_mem_destroy: destroying the shared memory lock --------------------------------------------------------------------------------------------------------------------------------------------------------------------- The kamailio.cfg is as given below: ####### Global Parameters ######### debug=3 log_stderror=no log_facility=LOG_LOCAL0 fork=yes children=4 /* uncomment the following lines to enable debugging */ debug=6 fork=no log_stderror=yes /* uncomment the next line to disable TCP (default on) */ #disable_tcp=yes /* uncomment the next line to enable the auto temporary blacklisting of not available destinations (default disabled) */ #disable_dns_blacklist=no /* uncomment the next line to enable IPv6 lookup after IPv4 dns lookup failures (default disabled) */ #dns_try_ipv6=yes /* uncomment the next line to disable the auto discovery of local aliases based on revers DNS on IPs (default on) */ #auto_aliases=no /* uncomment the following lines to enable TLS support (default off) */ #disable_tls = no #listen = tls:your_IP:5061 #tls_verify_server = 1 #tls_verify_client = 1 #tls_require_client_certificate = 0 #tls_method = TLSv1 #tls_certificate = "//etc/kamailio/tls/user/user-cert.pem" #tls_private_key = "//etc/kamailio/tls/user/user-privkey.pem" #tls_ca_list = "//etc/kamailio/tls/user/user-calist.pem" port=5060 /* uncomment and configure the following line if you want Kamailio to bind on a specific interface/port/proto (default bind on all available) */ #listen=udp:192.168.1.2:5060 ####### Modules Section ######## #set module path mpath="//lib/kamailio/modules/" /* uncomment next line for MySQL DB support */ #loadmodule "db_mysql.so" loadmodule "db_text.so" loadmodule "sl.so" loadmodule "tm.so" loadmodule "rr.so" loadmodule "maxfwd.so" loadmodule "usrloc.so" loadmodule "registrar.so" loadmodule "textops.so" loadmodule "mi_fifo.so" loadmodule "uri_db.so" loadmodule "uri.so" loadmodule "xlog.so" loadmodule "acc.so" /* uncomment next lines for MySQL based authentication support NOTE: a DB (like db_mysql) module must be also loaded */ loadmodule "auth.so" loadmodule "auth_db.so" /* uncomment next line for aliases support NOTE: a DB (like db_mysql) module must be also loaded */ #loadmodule "alias_db.so" /* uncomment next line for multi-domain support NOTE: a DB (like db_mysql) module must be also loaded NOTE: be sure and enable multi-domain support in all used modules (see "multi-module params" section ) */ #loadmodule "domain.so" /* uncomment the next two lines for presence server support NOTE: a DB (like db_mysql) module must be also loaded */ #loadmodule "presence.so" #loadmodule "presence_xml.so" # ----------------- setting module-specific parameters --------------- modparam("db_text", "db_mode", 0) # ----- mi_fifo params ----- modparam("mi_fifo", "fifo_name", "/tmp/kamailio_fifo") # ----- rr params ----- # add value to ;lr param to cope with most of the UAs modparam("rr", "enable_full_lr", 1) # do not append from tag to the RR (no need for this script) modparam("rr", "append_fromtag", 0) # ----- rr params ----- modparam("registrar", "method_filtering", 1) /* uncomment the next line to disable parallel forking via location */ # modparam("registrar", "append_branches", 0) /* uncomment the next line not to allow more than 10 contacts per AOR */ #modparam("registrar", "max_contacts", 10) # ----- uri_db params ----- /* by default we disable the DB support in the module as we do not need it in this configuration */ modparam("uri_db", "use_uri_table", 0) modparam("uri_db", "db_url", "") # ----- acc params ----- /* what sepcial events should be accounted ? */ modparam("acc", "early_media", 1) modparam("acc", "report_ack", 1) modparam("acc", "report_cancels", 1) /* by default ww do not adjust the direct of the sequential requests. if you enable this parameter, be sure the enable "append_fromtag" in "rr" module */ modparam("acc", "detect_direction", 0) /* account triggers (flags) */ modparam("acc", "failed_transaction_flag", 3) modparam("acc", "log_flag", 1) modparam("acc", "log_missed_flag", 2) /* uncomment the following lines to enable DB accounting also */ modparam("acc", "db_flag", 1) modparam("acc", "db_missed_flag", 2) # ----- usrloc params ----- modparam("usrloc", "db_mode", 0) /* uncomment the following lines if you want to enable DB persistency for location entries */ modparam("usrloc", "db_mode", 2) modparam("usrloc", "db_url", "dbtext:///usr/local/etc/kamailio/dbtext") # ----- auth_db params ----- /* uncomment the following lines if you want to enable the DB based authentication */ modparam("auth_db", "calculate_ha1", yes) modparam("auth_db", "password_column", "password") modparam("auth_db", "db_url", "dbtext:///usr/local/etc/kamailio/dbtext") #modparam("auth_db", "load_credentials", "") # ----- alias_db params ----- /* uncomment the following lines if you want to enable the DB based aliases */ #modparam("alias_db", "db_url", # "mysql://openser:openserrw@localhost/openser") # ----- domain params ----- /* uncomment the following lines to enable multi-domain detection support */ #modparam("domain", "db_url", # "mysql://openser:openserrw@localhost/openser") #modparam("domain", "db_mode", 1) # Use caching # ----- multi-module params ----- /* uncomment the following line if you want to enable multi-domain support in the modules (dafault off) */ #modparam("alias_db|auth_db|usrloc|uri_db", "use_domain", 1) # ----- presence params ----- /* uncomment the following lines if you want to enable presence */ #modparam("presence|presence_xml", "db_url", # "mysql://openser:openserrw@localhost/openser") #modparam("presence_xml", "force_active", 1) #modparam("presence", "server_address", "sip:192.168.1.2:5060") ####### Routing Logic ######## # main request routing logic route{ if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); exit; } if (has_totag()) { # sequential request withing a dialog should # take the path determined by record-routing if (loose_route()) { if (is_method("BYE")) { setflag(1); # do accounting ... setflag(3); # ... even if the transaction fails } route(1); } else { /* uncomment the following lines if you want to enable presence */ ##if (is_method("SUBSCRIBE") && $rd == "your.server.ip.address") { ## # in-dialog subscribe requests ## route(2); ## exit; ##} if ( is_method("ACK") ) { if ( t_check_trans() ) { # non loose-route, but stateful ACK; must be an ACK after a 487 or e.g. 404 from upstream server t_relay(); exit; } else { # ACK without matching transaction ... ignore and discard.\n"); exit; } } sl_send_reply("404","Not here"); } exit; } #initial requests # CANCEL processing if (is_method("CANCEL")) { if (t_check_trans()) t_relay(); exit; } t_check_trans(); # authenticate if from local subscriber (uncomment to enable auth) if (!(method=="REGISTER") && from_uri==myself) { if (!proxy_authorize("192.168.20.35", "subscriber")) { proxy_challenge("192.168.20.35", "0"); exit; } if (!check_from()) { sl_send_reply("403","Forbidden auth ID"); exit; } consume_credentials(); # caller authenticated } # record routing if (!is_method("REGISTER|MESSAGE")) record_route(); # account only INVITEs if (is_method("INVITE")) { setflag(1); # do accounting } if (!uri==myself) /* replace with following line if multi-domain support is used */ ##if (!is_uri_host_local()) { append_hf("P-hint: outbound\r\n"); # if you have some interdomain connections via TLS ##if($rd=="tls_domain1.net") { ## t_relay("tls:domain1.net"); ## exit; ##} else if($rd=="tls_domain2.net") { ## t_relay("tls:domain2.net"); ## exit; ##} route(1); } # requests for my domain /* uncomment this if you want to enable presence server and comment the next 'if' block NOTE: uncomment also the definition of route[2] from below */ ##if( is_method("PUBLISH|SUBSCRIBE")) ## route(2); if (is_method("PUBLISH")) { sl_send_reply("503", "Service Unavailable"); exit; } if (is_method("REGISTER")) { # authenticate the REGISTER requests (uncomment to enable auth) if (!www_authorize("192.168.20.35", "subscriber")) { www_challenge("192.168.20.35", "0"); exit; } if (!check_to()) { sl_send_reply("403","Forbidden auth ID"); exit; } if (!save("location")) sl_reply_error(); exit; } if ($rU==NULL) { # request with no Username in RURI sl_send_reply("484","Address Incomplete"); exit; } # apply DB based aliases (uncomment to enable) ##alias_db_lookup("dbaliases"); if (!lookup("location")) { switch ($retcode) { case -1: case -3: t_newtran(); t_reply("404", "Not Found"); exit; case -2: sl_send_reply("405", "Method Not Allowed"); exit; } } # when routing via usrloc, log the missed calls also setflag(2); route(1); } route[1] { # for INVITEs enable some additional helper routes if (is_method("INVITE")) { t_on_branch("2"); t_on_reply("2"); t_on_failure("1"); } if (!t_relay()) { sl_reply_error(); }; exit; } # Presence route /* uncomment the whole following route for enabling presence NOTE: do not forget to enable the call of this route from the main route */ ##route[2] ##{ ## if (!t_newtran()) ## { ## sl_reply_error(); ## exit; ## }; ## ## if(is_method("PUBLISH")) ## { ## handle_publish(); ## t_release(); ## } ## else ## if( is_method("SUBSCRIBE")) ## { ## handle_subscribe(); ## t_release(); ## } ## ## exit; ##} branch_route[2] { xlog("new branch at $ru\n"); } onreply_route[2] { xlog("incoming reply\n"); } failure_route[1] { if (t_was_cancelled()) { exit; } # uncomment the following lines if you want to block client # redirect based on 3xx replies. ##if (t_check_status("3[0-9][0-9]")) { ##t_reply("404","Not found"); ## exit; ##} # uncomment the following lines if you want to redirect the failed # calls to a different new destination ##if (t_check_status("486|408")) { ## sethostport("192.168.2.100:5060"); ## append_branch(); ## # do not set the missed call flag again ## t_relay(); ##} } ------------------------------------------------------------------------------------------------------------------------------------ Any suggestion will be very helpful. Thanks in advance. Dhaval

2 1

[Kamailio-Users] Port of kamailio to OpenBSD
by Don Jackson 05 Dec '08

05 Dec '08

I have motivated the creation of a port of kamailio to OpenBSD, the port creates binary packages, which can then be added via the pkg_add command. I could definitely use input and testing of this port from the kamailio community, if you are interested in running kamailio on OpenBSD, I could use your help! We also needed to create a port of radiusclient to support kamailio. Both ports are attached to the messages appended below. Don Begin forwarded message: > From: Don Jackson <don.jackson(a)gmail.com> > Date: November 18, 2008 11:16:22 AM PST > To: ports(a)openbsd.org > Subject: NEW: telephony/kamailio-1.4.2 (kamailio used to be called > OpenSER) > > > Tested on 4.4/amd64, definitely interested in more testing > > $ cat DESCR-main > > KAMAILIO (OpenSER) is a mature and flexible open source SIP server > (RFC3261). > It can be used on systems with limitted resources as well as on > carrier grade > servers, scaling to up to thousands call setups per second. It is > written in > pure C for Unix/Linux-like systems with architecture specific > optimizations to > offer high performances. It is customizable, being able to feature > as fast load > balancer; SIP server flavours: registrar, location server, proxy > server, > redirect server; gateway to SMS/XMPP; or advanced VoIP application > server. > > Begin forwarded message: > From: Don Jackson <don.jackson(a)gmail.com> > Date: November 18, 2008 11:11:53 AM PST > To: ports(a)openbsd.org > Subject: NEW: net/radiusclient-ng-0.5.6 > > > This port is needed for the kamailio/openser port (see subsequent > email) > > Tested on 4.4/amd64, definitely interested in more testing. > > $ cat pkg/DESCR > > Purpose of this project is to build portable, easy-to-use and standard > compliant library suitable for developing free and commercial software > that need support for a RADIUS protocol (RFCs 2138 and 2139). > > > >

2 3

[Kamailio-Users] reply_route is not called though a response is received
by Aurelien Grimaud 05 Dec '08

05 Dec '08

Hi, I am running a rather old version of openser, but since in a production context, I cannot upgrade anytime I want to catch up with newer releases. I searched bugs and googled for my problem without any result. There it is. I have a module with functions beginning with mn_ mn_received handle any incoming request and prints it out. my module has a callback on response which prints out responses. My configuration file is something like // handle register mn_received() ; record_route() ; if ( method=="INVITE") { t_on_failure(ROUTE_INVITE) ; t_on_reply(ROUTE_INVITE) ; } Then the request is t_relayed to destination. The onreply_route[ROUTE_INVITE] prints some output, and fix_contact on 200, ... whatever. Then this happens : - An INVITE is received from A (I see it with mn_received) - INVITE is relayed to destination B - B replies 180, I see the response on my module output and I see my onreply_route[INVITE] statements. - B replies 200, I see the response on my module output, but, I *do not* see my reply_route statements. - A sends ACK for INVITE - ACK is relayed to B 2 minutes later (fr_inv_timer), the failure_route[INVITE] is triggered ! Since I use failure routes to manage serial forking, this means openser forward the initial INVITE to the other destination, though first call was established ! Moreover, first call, which seems ok is CANCELED by the openser (I can see a 200 answer to a cancel from B) Openser did not disarm the fr_inv_timer on "200" answer to INVITE ? Openser did not triggered my onreply_route... Has someone already experienced this ? Has someone a clue where it may come from ? - Sometimes it works ok - Sometimes, 180 is not "seen" and 200 is ok - Sometimes 180 is seen but not 200 - Sometimes neither 180, nor 200 are seen - Headers in 180 and 200 are the same except for content - I'm running openser-1.2.0 (ouch !) I'm stuck ! Could this be related to 2008-05-15 10:59 Bogdan-Andrei Iancu, <bogdan at voice-system dot ro> * [r4191] modules/tm/t_reply.c: backport from trunk (rev #4190): - fixed race condition that may lead to deadlock on the transaction lock. As the reply route (t_on_reply()) stored in transaction may be changed in reply route br the current process or any other process, to avoid race conditions, it is better to make a local copy of the reply route number to be sure it will not be changed. The deadlock can appear as the reply route number is used in several conditions to determine id locking is required. But as this value may be changed (by current or other process), it may lead to multiple lockings with no unlock -> deadlock. NOTE: this might happen only if onreply_avp_mode is turned on. Aurelien

2 2

Re: [Kamailio-Users] Failover from SRV lookups?
by Henning Westerholt 05 Dec '08

05 Dec '08

On Thursday 04 December 2008, Geir O. Jensen wrote: > [..] > However, this sounds like it will only solve the problem every other time, > so some calls will go through quicker than the others. I guess our GW > supplier should've used a better solution for their loadbalancing (for > instance anycast) but that is out of my hands. > > Thanks again for the tip, I'll keep it in mind if/when we upgrade... Hi Geir, one other thing would be to not use the SRV records for loadbalancing. I think the dispatcher module has functionality to query configured servers with an options ping, and disable balancing to failed ones. Or you can use the carrierroute module, which gives you complete control over the routing, you can disable then the failed GW with some external scripts. Cheers, Henning

2 1

[Kamailio-Users] callerid openser
by Ricky Gutierrez 04 Dec '08

04 Dec '08

Hi , is possible to negotiate the callerid for each extension with openser? regards rickygm

2 2

Re: [Kamailio-Users] Thomson ST2030 SIP contact problem
by Samuel Muller 04 Dec '08

04 Dec '08

Hello, I tried all the ways you told : I moved the SIP phone at home, which I don't have any firewall and it does not pass through the entreprise fw. so the SIP phone is directly connected to the proxy. it registers well, no pbm, but the problem stay. Impossible to make a call to the Thomson. INVITE from any SIP phone (hard or soft, I tried with a Linksys, then a SJ Phone) through Kamailio is not going to the Thomson. All the others SIP stuff are working (Linksys to SJ Phone, ...). I tried many configuration changes into the Thomson ST2030, unsuccessfully. I mean it's not a NAT problem ... Here you are the SIP messages in the kamailio debug from SJ Phone (0123451011) to the f***in' Thomson (0123451014) : Dec 1 20:49:36 kamailio[29592]: -> incoming SIP buffer message: INVITE sip:0123451014@sip.720.fr <sip%3A0123451014(a)sip.720.fr> SIP/2.0 Via: SIP/2.0/UDP 192.168.1.3 ;rport;branch=z9hG4bKc0a801030000004549343fcf39c16ac5000000f0 Content-Length: 264 Contact: <sip:0123451011@192.168.1.3:5060> Call-ID: 2E029B5E-1DD2-11B2-A585-993A960A9D75(a)192.168.1.3 Content-Type: application/sdp CSeq: 2 INVITE From: "sambook"<sip:0123451011@sip.720.fr <sip%3A0123451011(a)sip.720.fr> >;tag=409529589751851917 Max-Forwards: 70 To: <sip:0123451014@sip.720.fr <sip%3A0123451014(a)sip.720.fr>> User-Agent: SJphone/1.60.299a/L (SJ Labs) Proxy-Authorization: Digest username="0123451011",realm="sip.720.fr", nonce="493440fb0000001024641d0bca47789c4c6f68d81262f201",uri=" sip:0123451014@sip.720.fr <sip%3A0123451014(a)sip.720.fr>", response="b8df3912d21ddd8aca40c0bf254bbdcf",cnonce="40952964931016109891",qop="auth",nc="00000001" v=0 o=- 3437149775 3437149775 IN IP4 192.168.1.3 s=SJphone c=IN IP4 192.168.1.3 t=0 0 a=direction:active m=audio 49168 RTP/AVP 0 8 3 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:3 GSM/8000 Dec 1 20:49:36 kamailio[29592]: -> outgoing SIP buffer message: INVITE sip:0123451014@sip.720.fr <sip%3A0123451014(a)sip.720.fr> SIP/2.0 Via: SIP/2.0/UDP 192.168.1.3 ;rport;branch=z9hG4bKc0a801030000004549343fcf39c16ac5000000f0 Content-Length: 264 Contact: <sip:0123451011@192.168.1.3:5060> Call-ID: 2E029B5E-1DD2-11B2-A585-993A960A9D75(a)192.168.1.3 Content-Type: application/sdp CSeq: 2 INVITE From: "sambook"<sip:0123451011@sip.720.fr <sip%3A0123451011(a)sip.720.fr> >;tag=409529589751851917 Max-Forwards: 69 To: <sip:0123451014@sip.720.fr <sip%3A0123451014(a)sip.720.fr>> User-Agent: SJphone/1.60.299a/L (SJ Labs) Proxy-Authorization: Digest username="0123451011",realm="sip.720.fr", nonce="493440fb0000001024641d0bca47789c4c6f68d81262f201",uri=" sip:0123451014@sip.720.fr <sip%3A0123451014(a)sip.720.fr>", response="b8df3912d21ddd8aca40c0bf254bbdcf",cnonce="40952964931016109891",qop="auth",nc="00000001" v=0 o=- 3437149775 3437149775 IN IP4 192.168.1.3 s=SJphone c=IN IP4 192.168.1.3 t=0 0 a=direction:active m=audio 49168 RTP/AVP 0 8 3 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:3 GSM/8000 In the attached file, the full kamailio debug level 9. It seems that nothing is coming to the Thomson (I don't have any hub where I can sniff the frames). "The truth is out there" ... :/ .desperate house Sam. On Mon, Dec 1, 2008 at 1:44 PM, Samuel Muller <sml(a)720.fr> wrote: > many thanks Klaus, > > I'll check tonight at home, and will reply to you after. > > sincerely, thanks ! > > .Sam. > > > > > On Mon, Dec 1, 2008 at 1:28 PM, Klaus Darilion < > klaus.mailinglists(a)pernau.at> wrote: > >> Hi Samuel! >> >> The INVITE sent from Kamailio to Thomson phone does not trigger any >> response. There are various possible reasons: >> >> 1. INVITE is ignored by Thomson phone >> 2. INVITE does not make it thorugh to the Thomson phone >> 2.1 either sent to the wrong port >> 2.2 or the NAT binding time out, thus NAT does not forward correctly >> >> Thus, verify if the INVITE is received by the NAT device and forwarded to >> the Thomson phone (e.g. putting a hub between the NAT router and the phone). >> REGISTER with the Thomson phone and then immediately after call it >> (linksys->thomson) - this should work as the binding should be alive just >> after the registration. >> >> The problem could also be caused by a buggy NAT router or VPN client or >> firewall ALGs. >> >> To further debug this issue you could also try the Thomson phone with >> another VoIP service (e.g. iptel.org or ekiga.net) or try the Thomson >> phone from another access (e.g. try it at home bypassing your company >> FW/NAT). >> >> You could also try to avoid port 5060, e.g. Put the proxy on port 5678 and >> also use other ports locally for the SIP clients. SIP ALGs (application >> level gateways) usually are triggered by port 5060. >> >> regards >> klaus >> >> >> Samuel Muller schrieb: >> >>> >>> >>> On Mon, Dec 1, 2008 at 12:24 PM, Klaus Darilion < >>> klaus.mailinglists(a)pernau.at <mailto:klaus.mailinglists@pernau.at>> >>> wrote: >>> >>> >>> >>> Samuel Muller schrieb: >>> >>> Hey Klaus, >>> >>> first, some answers : >>> >>> -> when a thomson is the callee, there's no ringing even if >>> indicated into the SIP message. >>> -> when a thomson is the caller, no problem, there's a ring, and >>> the call is ok with audio. >>> >>> >>> Please be a bit more specific: What does "no ring" mean? >>> No "180 ringing" response from callee to caller? >>> "180 ringing" response but no "ring-back" at the caller's client? >>> >>> >>> oups, sorry, I mean : SIP messages are ok, there is all the sig process. >>> >>> the architecture is : >>> linksys + thomson -> cisco 827 -> SDSL -> our backbone which have a >>> firewall for VPN (so NAT and NAPT are applied here), then the kamailio with >>> a public ip. >>> >>> you have the 100 trying, 180 ringing in the SIP message, but there's no >>> ring-back tone for the callee. >>> >>> in the attached file : >>> linksys to linksys, where all the call process is ok (sip + rtp) >>> thomson to linksys, idem >>> linksys to thomson, sip ok but rtp apparently not. >>> I forgot the firewall for the vpn, rtp proxying is required, sorry - so >>> yes rtp proxy must be used. >>> >>> regards, >>> >>> .Sam. >>> >>>

2 2

Re: [Kamailio-Users] Kamailio 1.4.1 fails at startup
by Henning Westerholt 04 Dec '08

04 Dec '08

On Thursday 04 December 2008, Arturo Díaz Almagro wrote: > Hi Henning, > > Forget the last mail. This is the configuration and the output log. I got a > segmentation fault in the pdt module: > [..] > Dec 4 13:28:37 mediaGW kamailio[9082]: DBG:db_text:dbt_load_file: > column[0] is INT! > > This error is gotten with kamailio 1.4.1 and 1.4.2. If I comment out the > modparam lines configuring pdt module kamailio starts up correctly. Hi Arturo, do you get a core dump from the segmention fault? If not, please enable the core dumping (e.g. with ulimit -c unlimited), and send me the backtrace when you examine the dump with gdb. As alternative you could also send me the DB contents that leads to the crash with private mail. Cheers, Henning

1 0

Re: [Kamailio-Users] lost path
by Daniel-Constantin Mierla 04 Dec '08

04 Dec '08

Hello, please post such questions to users mailing lists (cc-ed). Cheers, Daniel On 12/04/08 01:18, Waseem Besada wrote: > Hi > > I highly appreciate your help to solve the error I get when I try to > create a database. It seems that path to standard-create.sql is not > set probably and I'm lost how this can be fixed. > > Thank you in advance, > /Waseem > > linux-0g00:/usr/local/sbin # ./kamdbctl create > MySQL password for root: > INFO: test server charset > INFO: creating database openser ... > /usr/local/lib64/kamailio/kamctl/kamdbctl.mysql: line 155: > ./mysql/standard-create.sql: No such file or directory > ERROR: Creating core tables failed! >

1 0

[Kamailio-Users] Kamailio 1.4.1 fails at startup
by Arturo Díaz Almagro 03 Dec '08

03 Dec '08

Hello all, I am defining a little script for Kamailio working as a simple forwarder (doing some simple tasks sometimes). I have to use an static database with few rows of PDT data so I decided to use a text database via db_text module. The scripts seems to ok because I do not get any error message from start up logging but kamailio processes are not there!! Moreover, I am not making use of the functions in the script, only initialization!! I am using kamailio-1.4.1-notls and these are the script lines defining the initialization of those modules. Thanks a lot. ####### Global Parameters ######### debug=3 log_stderror=no fork=yes children=7 #KAMAILIO_CHILDREN /* uncomment the next line to disable TCP (default on) */ disable_tcp=yes /* uncomment the next line to enable the auto temporary blacklisting of not available destinations (default disabled) */ #disable_dns_blacklist=no /* uncomment the next line to enable IPv6 lookup after IPv4 dns lookup failures (default disabled) */ #dns_try_ipv6=yes /* uncomment the next line to disable the auto discovery of local aliases based on revers DNS on IPs (default on) */ #auto_aliases=no /* uncomment and configure the following line if you want Kamailio to bind on a specific interface/port/proto (default bind on all available) */ listen=udp:172.16.10.1:5060#KAMAILIO_PROTO:KAMAILIO_IP:KAMAILIO_PORT port=5060 #KAMAILIO_PORT /* domain alias for the host */ alias=domain1.com #KAMAILIO_DOMAIN # global domain alias=domain2.com ####### Modules Section ######## #set module path mpath="//lib/kamailio/modules/" loadmodule "db_text.so" loadmodule "sl.so" loadmodule "tm.so" loadmodule "rr.so" loadmodule "maxfwd.so" loadmodule "textops.so" loadmodule "mi_fifo.so" loadmodule "uri.so" loadmodule "xlog.so" loadmodule "path.so" loadmodule "pdt.so" loadmodule "avpops.so" # ----------------- setting module-specific parameters --------------- modparam("pdt|avpops", "db_url", "text:///tmp/kamailio_db") # ----- mi_fifo params ----- modparam("mi_fifo", "fifo_name", "/tmp/kamailio_fifo") # ----- rr params ----- # add value to ;lr param to cope with most of the UAs modparam("rr", "enable_full_lr", 1) # do not append from tag to the RR (no need for this script) #modparam("rr", "append_fromtag", 0) # ----- path params ----- modparam("path", "use_received", 0) # ----- dbtext ----- modparam("db_text", "db_mode", 0) # ----- pdt params ----- modparam("pdt", "db_table", "pdt") modparam("pdt", "sdomain_column", "sdomain") modparam("pdt", "prefix_column", "prefix") modparam("pdt", "domain_column", "domain") ####### Routing Logic ######## [..] -- Arturo Díaz

2 2

[Kamailio-Users] How are computed $Tf and $Ts?
by Iñaki Baz Castillo 03 Dec '08

03 Dec '08

Hi, it doesn't make sense: xlog("L_INFO","--- time pre http: $Tf - $Ts\n"); http_query("/test1.html", "r_uri=$(ru{s.escape.param})&f_uri=$(fu{s.escape.param})", "$var(result)"); xlog("L_INFO","--- time post http: $Tf - $Ts\n"); I always get: --- time pre http: Mon Nov 24 14:37:25 2008 - 1227533845 --- time post http: Mon Nov 24 14:37:25 2008 - 1227533845 Of course it's just impossible that the http query takes 0.000 seconds. I could use 'benchmark' module fot this stuf, but I wonder why $Tf returns the same value in any place of the script. Maybe it is just computed at the script start for each message? Thanks. -- Iñaki Baz Castillo

2 4

Re: [Serusers] How can I keep SER from changing reply Response Code from 503 to 500?
by Frank Durda IV 03 Dec '08

03 Dec '08

Jeroen van Bemmel wrote: > Frank, > > RFC3261 specifically specifies that proxies should convert response code > 503 into 500: > > A proxy which receives a 503 (Service Unavailable) response > SHOULD NOT forward it upstream unless it can determine that any > subsequent requests it might proxy will also generate a 503. > In other words, forwarding a 503 means that the proxy knows it > cannot service any requests, not just the one for the Request- > URI in the request which generated the 503. If the only > response that was received is a 503, the proxy SHOULD generate > a 500 response and forward that upstream. > > So SER is behaving in accordance with the standard. There might be a > configuration option to turn this off? Well, yes and no. Thanks for pointing out this item in the RFC which I missed, but if the RFC action is honored, then SER should have emitted "500 Server Internal Error" which is in the RFC, and not the hybrid and made-up "500 Service Unavailable", which is not in the RFC. So, I think SER is wrong at least on that point. (Personally I think SIP desperately needs at least 20 additional defined Response Codes so we can all quit using the existing not-entirely-inappropriate values to cover real-life situations, but right now the book says that's all the codes that we've all got to work with. When you see a dozen SS7 release codes all map to the same SIP Response Codes, you don't have nearly enough SIP Response Codes, but I digress.) That said, our SER server knows the given condition sent from a paired PSTN switch is permanent, eg the SIP caller can't call this number via our network now, tomorrow or next week because of who you they or whom their provider is (or what they failed to buy), so in this situation returning 503 all the way out of our network is correct behavior (as stated in the RFC), and doing so allows the upstream entity to click over to the next preferred carrier that might reach that destination. We have found that many SIP providers simply blindly lob all calls at the cheapest carrier and if a given call bounces, repeat that action with the next-cheapest carrier, and the next until they finally resort to a Tandem that will take anything, but will also be the most expensive way to route the call. Nearly all require us to send them back a 503 (a few want us to send 502 back instead) to say back to them "not via here, try next door". Deplorable and this method certainly causes slow call set-up times, but that is what quite a few of these outfits are doing. So, our SER must send them back a 503 and not a 500 in this situation. If I explicitly state one in a reply rule, will that override this default behavior, or will some deeper part of SER veto even a sl_reply("503", "Service Unavailable"); added to the onreply_route? If so, where is this piece of source code, so that I may break this well-intended but undesired behavior?

5 8

[Kamailio-Users] important: pseudo-variables moved to pv module
by Daniel-Constantin Mierla 03 Dec '08

03 Dec '08

Hello, please note that pseudo-variables implemented in core for kamailio/openser versions <= 1.4.x are now moved in pv module. This is part of cleaning up the core, in order to keep it slimmer and less exposed to bugs. There are modules and use cases that need no PVs, therefore no need of keeping the implementation of about 100 PV in core. Now the core includes only an API that allows to: - register PVs from modules - parse PV names in config script, evaluate PVs, assign values to PVs $shv() - shared variables, and $time() - broken down time, were moved from cfgutils module to pv module ($shv() depends on $var()). To summarize, if you need $ru, $avp(...), $var(...), a.s.o. in your config file you have to load pv module from now on with devel version and upcoming stable releases. Two new pseudo-variables were introduced with this occasion, $TS and $TF, see more: http://www.kamailio.org/dokuwiki/doku.php/pseudovariables:devel#string_form… http://www.kamailio.org/dokuwiki/doku.php/pseudovariables:devel#unix_time_s… Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

1 0

[Kamailio-Users] how to use 2 mysql servers?
by BERGANZ François 03 Dec '08

03 Dec '08

Hello, I need to know how to use 2 mysql servers, if my first server go down Have you an idea? thankyopu Cordialement, BERGANZ François P Pensez à l'Environnement, n'imprimez ce mail que si nécessaire.

10 18

[Kamailio-Users] 403 Forbidden to SUBSCRIBE for reg-event package
by skumar453＠gmail.com 03 Dec '08

03 Dec '08

Hi, I am getting "403 Forbidden to SUBSCRIBE" error message. below is the scenario: 1. SCSCF is sending third party register request (with reg event) to AS. 2. AS is sending back 200 OK 3. AS is sending SUBSCRIBE (with reg event) to SCSCF. 4. scscf is sending back "403 - Forbidden to SUBSCRIBE" error message to AS. my SIP message is inline with the specification 24.141 (section: A.7. PNA subscription for the reg-event package) also. Here is my SIP message: ----------------------- SUBSCRIBE sip:alice@mydomain.com SIP/2.0 Via: SIP/2.0/UDP 172.18.2.92:5065;branch=z9hG4bK374b.eee261c1.0 To: sip:alice@mydomain.com From: sip:172.18.2.92:5065;tag=933e5c49d48198cc3b1dfd0b30660d07-2f8d CSeq: 10 SUBSCRIBE Call-ID: 2d0f7fbf-1185(a)172.18.2.92 Content-Length: 0 User-Agent: OpenSIPS (1.4.0-notls (i386/linux)) Max-Forwards: 70 Event: reg Contact: <sip:172.18.2.92:5065> P-Asserted-Identity: <sip:172.18.2.92:5065> Expires: 600000 Can anybody help me resolving this? Regards, suresh

2 1

[Kamailio-Users] load_credentials() in auth_db.
by Alex Balashov 03 Dec '08

03 Dec '08

Are there any plans to allow loading of credentials into userspace variables ($var(column)) in addition to AVPs? -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599

2 1

Re: [Serusers] Registering port instead of contact field port
by Iñaki Baz Castillo 02 Dec '08

02 Dec '08

El Jueves, 27 de Noviembre de 2008, Daniel Serrano escribió: > Dear all, > > I am using SER as IM server and I found that the SER use the contact > field to storage the user's location in the memory for future requests. > I noted this using the command "serctl alias show" and checking some > traces. > Since I'm using a NAT scenario I'd like to use the UDP port that my > SER server receives during the registration instead of the contact > field port to reach the users after their registration. Is there any > way to do this? "rport" does it, but the client must indicate support of "rport" by adding ";rport" parameter to its Via header. Anyway, *SER can force it by using "force_rport()". -- Iñaki Baz Castillo

3 5

[Kamailio-Users] PDT module - multiple prefix single domain
by Matteo Piazza 02 Dec '08

02 Dec '08

Hi all, I notice a thing about PDT module. If you try to put in the table two entry with the same destination domain at the load of the parameter is reported an error of duplication: Nov 28 09:32:23 [5169] ERROR:pdt:pdt_load_db: sdomain [*]: prefix [04610202] or domain <tnn.multivoce.tnnet.it> duplicated entry of the table id | sdomain | prefix | domain ----+---------+----------+-------------------------- 1 | * | * | intercom.tnnet.it 4 | * | 04610200 | tsm.multivoce.tnnet.it 2 | * | 04610201 | tnn.multivoce.tnnet.it 3 | * | 04610202 | tnn.multivoce.tnnet.it Is this mean that the prefix must be only one for a single domain. This is a limition where I have a single domain that manage multiple prefix not consecutive. Did I understand right? Matteo -- ==================================== Matteo Piazza Trentino Network s.r.l. a Socio Unico matteo.piazza(a)trentinonetwork.it Via Gilli, 2 - 38100 TRENTO Tel (+39) 0461.020224 ====================================

3 6

[Kamailio-Users] Meeting at 25C3 in Berlin
by Henning Westerholt 01 Dec '08

01 Dec '08

Hello all, i'll be present this year at the 25th Chaos Communication Congress in Berlin [1], December 27th to 30th, 2008. So if some people here also participate in this event, and want to meet for some hacking sessions and discussions around the Kamailio/ sip-router project please drop me a personal mail. Regards, Henning [1] http://events.ccc.de/congress/2008/

1 0

Re: [Kamailio-Users] Thomson ST2030 SIP contact problem
by Samuel Muller 01 Dec '08

01 Dec '08

On Mon, Dec 1, 2008 at 12:24 PM, Klaus Darilion < klaus.mailinglists(a)pernau.at> wrote: > > > Samuel Muller schrieb: > >> Hey Klaus, >> >> first, some answers : >> >> -> when a thomson is the callee, there's no ringing even if indicated >> into the SIP message. >> -> when a thomson is the caller, no problem, there's a ring, and the call >> is ok with audio. >> > > Please be a bit more specific: What does "no ring" mean? > No "180 ringing" response from callee to caller? > "180 ringing" response but no "ring-back" at the caller's client? > oups, sorry, I mean : SIP messages are ok, there is all the sig process. the architecture is : linksys + thomson -> cisco 827 -> SDSL -> our backbone which have a firewall for VPN (so NAT and NAPT are applied here), then the kamailio with a public ip. you have the 100 trying, 180 ringing in the SIP message, but there's no ring-back tone for the callee. in the attached file : linksys to linksys, where all the call process is ok (sip + rtp) thomson to linksys, idem linksys to thomson, sip ok but rtp apparently not. I forgot the firewall for the vpn, rtp proxying is required, sorry - so yes rtp proxy must be used. regards, .Sam. > > -> the SIP mesages are the same in the 2 cases. >> >> incoming invite are exactly the same (but the source IP, and the >> "user=phone" parameter, for sure). >> outgoing invite, in the 2 cases, replaces the source IP on the "c" line >> into the SDP by the RTP proxy IP (but at the end, it indicates >> a=nortpproxy:yes >> > > a=nortpproxy:yes is fine. This line will signal to upstream proxies that an > RTP proxy was already activated and there is no need to activate further RTP > proxies. > > > Please post a complete ngrep trace (INVITE.....BYE) for the sucessfull and > for the unsuccessful call. > > > Did I force 2 times the RTP proxy, or is there a >> > > no > > fix_nated_contact/fix_nated_register pbm ? >> > > For REGISTER handling you use fix_nated_register. For all other cases you > use fix_nated_contact. > > > BTW: What do you mean by "there's no RTP proxying" in the "not ok" case? > > regards > klaus > > >> really strange, I can send to you the kamailio debugs if you need it >> >> in advance many thanks, >> >> .Sam. >> >> >> >> >> On Mon, Dec 1, 2008 at 11:50 AM, Klaus Darilion < >> klaus.mailinglists(a)pernau.at <mailto:klaus.mailinglists@pernau.at>> >> wrote: >> >> Hi Samuel! >> >> What exactly is the problem when "not ok". >> is signaling fine? >> what is the audio problem (one way audio? no audio at all?) >> >> compare the SDP of the incoming INVITE with the outgoing INVITE. If >> you use rtpproxy, the IP address in the c line should be changed. >> >> >> regards >> klaus >> >> Samuel Muller schrieb: >> >> Hello, >> >> >> ok, I tested this in the same LAN : >> >> Thomson st2030 -> Linksys spa941 : ok >> Linksys -> Thomson : not ok >> Linksys -> another working Linksys : ok >> Thomson -> another Thomson : not ok >> >> Indeed there's no RTP proxying. >> I check all the SIP messages below, the only differences I saw >> are : "user=phone" and the rtpmap. >> concerning NAT there are behind the same router, the location >> saved is fine ? >> >> in the kamailio log, the routing logic is the same. >> registration of all sip phones are ok, proxy auth too. >> the Thomsons can't find any other sip phones ... >> >> here are all the invites (got with ngrep) : >> >> >> *** Here you have the INVITE message in the case Linksys => >> Linksys (call ok) >> >> U 2008/12/01 10:34:09.950709 77.246.81.162:25722 >> <http://77.246.81.162:25722> <http://77.246.81.162:25722> -> >> 77.246.81.132:5060 <http://77.246.81.132:5060> >> <http://77.246.81.132:5060> >> INVITE sip:0123451010@sip.720.fr <sip%3A0123451010(a)sip.720.fr> >> <mailto:sip%3A0123451010@sip.720.fr<sip%253A0123451010(a)sip.720.fr> >> > >> <mailto:sip%3A0123451010@sip.720.fr<sip%253A0123451010(a)sip.720.fr> >> <mailto:sip%253A0123451010@sip.720.fr<sip%25253A0123451010(a)sip.720.fr>>> >> SIP/2.0. >> >> Via: SIP/2.0/UDP 192.168.0.120:5060;branch=z9hG4bK-bdbd130c. >> From: "linksys1" <sip:0123451005@sip.720.fr<sip%3A0123451005(a)sip.720.fr> >> <mailto:sip%3A0123451005@sip.720.fr<sip%253A0123451005(a)sip.720.fr> >> > >> <mailto:sip%3A0123451005@sip.720.fr<sip%253A0123451005(a)sip.720.fr> >> <mailto:sip%253A0123451005@sip.720.fr<sip%25253A0123451005(a)sip.720.fr> >> >>>;tag=6fc94d28edd8dcaao0. >> To: "linksys2" <sip:0123451010@sip.720.fr<sip%3A0123451010(a)sip.720.fr> >> <mailto:sip%3A0123451010@sip.720.fr<sip%253A0123451010(a)sip.720.fr> >> > >> <mailto:sip%3A0123451010@sip.720.fr<sip%253A0123451010(a)sip.720.fr> >> <mailto:sip%253A0123451010@sip.720.fr<sip%25253A0123451010(a)sip.720.fr> >> >>>. >> Remote-Party-ID: "linksys1" <sip:0123451005@sip.720.fr<sip%3A0123451005(a)sip.720.fr> >> <mailto:sip%3A0123451005@sip.720.fr<sip%253A0123451005(a)sip.720.fr> >> > >> <mailto:sip%3A0123451005@sip.720.fr<sip%253A0123451005(a)sip.720.fr> >> <mailto:sip%253A0123451005@sip.720.fr<sip%25253A0123451005(a)sip.720.fr> >> >>>;screen=yes;party=calling. >> Call-ID: 7dba9d80-33140832(a)192.168.0.120 >> <mailto:7dba9d80-33140832@192.168.0.120> >> <mailto:7dba9d80-33140832@192.168.0.120 >> <mailto:7dba9d80-33140832@192.168.0.120>>. >> >> CSeq: 102 INVITE. >> Max-Forwards: 50. >> Proxy-Authorization: Digest >> username="0123451005",realm="sip.720.fr <http://sip.720.fr> >> <http://sip.720.fr >> >",nonce="4933b0bd000000bb6b5025b195e2dac29e1a78759732fcfb",uri=" >> sip:0123451010@sip.720.fr <sip%3A0123451010(a)sip.720.fr> >> <mailto:sip%3A0123451010@sip.720.fr<sip%253A0123451010(a)sip.720.fr> >> > >> <mailto:sip%3A0123451010@sip.720.fr<sip%253A0123451010(a)sip.720.fr> >> <mailto:sip%253A0123451010@sip.720.fr<sip%25253A0123451010(a)sip.720.fr> >> >>",algorithm=MD5,response="2d6a83ad081b23632bbc40bcfb277daf",qop=auth,nc=00000001,cnonce="6dec9235". >> >> Contact: "linksys1" <sip:0123451005@192.168.0.120:5060 >> <http://sip:0123451005@192.168.0.120:5060> >> <http://sip:0123451005@192.168.0.120:5060>>. >> >> Expires: 240. >> User-Agent: Linksys/SPA941-5.1.8. >> Content-Length: 259. >> Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER. >> Supported: replaces. >> Content-Type: application/sdp. >> . >> v=0. >> o=- 316723 316723 IN IP4 192.168.0.120 <http://192.168.0.120> >> <http://192.168.0.120>. >> s=-. >> c=IN IP4 192.168.0.120 <http://192.168.0.120> >> <http://192.168.0.120>. >> >> t=0 0. >> m=audio 38544 RTP/AVP 18 0 8 101. >> a=rtpmap:18 G729a/8000. >> a=rtpmap:0 PCMU/8000. >> a=rtpmap:8 PCMA/8000. >> a=rtpmap:101 telephone-event/8000. >> a=fmtp:101 0-15. >> a=ptime:30. >> a=sendrecv. >> >> *** Here you have the INVITE message in the case Linksys => >> Thomson (call ok) >> >> U 2008/12/01 10:39:43.317899 77.246.81.162:25722 >> <http://77.246.81.162:25722> <http://77.246.81.162:25722> -> >> 77.246.81.132:5060 <http://77.246.81.132:5060> >> <http://77.246.81.132:5060> >> >> INVITE sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr> >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> > >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr>>> >> SIP/2.0. >> Via: SIP/2.0/UDP 192.168.0.120:5060;branch=z9hG4bK-30acba56. >> From: "linksys1" <sip:0123451005@sip.720.fr<sip%3A0123451005(a)sip.720.fr> >> <mailto:sip%3A0123451005@sip.720.fr<sip%253A0123451005(a)sip.720.fr> >> > >> <mailto:sip%3A0123451005@sip.720.fr<sip%253A0123451005(a)sip.720.fr> >> <mailto:sip%253A0123451005@sip.720.fr<sip%25253A0123451005(a)sip.720.fr> >> >>>;tag=4829c42d46f54ba1o0. >> To: "thomson1" <sip:0123451013@sip.720.fr<sip%3A0123451013(a)sip.720.fr> >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> > >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> >>>. >> Remote-Party-ID: "linksys1" <sip:0123451005@sip.720.fr<sip%3A0123451005(a)sip.720.fr> >> <mailto:sip%3A0123451005@sip.720.fr<sip%253A0123451005(a)sip.720.fr> >> > >> <mailto:sip%3A0123451005@sip.720.fr<sip%253A0123451005(a)sip.720.fr> >> <mailto:sip%253A0123451005@sip.720.fr<sip%25253A0123451005(a)sip.720.fr> >> >>>;screen=yes;party=calling. >> Call-ID: ebfea81d-6dcc3871(a)192.168.0.120 >> <mailto:ebfea81d-6dcc3871@192.168.0.120> >> <mailto:ebfea81d-6dcc3871@192.168.0.120 >> <mailto:ebfea81d-6dcc3871@192.168.0.120>>. >> >> CSeq: 102 INVITE. >> Max-Forwards: 50. >> Proxy-Authorization: Digest >> username="0123451005",realm="sip.720.fr <http://sip.720.fr> >> <http://sip.720.fr >> >",nonce="4933b20b000000bcd4130811017007669127457c07480a0e",uri=" >> sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr> >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> > >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> >>",algorithm=MD5,response="a888badf3b4a5d787f2a763dd8fd8c28",qop=auth,nc=00000001,cnonce="7405f5b". >> Contact: "linksys1" <sip:0123451005@192.168.0.120:5060 >> <http://sip:0123451005@192.168.0.120:5060> >> <http://sip:0123451005@192.168.0.120:5060>>. >> >> Expires: 240. >> User-Agent: Linksys/SPA941-5.1.8. >> Content-Length: 259. >> Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER. >> Supported: replaces. >> Content-Type: application/sdp. >> . >> v=0. >> o=- 350059 350059 IN IP4 192.168.0.120 <http://192.168.0.120> >> <http://192.168.0.120>. >> s=-. >> c=IN IP4 192.168.0.120 <http://192.168.0.120> >> <http://192.168.0.120>. >> >> t=0 0. >> m=audio 38546 RTP/AVP 18 0 8 101. >> a=rtpmap:18 G729a/8000. >> a=rtpmap:0 PCMU/8000. >> a=rtpmap:8 PCMA/8000. >> a=rtpmap:101 telephone-event/8000. >> a=fmtp:101 0-15. >> a=ptime:30. >> a=sendrecv. >> >> *** Here you have the INVITE message in the case Thomson => >> Linksys (call not ok) >> >> U 2008/12/01 10:41:54.428224 77.246.81.162:24507 >> <http://77.246.81.162:24507> <http://77.246.81.162:24507> -> >> 77.246.81.132:5060 <http://77.246.81.132:5060> >> <http://77.246.81.132:5060> >> >> INVITE sip:0123451010@sip.720.fr:5060;user=phone SIP/2.0. >> Via: SIP/2.0/UDP >> 192.168.0.184:5060;branch=z9hG4bK7920248682981536932-1809931. >> From: >> "thomson1"<sip:0123451013@sip.720.fr:5060 >> ;user=phone>;tag=c0a80101-1b9de5. >> To: <sip:0123451010@sip.720.fr:5060;user=phone>. >> Call-ID: 1bc719-c0a80101-0-2(a)192.168.0.184 >> <mailto:1bc719-c0a80101-0-2@192.168.0.184> >> <mailto:1bc719-c0a80101-0-2@192.168.0.184 >> <mailto:1bc719-c0a80101-0-2@192.168.0.184>>. >> >> CSeq: 2 INVITE. >> Max-Forwards: 70. >> Supported: timer, replaces. >> Session-Expires: 1800. >> Proxy-Authorization: Digest username="0123451013", >> realm="sip.720.fr <http://sip.720.fr> <http://sip.720.fr>", >> nonce="4933b28e000000bf60feb103ab85ee5f758ec510d7773f66", >> uri="sip:0123451010@sip.720.fr:5060;user=phone", >> response="1eb59cbc25d6db05fafcd5d8b915da4a", algorithm=MD5, >> qop=auth, cnonce="1b9e0b", nc=00000001. >> >> Allow: >> >> INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,SUBSCRIBE,NOTIFY,UPDATE,REFER,REGISTER,INFO. >> Contact: <sip:0123451013@192.168.0.184:5060;user=phone>. >> User-Agent: THOMSON thomson1 hw5 fw1.63 00-14-7F-00-5E-0A. >> Allow-Events: refer,dialog,message-summary,check-sync,talk,hold. >> Content-Type: application/sdp. >> Content-Length: 299. >> . >> v=0. >> o=0123451013 1809894 1809894 IN IP4 192.168.0.184 >> <http://192.168.0.184> <http://192.168.0.184>. >> s=-. >> c=IN IP4 192.168.0.184 <http://192.168.0.184> >> <http://192.168.0.184>. >> >> t=0 0. >> m=audio 41000 RTP/AVP 8 0 18 4 96. >> a=rtpmap:8 PCMA/8000. >> a=rtpmap:0 PCMU/8000. >> a=rtpmap:18 G729/8000. >> a=fmtp:18 annexb=no. >> a=rtpmap:4 G723/8000. >> a=rtpmap:96 telephone-event/8000. >> a=fmtp:96 0-15. >> a=sendrecv. >> >> *** Here you have the INVITE message in the case Thomson => >> Thomson (call not ok) >> >> U 2008/12/01 10:43:41.340288 77.246.81.162:30201 >> <http://77.246.81.162:30201> <http://77.246.81.162:30201> -> >> >> 77.246.81.132:5060 <http://77.246.81.132:5060> >> <http://77.246.81.132:5060> >> >> INVITE sip:0123451013@sip.720.fr:5060;user=phone SIP/2.0. >> Via: SIP/2.0/UDP >> 192.168.0.185:5060;branch=z9hG4bK9142470814203758154-1862706. >> From: >> "thomson2"<sip:0123451014@sip.720.fr:5060 >> ;user=phone>;tag=c0a80101-1c6c04. >> To: <sip:0123451013@sip.720.fr:5060;user=phone>. >> Call-ID: 1c93e7-c0a80101-0-2(a)192.168.0.185 >> <mailto:1c93e7-c0a80101-0-2@192.168.0.185> >> <mailto:1c93e7-c0a80101-0-2@192.168.0.185 >> <mailto:1c93e7-c0a80101-0-2@192.168.0.185>>. >> >> CSeq: 2 INVITE. >> Max-Forwards: 70. >> Supported: timer, replaces. >> Session-Expires: 1800.Proxy-Authorization: Digest >> username="0123451014", realm="sip.720.fr <http://sip.720.fr> >> <http://sip.720.fr>", >> nonce="4933b2f9000000c25f1b77c7d99d35ceeb25c03a20f5e153", >> uri="sip:0123451013@sip.720.fr:5060;user=phone", >> response="2c46b135e8453fce29308c03cf89aac5", algorithm=MD5, >> qop=auth, cnonce="1c6c33", nc=00 >> >> 000001. >> Allow: >> >> INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,SUBSCRIBE,NOTIFY,UPDATE,REFER,REGISTER,INFO. >> Contact: <sip:0123451014@192.168.0.185:5060;user=phone>. >> User-Agent: THOMSON thomson1 hw5 fw1.63 00-14-7F-E1-63-34. >> Allow-Events: refer,dialog,message-summary,check-sync,talk,hold. >> Content-Type: application/sdp. >> Content-Length: 299. >> . >> v=0. >> o=0123451014 1862661 1862661 IN IP4 192.168.0.185 >> <http://192.168.0.185> <http://192.168.0.185>. >> >> s=-. >> c=IN IP4 192.168.0.185 <http://192.168.0.185> >> <http://192.168.0.185>. >> >> t=0 0. >> m=audio 41000 RTP/AVP 8 0 18 4 96. >> a=rtpmap:8 PCMA/8000. >> a=rtpmap:0 PCMU/8000. >> a=rtpmap:18 G729/8000. >> a=fmtp:18 annexb=no. >> a=rtpmap:4 G723/8000. >> a=rtpmap:96 telephone-event/8000. >> a=fmtp:96 0-15. >> a=sendrecv. >> >> >> >> It's strange ... >> >> .Sam. >> >> >> On Fri, Nov 28, 2008 at 12:52 PM, Klaus Darilion >> <klaus.mailinglists(a)pernau.at >> <mailto:klaus.mailinglists@pernau.at> >> <mailto:klaus.mailinglists@pernau.at >> <mailto:klaus.mailinglists@pernau.at>>> wrote: >> >> the user=phone parameter in the Contact is probably not the >> problem >> - there can be any parameter there. Except the client does not >> accept its own contact. >> >> I suspect a NAT problem >> >> regards >> klaus >> >> Samuel Muller schrieb: >> >> Hello all, >> >> I've a little problem with the SIP phone Thomson ST2030. >> When it registers, it auto-adds ";user=phone" in all the >> fields >> it can be. >> The problem is that it can't be called due to the contact >> header, kamailio can't found the phone. >> >> I tried to delete the filed during the REGISTER and the >> PROXY >> AUTH processes, with no success ... >> >> If someone has a solution, many thanks ! >> >> -- -- >> kamailio.cfg : >> -- -- >> ... >> # ;user=phone hack >> if (search("^Contact:.*;user=phone")) >> { >> xlog("L_INFO", "-> user=phone found, >> remove it - >> F=$fu ContactHF=$ct"); >> replace_all(";user=phone", "\r\n"); >> #subst("/;user=phone$;$")) >> } >> ... >> >> => all the logs here : >> >> -- -- >> SQL result >> -- -- >> >> Database: openser >> SQL query: SELECT * FROM `location` WHERE `id` = 383 >> LIMIT 0, 30 ; >> >> id 383 >> username 0123451013 >> domain sip.720.fr <http://sip.720.fr> >> <http://sip.720.fr> >> <http://sip.720.fr> >> >> contact sip:0123451013@192.168.0.158:5060;user=phone >> received sip:77.246.81.162:1902 >> <http://77.246.81.162:1902> <http://77.246.81.162:1902> >> <http://77.246.81.162:1902> >> >> path NULL >> expires 2008-11-28 13:02:16 >> q 0.00 >> callid 18786315-c0a80101-5-a(a)192.168.0.158 >> <mailto:18786315-c0a80101-5-a@192.168.0.158> >> <mailto:18786315-c0a80101-5-a@192.168.0.158 >> <mailto:18786315-c0a80101-5-a@192.168.0.158>> >> <mailto:18786315-c0a80101-5-a@192.168.0.158 >> <mailto:18786315-c0a80101-5-a@192.168.0.158> >> <mailto:18786315-c0a80101-5-a@192.168.0.158 >> <mailto:18786315-c0a80101-5-a@192.168.0.158>>> >> >> cseq 270 >> last_modified 2008-11-28 12:02:16 >> flags 0 >> cflags 64 >> user_agent THOMSON ST2030 hw5 fw1.63 00-14-7F-00-5E-0A >> socket udp:77.246.81.132:5060 >> <http://77.246.81.132:5060> >> <http://77.246.81.132:5060> <http://77.246.81.132:5060> >> >> >> methods NULL >> >> -- -- >> kamailio REGISTER sip buffer >> -- -- >> >> REGISTER sip:sip.720.fr <http://sip.720.fr> >> <http://sip.720.fr> >> <http://sip.720.fr>;user=phone SIP/2.0 >> >> Via: SIP/2.0/UDP >> 192.168.0.158:5060 >> ;branch=z9hG4bK363142985921875976-158787787 >> From: >> <sip:0123451013@sip.720.fr:5060 >> ;user=phone>;tag=c0a80101-976e8ab >> To: <sip:0123451013@sip.720.fr:5060;user=phone> >> Call-ID: 18786315-c0a80101-5-a(a)192.168.0.158 >> <mailto:18786315-c0a80101-5-a@192.168.0.158> >> <mailto:18786315-c0a80101-5-a@192.168.0.158 >> <mailto:18786315-c0a80101-5-a@192.168.0.158>> >> <mailto:18786315-c0a80101-5-a@192.168.0.158 >> <mailto:18786315-c0a80101-5-a@192.168.0.158> >> <mailto:18786315-c0a80101-5-a@192.168.0.158 >> <mailto:18786315-c0a80101-5-a@192.168.0.158>>> >> >> CSeq: 250 REGISTER >> Max-Forwards: 69 >> Expires: 3600 >> Contact: <sip:0123451013@192.168.0.158:5060;user=phone> >> Authorization: Digest username="0123451013", >> realm="sip.720.fr <http://sip.720.fr> >> <http://sip.720.fr> <http://sip.720.fr>", >> nonce="492f8a92000000697e7fefd30ce752d7e50c6166da2cc6e2", >> uri="sip:sip.720.fr <http://sip.720.fr> >> <http://sip.720.fr> <http://sip.720.fr>", >> >> response="37f8ec824ba77eb37583f38f2a509f77", >> >> algorithm=MD5, qop=auth, cnonce="976e8cb", nc=00000001 >> User-Agent: THOMSON ST2030 hw5 fw1.63 00-14-7F-00-5E-0A >> Allow-Events: >> refer,dialog,message-summary,check-sync,talk,hold >> Content-Length: 0 >> >> -- -- >> ngrep log : >> -- -- >> >> U 2008/11/28 12:13:59.813649 77.246.81.162:8680 >> <http://77.246.81.162:8680> >> <http://77.246.81.162:8680> <http://77.246.81.162:8680> -> >> >> 77.246.81.132:5060 <http://77.246.81.132:5060> >> <http://77.246.81.132:5060> >> <http://77.246.81.132:5060> >> INVITE sip:0123451013@sip.720.fr<sip%3A0123451013(a)sip.720.fr> >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> > >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> >> >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> > >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> <mailto:sip%25253A0123451013@sip.720.fr<sip%2525253A0123451013(a)sip.720.fr>>>> >> SIP/2.0. >> >> >> Via: SIP/2.0/UDP 192.168.0.113:5060 >> ;branch=z9hG4bK-eb23842c. >> From: "Sam" <sip:0123451010@sip.720.fr<sip%3A0123451010(a)sip.720.fr> >> <mailto:sip%3A0123451010@sip.720.fr<sip%253A0123451010(a)sip.720.fr> >> > >> <mailto:sip%3A0123451010@sip.720.fr<sip%253A0123451010(a)sip.720.fr> >> <mailto:sip%253A0123451010@sip.720.fr<sip%25253A0123451010(a)sip.720.fr> >> >> >> <mailto:sip%3A0123451010@sip.720.fr<sip%253A0123451010(a)sip.720.fr> >> <mailto:sip%253A0123451010@sip.720.fr<sip%25253A0123451010(a)sip.720.fr> >> > >> <mailto:sip%253A0123451010@sip.720.fr<sip%25253A0123451010(a)sip.720.fr> >> <mailto:sip%25253A0123451010@sip.720.fr<sip%2525253A0123451010(a)sip.720.fr> >> >>>>;tag=4209e88c969ca7dfo0. >> >> To: "st2030" <sip:0123451013@sip.720.fr<sip%3A0123451013(a)sip.720.fr> >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> > >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> >> >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> > >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> <mailto:sip%25253A0123451013@sip.720.fr<sip%2525253A0123451013(a)sip.720.fr> >> >>>>. >> >> Remote-Party-ID: "Sam" <sip:0123451010@sip.720.fr<sip%3A0123451010(a)sip.720.fr> >> <mailto:sip%3A0123451010@sip.720.fr<sip%253A0123451010(a)sip.720.fr> >> > >> <mailto:sip%3A0123451010@sip.720.fr<sip%253A0123451010(a)sip.720.fr> >> <mailto:sip%253A0123451010@sip.720.fr<sip%25253A0123451010(a)sip.720.fr> >> >> >> <mailto:sip%3A0123451010@sip.720.fr<sip%253A0123451010(a)sip.720.fr> >> <mailto:sip%253A0123451010@sip.720.fr<sip%25253A0123451010(a)sip.720.fr> >> > >> <mailto:sip%253A0123451010@sip.720.fr<sip%25253A0123451010(a)sip.720.fr> >> <mailto:sip%25253A0123451010@sip.720.fr<sip%2525253A0123451010(a)sip.720.fr> >> >>>>;screen=yes;party=calling. >> >> Call-ID: 39d2f3d0-b283756b(a)192.168.0.113 >> <mailto:39d2f3d0-b283756b@192.168.0.113> >> <mailto:39d2f3d0-b283756b@192.168.0.113 >> <mailto:39d2f3d0-b283756b@192.168.0.113>> >> <mailto:39d2f3d0-b283756b@192.168.0.113 >> <mailto:39d2f3d0-b283756b@192.168.0.113> >> <mailto:39d2f3d0-b283756b@192.168.0.113 >> <mailto:39d2f3d0-b283756b@192.168.0.113>>>. >> >> CSeq: 102 INVITE. >> Max-Forwards: 50. >> Proxy-Authorization: Digest >> username="0123451010",realm="sip.720.fr >> <http://sip.720.fr> <http://sip.720.fr> >> <http://sip.720.fr >> >",nonce="492fd3a300000094c9e8b4f3805f7f96dc3f36f981a64570",uri=" >> sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr> >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> > >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> >> >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> > >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> <mailto:sip%25253A0123451013@sip.720.fr<sip%2525253A0123451013(a)sip.720.fr> >> >>>",algorithm=MD5,response="1538e1ac3e3181f8bfb6f473f2470a6a",qop=auth,nc=00000001,cnonce="7c8a76fd". >> >> >> Contact: "Sam" <sip:0123451010@192.168.0.113:5060 >> <http://sip:0123451010@192.168.0.113:5060> >> <http://sip:0123451010@192.168.0.113:5060> >> <http://sip:0123451010@192.168.0.113:5060>>. >> >> Expires: 240. >> User-Agent: Linksys/SPA941-5.1.8. >> Content-Length: 263. >> Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, >> PRACK, >> REFER. >> Supported: 100rel, replaces. >> Content-Type: application/sdp. >> . >> v=0. >> o=- 33629308 33629308 IN IP4 192.168.0.113 >> <http://192.168.0.113> >> <http://192.168.0.113> <http://192.168.0.113>. >> >> s=-. >> c=IN IP4 192.168.0.113 <http://192.168.0.113> >> <http://192.168.0.113> >> <http://192.168.0.113>. >> >> t=0 0. >> m=audio 35692 RTP/AVP 18 0 8 101. >> a=rtpmap:18 G729a/8000. >> a=rtpmap:0 PCMU/8000. >> a=rtpmap:8 PCMA/8000. >> a=rtpmap:101 telephone-event/8000. >> a=fmtp:101 0-15. >> a=ptime:30. >> a=sendrecv. >> >> >> U 2008/11/28 12:13:59.820056 77.246.81.132:5060 >> <http://77.246.81.132:5060> >> <http://77.246.81.132:5060> <http://77.246.81.132:5060> -> >> >> 77.246.81.162:8680 <http://77.246.81.162:8680> >> <http://77.246.81.162:8680> >> <http://77.246.81.162:8680> >> >> SIP/2.0 100 Trying. >> Via: SIP/2.0/UDP >> 192.168.0.113:5060 >> ;branch=z9hG4bK-eb23842c;rport=8680;received=77.246.81.162 >> <http://77.246.81.162> >> <http://77.246.81.162> <http://77.246.81.162>. >> >> From: "Sam" <sip:0123451010@sip.720.fr<sip%3A0123451010(a)sip.720.fr> >> <mailto:sip%3A0123451010@sip.720.fr<sip%253A0123451010(a)sip.720.fr> >> > >> <mailto:sip%3A0123451010@sip.720.fr<sip%253A0123451010(a)sip.720.fr> >> <mailto:sip%253A0123451010@sip.720.fr<sip%25253A0123451010(a)sip.720.fr> >> >> >> <mailto:sip%3A0123451010@sip.720.fr<sip%253A0123451010(a)sip.720.fr> >> <mailto:sip%253A0123451010@sip.720.fr<sip%25253A0123451010(a)sip.720.fr> >> > >> <mailto:sip%253A0123451010@sip.720.fr<sip%25253A0123451010(a)sip.720.fr> >> <mailto:sip%25253A0123451010@sip.720.fr<sip%2525253A0123451010(a)sip.720.fr> >> >>>>;tag=4209e88c969ca7dfo0. >> >> To: "st2030" <sip:0123451013@sip.720.fr<sip%3A0123451013(a)sip.720.fr> >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> > >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> >> >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> > >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> <mailto:sip%25253A0123451013@sip.720.fr<sip%2525253A0123451013(a)sip.720.fr> >> >>>>. >> >> Call-ID: 39d2f3d0-b283756b(a)192.168.0.113 >> <mailto:39d2f3d0-b283756b@192.168.0.113> >> <mailto:39d2f3d0-b283756b@192.168.0.113 >> <mailto:39d2f3d0-b283756b@192.168.0.113>> >> <mailto:39d2f3d0-b283756b@192.168.0.113 >> <mailto:39d2f3d0-b283756b@192.168.0.113> >> <mailto:39d2f3d0-b283756b@192.168.0.113 >> <mailto:39d2f3d0-b283756b@192.168.0.113>>>. >> >> CSeq: 102 INVITE. >> Server: 720 DEGRES SIP PROXY. >> Content-Length: 0. >> Warning: 392 77.246.81.132:5060 >> <http://77.246.81.132:5060> <http://77.246.81.132:5060> >> <http://77.246.81.132:5060> "Noisy feedback tells: >> pid=14141 >> req_src_ip=77.246.81.162 <http://77.246.81.162> >> <http://77.246.81.162> >> <http://77.246.81.162> req_src_port=8680 >> in_uri=sip:0123451013@sip.720.fr<sip%3A0123451013(a)sip.720.fr> >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> > >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> >> >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> > >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> <mailto:sip%25253A0123451013@sip.720.fr<sip%2525253A0123451013(a)sip.720.fr> >> >>> >> >> out_uri=sip:0123451013@sip.720.fr<sip%3A0123451013(a)sip.720.fr> >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> > >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> >> >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> > >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> <mailto:sip%25253A0123451013@sip.720.fr<sip%2525253A0123451013(a)sip.720.fr>>>> >> via_cnt==1". >> >> . >> >> >> U 2008/11/28 12:13:59.882639 77.246.81.132:5060 >> <http://77.246.81.132:5060> >> <http://77.246.81.132:5060> <http://77.246.81.132:5060> -> >> >> 77.246.81.162:1902 <http://77.246.81.162:1902> >> <http://77.246.81.162:1902> >> <http://77.246.81.162:1902> >> >> INVITE sip:0123451013@192.168.0.158:5060;user=phone >> SIP/2.0. >> Record-Route: <sip:77.246.81.132 <http://77.246.81.132> >> <http://77.246.81.132> >> <http://77.246.81.132 >> >;lr=on;ftag=4209e88c969ca7dfo0;nat=yes;vsf=dTRjN2NvOSh5O2l3chRUKWUpZWo5MGkrLFxGBRldBw-->. >> Via: SIP/2.0/UDP 77.246.81.132 <http://77.246.81.132> >> <http://77.246.81.132> >> <http://77.246.81.132>;branch=z9hG4bK821.3a570854.0. >> Via: SIP/2.0/UDP >> 192.168.0.113:5060;rport=8680;received=77.246.81.162 >> <http://77.246.81.162> >> <http://77.246.81.162> >> <http://77.246.81.162>;branch=z9hG4bK-eb23842c. >> >> From: "Anonymous" >> <sip:anonymous@anonymous.invalid>;tag=4209e88c969ca7dfo0. >> To: "st2030" <sip:0123451013@sip.720.fr<sip%3A0123451013(a)sip.720.fr> >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> > >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> >> >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> > >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> <mailto:sip%25253A0123451013@sip.720.fr<sip%2525253A0123451013(a)sip.720.fr> >> >>>>. >> >> Call-ID: 39d2f3d0-b283756b(a)192.168.0.113 >> <mailto:39d2f3d0-b283756b@192.168.0.113> >> <mailto:39d2f3d0-b283756b@192.168.0.113 >> <mailto:39d2f3d0-b283756b@192.168.0.113>> >> <mailto:39d2f3d0-b283756b@192.168.0.113 >> <mailto:39d2f3d0-b283756b@192.168.0.113> >> <mailto:39d2f3d0-b283756b@192.168.0.113 >> <mailto:39d2f3d0-b283756b@192.168.0.113>>>. >> >> CSeq: 102 INVITE. >> Max-Forwards: 49. >> Contact: "Sam" <sip:0123451010@77.246.81.162:8680 >> <http://sip:0123451010@77.246.81.162:8680> >> <http://sip:0123451010@77.246.81.162:8680> >> <http://sip:0123451010@77.246.81.162:8680>>. >> >> Expires: 240. >> User-Agent: Linksys/SPA941-5.1.8. >> Content-Length: 281. >> Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, >> PRACK, >> REFER. >> Supported: 100rel, replaces. >> Content-Type: application/sdp. >> Privacy: id. >> Remote-Party-ID: >> <<null>>;party=caller;privacy=yes;screen=no. >> . >> v=0. >> o=- 33629308 33629308 IN IP4 192.168.0.113 >> <http://192.168.0.113> >> <http://192.168.0.113> <http://192.168.0.113>. >> >> s=-. >> c=IN IP4 77.246.81.133 <http://77.246.81.133> >> <http://77.246.81.133> >> <http://77.246.81.133>. >> >> t=0 0. >> m=audio 35132 RTP/AVP 18 0 8 101. >> a=rtpmap:18 G729a/8000. >> a=rtpmap:0 PCMU/8000. >> a=rtpmap:8 PCMA/8000. >> a=rtpmap:101 telephone-event/8000. >> a=fmtp:101 0-15. >> a=ptime:30. >> a=sendrecv. >> a=nortpproxy:yes. >> >> >> U 2008/11/28 12:14:00.273883 77.246.81.132:5060 >> <http://77.246.81.132:5060> >> <http://77.246.81.132:5060> <http://77.246.81.132:5060> -> >> >> 77.246.81.162:1902 <http://77.246.81.162:1902> >> <http://77.246.81.162:1902> >> <http://77.246.81.162:1902> >> >> INVITE sip:0123451013@192.168.0.158:5060;user=phone >> SIP/2.0. >> Record-Route: <sip:77.246.81.132 <http://77.246.81.132> >> <http://77.246.81.132> >> <http://77.246.81.132 >> >;lr=on;ftag=4209e88c969ca7dfo0;nat=yes;vsf=dTRjN2NvOSh5O2l3chRUKWUpZWo5MGkrLFxGBRldBw-->. >> Via: SIP/2.0/UDP 77.246.81.132 <http://77.246.81.132> >> <http://77.246.81.132> >> <http://77.246.81.132>;branch=z9hG4bK821.3a570854.0. >> Via: SIP/2.0/UDP >> 192.168.0.113:5060;rport=8680;received=77.246.81.162 >> <http://77.246.81.162> >> <http://77.246.81.162> >> <http://77.246.81.162>;branch=z9hG4bK-eb23842c. >> >> From: "Anonymous" >> <sip:anonymous@anonymous.invalid>;tag=4209e88c969ca7dfo0. >> To: "st2030" <sip:0123451013@sip.720.fr<sip%3A0123451013(a)sip.720.fr> >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> > >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> >> >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> > >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> <mailto:sip%25253A0123451013@sip.720.fr<sip%2525253A0123451013(a)sip.720.fr> >> >>>>. >> >> Call-ID: 39d2f3d0-b283756b(a)192.168.0.113 >> <mailto:39d2f3d0-b283756b@192.168.0.113> >> <mailto:39d2f3d0-b283756b@192.168.0.113 >> <mailto:39d2f3d0-b283756b@192.168.0.113>> >> <mailto:39d2f3d0-b283756b@192.168.0.113 >> <mailto:39d2f3d0-b283756b@192.168.0.113> >> <mailto:39d2f3d0-b283756b@192.168.0.113 >> <mailto:39d2f3d0-b283756b@192.168.0.113>>>. >> >> CSeq: 102 INVITE. >> Max-Forwards: 49. >> Contact: "Sam" <sip:0123451010@77.246.81.162:8680 >> <http://sip:0123451010@77.246.81.162:8680> >> <http://sip:0123451010@77.246.81.162:8680> >> <http://sip:0123451010@77.246.81.162:8680>>. >> >> Expires: 240. >> User-Agent: Linksys/SPA941-5.1.8. >> Content-Length: 281. >> Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, >> PRACK, >> REFER. >> Supported: 100rel, replaces. >> Content-Type: application/sdp. >> Privacy: id. >> Remote-Party-ID: >> <<null>>;party=caller;privacy=yes;screen=no. >> . >> v=0. >> o=- 33629308 33629308 IN IP4 192.168.0.113 >> <http://192.168.0.113> >> <http://192.168.0.113> <http://192.168.0.113>. >> >> s=-. >> c=IN IP4 77.246.81.133 <http://77.246.81.133> >> <http://77.246.81.133> >> <http://77.246.81.133>. >> >> t=0 0. >> m=audio 35132 RTP/AVP 18 0 8 101. >> a=rtpmap:18 G729a/8000. >> a=rtpmap:0 PCMU/8000. >> a=rtpmap:8 PCMA/8000. >> a=rtpmap:101 telephone-event/8000. >> a=fmtp:101 0-15. >> a=ptime:30. >> a=sendrecv. >> a=nortpproxy:yes. >> >> >> U 2008/11/28 12:14:01.272604 77.246.81.132:5060 >> <http://77.246.81.132:5060> >> <http://77.246.81.132:5060> <http://77.246.81.132:5060> -> >> >> 77.246.81.162:1902 <http://77.246.81.162:1902> >> <http://77.246.81.162:1902> >> <http://77.246.81.162:1902> >> >> INVITE sip:0123451013@192.168.0.158:5060;user=phone >> SIP/2.0. >> Record-Route: <sip:77.246.81.132 <http://77.246.81.132> >> <http://77.246.81.132> >> <http://77.246.81.132 >> >;lr=on;ftag=4209e88c969ca7dfo0;nat=yes;vsf=dTRjN2NvOSh5O2l3chRUKWUpZWo5MGkrLFxGBRldBw-->. >> Via: SIP/2.0/UDP 77.246.81.132 <http://77.246.81.132> >> <http://77.246.81.132> >> <http://77.246.81.132>;branch=z9hG4bK821.3a570854.0. >> Via: SIP/2.0/UDP >> 192.168.0.113:5060;rport=8680;received=77.246.81.162 >> <http://77.246.81.162> >> <http://77.246.81.162> >> <http://77.246.81.162>;branch=z9hG4bK-eb23842c. >> >> From: "Anonymous" >> <sip:anonymous@anonymous.invalid>;tag=4209e88c969ca7dfo0. >> To: "st2030" <sip:0123451013@sip.720.fr<sip%3A0123451013(a)sip.720.fr> >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> > >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> >> >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> > >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> <mailto:sip%25253A0123451013@sip.720.fr<sip%2525253A0123451013(a)sip.720.fr> >> >>>>. >> >> Call-ID: 39d2f3d0-b283756b(a)192.168.0.113 >> <mailto:39d2f3d0-b283756b@192.168.0.113> >> <mailto:39d2f3d0-b283756b@192.168.0.113 >> <mailto:39d2f3d0-b283756b@192.168.0.113>> >> <mailto:39d2f3d0-b283756b@192.168.0.113 >> <mailto:39d2f3d0-b283756b@192.168.0.113> >> <mailto:39d2f3d0-b283756b@192.168.0.113 >> <mailto:39d2f3d0-b283756b@192.168.0.113>>>. >> >> CSeq: 102 INVITE. >> Max-Forwards: 49. >> Contact: "Sam" <sip:0123451010@77.246.81.162:8680 >> <http://sip:0123451010@77.246.81.162:8680> >> <http://sip:0123451010@77.246.81.162:8680> >> <http://sip:0123451010@77.246.81.162:8680>>. >> >> Expires: 240. >> User-Agent: Linksys/SPA941-5.1.8. >> Content-Length: 281. >> Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, >> PRACK, >> REFER. >> Supported: 100rel, replaces. >> Content-Type: application/sdp. >> Privacy: id. >> Remote-Party-ID: >> <<null>>;party=caller;privacy=yes;screen=no. >> . >> v=0. >> o=- 33629308 33629308 IN IP4 192.168.0.113 >> <http://192.168.0.113> >> <http://192.168.0.113> <http://192.168.0.113>. >> >> s=-. >> c=IN IP4 77.246.81.133 <http://77.246.81.133> >> <http://77.246.81.133> >> <http://77.246.81.133>. >> >> t=0 0. >> m=audio 35132 RTP/AVP 18 0 8 101. >> a=rtpmap:18 G729a/8000. >> a=rtpmap:0 PCMU/8000. >> a=rtpmap:8 PCMA/8000. >> a=rtpmap:101 telephone-event/8000. >> a=fmtp:101 0-15. >> a=ptime:30. >> a=sendrecv. >> a=nortpproxy:yes. >> >> >> U 2008/11/28 12:14:03.283852 77.246.81.132:5060 >> <http://77.246.81.132:5060> >> <http://77.246.81.132:5060> <http://77.246.81.132:5060> -> >> >> 77.246.81.162:1902 <http://77.246.81.162:1902> >> <http://77.246.81.162:1902> >> <http://77.246.81.162:1902> >> >> INVITE sip:0123451013@192.168.0.158:5060;user=phone >> SIP/2.0. >> Record-Route: <sip:77.246.81.132 <http://77.246.81.132> >> <http://77.246.81.132> >> <http://77.246.81.132 >> >;lr=on;ftag=4209e88c969ca7dfo0;nat=yes;vsf=dTRjN2NvOSh5O2l3chRUKWUpZWo5MGkrLFxGBRldBw-->. >> Via: SIP/2.0/UDP 77.246.81.132 <http://77.246.81.132> >> <http://77.246.81.132> >> <http://77.246.81.132>;branch=z9hG4bK821.3a570854.0. >> Via: SIP/2.0/UDP >> 192.168.0.113:5060;rport=8680;received=77.246.81.162 >> <http://77.246.81.162> >> <http://77.246.81.162> >> <http://77.246.81.162>;branch=z9hG4bK-eb23842c. >> >> From: "Anonymous" >> <sip:anonymous@anonymous.invalid>;tag=4209e88c969ca7dfo0. >> To: "st2030" <sip:0123451013@sip.720.fr<sip%3A0123451013(a)sip.720.fr> >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> > >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> >> >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> > >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> <mailto:sip%25253A0123451013@sip.720.fr<sip%2525253A0123451013(a)sip.720.fr> >> >>>>. >> >> Call-ID: 39d2f3d0-b283756b(a)192.168.0.113 >> <mailto:39d2f3d0-b283756b@192.168.0.113> >> <mailto:39d2f3d0-b283756b@192.168.0.113 >> <mailto:39d2f3d0-b283756b@192.168.0.113>> >> <mailto:39d2f3d0-b283756b@192.168.0.113 >> <mailto:39d2f3d0-b283756b@192.168.0.113> >> <mailto:39d2f3d0-b283756b@192.168.0.113 >> <mailto:39d2f3d0-b283756b@192.168.0.113>>>. >> >> CSeq: 102 INVITE. >> Max-Forwards: 49. >> Contact: "Sam" <sip:0123451010@77.246.81.162:8680 >> <http://sip:0123451010@77.246.81.162:8680> >> <http://sip:0123451010@77.246.81.162:8680> >> <http://sip:0123451010@77.246.81.162:8680>>. >> >> Expires: 240. >> User-Agent: Linksys/SPA941-5.1.8. >> Content-Length: 281. >> Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, >> PRACK, >> REFER. >> Supported: 100rel, replaces. >> Content-Type: application/sdp. >> Privacy: id. >> Remote-Party-ID: >> <<null>>;party=caller;privacy=yes;screen=no. >> . >> v=0. >> o=- 33629308 33629308 IN IP4 192.168.0.113 >> <http://192.168.0.113> >> <http://192.168.0.113> <http://192.168.0.113>. >> >> s=-. >> c=IN IP4 77.246.81.133 <http://77.246.81.133> >> <http://77.246.81.133> >> <http://77.246.81.133>. >> >> t=0 0. >> m=audio 35132 RTP/AVP 18 0 8 101. >> a=rtpmap:18 G729a/8000. >> a=rtpmap:0 PCMU/8000. >> a=rtpmap:8 PCMA/8000. >> a=rtpmap:101 telephone-event/8000. >> a=fmtp:101 0-15. >> a=ptime:30. >> a=sendrecv. >> a=nortpproxy:yes. >> >> >> U 2008/11/28 12:14:04.905612 77.246.81.162:8680 >> <http://77.246.81.162:8680> >> <http://77.246.81.162:8680> <http://77.246.81.162:8680> -> >> >> 77.246.81.132:5060 <http://77.246.81.132:5060> >> <http://77.246.81.132:5060> >> <http://77.246.81.132:5060> >> CANCEL sip:0123451013@sip.720.fr<sip%3A0123451013(a)sip.720.fr> >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> > >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> >> >> <mailto:sip%3A0123451013@sip.720.fr<sip%253A0123451013(a)sip.720.fr> >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> > >> <mailto:sip%253A0123451013@sip.720.fr<sip%25253A0123451013(a)sip.720.fr> >> <mailto:sip%25253A0123451013@sip.720.fr<sip%2525253A0123451013(a)sip.720.fr>>>> >> SIP/2.0. >> >> >> Via: SIP/2.0/UDP 192.168.0.113:5060 >> ;branch=z9hG4bK-eb23842c. >> From: "Sam" <sip:0123451010@sip.720.fr<sip%3A0123451010(a)sip.720.fr> >> <mailto:sip%3A0123451010@sip.720.fr<sip%253A0123451010(a)sip.720.fr> >> > >> <mailto:sip%3A0123451010@sip.720.fr<sip%253A0123451010(a)sip.720.fr> >> <mailto:sip%253A0123451010@sip.720.fr<sip%25253A0123451010(a)sip.720.fr> >> >> >> <mailto:sip%3A0123451010@sip.720.fr<sip%253A0123451010(a)sip.720.fr> >> <mailto:sip%253A0123451010@sip.720.fr<sip%25253A0123451010(a)sip.720.fr> >> > >> <mailto:sip%253A0123451010@sip.720.fr<sip%25253A0123451010(a)sip.720.fr> >> <mailto:sip%25253A0123451010@ <sip%2525253A0123451010(a)sip.720.fr> > > ... > > [Message clipped] -- Samuel MULLER Ingénieur Reseaux & Telecom 720 DEGRES +33 (0)663 128 505 sml(a)720.fr

2 1

[Kamailio-Users] Thomson ST2030 SIP contact problem
by Samuel Muller 01 Dec '08

01 Dec '08

Hello all, I've a little problem with the SIP phone Thomson ST2030. When it registers, it auto-adds ";user=phone" in all the fields it can be. The problem is that it can't be called due to the contact header, kamailio can't found the phone. I tried to delete the filed during the REGISTER and the PROXY AUTH processes, with no success ... If someone has a solution, many thanks ! -- -- kamailio.cfg : -- -- ... # ;user=phone hack if (search("^Contact:.*;user=phone")) { xlog("L_INFO", "-> user=phone found, remove it - F=$fu ContactHF=$ct"); replace_all(";user=phone", "\r\n"); #subst("/;user=phone$;$")) } ... => all the logs here : -- -- SQL result -- -- Database: openser SQL query: SELECT * FROM `location` WHERE `id` = 383 LIMIT 0, 30 ; id 383 username 0123451013 domain sip.720.fr contact sip:0123451013@192.168.0.158:5060;user=phone received sip:77.246.81.162:1902 path NULL expires 2008-11-28 13:02:16 q 0.00 callid 18786315-c0a80101-5-a(a)192.168.0.158 cseq 270 last_modified 2008-11-28 12:02:16 flags 0 cflags 64 user_agent THOMSON ST2030 hw5 fw1.63 00-14-7F-00-5E-0A socket udp:77.246.81.132:5060 methods NULL -- -- kamailio REGISTER sip buffer -- -- REGISTER sip:sip.720.fr;user=phone SIP/2.0 Via: SIP/2.0/UDP 192.168.0.158:5060 ;branch=z9hG4bK363142985921875976-158787787 From: <sip:0123451013@sip.720.fr:5060;user=phone>;tag=c0a80101-976e8ab To: <sip:0123451013@sip.720.fr:5060;user=phone> Call-ID: 18786315-c0a80101-5-a(a)192.168.0.158 CSeq: 250 REGISTER Max-Forwards: 69 Expires: 3600 Contact: <sip:0123451013@192.168.0.158:5060;user=phone> Authorization: Digest username="0123451013", realm="sip.720.fr", nonce="492f8a92000000697e7fefd30ce752d7e50c6166da2cc6e2", uri="sip:sip.720.fr", response="37f8ec824ba77eb37583f38f2a509f77", algorithm=MD5, qop=auth, cnonce="976e8cb", nc=00000001 User-Agent: THOMSON ST2030 hw5 fw1.63 00-14-7F-00-5E-0A Allow-Events: refer,dialog,message-summary,check-sync,talk,hold Content-Length: 0 -- -- ngrep log : -- -- U 2008/11/28 12:13:59.813649 77.246.81.162:8680 -> 77.246.81.132:5060 INVITE sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr> SIP/2.0. Via: SIP/2.0/UDP 192.168.0.113:5060;branch=z9hG4bK-eb23842c. From: "Sam" <sip:0123451010@sip.720.fr <sip%3A0123451010(a)sip.720.fr> >;tag=4209e88c969ca7dfo0. To: "st2030" <sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr>>. Remote-Party-ID: "Sam" <sip:0123451010@sip.720.fr<sip%3A0123451010(a)sip.720.fr> >;screen=yes;party=calling. Call-ID: 39d2f3d0-b283756b(a)192.168.0.113. CSeq: 102 INVITE. Max-Forwards: 50. Proxy-Authorization: Digest username="0123451010",realm="sip.720.fr ",nonce="492fd3a300000094c9e8b4f3805f7f96dc3f36f981a64570",uri=" sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr> ",algorithm=MD5,response="1538e1ac3e3181f8bfb6f473f2470a6a",qop=auth,nc=00000001,cnonce="7c8a76fd". Contact: "Sam" <sip:0123451010@192.168.0.113:5060>. Expires: 240. User-Agent: Linksys/SPA941-5.1.8. Content-Length: 263. Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER. Supported: 100rel, replaces. Content-Type: application/sdp. . v=0. o=- 33629308 33629308 IN IP4 192.168.0.113. s=-. c=IN IP4 192.168.0.113. t=0 0. m=audio 35692 RTP/AVP 18 0 8 101. a=rtpmap:18 G729a/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:30. a=sendrecv. U 2008/11/28 12:13:59.820056 77.246.81.132:5060 -> 77.246.81.162:8680 SIP/2.0 100 Trying. Via: SIP/2.0/UDP 192.168.0.113:5060 ;branch=z9hG4bK-eb23842c;rport=8680;received=77.246.81.162. From: "Sam" <sip:0123451010@sip.720.fr <sip%3A0123451010(a)sip.720.fr> >;tag=4209e88c969ca7dfo0. To: "st2030" <sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr>>. Call-ID: 39d2f3d0-b283756b(a)192.168.0.113. CSeq: 102 INVITE. Server: 720 DEGRES SIP PROXY. Content-Length: 0. Warning: 392 77.246.81.132:5060 "Noisy feedback tells: pid=14141 req_src_ip=77.246.81.162 req_src_port=8680 in_uri=sip:0123451013@sip.720.fr<sip%3A0123451013(a)sip.720.fr>out_uri= sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr> via_cnt==1". . U 2008/11/28 12:13:59.882639 77.246.81.132:5060 -> 77.246.81.162:1902 INVITE sip:0123451013@192.168.0.158:5060;user=phone SIP/2.0. Record-Route: <sip:77.246.81.132 ;lr=on;ftag=4209e88c969ca7dfo0;nat=yes;vsf=dTRjN2NvOSh5O2l3chRUKWUpZWo5MGkrLFxGBRldBw-->. Via: SIP/2.0/UDP 77.246.81.132;branch=z9hG4bK821.3a570854.0. Via: SIP/2.0/UDP 192.168.0.113:5060;rport=8680;received=77.246.81.162 ;branch=z9hG4bK-eb23842c. From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=4209e88c969ca7dfo0. To: "st2030" <sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr>>. Call-ID: 39d2f3d0-b283756b(a)192.168.0.113. CSeq: 102 INVITE. Max-Forwards: 49. Contact: "Sam" <sip:0123451010@77.246.81.162:8680>. Expires: 240. User-Agent: Linksys/SPA941-5.1.8. Content-Length: 281. Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER. Supported: 100rel, replaces. Content-Type: application/sdp. Privacy: id. Remote-Party-ID: <<null>>;party=caller;privacy=yes;screen=no. . v=0. o=- 33629308 33629308 IN IP4 192.168.0.113. s=-. c=IN IP4 77.246.81.133. t=0 0. m=audio 35132 RTP/AVP 18 0 8 101. a=rtpmap:18 G729a/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:30. a=sendrecv. a=nortpproxy:yes. U 2008/11/28 12:14:00.273883 77.246.81.132:5060 -> 77.246.81.162:1902 INVITE sip:0123451013@192.168.0.158:5060;user=phone SIP/2.0. Record-Route: <sip:77.246.81.132 ;lr=on;ftag=4209e88c969ca7dfo0;nat=yes;vsf=dTRjN2NvOSh5O2l3chRUKWUpZWo5MGkrLFxGBRldBw-->. Via: SIP/2.0/UDP 77.246.81.132;branch=z9hG4bK821.3a570854.0. Via: SIP/2.0/UDP 192.168.0.113:5060;rport=8680;received=77.246.81.162 ;branch=z9hG4bK-eb23842c. From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=4209e88c969ca7dfo0. To: "st2030" <sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr>>. Call-ID: 39d2f3d0-b283756b(a)192.168.0.113. CSeq: 102 INVITE. Max-Forwards: 49. Contact: "Sam" <sip:0123451010@77.246.81.162:8680>. Expires: 240. User-Agent: Linksys/SPA941-5.1.8. Content-Length: 281. Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER. Supported: 100rel, replaces. Content-Type: application/sdp. Privacy: id. Remote-Party-ID: <<null>>;party=caller;privacy=yes;screen=no. . v=0. o=- 33629308 33629308 IN IP4 192.168.0.113. s=-. c=IN IP4 77.246.81.133. t=0 0. m=audio 35132 RTP/AVP 18 0 8 101. a=rtpmap:18 G729a/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:30. a=sendrecv. a=nortpproxy:yes. U 2008/11/28 12:14:01.272604 77.246.81.132:5060 -> 77.246.81.162:1902 INVITE sip:0123451013@192.168.0.158:5060;user=phone SIP/2.0. Record-Route: <sip:77.246.81.132 ;lr=on;ftag=4209e88c969ca7dfo0;nat=yes;vsf=dTRjN2NvOSh5O2l3chRUKWUpZWo5MGkrLFxGBRldBw-->. Via: SIP/2.0/UDP 77.246.81.132;branch=z9hG4bK821.3a570854.0. Via: SIP/2.0/UDP 192.168.0.113:5060;rport=8680;received=77.246.81.162 ;branch=z9hG4bK-eb23842c. From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=4209e88c969ca7dfo0. To: "st2030" <sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr>>. Call-ID: 39d2f3d0-b283756b(a)192.168.0.113. CSeq: 102 INVITE. Max-Forwards: 49. Contact: "Sam" <sip:0123451010@77.246.81.162:8680>. Expires: 240. User-Agent: Linksys/SPA941-5.1.8. Content-Length: 281. Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER. Supported: 100rel, replaces. Content-Type: application/sdp. Privacy: id. Remote-Party-ID: <<null>>;party=caller;privacy=yes;screen=no. . v=0. o=- 33629308 33629308 IN IP4 192.168.0.113. s=-. c=IN IP4 77.246.81.133. t=0 0. m=audio 35132 RTP/AVP 18 0 8 101. a=rtpmap:18 G729a/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:30. a=sendrecv. a=nortpproxy:yes. U 2008/11/28 12:14:03.283852 77.246.81.132:5060 -> 77.246.81.162:1902 INVITE sip:0123451013@192.168.0.158:5060;user=phone SIP/2.0. Record-Route: <sip:77.246.81.132 ;lr=on;ftag=4209e88c969ca7dfo0;nat=yes;vsf=dTRjN2NvOSh5O2l3chRUKWUpZWo5MGkrLFxGBRldBw-->. Via: SIP/2.0/UDP 77.246.81.132;branch=z9hG4bK821.3a570854.0. Via: SIP/2.0/UDP 192.168.0.113:5060;rport=8680;received=77.246.81.162 ;branch=z9hG4bK-eb23842c. From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=4209e88c969ca7dfo0. To: "st2030" <sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr>>. Call-ID: 39d2f3d0-b283756b(a)192.168.0.113. CSeq: 102 INVITE. Max-Forwards: 49. Contact: "Sam" <sip:0123451010@77.246.81.162:8680>. Expires: 240. User-Agent: Linksys/SPA941-5.1.8. Content-Length: 281. Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER. Supported: 100rel, replaces. Content-Type: application/sdp. Privacy: id. Remote-Party-ID: <<null>>;party=caller;privacy=yes;screen=no. . v=0. o=- 33629308 33629308 IN IP4 192.168.0.113. s=-. c=IN IP4 77.246.81.133. t=0 0. m=audio 35132 RTP/AVP 18 0 8 101. a=rtpmap:18 G729a/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:30. a=sendrecv. a=nortpproxy:yes. U 2008/11/28 12:14:04.905612 77.246.81.162:8680 -> 77.246.81.132:5060 CANCEL sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr> SIP/2.0. Via: SIP/2.0/UDP 192.168.0.113:5060;branch=z9hG4bK-eb23842c. From: "Sam" <sip:0123451010@sip.720.fr <sip%3A0123451010(a)sip.720.fr> >;tag=4209e88c969ca7dfo0. To: "st2030" <sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr>>. Call-ID: 39d2f3d0-b283756b(a)192.168.0.113. CSeq: 102 CANCEL. Max-Forwards: 50. Proxy-Authorization: Digest username="0123451010",realm="sip.720.fr ",nonce="492fd3a300000094c9e8b4f3805f7f96dc3f36f981a64570",uri=" sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr> ",algorithm=MD5,response="07e4433c6000309b8cac1f917dbb9643",qop=auth,nc=00000002,cnonce="7c8a76fd". User-Agent: Linksys/SPA941-5.1.8. Content-Length: 0. . U 2008/11/28 12:14:04.912088 77.246.81.132:5060 -> 77.246.81.162:8680 SIP/2.0 501 Method Not Supported Here. Via: SIP/2.0/UDP 192.168.0.113:5060 ;branch=z9hG4bK-eb23842c;rport=8680;received=77.246.81.162. From: "Sam" <sip:0123451010@sip.720.fr <sip%3A0123451010(a)sip.720.fr> >;tag=4209e88c969ca7dfo0. To: "st2030" <sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr> >;tag=d25c9349df891607b66aeb00d1da49ca.b1d0. Call-ID: 39d2f3d0-b283756b(a)192.168.0.113. CSeq: 102 CANCEL. Server: 720 DEGRES SIP PROXY. Content-Length: 0. Warning: 392 77.246.81.132:5060 "Noisy feedback tells: pid=14137 req_src_ip=77.246.81.162 req_src_port=8680 in_uri=sip:0123451013@sip.720.fr<sip%3A0123451013(a)sip.720.fr>out_uri= sip:0123451013@sip.720.fr <sip%3A0123451013(a)sip.720.fr> via_cnt==1". -- Samuel MULLER Ingénieur Reseaux & Telecom 720 DEGRES +33 (0)663 128 505 sml(a)720.fr

3 6

[Kamailio-Users] Webx-SER: a new project to give kamailio users a web interface (like Serweb was)
by yannick 30 Nov '08

30 Nov '08

Hello, I started a project to give users of Kamailio server a web interface to register and manage their datas. It was inspired by a need of the Ekiga.net platform ( https://www.ekiga.net ) to allow users register like they were able to do when Ekiga.net was using SER and Serweb. I called this software Webx-SER. Webx-SER feature now: * Registration of accounts to kamailio * Password reminder * Changing password Technically, Webx-SER use PHP and MySQL. It has a cache system for common non-interactives pages, a template system to split HTML from PHP and a captcha system to prevent bots. Some work has been put in managing forms to make it user-friendly. The licence is GPL 3 or higher. Webx-SER is actually used on https://www.ekiga.net There is a web site for Webx-SER developments, including users and devels mailing-list, bug tracking system, source tarball releases and GIT repository for source code here: http://webxser.tuxfamily.org/ Feedback, comments, help in coding will be warmly welcome. I also want to thanks Damien Sandras and Jan Schampera for their help, support and inspiration. Best regards, Yannick Defais -- Me joindre en téléphonie IP / vidéoconférence ? sip:yannick@ekiga.net Logiciel de VoIP Ekiga : http://www.ekiga.org http://wiki.ekiga.org/index.php/Which_programs_work_with_Ekiga_%3F

2 3

[Kamailio-Users] Attendant call transfer between asterisk gateway and OpenSER problem
by muhammad akl 28 Nov '08

28 Nov '08

I have the following scenario : Pstn Number(1234567) <-----------> Asterisk GW <----------------> Openser | <-------------->11803 | | | <--------------> 11801 Firstly extension 11803 will call the pstn number and this works fine without no problem , after that 11803 will put 1234567 on hold and will call 11801 , then 11803 will transfer 1234567 to 11801 (<---- the problem now started ), what is happening now is that both 123456 and 11801 will be on hold with 11803 after the transfer is done I've traced the full dialog between the three extensions and found an interesting part , which a NOTIFY message came from asterisk and contains this sentence : SIP/2.0 481 Call leg/transaction does not exist The addresses of the devices as follows : Asterisk Gw : 192.168.200.202 OpenSER : 192.168.200.10 11803 : 192.168.200.222 11801 : 192.168.200.224 The full trace : http://muhammad.akl.googlepages.com/debug.txt Regards

2 2

Re: [Kamailio-Users] Trying to deliver a call across multiple peers with t_relay
by Tyler Brauer 28 Nov '08

28 Nov '08

Thank you Klaus for the suggestions. I've implemented the configuration below. When the first t_relay fails, Kamailio generates the 408 Request Timeout and doesn't attempt to try an INVITE to the second address. This what the syslog says: Nov 28 06:11:13 server kamailio[1315]: Attempting Carrier 1 Nov 28 06:11:28 server kamailio[1323]: Attempting Carrier 2 Nov 28 06:11:28 server kamailio[1323]: ERROR:tm:t_forward_nonack: no branch for forwarding Nov 28 06:11:28 server kamailio[1323]: ERROR:tm:w_t_relay: t_forward_nonack failed Nov 28 06:11:28 server kamailio[1317]: Attempting Carrier 1 And here's the watered-down version of my configuration. # - - - - - - - - - - - - - - - - - - - - route[0] { if($si=='10.10.10.10') { # Allowed Host route(1); } else { sl_send_reply("603", "Decline"); exit; } } # - - - - - - - - - - - - - - - - - - - - route[1] { if(msg:len > 2048) { sl_send_reply("513", "Message Too Big"); exit; } if (!mf_process_maxfwd_header("10")) { sl_send_reply("483", "Too Many Hops"); exit; } if (method==OPTIONS) { if ((uri==myself) && (! uri=~"sip:.*[@]+.*")) { options_reply(); exit; } } if (!method=="REGISTER") { record_route(); } if (loose_route()) { append_hf("P-hint: rr-enforced\r\n"); } if (is_method("CANCEL")) { if (t_check_trans()) { t_relay(); } exit; } route(2); } # - - - - - - - - - - - - - - - - - - - - route[2] { xlog("L_INFO", "Attempting Carrier 1"); t_on_failure("3"); t_relay("udp:1.1.1.1:5090","0x2"); exit; } # - - - - - - - - - - - - - - - - - - - - failure_route[3] { xlog("L_INFO", "Attempting Carrier 2"); t_on_failure("4"); t_relay("udp:2.2.2.2:5060"); exit; } # - - - - - - - - - - - - - - - - - - - - failure_route[4] { # I would like to know how to redirect the # original call destined to extension "100" # to 2015551234, but the originating server # will get nervous if the username@ part # of its SIP request is changed. How could } # - - - - - - - - - - - - - - - - - - - - Any further suggestions would be appreciated. Thanks!

2 1

[Kamailio-Users] Does enum_query support wildcard and non-terminal NAPTR record ?
by jerome boileau 28 Nov '08

28 Nov '08

Hi, I'm testing an ENUM DNS server (BIND9) with Openser 1.2.0. It seems that Openser Enum module doesn't support wildcard and non terminal NAPTR record. Enum module is working well when the NAPTR record is defined in the ENUM DNS with complete phone number and ‘u’ flag. Here is an example of the NAPTR record: 1.2.3.4.5.6.7.8.9.3.3.enum1.net IN NAPTR 10 100 "u" "E2U+sip" "!^.*$!sip:+33987654321@example.com!". When I declared a wildcard in the ENUM DNS (ie: *.enum1.net IN NAPTR 10 100 "u" "E2U+sip" "!^.*$!sip:+33987654321@example.com!".), enum_query function didn't find the NAPTR record. The following message is returned in the log, enum_query(): No NAPTR record found for 1.2.3.4.5.6.7.8.9.3.3.enum1.net. Should resolver (ie resolve.c source file) or enum module be modified to handle wildcard or is it just a parameter to set ? In case of wildcard CNAME record instead of NAPTR, openser behave in the same way, the CNAME record was not found. I also tried to use a non-terminal NAPTR to forward the ENUM DNS query towards another domain. Here is the NAPTR record declared in the ENUM DNS: 1.2.3.4.5.6.7.8.9.3.3.enum1.net IN NAPTR 10 100 "" "" "!^.*([0-9]{11})$!\\1.enum2.net!". By using sip_match function, the enum_query (ie do_query) function discards the NAPTR record without ‘u’ flag. I removed the check on the flag (comment sip_match function) so the NAPTR record is not discarded. But instead of looking for the terminal NATR record, enum_query function overwrites the Request URI with the non-terminal NAPTR record. Is the handling of non terminal NAPTR fixed in a new version of enum module ? If not, is it planned ? Thanks in advance for your help. Best regards, Jérôme -- View this message in context: http://www.nabble.com/Does-enum_query-support-wildcard-and-non-terminal-NAP… Sent from the OpenSER Users Mailing List mailing list archive at Nabble.com.

3 3

[Kamailio-Users] simultaneus calls limitations
by BERGANZ François 28 Nov '08

28 Nov '08

Hello all, How can I contrôle « simultaneus calls limitation I could try to add in the database the number off simultaneous calls per user and when I check invite+1 cancel-1 bye-1 busy-1 BUT I have to insert in the database for each calls the call-id to know which user to do +1 or -1 Have you another idea? Thank you Cordialement, BERGANZ François P Pensez à l'Environnement, n'imprimez ce mail que si nécessaire.

2 1

[Kamailio-Users] How to add Retry-After header in 503 response
by Alex Hermann 28 Nov '08

28 Nov '08

Hello, is there a way to add a Retry-After header to a 503 response i'm sending out using t_reply? Use case: t_relay creates an internal 408 on timeout. From failure-route, i want to pass it upstream as 503 with retry-after header. Changing the reply to 503 using t_reply works, but how to add the header? The reply obviously doens't pass through any reply_route. -- Greetings, Alex Hermann

3 4

[Kamailio-Users] Trying to deliver a call across multiple peers with t_relay
by Tyler Brauer 28 Nov '08

28 Nov '08

Good morning/afternoon/evening! I'm trying to accomplish two things. * First, I'd like to try sending a call from our B2BUA through Kamailio to one of our SIP peers, but in the event that the peer is unreachable, try the same call across an alternate peer. I'm currently trying something in our routing block like this. if(!t_relay("udp:1.1.1.1:5060","0x2")) { if(!t_relay("udp:2.2.2.2:5060")) { xlog("L_INFO", "Could not complete"); } } I've also been trying to put together something similar using t_on_failure(#) and a failure_route[#] block to say "if the first t_relay fails, try this instead". In both instances, when fr_timer elapses because the first peer hasn't responded to an INVITE, I can't stop Kamailio from throwing a "SIP/2.0 408 Request Timeout" back to the B2BUA. I have tried setting the flag on t_relay to keep quiet in the event of a forward failure, and instead use something like sl_send_reply("181", "Call Is Being Forwarded") to say to the agent "hold on, we're still trying". I can't seem to find the syntax to make any of that work. The 408 still keeps getting delivered (in spite of the flag on t_relay) to our server, which causes it to stop trying to deliver the call through Kamailio. * The second thing I'd like is that if the first two peers are unavailable, the request is rewritten to go across a third peer as a PSTN call. (eg: a call tries to reach 101(a)1.1.1.1 fails, then 101(a)2.2.2.2 fails, so then 2015551234(a)3.3.3.3 is tried). This requires rewriting the username field of the request URI, but I'm not sure how to do that without confusing the originating server. Could anyone help with the config syntax to resolve either of those two problems? Thank you very much!

3 2

[Kamailio-Users] important: pseudo-variables moved from core to pv module
by Elena-Ramona Modroiu 27 Nov '08

27 Nov '08

Hi, all pseudo-variables exported by core in the past are now in PV module. Therefore if you use any of them in your config you have to load the PV module. This is valid with devel version (trunk). This change was discussed some time ago on devel mailing list, the core is slimmer now. Soon transformations will be moved as well, making possible to export new transformations from modules. The core will include only the API to export PV and transformations, plus the engine to use them in config file. Regards, Ramona

3 2

[Serusers] Registering port instead of contact field port
by Daniel Serrano 27 Nov '08

27 Nov '08

Dear all, I am using SER as IM server and I found that the SER use the contact field to storage the user's location in the memory for future requests. I noted this using the command "serctl alias show" and checking some traces. Since I'm using a NAT scenario I'd like to use the UDP port that my SER server receives during the registration instead of the contact field port to reach the users after their registration. Is there any way to do this? Thanks in advanced. * Daniel Serrano D.** *

2 1

[Kamailio-Users] WARNING dbrow2info: non-local socket
by ALAEDDINE abbech 27 Nov '08

27 Nov '08

Hi, maybe this has been discussed before and maybe I'm not too good in reading mailinglists, but anyhow. If you have two OpenSER proxies storing to the same location table. I see in my logs: WARNING:usrloc:dbrow2info: non-local socket @of other server:5060 ...ignoring, I have a probleme with my DB when i register some UA. This is crucial? If this is not crucial, might this message be supressed in some way? Thanks,

2 3

Re: [Kamailio-Users] method value of the CSeq field
by Alex Balashov 27 Nov '08

27 Nov '08

Iñaki Baz Castillo wrote: > El Miércoles, 26 de Noviembre de 2008, Alex Balashov escribió: >> Iñaki Baz Castillo wrote: >>> El Miércoles, 26 de Noviembre de 2008, Alex Balashov escribió: >>>> You can parse it yourself using textops from $hdr(CSeq). >>> Not needed at all, just read $rm variable (works for requests and >>> responses). >> I didn't say it was needed, just that it could be done. ;) $rm is >> definitely best. > > I agree with you, parsing $hdr(CSeq) is cooler XD > In about the same measure that #include <stdio.h> #include <stdlib.h> int main(void) { FILE *fp = fopen("/dev/stdout", "w"); fprintf(fp, "Hello World!\n"); fclose(fp); return EXIT_SUCCESS; } is cooler than 10 PRINT "HELLO WORLD" 20 END :) -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599

2 1

[Kamailio-Users] http_query function
by jh＠tutpro.com 27 Nov '08

27 Nov '08

--text follows this line-- i wrote a http_query function that allows kamailio to make an http request and get access to parts of the reply. see trunk/modules/utils/README for details. -- juha

7 19

[Kamailio-Users] attendant call transfer between asterisk gateway and OpenSER problem
by muhammad akl 27 Nov '08

27 Nov '08

I have the following scenario : Pstn Number(1234567) <-----------> Asterisk GW <----------------> Openser | <-------------->11803 | | | <--------------> 11801 Firstly extension 11803 will call the pstn number and this works fine without no problem , after that 11803 will put 1234567 on hold and will call 11801 , then 11803 will transfer 1234567 to 11801 (<---- the problem now started ), what is happening now is that both 123456 and 11801 will be on hold with 11803 after the transfer is done I've traced the full dialog between the three extensions and found an interesting part , which a NOTIFY message came from asterisk and contains this sentence : SIP/2.0 481 Call leg/transaction does not exist The addresses of the devices as follows : Asterisk Gw : 192.168.200.202 OpenSER : 192.168.200.10 11803 : 192.168.200.222 11801 : 192.168.200.224 The full trace is below : interface: nge1 (192.168.200.0/255.255.255.0) filter: (ip) and ( port 5060 ) # U 192.168.200.222:5060 -> 192.168.200.10:5060 INVITE sip:1234567@192.168.200.10:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T1DC2F22B. Session-Expires: 1800. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372869 INVITE. Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 70. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Supported: timer,replaces. User-Agent: DPH-14001.01. Content-Type: application/sdp. Content-Length: 242. . v=0. o=11803 273718813 273718813 IN IP4 192.168.200.222. s=DPH-14001.01. c=IN IP4 192.168.200.222. t=0 0. m=audio 41000 RTP/AVP 0 18 4. a=rtpmap:0 PCMU/8000/1. a=rtpmap:18 G729/8000/1. a=fmtp:18 annexb=no. a=rtpmap:4 G723/8000/1. a=sendrecv. 8 # U 192.168.200.10:5060 -> 192.168.200.222:5060 SIP/2.0 407 Proxy Authentication Required. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T1DC2F22B. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060 >;tag=5be75dc65ffa8fb5a76b533c12178918.d1e1. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372869 INVITE. Proxy-Authenticate: Digest realm="192.168.200.10", nonce="492cf863ac436e9c37697617b6c5e4491e58df17". Server: OpenSER (1.3.3-notls (i386/solaris)). Content-Length: 0. . # U 192.168.200.222:5060 -> 192.168.200.10:5060 ACK sip:1234567@192.168.200.10:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T1DC2F22B. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060 >;tag=5be75dc65ffa8fb5a76b533c12178918.d1e1. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372869 ACK. User-Agent: DPH-14001.01. Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 70. Content-Length: 0. . # U 192.168.200.222:5060 -> 192.168.200.10:5060 INVITE sip:1234567@192.168.200.10:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T3F0957F2. Session-Expires: 1800. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372870 INVITE. Proxy-Authorization: Digest username="11803", realm="192.168.200.10", nonce="492cf863ac436e9c37697617b6c5e4491e58df17", opaque="", uri=" sip:1234567@192.168.200.10:5060", response="fefb838d12f5d716f5e1789a2a36ed93". Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 70. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Supported: timer,replaces. User-Agent: DPH-14001.01. Content-Type: application/sdp. Content-Length: 242. . v=0. o=11803 273718813 273718813 IN IP4 192.168.200.222. s=DPH-14001.01. c=IN IP4 192.168.200.222. t=0 0. m=audio 41000 RTP/AVP 0 18 4. a=rtpmap:0 PCMU/8000/1. a=rtpmap:18 G729/8000/1. a=fmtp:18 annexb=no. a=rtpmap:4 G723/8000/1. a=sendrecv. _ # U 192.168.200.10:5060 -> 192.168.200.222:5060 SIP/2.0 100 Giving a try. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T3F0957F2. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372870 INVITE. Server: OpenSER (1.3.3-notls (i386/solaris)). Content-Length: 0. . # U 192.168.200.10:5060 -> 192.168.200.202:5060 INVITE sip:1234567@192.168.200.202:5060 SIP/2.0. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK596c.3851.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T3F0957F2. Session-Expires: 1800. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372870 INVITE. Proxy-Authorization: Digest username="11803", realm="192.168.200.10", nonce="492cf863ac436e9c37697617b6c5e4491e58df17", opaque="", uri=" sip:1234567@192.168.200.10:5060", response="fefb838d12f5d716f5e1789a2a36ed93". Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 69. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Supported: timer,replaces. User-Agent: DPH-14001.01. Content-Type: application/sdp. Content-Length: 242. . v=0. o=11803 273718813 273718813 IN IP4 192.168.200.222. s=DPH-14001.01. c=IN IP4 192.168.200.222. t=0 0. m=audio 41000 RTP/AVP 0 18 4. a=rtpmap:0 PCMU/8000/1. a=rtpmap:18 G729/8000/1. a=fmtp:18 annexb=no. a=rtpmap:4 G723/8000/1. a=sendrecv. # U 192.168.200.202:5060 -> 192.168.200.10:5060 SIP/2.0 100 Trying. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK596c.3851.0;received= 192.168.200.10. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T3F0957F2. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372870 INVITE. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Contact: <sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202>>. Content-Length: 0. . U 192.168.200.202:5060 -> 192.168.200.10:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK596c.3851.0;received= 192.168.200.10. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T3F0957F2. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372870 INVITE. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Contact: <sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202>>. Content-Type: application/sdp. Content-Length: 235. . v=0. o=root 2712 2712 IN IP4 192.168.200.202. s=session. c=IN IP4 192.168.200.202. t=0 0. m=audio 19872 RTP/AVP 0 18. a=rtpmap:0 PCMU/8000. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=silenceSupp:off - - - -. a=ptime:20. a=sendrecv. # U 192.168.200.10:5060 -> 192.168.200.222:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T3F0957F2. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372870 INVITE. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Contact: <sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202>>. Content-Type: application/sdp. Content-Length: 235. . v=0. o=root 2712 2712 IN IP4 192.168.200.202. s=session. c=IN IP4 192.168.200.202. t=0 0. m=audio 19872 RTP/AVP 0 18. a=rtpmap:0 PCMU/8000. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=silenceSupp:off - - - -. a=ptime:20. a=sendrecv. # U 192.168.200.222:5060 -> 192.168.200.10:5060 ACK sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202> SIP/2.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T2A279063. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372870 ACK. User-Agent: DPH-14001.01. Contact: <sip:11803@192.168.200.222:5060>. Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. Max-Forwards: 70. Content-Length: 0. . # U 192.168.200.10:5060 -> 192.168.200.202:5060 ACK sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202> SIP/2.0. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK596c.3851.2. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T2A279063. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372870 ACK. User-Agent: DPH-14001.01. Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 69. Content-Length: 0. . U 192.168.200.222:5060 -> 192.168.200.10:5060 INVITE sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202> SIP/2.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T6F622AB5. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372871 INVITE. Contact: <sip:11803@192.168.200.222:5060>. Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. Max-Forwards: 70. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Supported: timer,replaces. User-Agent: DPH-14001.01. Content-Type: application/sdp. Content-Length: 234. . v=0. o=11803 273718813 273718814 IN IP4 192.168.200.222. s=DPH-14001.01. c=IN IP4 0.0.0.0. t=0 0. m=audio 41000 RTP/AVP 0 18 4. a=rtpmap:0 PCMU/8000/1. a=rtpmap:18 G729/8000/1. a=fmtp:18 annexb=no. a=rtpmap:4 G723/8000/1. a=sendonly. # U 192.168.200.10:5060 -> 192.168.200.222:5060 SIP/2.0 100 Giving a try. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T6F622AB5. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372871 INVITE. Server: OpenSER (1.3.3-notls (i386/solaris)). Content-Length: 0. . # U 192.168.200.10:5060 -> 192.168.200.202:5060 INVITE sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202> SIP/2.0. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK696c.5c64.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T6F622AB5. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372871 INVITE. Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 69. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Supported: timer,replaces. User-Agent: DPH-14001.01. Content-Type: application/sdp. Content-Length: 234. . v=0. o=11803 273718813 273718814 IN IP4 192.168.200.222. s=DPH-14001.01. c=IN IP4 0.0.0.0. t=0 0. m=audio 41000 RTP/AVP 0 18 4. a=rtpmap:0 PCMU/8000/1. a=rtpmap:18 G729/8000/1. a=fmtp:18 annexb=no. a=rtpmap:4 G723/8000/1. a=sendonly. # U 192.168.200.202:5060 -> 192.168.200.10:5060 SIP/2.0 100 Trying. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK696c.5c64.0;received= 192.168.200.10. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T6F622AB5. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372871 INVITE. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Contact: <sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202>>. Content-Length: 0. . # U 192.168.200.202:5060 -> 192.168.200.10:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK696c.5c64.0;received= 192.168.200.10. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T6F622AB5. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372871 INVITE. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Contact: <sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202>>. Content-Type: application/sdp. Content-Length: 235. . v=0. o=root 2712 2713 IN IP4 192.168.200.202. s=session. c=IN IP4 192.168.200.202. t=0 0. m=audio 19872 RTP/AVP 0 18. a=rtpmap:0 PCMU/8000. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=silenceSupp:off - - - -. a=ptime:20. a=recvonly. # U 192.168.200.10:5060 -> 192.168.200.222:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T6F622AB5. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372871 INVITE. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Contact: <sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202>>. Content-Type: application/sdp. Content-Length: 235. . v=0. o=root 2712 2713 IN IP4 192.168.200.202. s=session. c=IN IP4 192.168.200.202. t=0 0. m=audio 19872 RTP/AVP 0 18. a=rtpmap:0 PCMU/8000. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=silenceSupp:off - - - -. a=ptime:20. a=recvonly. # U 192.168.200.222:5060 -> 192.168.200.10:5060 ACK sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202> SIP/2.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T555ECDF6. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372871 ACK. User-Agent: DPH-14001.01. Contact: <sip:11803@192.168.200.222:5060>. Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. Max-Forwards: 70. Content-Length: 0. . # U 192.168.200.10:5060 -> 192.168.200.202:5060 ACK sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202> SIP/2.0. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK696c.5c64.2. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T555ECDF6. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372871 ACK. User-Agent: DPH-14001.01. Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 69. Content-Length: 0. . # U 192.168.200.222:5060 -> 192.168.200.10:5060 INVITE sip:11801@192.168.200.10:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T584FCDF0. Session-Expires: 1800. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. CSeq: 612491577 INVITE. Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 70. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Supported: timer,replaces. User-Agent: DPH-14001.01. Content-Type: application/sdp. Content-Length: 242. . v=0. o=11803 273772573 273772573 IN IP4 192.168.200.222. s=DPH-14001.01. c=IN IP4 192.168.200.222. t=0 0. m=audio 41000 RTP/AVP 0 18 4. a=rtpmap:0 PCMU/8000/1. a=rtpmap:18 G729/8000/1. a=fmtp:18 annexb=no. a=rtpmap:4 G723/8000/1. a=sendrecv. # U 192.168.200.10:5060 -> 192.168.200.222:5060 SIP/2.0 407 Proxy Authentication Required. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T584FCDF0. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060 >;tag=5be75dc65ffa8fb5a76b533c12178918.146b. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. CSeq: 612491577 INVITE. Proxy-Authenticate: Digest realm="192.168.200.10", nonce="492cf87251a238af089dfab6b5d7f8c274907ba8". Server: OpenSER (1.3.3-notls (i386/solaris)). Content-Length: 0. . # U 192.168.200.222:5060 -> 192.168.200.10:5060 ACK sip:11801@192.168.200.10:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T584FCDF0. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060 >;tag=5be75dc65ffa8fb5a76b533c12178918.146b. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. CSeq: 612491577 ACK. User-Agent: DPH-14001.01. Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 70. Content-Length: 0. . 2 # U 192.168.200.222:5060 -> 192.168.200.10:5060 INVITE sip:11801@192.168.200.10:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T51E2E9FC. Session-Expires: 1800. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. CSeq: 612491578 INVITE. Proxy-Authorization: Digest username="11803", realm="192.168.200.10", nonce="492cf87251a238af089dfab6b5d7f8c274907ba8", opaque="", uri=" sip:11801@192.168.200.10:5060", response="c182454ce412ce07dd2a0d13c416bf58". Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 70. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Supported: timer,replaces. User-Agent: DPH-14001.01. Content-Type: application/sdp. Content-Length: 242. . v=0. o=11803 273772573 273772573 IN IP4 192.168.200.222. s=DPH-14001.01. c=IN IP4 192.168.200.222. t=0 0. m=audio 41000 RTP/AVP 0 18 4. a=rtpmap:0 PCMU/8000/1. a=rtpmap:18 G729/8000/1. a=fmtp:18 annexb=no. a=rtpmap:4 G723/8000/1. a=sendrecv. b # U 192.168.200.10:5060 -> 192.168.200.222:5060 SIP/2.0 100 Giving a try. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T51E2E9FC. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. CSeq: 612491578 INVITE. Server: OpenSER (1.3.3-notls (i386/solaris)). Content-Length: 0. . # U 192.168.200.10:5060 -> 192.168.200.224:5060 INVITE sip:11801@192.168.200.224:5060 SIP/2.0. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T408052446>. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bKa2ce.3cf7.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T51E2E9FC. Session-Expires: 1800. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. CSeq: 612491578 INVITE. Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 69. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Supported: timer,replaces. User-Agent: DPH-14001.01. Content-Type: application/sdp. Content-Length: 242. . v=0. o=11803 273772573 273772573 IN IP4 192.168.200.222. s=DPH-14001.01. c=IN IP4 192.168.200.222. t=0 0. m=audio 41000 RTP/AVP 0 18 4. a=rtpmap:0 PCMU/8000/1. a=rtpmap:18 G729/8000/1. a=fmtp:18 annexb=no. a=rtpmap:4 G723/8000/1. a=sendrecv. # U 192.168.200.224:5060 -> 192.168.200.10:5060 SIP/2.0 100 Trying. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bKa2ce.3cf7.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T51E2E9FC. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. Contact: <sip:11801@192.168.200.224:5060>. CSeq: 612491578 INVITE. User-Agent: DPH-14001.01. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Content-Length: 0. . # U 192.168.200.224:5060 -> 192.168.200.10:5060 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bKa2ce.3cf7.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T51E2E9FC. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>;tag=0015E970817D_T1147221029. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. Contact: <sip:11801@192.168.200.224:5060>. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T408052446>. CSeq: 612491578 INVITE. User-Agent: DPH-14001.01. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Content-Length: 0. . 0 # U 192.168.200.10:5060 -> 192.168.200.222:5060 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T51E2E9FC. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>;tag=0015E970817D_T1147221029. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. Contact: <sip:11801@192.168.200.224:5060>. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T408052446>. CSeq: 612491578 INVITE. User-Agent: DPH-14001.01. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Content-Length: 0. . # U 192.168.200.224:5060 -> 192.168.200.10:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bKa2ce.3cf7.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T51E2E9FC. Require: timer. Session-Expires: 1800;refresher=uac. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>;tag=0015E970817D_T1147221029. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. Contact: <sip:11801@192.168.200.224:5060>. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T408052446>. CSeq: 612491578 INVITE. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Supported: timer,replaces. Content-Type: application/sdp. Content-Length: 167. . v=0. o=11801 276818065 276818065 IN IP4 192.168.200.224. s=DPH-14001.01. c=IN IP4 192.168.200.224. t=0 0. m=audio 41000 RTP/AVP 0. a=rtpmap:0 PCMU/8000/1. a=sendrecv. # U 192.168.200.10:5060 -> 192.168.200.222:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T51E2E9FC. Require: timer. Session-Expires: 1800;refresher=uac. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>;tag=0015E970817D_T1147221029. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. Contact: <sip:11801@192.168.200.224:5060>. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T408052446>. CSeq: 612491578 INVITE. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Supported: timer,replaces. Content-Type: application/sdp. Content-Length: 167. . v=0. o=11801 276818065 276818065 IN IP4 192.168.200.224. s=DPH-14001.01. c=IN IP4 192.168.200.224. t=0 0. m=audio 41000 RTP/AVP 0. a=rtpmap:0 PCMU/8000/1. a=sendrecv. # U 192.168.200.222:5060 -> 192.168.200.10:5060 ACK sip:11801@192.168.200.224:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T3C593173. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>;tag=0015E970817D_T1147221029. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. CSeq: 612491578 ACK. User-Agent: DPH-14001.01. Contact: <sip:11803@192.168.200.222:5060>. Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T408052446>. Max-Forwards: 70. Content-Length: 0. . 0 # U 192.168.200.10:5060 -> 192.168.200.224:5060 ACK sip:11801@192.168.200.224:5060 SIP/2.0. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T408052446>. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bKa2ce.3cf7.2. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T3C593173. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>;tag=0015E970817D_T1147221029. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. CSeq: 612491578 ACK. User-Agent: DPH-14001.01. Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 69. Content-Length: 0. . # U 192.168.200.222:5060 -> 192.168.200.10:5060 INVITE sip:11801@192.168.200.224:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T1280D8E9. Session-Expires: 1800;refresher=uac. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>;tag=0015E970817D_T1147221029. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. CSeq: 612491579 INVITE. Contact: <sip:11803@192.168.200.222:5060>. Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T408052446>. Max-Forwards: 70. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Supported: timer,replaces. User-Agent: DPH-14001.01. Content-Type: application/sdp. Content-Length: 234. . v=0. o=11803 273772573 273772574 IN IP4 192.168.200.222. s=DPH-14001.01. c=IN IP4 0.0.0.0. t=0 0. m=audio 41000 RTP/AVP 0 18 4. a=rtpmap:0 PCMU/8000/1. a=rtpmap:18 G729/8000/1. a=fmtp:18 annexb=no. a=rtpmap:4 G723/8000/1. a=sendonly. # U 192.168.200.10:5060 -> 192.168.200.222:5060 SIP/2.0 100 Giving a try. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T1280D8E9. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>;tag=0015E970817D_T1147221029. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. CSeq: 612491579 INVITE. Server: OpenSER (1.3.3-notls (i386/solaris)). Content-Length: 0. . # U 192.168.200.10:5060 -> 192.168.200.224:5060 INVITE sip:11801@192.168.200.224:5060 SIP/2.0. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T408052446>. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK92ce.5361.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T1280D8E9. Session-Expires: 1800;refresher=uac. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>;tag=0015E970817D_T1147221029. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. CSeq: 612491579 INVITE. Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 69. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Supported: timer,replaces. User-Agent: DPH-14001.01. Content-Type: application/sdp. Content-Length: 234. . v=0. o=11803 273772573 273772574 IN IP4 192.168.200.222. s=DPH-14001.01. c=IN IP4 0.0.0.0. t=0 0. m=audio 41000 RTP/AVP 0 18 4. a=rtpmap:0 PCMU/8000/1. a=rtpmap:18 G729/8000/1. a=fmtp:18 annexb=no. a=rtpmap:4 G723/8000/1. a=sendonly. # U 192.168.200.224:5060 -> 192.168.200.10:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK92ce.5361.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T1280D8E9. Require: timer. Session-Expires: 1800;refresher=uac. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>;tag=0015E970817D_T1147221029. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. Contact: <sip:11801@192.168.200.224:5060>. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T408052446>. CSeq: 612491579 INVITE. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Supported: timer,replaces. Content-Type: application/sdp. Content-Length: 167. . v=0. o=11801 276818065 276818065 IN IP4 192.168.200.224. s=DPH-14001.01. c=IN IP4 192.168.200.224. t=0 0. m=audio 41000 RTP/AVP 0. a=rtpmap:0 PCMU/8000/1. a=recvonly. # U 192.168.200.10:5060 -> 192.168.200.222:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T1280D8E9. Require: timer. Session-Expires: 1800;refresher=uac. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>;tag=0015E970817D_T1147221029. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. Contact: <sip:11801@192.168.200.224:5060>. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T408052446>. CSeq: 612491579 INVITE. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Supported: timer,replaces. Content-Type: application/sdp. Content-Length: 167. . v=0. o=11801 276818065 276818065 IN IP4 192.168.200.224. s=DPH-14001.01. c=IN IP4 192.168.200.224. t=0 0. m=audio 41000 RTP/AVP 0. a=rtpmap:0 PCMU/8000/1. a=recvonly. # U 192.168.200.222:5060 -> 192.168.200.10:5060 ACK sip:11801@192.168.200.224:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T72B9563C. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>;tag=0015E970817D_T1147221029. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. CSeq: 612491579 ACK. User-Agent: DPH-14001.01. Contact: <sip:11803@192.168.200.222:5060>. Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T408052446>. Max-Forwards: 70. Content-Length: 0. . 1 # U 192.168.200.10:5060 -> 192.168.200.224:5060 ACK sip:11801@192.168.200.224:5060 SIP/2.0. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T408052446>. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK92ce.5361.2. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T72B9563C. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. To: <sip:11801@192.168.200.10:5060>;tag=0015E970817D_T1147221029. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. CSeq: 612491579 ACK. User-Agent: DPH-14001.01. Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 69. Content-Length: 0. . # U 192.168.200.222:5060 -> 192.168.200.10:5060 REFER sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202> SIP/2.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T218F1384. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372872 REFER. Refer-To: < sip:11801@192.168.200.10:5060?Replaces=CALL_ID21_0015E9A0D90F_T1842345680%40192.168.200.222%3Bto-tag%3D0015E970817D_T1147221029%3Bfrom-tag%3D0015E9A0D90F_T408052446 >. Referred-by: <sip:11803@192.168.200.10 <sip%3A11803(a)192.168.200.10>>. Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 70. Content-Length: 0. . P # U 192.168.200.10:5060 -> 192.168.200.202:5060 REFER sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202> SIP/2.0. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK396c.8f11.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T218F1384. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372872 REFER. Refer-To: < sip:11801@192.168.200.10:5060?Replaces=CALL_ID21_0015E9A0D90F_T1842345680%40192.168.200.222%3Bto-tag%3D0015E970817D_T1147221029%3Bfrom-tag%3D0015E9A0D90F_T408052446 >. Referred-by: <sip:11803@192.168.200.10 <sip%3A11803(a)192.168.200.10>>. Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 69. Content-Length: 0. . # U 192.168.200.202:5060 -> 192.168.200.10:5060 SIP/2.0 202 Accepted. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK396c.8f11.0;received= 192.168.200.10. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T218F1384. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372872 REFER. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Contact: <sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202>>. Content-Length: 0. . # U 192.168.200.10:5060 -> 192.168.200.222:5060 SIP/2.0 202 Accepted. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T218F1384. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372872 REFER. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Contact: <sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202>>. Content-Length: 0. . # U 192.168.200.202:5060 -> 192.168.200.10:5060 NOTIFY sip:11803@192.168.200.222:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.200.202:5060;branch=z9hG4bK511c6a05;rport. Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. From: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. To: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. Contact: <sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202>>. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 102 NOTIFY. User-Agent: Asterisk PBX. Max-Forwards: 70. Event: refer;id=1844372872. Subscription-state: terminated;reason=noresource. Content-Type: message/sipfrag;version=2.0. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Content-Length: 49. . SIP/2.0 481 Call leg/transaction does not exist. # U 192.168.200.10:5060 -> 192.168.200.222:5060 NOTIFY sip:11803@192.168.200.222:5060 SIP/2.0. Record-Route: <sip:192.168.200.10;lr=on;ftag=as17b63c65>. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK3dbb.fc91.0. Via: SIP/2.0/UDP 192.168.200.202:5060;branch=z9hG4bK511c6a05;rport=5060. From: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. To: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. Contact: <sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202>>. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 102 NOTIFY. User-Agent: Asterisk PBX. Max-Forwards: 69. Event: refer;id=1844372872. Subscription-state: terminated;reason=noresource. Content-Type: message/sipfrag;version=2.0. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Content-Length: 49. . SIP/2.0 481 Call leg/transaction does not exist. # U 192.168.200.222:5060 -> 192.168.200.10:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK3dbb.fc91.0. Via: SIP/2.0/UDP 192.168.200.202:5060;branch=z9hG4bK511c6a05;rport=5060. From: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. To: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 102 NOTIFY. User-Agent: DPH-14001.01. Content-Length: 0. . 6 # U 192.168.200.10:5060 -> 192.168.200.202:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.200.202:5060;branch=z9hG4bK511c6a05;rport=5060. From: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. To: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 102 NOTIFY. User-Agent: DPH-14001.01. Content-Length: 0. . # U 192.168.200.201:26114 -> 192.168.200.10:5060 . . .............. # U 192.168.200.101:5060 -> 192.168.200.10:5060 .................. # U 192.168.200.224:5060 -> 192.168.200.10:5060 BYE sip:11803@192.168.200.222:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.200.224:5060;branch=z9hG4bK_0015E970817D_T7AFA8E38. From: <sip:11801@192.168.200.10:5060>;tag=0015E970817D_T1147221029. To: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. CSeq: 1461395436 BYE. User-Agent: DPH-14001.01. Contact: <sip:11801@192.168.200.224:5060>. Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T408052446>. Max-Forwards: 70. Content-Length: 0. . # U 192.168.200.10:5060 -> 192.168.200.222:5060 BYE sip:11803@192.168.200.222:5060 SIP/2.0. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E970817D_T1147221029>. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bKd255.f616.0. Via: SIP/2.0/UDP 192.168.200.224:5060;branch=z9hG4bK_0015E970817D_T7AFA8E38. From: <sip:11801@192.168.200.10:5060>;tag=0015E970817D_T1147221029. To: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. CSeq: 1461395436 BYE. User-Agent: DPH-14001.01. Contact: <sip:11801@192.168.200.224:5060>. Max-Forwards: 69. Content-Length: 0. . # U 192.168.200.222:5060 -> 192.168.200.10:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bKd255.f616.0. Via: SIP/2.0/UDP 192.168.200.224:5060;branch=z9hG4bK_0015E970817D_T7AFA8E38. From: <sip:11801@192.168.200.10:5060>;tag=0015E970817D_T1147221029. To: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. CSeq: 1461395436 BYE. User-Agent: DPH-14001.01. Content-Length: 0. . # U 192.168.200.10:5060 -> 192.168.200.224:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.200.224:5060;branch=z9hG4bK_0015E970817D_T7AFA8E38. From: <sip:11801@192.168.200.10:5060>;tag=0015E970817D_T1147221029. To: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T408052446. Call-ID: CALL_ID21_0015E9A0D90F_T1842345680(a)192.168.200.222. CSeq: 1461395436 BYE. User-Agent: DPH-14001.01. Content-Length: 0. . # U 192.168.200.222:5060 -> 192.168.200.10:5060 INVITE sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202> SIP/2.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T5152F022. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372873 INVITE. Contact: <sip:11803@192.168.200.222:5060>. Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. Max-Forwards: 70. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Supported: timer,replaces. User-Agent: DPH-14001.01. Content-Type: application/sdp. Content-Length: 242. . v=0. o=11803 273718813 273718815 IN IP4 192.168.200.222. s=DPH-14001.01. c=IN IP4 192.168.200.222. t=0 0. m=audio 41000 RTP/AVP 0 18 4. a=rtpmap:0 PCMU/8000/1. a=rtpmap:18 G729/8000/1. a=fmtp:18 annexb=no. a=rtpmap:4 G723/8000/1. a=sendrecv. # U 192.168.200.10:5060 -> 192.168.200.222:5060 SIP/2.0 100 Giving a try. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T5152F022. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372873 INVITE. Server: OpenSER (1.3.3-notls (i386/solaris)). Content-Length: 0. . # U 192.168.200.10:5060 -> 192.168.200.202:5060 INVITE sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202> SIP/2.0. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK496c.a647.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T5152F022. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372873 INVITE. Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 69. Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,REFER,DO,UPDATE,OPTIONS,SUBSCRIBE,INFO. Supported: timer,replaces. User-Agent: DPH-14001.01. Content-Type: application/sdp. Content-Length: 242. . v=0. o=11803 273718813 273718815 IN IP4 192.168.200.222. s=DPH-14001.01. c=IN IP4 192.168.200.222. t=0 0. m=audio 41000 RTP/AVP 0 18 4. a=rtpmap:0 PCMU/8000/1. a=rtpmap:18 G729/8000/1. a=fmtp:18 annexb=no. a=rtpmap:4 G723/8000/1. a=sendrecv. # U 192.168.200.202:5060 -> 192.168.200.10:5060 SIP/2.0 100 Trying. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK496c.a647.0;received= 192.168.200.10. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T5152F022. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372873 INVITE. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Contact: <sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202>>. Content-Length: 0. . # U 192.168.200.202:5060 -> 192.168.200.10:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK496c.a647.0;received= 192.168.200.10. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T5152F022. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372873 INVITE. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Contact: <sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202>>. Content-Type: application/sdp. Content-Length: 235. . v=0. o=root 2712 2714 IN IP4 192.168.200.202. s=session. c=IN IP4 192.168.200.202. t=0 0. m=audio 19872 RTP/AVP 0 18. a=rtpmap:0 PCMU/8000. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=silenceSupp:off - - - -. a=ptime:20. a=sendrecv. # U 192.168.200.10:5060 -> 192.168.200.222:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T5152F022. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372873 INVITE. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Contact: <sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202>>. Content-Type: application/sdp. Content-Length: 235. . v=0. o=root 2712 2714 IN IP4 192.168.200.202. s=session. c=IN IP4 192.168.200.202. t=0 0. m=audio 19872 RTP/AVP 0 18. a=rtpmap:0 PCMU/8000. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=silenceSupp:off - - - -. a=ptime:20. a=sendrecv. # U 192.168.200.222:5060 -> 192.168.200.10:5060 ACK sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202> SIP/2.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T36B8312B. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372873 ACK. User-Agent: DPH-14001.01. Contact: <sip:11803@192.168.200.222:5060>. Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. Max-Forwards: 70. Content-Length: 0. . # U 192.168.200.10:5060 -> 192.168.200.202:5060 ACK sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202> SIP/2.0. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK496c.a647.2. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T36B8312B. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372873 ACK. User-Agent: DPH-14001.01. Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 69. Content-Length: 0. . # U 192.168.200.222:5060 -> 192.168.200.10:5060 BYE sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202> SIP/2.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T2506AE3F. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372874 BYE. User-Agent: DPH-14001.01. Contact: <sip:11803@192.168.200.222:5060>. Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. Max-Forwards: 70. Content-Length: 0. . # U 192.168.200.10:5060 -> 192.168.200.202:5060 BYE sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202> SIP/2.0. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK196c.a9d3.0. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T2506AE3F. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372874 BYE. User-Agent: DPH-14001.01. Contact: <sip:11803@192.168.200.222:5060>. Max-Forwards: 69. Content-Length: 0. . # U 192.168.200.202:5060 -> 192.168.200.10:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.200.10;branch=z9hG4bK196c.a9d3.0;received= 192.168.200.10. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T2506AE3F. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372874 BYE. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Contact: <sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202>>. Content-Length: 0. . # U 192.168.200.10:5060 -> 192.168.200.222:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.200.222:5060;branch=z9hG4bK_0015E9A0D90F_T2506AE3F. Record-Route: <sip:192.168.200.10;lr=on;ftag=0015E9A0D90F_T1123280974>. From: <sip:11803@192.168.200.10:5060>;tag=0015E9A0D90F_T1123280974. To: <sip:1234567@192.168.200.10:5060>;tag=as17b63c65. Call-ID: CALL_ID20_0015E9A0D90F_T647138101(a)192.168.200.222. CSeq: 1844372874 BYE. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Contact: <sip:1234567@192.168.200.202 <sip%3A1234567(a)192.168.200.202>>. Content-Length: 0. .

1 0

[Kamailio-Users] serMyAdmin 1.0 Beta error
by Ricky Gutierrez 26 Nov '08

26 Nov '08

Hi list, recently I had to make some modifications to the chart subscriber of my openser to be able to use the CDRTool, now when I make an user with the serMyAdmin-BETA-1.0.war it shows me an error : please they can help me with this problem? best regards rickygm Grails Runtime Exception Error Details [leonardo]Caused by: org.springframework.jdbc.UncategorizedSQLException: Hibernate operation: could not insert: [User]; uncategorized SQLException for SQL [insert into subscriber (version, password_hash, auth_username, rpid, datetime_created, domain_id, domain, email_address, first_name, ha1, ha1b, last_name, username, password, role_id, class) values (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, 'User')]; SQL state [HY000]; error code [1364]; Field 'quota' doesn't have a default value; nested exception is java.sql.SQLException: Field 'quota' doesn't have a default value Class: UserController

2 2

[Kamailio-Users] basic config
by Lens Oreste 26 Nov '08

26 Nov '08

I am trying to do a basic configuration, I need to add a couple of routes and add radius for billing. Please let me show me how

3 2

[Kamailio-Users] method value of the CSeq field
by Alex R.S.M 26 Nov '08

26 Nov '08

Hi, Is there any variable to return the method value of the CSeq field? (example: returns "ACK" for CSeq:1165 ACK) $cs returns only the "Sequence Number". Thansk, Alex R, _________________________________________________________________ Access your email online and on the go with Windows Live Hotmail. http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_access…

4 6

Re: [Kamailio-Users] UAC on ACK in reInvite
by Schober Walter 26 Nov '08

26 Nov '08

To finish the thread: I just entered below loose_route(): if (check_route_param("vsf=")) { avp_write("$hdr(Route[0])", "$avp(rr-param)"); avp_subst("$avp(rr-param)", "/^.*?(;vsf=[^>]+).*/\1/"); # $hdr(Route[0]) is not 1st header only, if multi header in one line xlog("L_INFO", ">> Stored UAC params $avp(rr-param)"); add_rr_param("$avp(rr-param)"); } > -----Original Message----- > From: Schober Walter > Sent: Wednesday, November 26, 2008 2:39 PM > To: 'Klaus Darilion' > Cc: 'users(a)lists.kamailio.org' > Subject: RE: AW: [Kamailio-Users] UAC on ACK in reInvite > > See below... > > > -----Original Message----- > > From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > > Sent: Wednesday, November 26, 2008 1:21 AM > [...] > > > > This is clearly a bug in the useragent. The route set must not be > > changed with reINVITEs. Thus, according to the standard the > > Record-Route > > headers for indialog requests are not needed. Maybe you are calling > > record_route() for indialog requests and this confuses the client. > Fully agree on this. But some proxies add Record-Route, some > don't, Openser/Kamailio can configure it. > > It's not that clear in the RFC, but I see it the same way: > RFC 3261, 12.2 Request within a Dialog > ... > Requests within a dialog MAY contain Record-Route and > Contact header > fields. However, these requests do not cause the dialog's > route set > to be modified, although they may modify the remote target URI. > > 12.2.1.2 Processing the Responses > -> The only thing mentioned is that the _Target URI_ gets > refreshed by the 200 OK. > > => reInvites do not modify the routeset of any subsequent > request, neither the ACK not any other upcoming request. > > > Try removing the record_route() for indialog requests - may > then the > > buggy client remembers the original route set. > Done. Client sends ACK on reInvite directly then :-( > Counterpath is OK, Teles Voipbox not, other clients to be tested ... > > So I will have to add vsf uri param from Route to record > route in the proxy. This at least is a reason to upgrade :-) > It's done more easily with tranformations. > > Thanks for the discussion! For me it's "clearly a bug in the > UA" now, too ;-) However, let's find a workaround. > > br > Walter

1 0

[Serusers] Need help on a call forward always question
by Steven C. Blair 26 Nov '08

26 Nov '08

I am experiencing an issue with server side call forward always which I didn't see before but I now believe has always existed. Call forward always has been working. We recently switched phone manufacturers and now have the ability to offer bridged line appearance (BLA). Part of the process for offering BLA is to have the phones register with the shared attribute for a given line. When we enable this attribute server side call forward always breaks. When I say break I mean that the call forwards OK but the intermediate IP phone now rings which it never did before. Using ngrep I see that even with the old config (non-BLA setup) we had the same message flow: Invite (from PSTN gateway)-> Invite received at proxy-> Proxy responds to gateway with 200 OK-> Proxy loads forward address from mysql usr_preferences table Proxy rewrite R-URI to the forward address - avp_pushto("$ruri/username", "s:fwdaaddr"); Proxy send invite to this new address - but... Proxy also sends invite to each contact address registered to the original AOR. This should not happen but I think it was Always happening and the old phones just ignored it. Any thoughts on why and how to correct this behavior? The ser.cfg snippets involved are included below: Determine if call forward all is on: # call forward always if (avp_db_load("$ruri/username", "s:callfwdall")) { if (avp_check("s:callfwdall","eq/y/i")) { xlog("L_INFO", "\n[SER]: [%Tf] [%ci] User <%ru> has enabled Call Forward Always\n"); avp_write("$ruri", "$ocn"); - save original RURI for voicemail access if needed if (avp_db_load("$ruri/username", "s:fwdaaddr")) { avp_pushto("$ruri/username", "s:fwdaaddr"); rewritehostport("mydomain.edu"); xlog("L_INFO", "\n[SER]: [%Tf] [%ci] Calls for user <%tu> FORWARDING to <%ru>\n"); route(2); break; }; And call relaying is done by: route[2] { xlog("L_INFO", "\n[SER]: Route block #2 campus 5-digit extensions:\n\n"); xlog("L_INFO", "\n[SER]: [%Tf] [%ci] Route block #2: sending oncampus call from <%fu> to local gateway\n"); avp_write("65", "inv_timeout"); rewritehostport("my-gwy-ip-address:5060"); t_on_failure("1"); # for gwy failover t_relay(); break; }; Thanks,Steve Senior Network Engineer, Information Systems and Computing Networking and Telecommunications , Suite 221A /6228 University of Pennsylvania Voice:215-573-8396 FAX:215-898-9348

1 0

[Serusers] Call forward always question
by Steven C. Blair 26 Nov '08

26 Nov '08

I am experiencing an issue with server side call forward always which I didn't see before but I now believe has always existed. We recently switched phone manufacturers and now have the ability to offer bridged line appearance (BLA). Part of the process for offering BLA is to have the phones register with the shared attribute for a given line. When we enable this attribute server side call forward always breaks. When I say break I mean that the call forwards OK but the intermediate IP phone now rings which it never did before. Using ngrep I see that even with the old config we had the same message flow: Invite (from PSTN gateway)-> Invite received at proxy-> Proxy responds to gateway with 200 OK-> Proxy loads forward address from mysql usr_preferences table Proxy rewrite R-URI to the forward address - avp_pushto("$ruri/username", "s:fwdaaddr"); Proxy send invite to this new address - but... Proxy also sends invite to each contact address registered to the original AOR. This should not happen but I think it was Always happening and the old phones just ignored it. Any thoughts on why and how to correct this behavior? The ser.cfg snippets involved are included below: Determine if call forward all is on: # call forward always if (avp_db_load("$ruri/username", "s:callfwdall")) { if (avp_check("s:callfwdall","eq/y/i")) { xlog("L_INFO", "\n[SER]: [%Tf] [%ci] User <%ru> has enabled Call Forward Always\n"); avp_write("$ruri", "$ocn"); - save original RURI for voicemail access if needed if (avp_db_load("$ruri/username", "s:fwdaaddr")) { avp_pushto("$ruri/username", "s:fwdaaddr"); rewritehostport("mydomain.edu"); xlog("L_INFO", "\n[SER]: [%Tf] [%ci] Calls for user <%tu> FORWARDING to <%ru>\n"); route(2); break; }; And call relaying is done by: route[2] { xlog("L_INFO", "\n[SER]: Route block #2 campus 5-digit extensions:\n\n"); xlog("L_INFO", "\n[SER]: [%Tf] [%ci] Route block #2: sending oncampus call from <%fu> to local gateway\n"); avp_write("65", "inv_timeout"); rewritehostport("my-gwy-ip-address:5060"); t_on_failure("1"); # for gwy failover t_relay(); break; }; Thanks,Steve

1 0

[Kamailio-Users] Statistic in openser
by ALAEDDINE abbech 26 Nov '08

26 Nov '08

Hi, I know the commande #openserctl monitor and # openserctl fifo get_statistics all But i like have the number of INVITE / second in openser and the succeful INVITE/second. Who know any commande to have this statistic? thanks

3 2

Re: [Kamailio-Users] UAC on ACK in reInvite
by Schober Walter 26 Nov '08

26 Nov '08

See below... > -----Original Message----- > From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] > Sent: Wednesday, November 26, 2008 1:21 AM [...] > > This is clearly a bug in the useragent. The route set must not be > changed with reINVITEs. Thus, according to the standard the > Record-Route > headers for indialog requests are not needed. Maybe you are calling > record_route() for indialog requests and this confuses the client. Fully agree on this. But some proxies add Record-Route, some don't, Openser/Kamailio can configure it. It's not that clear in the RFC, but I see it the same way: RFC 3261, 12.2 Request within a Dialog ... Requests within a dialog MAY contain Record-Route and Contact header fields. However, these requests do not cause the dialog's route set to be modified, although they may modify the remote target URI. 12.2.1.2 Processing the Responses -> The only thing mentioned is that the _Target URI_ gets refreshed by the 200 OK. => reInvites do not modify the routeset of any subsequent request, neither the ACK not any other upcoming request. > Try removing the record_route() for indialog requests - may then the > buggy client remembers the original route set. Done. Client sends ACK on reInvite directly then :-( Counterpath is OK, Teles Voipbox not, other clients to be tested ... So I will have to add vsf uri param from Route to record route in the proxy. This at least is a reason to upgrade :-) It's done more easily with tranformations. Thanks for the discussion! For me it's "clearly a bug in the UA" now, too ;-) However, let's find a workaround. br Walter

2 1

[Kamailio-Users] avp assignment in openser 1.1
by ALAEDDINE abbech 26 Nov '08

26 Nov '08

Hi all, I have openser 1.1.0 and i can't do any change before i'm certain. can i write this code or we have an other syntaxe with version 1.1. $avp(s:PAI):= '"' + $fU + '" ' + '<sip:01010101010@192.222.115.213:5060>'; append_hf("P-Asserted-Identity: $avp(s:PAI)\r\n"); thanks

3 2

[Kamailio-Users] disply name RFC 3325
by ALAEDDINE abbech 26 Nov '08

26 Nov '08

Hi, I want to disply a number "010101010101" with use of RFC 3325 in openser. I read the RFC 3325 but i don't understand how do it. Where i put this number ? in diply name in P-Asserted-Identity, in username in P-Asserted-Identity ,in diply name in FROM or in username in FROM ?

4 5

[Kamailio-Users] replace the ' sip to' header
by BERGANZ François 26 Nov '08

26 Nov '08

Hello, I need to change the to sip header. How can I do it? Cordialement, BERGANZ François cid:image001.gif@01C8F7CD.6BC1D2C0 http://www.acropolistelecom.net <http://www.acropolistelecom.net/> P Pensez à l'Environnement, n'imprimez ce mail que si nécessaire.

3 2

[Kamailio-Users] avp assignment in openser 1.1
by ALAEDDINE abbech 26 Nov '08

26 Nov '08

Hi all, I have openser 1.1.0 and i can't do any change before i'm certain. can i write this code or we have an other syntaxe with version 1.1. $avp(s:PAI):= '"' + $fU + '" ' + '<sip:01010101010@192.222.115.213:5060>'; append_hf("P-Asserted-Identity: $avp(s:PAI)\r\n"); thanks

1 0

Re: [Kamailio-Users] UAC on ACK in reInvite
by Schober Walter 26 Nov '08

26 Nov '08

Hi Klaus! Thanks for the hint! Indeed looking into the vsf=xxx parameter a little bit closer, I found out, that on the reInvite the uac_replace() is done due to the Route: vsf=xxx Param (knew that :-), but the vsf=xxx is not added again on to the Record-Route (missed that :-). So the 2nd 200 OK doesn't contain it in the route-set anymore, thus the following ACK doesn't have it in the Route Header. Is it up to me to add it to Record-Route Header, if the Route Header contains these parameters? Shouldn't the uac_replace() do that on replacing the From again? Let's see, what I can do here. Br Walter -----Ursprüngliche Nachricht----- Von: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] Gesendet: Dienstag, 25. November 2008 18:04 An: Schober Walter Cc: users(a)lists.kamailio.org Betreff: Re: [Kamailio-Users] UAC on ACK in reInvite Hi Walter! Automatic restoring uses record route parameters to store the original from URI. Maybe there is something wrong with the RR header. I can not remember any changes in UAC module, thus I am not sure if an update will help you. regards klaus Schober Walter wrote: > Hello All! > > Tried to fix that anyhow but without success yet. Anyone who could > just tell me, if it's fixed in 1.4.something? > > Scenario: > A -> Openser 1.1.1 -> Openser 1.1.1 -> Openser 1.1.1 (UAC:normalize > From to phone number in national format) -> B > > A Invites B => all OK > A reInvites B with T.38 -> INVITE => OK > <- 200 OK => OK > -> ACK => From field not handled by UAC. > > UAC config all default, so UAC restore mode "auto". Neither INVITE nor > ACK get's uac_replace'd in if(loose_route()) block, but INVITE get's > handled properly. > > Upgrading to 1.4 or 1.3 is risky - or is it not? ;-) - because never > touch a running system, isn't it? > But then that customer comes with that Allied Telesis CPE :-) (And Ati > blames the proxy for not matching the ACK in the CPE although they use > a from-tag, too). > > Many Thanks! > br > Walter > > _______________________________________________ > Users mailing list > Users(a)lists.kamailio.org > http://lists.kamailio.org/cgi-bin/mailman/listinfo/users

2 1

[Kamailio-Users] UAC on ACK in reInvite
by Schober Walter 25 Nov '08

25 Nov '08

Hello All! Tried to fix that anyhow but without success yet. Anyone who could just tell me, if it's fixed in 1.4.something? Scenario: A -> Openser 1.1.1 -> Openser 1.1.1 -> Openser 1.1.1 (UAC:normalize From to phone number in national format) -> B A Invites B => all OK A reInvites B with T.38 -> INVITE => OK <- 200 OK => OK -> ACK => From field not handled by UAC. UAC config all default, so UAC restore mode "auto". Neither INVITE nor ACK get's uac_replace'd in if(loose_route()) block, but INVITE get's handled properly. Upgrading to 1.4 or 1.3 is risky - or is it not? ;-) - because never touch a running system, isn't it? But then that customer comes with that Allied Telesis CPE :-) (And Ati blames the proxy for not matching the ACK in the CPE although they use a from-tag, too). Many Thanks! br Walter

2 1

Re: [Kamailio-Users] Username vs DID
by ingdavidcespedes＠cable.net.co 25 Nov '08

25 Nov '08

----- Mensaje original ----- De: Matteo D'Amato <matteo(a)ecosma.com> Fecha: Martes, Noviembre 25, 2008 10:12 am Asunto: [Kamailio-Users] Username vs DID > Yes I am using a PSTN Gateway, should I create a new table to hold > the link between the username and DID or do I use the information > in the alias table? > > And there may be some local calls between users, so are you saying > it would have been easier to use their actual DID numbers as their > usernames? I have seen something like this ie: PSTN Number: 7565079 Internal Extension:5079 So you use as username= 5079, and PSTN number 7565079. But it's always better, I think, to have internal user names as "John" and associate its DID only when he is trying to reach the PSTN, adding the RFC 3325 header field P-Asserted-Identity with the DID number. > --Matteo

2 1

[Serusers] problem getting calls to my gateway
by G. Ricca 25 Nov '08

25 Nov '08

1 0

[Kamailio-Users] Username vs DID
by Matteo D'Amato 25 Nov '08

25 Nov '08

Hello, I have users with one or more DID numbers assigned to them and some with none. What is the standard convention when choosing usernames? Initially I started with usernames with the following format 1001,1002,etc however when a user dials a number their username shows up instead of their DID. I'm assigning DID with the alias command. Is there a way to show their DID number or do I need to change the way I create usernames? --Matteo

2 3

[Kamailio-Users] 100% CPU and crashed coredump available
by Ali Jawad 25 Nov '08

25 Nov '08

Hi I have a high end server and only openser + a couple of calls running, I was not able to logon to the server using my softphone anymore. The server in question is Openser 1.3 The dump file core can be found at http://www.4shared.com/file/72990148/8dca8efd/core.html Regards

3 4

[Kamailio-Users] caller id on AS5350XM
by Mark Anthony C. Delfin 25 Nov '08

25 Nov '08

Hi List, We have some issue when we are restricting caller id to a particular sip carrier using a Cisco 5350XM. The cisco 5350XM sends the from header as From: "anonymous" <sip:0xxxxxx0@xx.yy.zz.99 <sip%3A0282073300(a)202.85.241.99>>;tag=1F480924-17D9 but the sip provider's SBC is case sensitive and requires From: "Anonymous" <sip:0282073300@xx.yy.zz.99<sip%3A0282073300(a)202.85.241.99> >;tag=1F480924-17D9. I can't find a config on Cisco to change anonymous to Anonymous. Does anyone knows how to change this on the AS5350XM. Thank you. Regards, Mark Anthony C. Delfin

2 1

[Kamailio-Users] OpenSER v1.3.4 released
by Daniel-Constantin Mierla 24 Nov '08

24 Nov '08

Hello, a new release in 1.3 series is out. OpenSER (new project name: Kamailio) 1.3.4 is based on the latest version of branch 1.3, including many fixes in code and documentation, therefore those running 1.3.x are advised to upgrade. Source tarballs are available at: http://www.kamailio.org/pub/kamailio/1.3.4/src/ <http://www.kamailio.org/pub/openser/1.3.4/src> Detailed changelog: http://www.kamailio.org/pub/openser/1.3.4/ChangeLog Download via SVN: svn co https://openser.svn.sourceforge.net/svnroot/openser/branches/1.3 kamailio Tag for this release can be browsed at: http://openser.svn.sourceforge.net/viewvc/openser/tags/1.3.4/ Project site at SourceForge.net: http://sourceforge.net/projects/openser/ Modules' documentation: http://www.kamailio.org/docs/modules/1.3.x/ <http://www.kamailio.org/docs/modules/1.3.x> What is new in 1.3.x release series is summarized in the announcement of v1.3.0: http://www.kamailio.org/mos/view/OpenSER-v1.3.x-Release-Notes/ <http://www.kamailio.org/mos/view/OpenSER-v1.3.x-Release-Notes> /Note: Kamailio is the new name of OpenSER project. First version under Kamailio name was 1.4.0. Older versions will continue to use OpenSER name. / Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

1 0

Re: [Kamailio-Users] Is PRACK Supported?
by ingdavidcespedes＠cable.net.co 24 Nov '08

24 Nov '08

Thanks Alex That was exactly what I wanted to know, if it could relay PRACK messages and associate them with the corresponding provisional response message. ----- Mensaje original ----- De: Alex Balashov <abalashov(a)evaristesys.com> Fecha: Lunes, Noviembre 24, 2008 2:28 pm Asunto: Re: [Kamailio-Users] Is PRACK Supported? > Yes. But it is up to the endpoint to send the PRACK in response to > a > non-100 provisional message sent reliably, not the proxy, so > Kamailio > doesn't really need to 'support' anything related to the PRACK > method > other than relaying it, which it will. > > ingdavidcespedes(a)cable.net.co wrote: > > > Hi > > > > Does anyone know if RFC 3262 and its PRACK response are > supported by Kamailio? How can I implement it? > > > > Thanks in advance. > > > > David Cespedes > > > > > > _______________________________________________ > > Users mailing list > > Users(a)lists.kamailio.org > > http://lists.kamailio.org/cgi-bin/mailman/listinfo/users > > > -- > Alex Balashov > Evariste Systems > Web : http://www.evaristesys.com/ > Tel : (+1) (678) 954-0670 > Direct : (+1) (678) 954-0671 > Mobile : (+1) (706) 338-8599 >

3 3

[Kamailio-Users] Is PRACK Supported?
by ingdavidcespedes＠cable.net.co 24 Nov '08

24 Nov '08

Hi Does anyone know if RFC 3262 and its PRACK response are supported by Kamailio? How can I implement it? Thanks in advance. David Cespedes

2 1

[Kamailio-Users] About http_query function and HTTP replies > 400
by Iñaki Baz Castillo 24 Nov '08

24 Nov '08

Hi, I see in the code: ----------- curl_easy_getinfo(curl, CURLINFO_HTTP_CODE, &stat); if ((stat >= 200) && (stat < 400)) { at = index(stream, (char)10); /* search for line feed */ if (at == NULL) { at = stream; /* set empty string */ } val.rs.s = stream; val.rs.len = at - stream; val.flags = PV_VAL_STR; dst = (pv_spec_t *)_dst; dst->setf(_m, &dst->pvp, (int)EQ_T, &val); } return stat; ----------- So if the reply is > 400 then the function doesn't extract the first line of the body. While it makes sense (if a web server returns 404 it means that the page has not been found so the body doesn't matter at all). But I'm trying to use "http_query" as a logic mechanism: - alice calls bob. - Kamailio asks a http server a query: http://web_server/check_permission.php?fu=alice&ru=bob - The web server runs its own logic (asking to BD and so) and decides that alice is not allowed to call bob. But bob wants to "explain" alice why he doesn't accept calls from him, so the web server replies: ----------------- HTTP/1.1 403 Forbidden Alice, you are very boring and I don't accept more calls from you ----------------- - So the $retcode of "http_query" would be 403 but we are also interested in the body (stored in $var(reply_http_query)) since we could generate a response like: sl_send_reply(403, "$var(reply_http_query)"); Doesn't it make sense? Also, web server could reply "HTTP/1.1 302 Moved temporaly" being the first line of the body the new SIP URI to contact. Opinions? BTW it could be really great if the reply body could be more complete, for example storing more than one line (various variables) and so... Regards. -- Iñaki Baz Castillo

1 0

Re: [Kamailio-Users] append_hf
by Matteo D'Amato 24 Nov '08

24 Nov '08

Hello, I'm trying to append trunk group information to my Contact header so I'm, using append_hf as follows append_hf("tgrp=30001 \r\n", "Contact"); but it seems to go on the second line. How do I remove the line feed? Max-Forwards: 69. Contact: <sip:1001@192.168.1.2:44114>. tgrp=DMS19 . --Matteo

3 8

[Serusers] REGISTER control based on UA
by inge 24 Nov '08

24 Nov '08

Hi all, I look for a workaround to use a white list in addition of authentification proces, based on User-Agent (ie. for example : deny "Asterisk IPBX" permit "Cisco IPhone...") I think to use permissions module, but I don't find an example of this usage. Thanks for your support. Regards, A. LEMOINE

2 3

[Serusers] ser 2.0 lookup_user
by G. Ricca 22 Nov '08

22 Nov '08

I'm testing ser 2.0 lookup_user("$tu.uid", "@ruri") fails if ruri is like this:'sip:user@domain;user=phone'. Es. if the call comes from PSTN. Have someone the solution?? g.ricca(a)csinfo.net

1 0

[Kamailio-Users] "408 - Request timeout" instead of "503" problem.
by Ricardo Martinez 21 Nov '08

21 Nov '08

Hello List. I have the next situation. I'm trying to build a "LCR" but using the information from a Radius Server, so 'im using the avp_radius module to obtain the "next_gw" data from my DB. So far so good, I have been able to retry a failed call with the next gateway in the list. In my tests I'm using a list of 3 gateways and I'm seeing the next behavior : I have all the gateways off-line, so the call is redirected to the first, second and and finally to the third gateway, when there is no moer gateways to try I have this statement in my config file : if( there is gateways to try on the list... ) { route(1); } else { sl_send_reply("503", "No more DB routes"); exit; } I send the "503 - No more DB routes" but the Kamailio also send a "408 Request Timeout". What could this be happening? I even tried with just one gateway on the list, with the same results. I was expecting just the "503" message, and not the "408". Hope that someone could help me. I'm attaching my kamailio-snnipet.cfg file and a full debug with the behavior. Thanks! Ricardo Martinez

2 2

[Kamailio-Users] TCP failover
by Gawith 21 Nov '08

21 Nov '08

Hi guys, is there a way to realize TCP fail over? With UDP, I check for 408s in the failure route and react accordingly. With TCP, the tm modules sends out a 477 without any chance for me to interfere. Regards.

3 4

[Kamailio-Users] Help!!!!! WARNING:tm:run_failure_handlers: no UAC or CANCEL support (1, 0)
by Krunal Patel 21 Nov '08

21 Nov '08

Hi, When I am sending high volume calls to openser , I am getting WARNING:tm:run_failure_handlers: no UAC or CANCEL support (1, 0). Please help me to find out the cause of it. I am using openser 1.2.3. Thanks Krunal Patel

3 6

[Kamailio-Users] about sip router project
by Daniel-Constantin Mierla 21 Nov '08

21 Nov '08

Hello, I want to reveal some details from the process of getting to sip-router.org project. Next statements are from my personal point of view -- warning: quite long message, probably boring... When all started, back in 2001/2002, it was research and SIP Express Router (SER). Over the time became more than that, the market demanded new features pushed beyond a SIP proxy/router definition, the place of this application was no longer in research, business side and telephony industry forced to take actions. In that context I co-founded OpenSER in 2005, leaving SER to continue its way. Now after several years, the situation evolved as well, SIP is clear the today's technology for telecommunication, every Telco out there is deploying/replacing its infrastructure with SIP. However, SIP was designed for more than this, other companies develop innovative services and products using this protocol. I could identify couple of directions within our project: - old-style-fashion switch - mapped on SIP Router/Proxy, where speed and reliability is the main concern - call/dialog stateful proxy (back-to-back user agent) - for a larger set of security and service features - pbx-like features using SIP signaling only - call pickup, shared line appearance, etc... - new fashion functionalities - IM&Presence, gaming, integrated and convergent communication, application servers... To be able to sustain and keep high level quality, it is clear that we need more companies in, entities that are interested on different directions of the development, so they contribute there. I am interested in the first and last direction with higher priority, but I don't want to leave out the other two. Moveover, kamailio/openser is used now in many deployments, some serving millions of users and billions of minutes per month. We need to provide a reliable environment so more companies are confident the development and maintenance continue. The project shall prove the maturity that is not dependent on gringo-like actions, one company influence, forking out of nowhere, domain hijacking, etc... this is the first goal for myself, something I want to ensure before anything else. sip-router.org was not one minute/meeting decision (after a beer, dinner or one email, ...). Discussions started between different persons, coordinated or privately, several months ago, long before the latest fork. It was clear that SER and OpenSER made their points over the time, one satisfying better the need for stability, performance, the other better for innovation and flexibility. At a point in future, sooner or later, each project would have been switched some of its resources to the other direction. At the time of announcement, the sip-router.org site had comprehensive content about how this will work. It was the result of face-to-face meetings, phone and email conversations that took place a lot in the last months before the news. It was no decision until everyone deeply involved in each project acknowledged that there are mutual benefits for everybody (developers, users and businesses behind both projects) backed up by willingness to do it in a fair manner. I cannot talk about other projects in the x-SER eco-system, but with Kamailio/OpenSER never was the case/proposal of merging back to SER, all the time was about collaboration and joint effort. It will never happen to drop our goals for innovation and flexibility. Therefore we discussed and agreed the development mechanisms to ensure the need of each project: a stable layer (core + tm) and innovation by modules or libraries. Nothing was left out, every aspect, from licensing, contribution, ... to releasing and management, was approached. The meeting in Karsruhe came just to conclude that. All our community members were happy about announcement, and, as a matter of fact, there were no political-like discussions conducted between our members since sip-router.org announcement, the focus moved on the technical side and good progress was reached so far: http://lists.kamailio.org/pipermail/users/2008-November/020694.html Personally, I consulted people in open source and communication world, that are not particularly technical or in relation with x-SER projects. Getting to sip-router.org took more than half year since I realized a common layer between the x-SER projects should be beneficial for everybody. There are more things to say, but maybe not that relevant. I let them for the time we meet at SIP Router events. Now I hope several points are more clear: - it is not a merge back in SER, it is a joint project (this just because some tried to suggest it) - the entire collaboration process was carefully discussed and planned - it was conducted by the need of reliable, non-confusing environment -- that ensures sustainable development, innovation and rock-solid stability, it protects the interests of developers, users and businesses investing resources in the project. At the end, I want to thank to Kamailio and SER management team members, to the developers and many other people involved in both projects that helped with this process - they dedicated lot of time and resources. Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

1 0

[Kamailio-Users] sip router project status
by Daniel-Constantin Mierla 21 Nov '08

21 Nov '08

Hello, just to let you know that yesterday evening first openser/kamailio modules run on the common core+tm provided by sip-router project. That was siputils (new module in Kamailio devel version). Soon after: - xlog module was ready too, with just an extra define in Makefile, marking the inclusion of pseudo-variable and transformation API in sip-router -- one can do color printing via xlog. Note that all pseudo-variables and transformations will be moved in PV module as discussed some time ago on Kamailio devel mailing list. - db api of Kamailio and SER were included as library and other modules become compilable with sip-router For reference: http://lists.sip-router.org/pipermail/sr-dev/2008-November/000071.html http://lists.sip-router.org/pipermail/sr-dev/2008-November/000077.html http://lists.sip-router.org/pipermail/sr-dev/2008-November/000081.html http://lists.sip-router.org/pipermail/sr-dev/2008-November/000082.html Once MI and statistics will become libraries as well, then many other modules shall work more or less out of the box (some statistics done in core and 1-2 mi commands will miss in the first phase). Then in comes the second big step, after module integration, config language update -- after that point we are kind of 70% ready. All these happened in just few days since source code repository (GIT) was up ... it looks like we will get most of the features from Kamailio/OpenSER and SER together sooner than I expected ... let's see ... Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

1 0

[Kamailio-Users] kamailio devel team
by Daniel-Constantin Mierla 21 Nov '08

21 Nov '08

Hello, last month was very busy for myself, with lot of work and traveling for the sip-router.org, so apart of announcing few updates, I focused on getting things done rather than going in pointless discussions. I will send couple of other emails related to this subject. However, there was one person writing untrue statements and offending the developers of Kamailio/OpenSER on mailing lists, web and IRC channels. If he would have searched a bit on the net, have talked with our developers, he would realize that people in our team are very rich in skills and experience, then probably he would refrain from statements like "no skills", "no knowledge". Until someone else than him, recognize him as the greatest, gets the Nobel prize, publishes world recognized books or standards, so I can take his opinion in consideration, the development of Kamailio/Project is ensured by people such as: - Juha Heinanen, doctor in computer science, former professor at Tampere University, author of many RFCs, and the list can continue ... from the web: http://occamnet.com/company/directors_and_advisors/jheinanen.cfm http://www.arkko.com/tools/rfcstats/juhaheinanen.html - Klaus Darilion, doctor in computer science at Technical University Vienna, involved in ENUM and security of VoIP/SIP, author/contributor to several open source applications and papers related to these domains http://www.ipcom.at/index.php?id=565 - Henning Westerholt, computer science engineer, in charge with the biggest VoIP deployment based on Kamailio/OpenSER I ever heard of: about 2 000 000 users, 5 000 000 phone numbers, 1 000 000 000 routed minutes per month. It is at least twice bigger than other deployments of openser/kamailio I am aware of. http://www.1und1.de I am stopping here, but all the other members of Kamailio/OpenSER devel team have broad knowledge in computer programming and VoIP technologies, authored or contributed to other open source applications -- just google the names. As co-founder of this project I felt is my duty to show the true. Therefore those statements are proofless and it is sad to see somebody can come up with such things. The development of Kamailio/OpenSER boosted since release 1.4, in summary: http://www.kamailio.org/dokuwiki/doku.php/features:new-in-1.5.x http://www.kamailio.org/dokuwiki/doku.php/roadmap:1.5.x and we are not ready yet with the new features for 1.5. Meanwhile, effort is directed to sip-router.org project as well -- I will post a status update soon. Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

1 0

Re: [Kamailio-Users] photos from Karlsruhe meeting
by luzango mfupe 20 Nov '08

20 Nov '08

Hi Daniel,Nice photos, but would you mind to put names of the participant in the photos??? i think that could be much better. Rgds, Lu. -- Luzango Mfupe TUUNE MOBILE Tel:0128440528/0123825710 Tshwane-RSA "...Ships are safe in harbor, but they were never meant to stay there......."

2 1

[Kamailio-Users] ACC module issue logging Reason: SIP header in missed_calls
by sergejf 20 Nov '08

20 Nov '08

2 3

[Kamailio-Users] openser - asterisk - methods field location table
by Matteo Piazza 20 Nov '08

20 Nov '08

Hi all, I'm using openser 1.3.3. And I found an issue between asterisk and openser. When an asterisk register himself to openser this is my opeserctl ul show: Contact:: sip:s@172.25.18.168 Q= Expires:: 116 Callid:: 76e873601b776e8a430237091a76a483(a)172.25.18.168 Cseq:: 103 User-agent:: Asterisk PBX 1.4 Test State:: CS_DIRTY Flags:: 0 Cflag:: 0 Socket:: udp:172.25.18.163:5060 Methods:: 4294967295 In to the postgres database into location table I have 2;"50001";"ttnnet.it";"sip:s@172.25.18.168";"";"";"2008-11-13 10:56:24";-1;"76e873601b776e8a430237091a76a483(a)172.25.18.168";108;"2008-11-13 10:54:24";0;0;"Asterisk PBX 1.4 Test";"udp:172.25.18.163:5060"; As you can see the methods field into the database is null! This causes an issue when you restart openser, the asterisk pbx is unreachable until the next registration because the lookup function doesn't match the methods field. The number 4294967295 is the max int (without sign), maybe there is a issue in the function that calculate this value and post the query. Any clue? Kind regards Matteo

2 12

Re: [Kamailio-Users] [OpenSER-Users] Perl module and moduleFunction()
by Daniel-Constantin Mierla 20 Nov '08

20 Nov '08

please cc always to mailing lists... On 11/18/08 18:30, Sebastian sastre wrote: > Daniel, > > Thanks a lot for the info. I was playing with the scripts yesterday to > find a workaround. > > When I call my perl script with perl_exec() if I rewrite the headers > with > > $m->rewrite_ruri("sip:A@B"); > > They never get overwritten. > rewrite_uri should set a new request URI, not headers. What do you expect to be overwritten? Daniel > Is there a way to access the $ru variable from the script? > > I also tried using the Avpops module but no luck. > > Thanks !!! > > Sebastian Sastre > Senior Network Engineer > > > NextCommunications, Inc. > 100 North Biscayne Blvd. Suite 900 > Miami, FL. 33132. USA > Phone: +1-305-356-4558 > Main: +1-305-356-454528 > Fax: +1-305-374-4081 > e-mail: sebas(a)nextcommunications.com > > -----Original Message----- > From: Daniel-Constantin Mierla [mailto:miconda@gmail.com] > Sent: Tuesday, November 18, 2008 6:14 AM > To: Sebastian sastre > Cc: users(a)lists.kamailio.org > Subject: Re: [Kamailio-Users] [OpenSER-Users] Perl module and > moduleFunction() > > Hello, > On 11/14/08 01:54, Sebastian sastre wrote: > >> Hello, >> >> >> >> I am interested in knowing which flags I can set to have the >> sl_send_reply work from a perl script. >> >> > be careful, it is prety dangerous -- the undocumented parameter is > "unsafemodfnc", set it to 1. > > Cheers, > Daniel > > -- Daniel-Constantin Mierla http://www.asipto.com

2 2

[Kamailio-Users] [Fwd: [Kamailio-Devel] Karlsruhe meeting minutes]
by Daniel-Constantin Mierla 20 Nov '08

20 Nov '08

-------- Original Message -------- Subject: [Kamailio-Devel] Karlsruhe meeting minutes Date: Thu, 20 Nov 2008 01:35:25 +0100 From: Andrei Pelinescu-Onciul <andrei(a)iptel.org> To: sr-dev(a)lists.sip-router.org, devel(a)lists.kamailio.org, serdev(a)iptel.org Hi, I've attached a very brief version of the Karlsruhe meeting minutes. It contains input mostly from me and Daniel (so that you know who to blame :-)). Sorry for the long delay. Hope we haven't missed anything and if we did feel free to reply to this thread. Thanks a lot to 1&1 for hosting the meeting and to everyone who was able to come on such a short notice. Andrei - move forward, sip-router.org repo should be up next week - end of January we should have a runable core+tm with support for the most used features from both kamailo and ser (100% support might be a little delayed) - kamailo next-next release (probably after spring next year) will be based on sip-router core+tm - next or next-next ser release will be based on sip-router (ser might make another 2.1 release from the current cvs, since the code is ready - to be discussed) - future releases will most likely be common and will unify all or most of the modules (depending on everything up to that point working ok) - copyright: patches that are not accompanied by (c) claims will not add to the (c). We should put this on a web page and when in doubt we can ask the patch author for confirmation. While it's likely this has no or very limited legal value (especially in Europe), it will server at least as a gentleman agreement. We need this because: 1. we need the agreement of all (c) holders for the GPL code to add licensing exemptions (e.g. we need to add an openssl linking exemption) and it's easy if we have a known "small" set of (c) holders 2. people might not like having multiple (c) notices on files they created, just because someone did send a trivial or not so significant patch (note: "trivial" and "significant" are very relative) On problems, probably the board will decide, if nobody gives up the claim we'll fork the module (worst case, to be avoided as hard as possible). - forking modules: highly discouraged, but allowed - unmantained and rarely used modules: removed after a grace period - board: for now we continue to have 2 boards, ser and kamailo at least until we have something runable. In the meantime we should think/discuss how the common board will look like: how it will be elected and for how long, "composition" (how many devels, how many from the user community, testers a.s.o) - testing: very important, Jerome proposed having beta-tester groups and stressed out the importance of dynamic tested. Everybody seems to agree, but there are doubts about finding beta-testers volunteers. - release management: we need a release manager for each release - documentation: kamailo uses a wiki for core, and docbook .xml for modules ser use NEWS (txt file) for core and docbook for modules, but it's in the process of migrating to a more man page friendly format (still .xml) More discussion is needed, between the main doc writers from both sided. sip-router.org: - repo should be up next week - sr-dev should be used for technical dicussions related to merging the cores - new features mails should be cc'ed to sr-dev too (very important especially when core or tm is involved). - todo: find easy to remember short name related projects: - some modules may be on separate repos for a while (e.g., openimscore), maintaned by their devs for using them out of the box with sip-router - stand-alone application servers (Voztelecom/WeSIP, Iptego/SASI) may merge the communication interface specs in the future. - it is a need for a place where to collect basic info about related projects further steps: - new meeting, to be organized somewhere end of winter/beginning of spring 2009 (topics: celebrate first integrated working version, discuss further development of sip-router) - setup of adjacent tools that help developing code and documentation (e.g., wiki, tracker) general opinions: - there are x-ser platforms running milions of users, sip-router must provide a rock-solid SIP server, esure trust and project reliability - while having a strong focus on above item, innovation shall not be stopped, new features to be added as module to avoid effects to core and main modules - very important modules (e.g., usrloc, registrar, ...) should be protected as much as possible, patches and new features to be carefully reviewed not to affect stability and interoperability - improvements to most important parts to be discussed on sr-dev mailing list _______________________________________________ Devel mailing list Devel(a)lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel

1 0

[Kamailio-Users] Help With AVP
by Ali Jawad 20 Nov '08

20 Nov '08

Hi I am trying to set a different number of rings for each user before the calls coming to him are diverted to his voicemail. Using: modparam("tm", "fr_inv_timer", 200) --> This is a global setting I need something that can be tuned individually like : modparam("tm", "fr_inv_timer_avp", "$avp(i:25)") If I do use the fr_inv_timer_avp where can I set the value of avp individually for the user. Should I use something like avp_write("$ruri/domain", "i:13"); <-- something similar to this in the route{} statement ? Please advice. With Regards Ali Jawad System Administrator Splendor Telecom (www.splendor.net) Beirut, Lebanon Phone: +961 1 373725 Fax: + 961 1 375554

2 1

[Kamailio-Users] Using rewritehost to multiple hosts
by Sven Schulz 20 Nov '08

20 Nov '08

Hi, Is there an easy way to do this? I'd like to use rewritehost to point to multiple IP addresses (for redundancy purposes). Can this be done with rewritehost or some other method? Sven Schulz Penn State University

2 1

Re: [Kamailio-Users] 64-bit openser
by Klaus Darilion 20 Nov '08

20 Nov '08

joy yue wrote: > > > > On 11/18/08, *Klaus Darilion* <klaus.mailinglists(a)pernau.at > <mailto:klaus.mailinglists@pernau.at>> wrote: > > joy yue wrote: > > > Hi Folks, > > I get out-of-memory error with openser1.3 version. As I already > increase the share memory size to 2G, looks like the only choice > is to compile openser as 64-bit binary. Before I go further, I'd > like to check if anyone has experience in this. Does OPenser > work with 64-bit binary? > > > > Maybe you are triggering a bug in openser and leaking memory. I > think it would be better to debug why you are running out of memory. > http://kamailio.org/dokuwiki/doku.php/troubleshooting:memory > > > It doesn't look like memory leak. With lower load, openser runs fine > without the out-of-memory error. Hi! (please cc the list) So how much traffic is on your openser? (registrations per seconds, transactions per seconds ...) Maybe it leaks only under heavy load? (e.g.race conditions?) regards klaus

4 11

[Kamailio-Users] Contact field
by Alex R.S.M 19 Nov '08

19 Nov '08

Hi, Is there a function that can modify "Contact" field in SIP header? Thanks, Alex _________________________________________________________________ Windows Live Hotmail now works up to 70% faster. http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_faster…

3 4

Re: [Kamailio-Users] 64-bit openser
by Samuel Muller 19 Nov '08

19 Nov '08

Heya Joy, I tried OpenSER 1.3 4 months ago in a 64-bit architecture and i had too many problems during compilation, or when ok, it crashes often. I'd to turn back my project to SER (sorry Daniel ;), I didn't have time to debug. Then, Kamailio project appeared, and I use it in a 64-bit architecture now, I didn't have any problems (compilation, ...). All is fine, it works perfectly. Maybe, just try it ? .Sam.

1 0

[Kamailio-Users] Problem With TM and USRLOC
by Ali Jawad 19 Nov '08

19 Nov '08

Hi All I do use usrloc in dbmode 1, I tried to apply modparam("tm", "fr_inv_timer", 15) But it did not work unless I do set dbmode 0 in usrloc. What happens is that if I do set the fr_inv_timer to 15 and userloc dbmode to 0 both parties hang up after 15 seconds. If I do set dbmode to 1, the calling party just keeps ringing after 15 seconds. And EVEN if the other party hangs up the calling party keeps ringing. This does not happen in dbmode 2 Please advice. Thanks

2 1

[Kamailio-Users] carrierroute extensions in kamailio 1.5
by Henning Westerholt 19 Nov '08

19 Nov '08

Hi all, i'm happy to announce that we finished the work on the carrierroute module for kamailio 1.5. We implemented a bunch of new features that makes the module more flexible then ever, and also fixed a few annoyances in the module usage: 1. Improved routing data loading The module supports now the partioned loading of routing data during startup and reloads. In the past when one want to load big route set it was necessary to increase the private memory pool size, as the data was stored temporarily there. Now this is not necessary anymore, its possible to load route sets with e.g. 400.000 rules in the standard (private memory) configuration. 2. Efficient matching of domains and carriers In the old implementation a simple linear list was used, this was replaced with a fast binary search function. The module can now look up carrier and domains in most cases with O(log n), which makes it more scalable when a big number of carriers and/ or domains are involved. Only when a dynamic string is used in the config script a full list search is needed. 3. Support for non-numerical prefix matching Carrierroute now supports also the prefix matching with non-numerical characters. Its possible to use the entire standard ascii charset for route matching. This is configurable with a module parameter, the default implementation is still the know digit matching method. Please keep in mind that memory demands will increase somewhat when the extended matching is used. This additonal flexibility will probably bring a small overhead with it, as some additional logic is involved during the routing deciscion. But i don't think this will be noticable on today standard servers. 4. Extensive refactoring and cleanups We restructured and refactored the code in most areas, to make the module implementation and structure more understandable, maintainable and extensible. We replaced the usage of custom datatypes and fixup functions with the standard core implementation, switched to the autogenerated DB interface and use now standard glibc functions e.g. for the list search. We changed certain structures to not store the full name of carriers and domains in memory to save space and got finally rid of this mismatch between internal and external carrier ID. More details about the new implementation can be found in the documentation at: http://www.kamailio.org/docs/modules/devel/carrierroute.html Porting hints, e.g. for the new database structure are provided at: http://www.kamailio.org/dokuwiki/doku.php/install:1.4.x-to-1.5.0 We did tests with our testsuite, but please keep in mind that there are probably a few bugs present. So any testing is highly appreciated, please report any bugs to the tracker or the development list. With best regards, Henning Westerholt -- Henning Westerholt - Development Consumer Products / DSL Core 1&1 Internet AG, Ernst-Frey-Str. 9, 76135 Karlsruhe, Germany Vorstände: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Thomas Gottschlich, Robert Hoffmann, Markus Huhn, Hans-Henning Kettler, Dr. Oliver Mauss, Jan Oetjen - Aufsichtsratsvorsitzender: Michael Scheeren Amtsgericht Montabaur / HRB 6484

1 0

[Serusers] Registration Issue
by Jai Rangi 19 Nov '08

19 Nov '08

<serusers(a)lists.iptel.org> All, I got a weird problem for Grand Stream 486 ATA registering on my ser server. Server in in US and ATA is registering from India. Here is ngrep trace. Every time the device tries to register the "Register" word get some extra characters. For example in this case REGISTER became R:50145EGISTER and ser replies with 404 User Not found. Anyone faced this issue, any idea how to debug/fix this problem this. U 59.180.68.3:50145 -> XXX.XXX.XXX.211:5060 *R:50145EGISTER* sip:XXX.XXX.XXX.211 SIP/2.0..Via: SIP/2.0/UDP 59.180.68.3:50146;branch=z9hG4bKbd52be32ad52bf32..From: <sip:1004613554@XXX.XXX.XXX.211;user=phone>;ta g=e5ca733921001365..To: <sip:1004613554@XXX.XXX.XXX.211;user=phone>..Contact: *..Supported: replaces, timer..Call-ID: 53fb73fb244b57b9@192.168.1.4..CSeq: 100 REG ISTER..Expires: 0..User-Agent: Grandstream HT487 1.1.0.26..Max-Forwards: 70..Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE..Content-L ength: 0.... # U XXX.XXX.XXX.211:5060 -> 59.180.68.3:50146 SIP/2.0 404 User Not Found..Via: SIP/2.0/UDP 59.180.68.3:50146;branch=z9hG4bKbd52be32ad52bf32..From: <sip:1004613554@XXX.XXX.XXX.211;user=phone>;tag=e5ca73392100 1365..To: <sip:1004613554@XXX.XXX.XXX.211;user=phone>;tag=2d30881a84b19f18b705d17dbf895433.1f56..Call-ID: 53fb73fb244b57b9@192.168.1.4..CSeq: 100 REGISTER..Serve r: Sip EXpress router (0.9.6 (i386/linux))..Content-Length: 0..Warning: 392 XXX.XXX.XXX.211:5060 "Noisy feedback tells: pid=7507 req_src_ip=59.180.68.3 req_src_ port=50145 in_uri=sip:XXX.XXX.XXX.211 out_uri=sip:XXX.XXX.XXX.211 via_cnt==1".... ### U 59.180.68.3:50145 -> XXX.XXX.XXX.211:5060 R:50145EGISTER sip:XXX.XXX.XXX.211 SIP/2.0..Via: SIP/2.0/UDP 59.180.68.3:50146;branch=z9hG4bKbd52be32ad52bf32..From: <sip:1004613554@XXX.XXX.XXX.211;user=phone>;ta g=e5ca733921001365..To: <sip:1004613554@XXX.XXX.XXX.211;user=phone>..Contact: *..Supported: replaces, timer..Call-ID: 53fb73fb244b57b9@192.168.1.4..CSeq: 100 REG ISTER..Expires: 0..User-Agent: Grandstream HT487 1.1.0.26..Max-Forwards: 70..Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE..Content-L ength: 0.... # U XXX.XXX.XXX.211:5060 -> 59.180.68.3:50146 SIP/2.0 404 User Not Found..Via: SIP/2.0/UDP 59.180.68.3:50146;branch=z9hG4bKbd52be32ad52bf32..From: <sip:1004613554@XXX.XXX.XXX.211;user=phone>;tag=e5ca73392100 1365..To: <sip:1004613554@XXX.XXX.XXX.211;user=phone>;tag=2d30881a84b19f18b705d17dbf895433.1f56..Call-ID: 53fb73fb244b57b9@192.168.1.4..CSeq: 100 REGISTER..Serve r: Sip EXpress router (0.9.6 (i386/linux))..Content-Length: 0..Warning: 392 XXX.XXX.XXX.211:5060 "Noisy feedback tells: pid=7522 req_src_ip=59.180.68.3 req_src_ port=50145 in_uri=sip:XXX.XXX.XXX.211 out_uri=sip:XXX.XXX.XXX.211 via_cnt==1"....

1 0

[Serusers] Register Signal issue.
by Jai Rangi 19 Nov '08

19 Nov '08

All, I got a weird problem for Grand Stream 486 ATA registering on my ser server. Server in in US and ATA is registering from India. Here is ngrep trace. Every time the device tries to register the "Register" word get some extra characters. For example in this case REGISTER became R:50145EGISTER and ser replies with 404 User Not found. Anyone faced this issue, any idea how to debug/fix this problem this. U 59.180.68.3:50145 -> XXX.XXX.XXX.211:5060 *R:50145EGISTER* sip:XXX.XXX.XXX.211 SIP/2.0..Via: SIP/2.0/UDP 59.180.68.3:50146;branch=z9hG4bKbd52be32ad52bf32..From: <sip:1004613554@XXX.XXX.XXX.211;user=phone>;ta g=e5ca733921001365..To: <sip:1004613554@XXX.XXX.XXX.211;user=phone>..Contact: *..Supported: replaces, timer..Call-ID: 53fb73fb244b57b9@192.168.1.4..CSeq: 100 REG ISTER..Expires: 0..User-Agent: Grandstream HT487 1.1.0.26..Max-Forwards: 70..Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE..Content-L ength: 0.... # U XXX.XXX.XXX.211:5060 -> 59.180.68.3:50146 SIP/2.0 404 User Not Found..Via: SIP/2.0/UDP 59.180.68.3:50146;branch=z9hG4bKbd52be32ad52bf32..From: <sip:1004613554@XXX.XXX.XXX.211;user=phone>;tag=e5ca73392100 1365..To: <sip:1004613554@XXX.XXX.XXX.211;user=phone>;tag=2d30881a84b19f18b705d17dbf895433.1f56..Call-ID: 53fb73fb244b57b9@192.168.1.4..CSeq: 100 REGISTER..Serve r: Sip EXpress router (0.9.6 (i386/linux))..Content-Length: 0..Warning: 392 XXX.XXX.XXX.211:5060 "Noisy feedback tells: pid=7507 req_src_ip=59.180.68.3 req_src_ port=50145 in_uri=sip:XXX.XXX.XXX.211 out_uri=sip:XXX.XXX.XXX.211 via_cnt==1".... ### U 59.180.68.3:50145 -> XXX.XXX.XXX.211:5060 R:50145EGISTER sip:XXX.XXX.XXX.211 SIP/2.0..Via: SIP/2.0/UDP 59.180.68.3:50146;branch=z9hG4bKbd52be32ad52bf32..From: <sip:1004613554@XXX.XXX.XXX.211;user=phone>;ta g=e5ca733921001365..To: <sip:1004613554@XXX.XXX.XXX.211;user=phone>..Contact: *..Supported: replaces, timer..Call-ID: 53fb73fb244b57b9@192.168.1.4..CSeq: 100 REG ISTER..Expires: 0..User-Agent: Grandstream HT487 1.1.0.26..Max-Forwards: 70..Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE..Content-L ength: 0.... # U XXX.XXX.XXX.211:5060 -> 59.180.68.3:50146 SIP/2.0 404 User Not Found..Via: SIP/2.0/UDP 59.180.68.3:50146;branch=z9hG4bKbd52be32ad52bf32..From: <sip:1004613554@XXX.XXX.XXX.211;user=phone>;tag=e5ca73392100 1365..To: <sip:1004613554@XXX.XXX.XXX.211;user=phone>;tag=2d30881a84b19f18b705d17dbf895433.1f56..Call-ID: 53fb73fb244b57b9@192.168.1.4..CSeq: 100 REGISTER..Serve r: Sip EXpress router (0.9.6 (i386/linux))..Content-Length: 0..Warning: 392 XXX.XXX.XXX.211:5060 "Noisy feedback tells: pid=7522 req_src_ip=59.180.68.3 req_src_ port=50145 in_uri=sip:XXX.XXX.XXX.211 out_uri=sip:XXX.XXX.XXX.211 via_cnt==1"....

1 0

[Serusers] Register Signal corrupted
by Jai Rangi 19 Nov '08

19 Nov '08

All, I got a weird problem for Grand Stream 486 ATA registering on my ser server. Server in in US and ATA is registering from India. Here is ngrep trace. Every time the device tries to register the "Register" word get some extra characters. For example in this case REGISTER became R:50145EGISTER and ser replies with 404 User Not found. Anyone faced this issue, any idea how to debug/fix this problem this. U 59.180.68.3:50145 -> XXX.XXX.XXX.211:5060 *R:50145EGISTER* sip:XXX.XXX.XXX.211 SIP/2.0..Via: SIP/2.0/UDP 59.180.68.3:50146;branch=z9hG4bKbd52be32ad52bf32..From: <sip:1004613554@XXX.XXX.XXX.211;user=phone> <sip:1004613554@XXX.XXX.XXX.211;user=phone>;ta g=e5ca733921001365..To: <sip:1004613554@XXX.XXX.XXX.211;user=phone> <sip:1004613554@XXX.XXX.XXX.211;user=phone>..Contact: *..Supported: replaces, timer..Call-ID: 53fb73fb244b57b9@192.168.1.4..CSeq: 100 REG ISTER..Expires: 0..User-Agent: Grandstream HT487 1.1.0.26..Max-Forwards: 70..Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE..Content-L ength: 0.... # U XXX.XXX.XXX.211:5060 -> 59.180.68.3:50146 SIP/2.0 404 User Not Found..Via: SIP/2.0/UDP 59.180.68.3:50146;branch=z9hG4bKbd52be32ad52bf32..From: <sip:1004613554@XXX.XXX.XXX.211;user=phone> <sip:1004613554@XXX.XXX.XXX.211;user=phone>;tag=e5ca73392100 1365..To: <sip:1004613554@XXX.XXX.XXX.211;user=phone> <sip:1004613554@XXX.XXX.XXX.211;user=phone>;tag=2d30881a84b19f18b705d17dbf895433.1f56..Call-ID: 53fb73fb244b57b9@192.168.1.4..CSeq: 100 REGISTER..Serve r: Sip EXpress router (0.9.6 (i386/linux))..Content-Length: 0..Warning: 392 XXX.XXX.XXX.211:5060 "Noisy feedback tells: pid=7507 req_src_ip=59.180.68.3 req_src_ port=50145 in_uri=sip:XXX.XXX.XXX.211 out_uri=sip:XXX.XXX.XXX.211 via_cnt==1".... ### U 59.180.68.3:50145 -> XXX.XXX.XXX.211:5060 R:50145EGISTER sip:XXX.XXX.XXX.211 SIP/2.0..Via: SIP/2.0/UDP 59.180.68.3:50146;branch=z9hG4bKbd52be32ad52bf32..From: <sip:1004613554@XXX.XXX.XXX.211;user=phone> <sip:1004613554@XXX.XXX.XXX.211;user=phone>;ta g=e5ca733921001365..To: <sip:1004613554@XXX.XXX.XXX.211;user=phone> <sip:1004613554@XXX.XXX.XXX.211;user=phone>..Contact: *..Supported: replaces, timer..Call-ID: 53fb73fb244b57b9@192.168.1.4..CSeq: 100 REG ISTER..Expires: 0..User-Agent: Grandstream HT487 1.1.0.26..Max-Forwards: 70..Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE..Content-L ength: 0.... # U XXX.XXX.XXX.211:5060 -> 59.180.68.3:50146 SIP/2.0 404 User Not Found..Via: SIP/2.0/UDP 59.180.68.3:50146;branch=z9hG4bKbd52be32ad52bf32..From: <sip:1004613554@XXX.XXX.XXX.211;user=phone> <sip:1004613554@XXX.XXX.XXX.211;user=phone>;tag=e5ca73392100 1365..To: <sip:1004613554@XXX.XXX.XXX.211;user=phone> <sip:1004613554@XXX.XXX.XXX.211;user=phone>;tag=2d30881a84b19f18b705d17dbf895433.1f56..Call-ID: 53fb73fb244b57b9@192.168.1.4..CSeq: 100 REGISTER..Serve r: Sip EXpress router (0.9.6 (i386/linux))..Content-Length: 0..Warning: 392 XXX.XXX.XXX.211:5060 "Noisy feedback tells: pid=7522 req_src_ip=59.180.68.3 req_src_ port=50145 in_uri=sip:XXX.XXX.XXX.211 out_uri=sip:XXX.XXX.XXX.211 via_cnt==1"....

1 0

Re: [Kamailio-Users] global variable for inter-transaction
by Ovidiu Sas 18 Nov '08

18 Nov '08

Yes. You will need to remove the entry when the dialog ends (on BYE). If you don't get a BYE, you may end up with leftovers. You can clean them up by setting a cron job to check for 'old' records into your 'dlg' table and remove them. The hash module solution is more elegant, but you will need to wait for the next release. Regards, Ovidiu Sas On Tue, Nov 18, 2008 at 5:12 PM, Alex R. S. M <alex_rsm(a)hotmail.com> wrote: > Then this table would have an entry for each dialog. Do we need to flush the > table at any time? > > >> Date: Tue, 18 Nov 2008 10:26:35 -0500 >> From: osas(a)voipembedded.com >> To: alex_rsm(a)hotmail.com >> Subject: Re: [Kamailio-Users] global variable for inter-transaction >> CC: users(a)lists.kamailio.org >> >> At this point in time there are no variables that can store a value >> across dialogs. >> One alternative would be to store the value into a db during the first >> transaction and then retrieve it on the second transaction belonging >> to the same dialog. Use clid/fromtag/totag to identify the dialog. >> >> Regards, >> Ovidiu Sas >> >> On Tue, Nov 18, 2008 at 10:22 AM, Alex R. S. M <alex_rsm(a)hotmail.com> >> wrote: >> > Hi, >> > >> > What type of variable can store a value from one Transaction to another >> > Transaction in the same dialog, i.e. to store a value from "200 >> > response" >> > and use it in "BYE request". I tried VAR and AVP and they both are being >> > reset in the new Transaction. >> > >> > Please advice, >> > AR >> > >> > ________________________________ >> > Proud to be a PC? Show the world. Download the "I'm a PC" Messenger >> > themepack now. Download now. >> > _______________________________________________ >> > Users mailing list >> > Users(a)lists.kamailio.org >> > http://lists.kamailio.org/cgi-bin/mailman/listinfo/users >> > >> > > > ________________________________ > Proud to be a PC? Show the world. Download the "I'm a PC" Messenger > themepack now. Download now.

1 0

[Kamailio-Users] global variable for inter-transaction
by Alex R.S.M 18 Nov '08

18 Nov '08

Hi, What type of variable can store a value from one Transaction to another Transaction in the same dialog, i.e. to store a value from "200 response" and use it in "BYE request". I tried VAR and AVP and they both are being reset in the new Transaction. Please advice, AR _________________________________________________________________ Proud to be a PC? Show the world. Download the “I’m a PC” Messenger themepack now. hthttp://clk.atdmt.com/MRT/go/119642558/direct/01/

4 4

[Kamailio-Users] 64-bit openser
by joy yue 18 Nov '08

18 Nov '08

Hi Folks, I get out-of-memory error with openser1.3 version. As I already increase the share memory size to 2G, looks like the only choice is to compile openser as 64-bit binary. Before I go further, I'd like to check if anyone has experience in this. Does OPenser work with 64-bit binary? thanks, -Joy

2 1

[Kamailio-Users] incorrect tag in ACK message
by Alex R.S.M 18 Nov '08

18 Nov '08

Hi, I made a simple SIP test call. The end point reply to kamailio with 180, 200 messages. The end point includes "tag=1_1555_t58918_125k" in TO field of these messages. However, kamailio reply with ACK message that includes a random tag (tag=5f08ae5f) in TO field. This tag is not the same as the one sent by the end point: 1.1.1.1 end-point ip address 2.2.2.2 kamailio ip address INVITE From: <sip:1.1.1.1@2.2.2.2>;tag=snl-1226930829-1404351227071264-11 To: <sip:14078789913@x.x.x.x;user=phone> Call-ID: 9280396221-9479318750707221-11-7604239022 180 From: <sip:1.1.1.1@2.2.2.2>;tag=snl-1226930829-1404351227071264-11 To: <sip:14078789913@x.x.x.x;user=phone>;tag=1_1555_t58918_125k Call-ID: 9280396221-9479318750707221-11-7604239022 200 From: <sip:1.1.1.1@2.2.2.2>;tag=snl-1226930829-1404351227071264-11 To: <sip:14078789913@x.x.x.x;user=phone>;tag=1_1555_t58918_125k Call-ID: 9280396221-9479318750707221-11-7604239022 ACK From: <sip:1.1.1.1@2.2.2.2>;tag=snl-1226930829-1404351227071264-11 To: <sip:14078789913@2.2.2.2;user=phone>;tag=5f08ae5f Call-ID: 9280396221-9479318750707221-11-7604239022 How can I force it to send the correct tag? Thanks, AR _________________________________________________________________ Windows Live Hotmail now works up to 70% faster. http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_faster…

3 14

[Kamailio-Users] photos from Karlsruhe meeting
by Daniel-Constantin Mierla 18 Nov '08

18 Nov '08

Hello, a photo album that includes pictures (thanks to Jerome and Henning) from last week's Karlsruhe meeting of SIP Router project is available at: http://sip-router.org/pub/photos/album-sip-router-karlsruhe/ Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

1 0

[Kamailio-Users] ERROR:usrloc:dbrow2info: non-local socket
by ALAEDDINE abbech 18 Nov '08

18 Nov '08

Hi, maybe this has been discussed before and maybe I'm not too good in reading mailinglists, but anyhow. If you have two OpenSER proxies, no replication, and storing to the same location table, is there a way of disregading the socket information? I see in my logs: ERROR:usrloc:dbrow2info: non-local socket...ignoring, and I'm not really sure the implications of this message. Is the message ignored or is the socket information ignored? If this is not crucial, might this message be supressed in some way?

2 1

[Kamailio-Users] (no subject)
by Ricardo Martinez 18 Nov '08

18 Nov '08

Hello list. I'm having some problems trying to build a counter for my kamailio.cfg file. This is what I have.. Th main() ... load avp from radius} var(i)=0; route(3); ... route[1] { t_on_failure("1"); if (!t_relay()) { sl_reply_error(); }; xlog("L_INFO","[$ci] $rm t_relay a $ru"); exit; } route(3) ... $var(nr)=$avp(s:caller_nr); If ( var(i) < $var(nr) ); $var(i) = $var(i) + 1; route(1); else exit; failure_route[1] { xlog("L_INFO", "[$ci] $rm:$ru failure_route\n"); if (t_was_cancelled()) { xlog("L_INFO", "[$ci] $rm:$ru t_was_cancelled en failure_route\n"); exit; } if (!next_gw()) { xlog("L_INFO", "[$ci] No hay mas gateways para $rm:$ou\n"); route(3); } else { xlog("L_INFO", "XXXXX"); } t_on_failure("1"); t_relay(); } After I restart the service the first time a call arrives the counter seems to go OK, the counter goes from 0 to 2 (if the caller_nr=3). But the second time the $var(i) at the main and route(3) it's = 0, but in the failure_route it keeps the value = 3. What I'm doing wrong? Can someone help me here? Thanks Ricardo Martinez.-

2 2

[Kamailio-Users] AVP variable as a variable in a function
by Alex R.S.M 18 Nov '08

18 Nov '08

Hi, How can I use AVP variable as a variable in a function (eg: append_branch(??)) ? append_branch( $avp(i:10) ); // getting error message append_branch( "$avp(i:10)" ); // takes "$avp(i:10)" as the function parameter and not its value Thanks, Alex _________________________________________________________________ Color coding for safety: Windows Live Hotmail alerts you to suspicious email. http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_safety…

4 5

[Kamailio-Users] 401 Unauthorized
by Robert R 18 Nov '08

18 Nov '08

Hi, When client trying to REGISTER, kamailio responses with 401 Unauthorized. if (is_method("REGISTER")) { if (!www_authorize("", "subscriber")) { www_challenge("", "0"); exit; } if (!save("location")) sl_reply_error(); exit; } Here is my debug log: Nov 10 13:52:46 kamailio: DBG:core:get_hdr_field: cseq <CSeq>: <1> <REGISTER> Nov 10 13:52:46 kamailio: DBG:tm:t_lookup_request: start searching: hash=39046, isACK=0 Nov 10 13:52:46 kamailio: DBG:tm:matching_3261: RFC3261 transaction matching failed Nov 10 13:52:46 kamailio: DBG:tm:t_lookup_request: no transaction found Nov 10 13:52:46 kamailio: DBG:core:grep_sock_info: checking if host==us: 14==14 && [209.16.123.160] == [209.16.123.160] Nov 10 13:52:46 kamailio: DBG:auth:pre_auth: credentials with given realm not found Nov 10 13:52:46 kamailio: DBG:auth:reserve_nonce_index: second= 36, sec_monit= -1, index= 0 Nov 10 13:52:46 kamailio: DBG:auth:build_auth_hf: nonce index= 0 Nov 10 13:52:46 kamailio: DBG:auth:build_auth_hf: 'WWW-Authenticate: Digest realm="xx.xx.xx.xx", nonce="4918842a00000000663ef5a903a02d6628e7e8e8b093c44b"^M ' Am I missing something in the config? Regards, RR

2 1

[Kamailio-Users] [OpenSER-Users] Perl module and moduleFunction()
by Sebastian sastre 18 Nov '08

18 Nov '08

Hello, I am interested in knowing which flags I can set to have the sl_send_reply work from a perl script. Thanks

2 1

[Kamailio-Users] Mediaproxy and SDP-mangle
by Cosimo Fadda 18 Nov '08

18 Nov '08

Hi everybody, I have a sever inside a DMZ with a private IP address (10.20.30.40) reachable from the outside with a Public IP (90.80.70.60) Natted 1:1 to the private IP. I want to setup mediaproxy on this server, but since I cannot configure it with the public IP, in the resulting SDP messages the Private IP will appear . Can I use the function: sdp_mangle_ip("10.20.30.40","90.80.70.60"); to correct this behaviour? Or there is another way to run mediaproxy in this scenario? Thanks in advance, Cosimo

2 2

[Kamailio-Users] [Fwd: [SR-Dev] git repository online]
by Daniel-Constantin Mierla 18 Nov '08

18 Nov '08

FYI -------- Original Message -------- Subject: [SR-Dev] git repository online Date: Tue, 18 Nov 2008 02:18:34 +0100 From: Andrei Pelinescu-Onciul <andrei(a)iptel.org> To: sr-dev(a)lists.sip-router.org As you probably have noticed the git repository for sip-router is now online. It was started from ser core and tm. git urls: git://git.sip-router.org/sip-router (read only) http://git.sip-router.org/sip-router (read only, slower, git://... recomended) ssh://git.sip-router.org/sip-router (read write but account on git.sip-router.org needed) Web interface: http://git.sip-router.org/cgi-bin/gitweb.cgi Branches acl: the repository is setup so that you can write/commit only to the following branches: <your_username>/.* tmp/.* master We'll add access to more branches as needed (I've added this rules to avoid creating lots of "root" branches by mistake, e.g. git pull from a local branch without a refspec). Please create the commit messages following the git convention (start with one short line, preferably less then 50 chars summarizing the changes, then one empty line and then a more detailed description). See: http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#creating-g… http://www.tpope.net/node/106 Quick git introduction: # clone the repo into the sip-router directory git clone git://git.sip-router.org/sip-router cd sip-router git branch -a # show all branches # create a local branch based on origin/andrei/mod_f_params git checkout --track -b my_branch origin/andrei/mod_f_params git log # see commit log git log --pretty=oneline # only the first line from each commit vim Makefile.defs git add Makefile.defs git commit # or git commmit -a to skip the add step and commit all # changed files # push changes back (note you need ssh access for this) # note: the next command will fail, unless your username is andrei :-) # publish changes on the local "my_branc" to the remote # andrei/mod_f_params git push origin my_branch:andrei/mod_f_params # or push them into the master branch if you are sure about them git push origin my_branch:master For more info about git try: http://git.or.cz/gitwiki/GitDocumentation and if you want to know how it works: http://eagain.net/articles/git-for-computer-scientists/ (highly recommended) CVS access: CVS_SERVER="git cvsserver" cvs \ -d :ext:andrei@git.sip-router.org/sip-router co master (instead of master you can use any other branch name that doesn't include a '/') The initial checkout takes a while, but after that cvs update seems fast enough. SVN access: unfortunately we do not have it. It looks like the git svnserver is in the project stage (there is some python code but not runnable yet). There is a way around it, but it would be quite complex to setup: a git to svn gateway and then svn to git imports. Other repositories on git.sip-router.org: ser - entire ser updated from cvs ser_core - only ser_core, automatically updated from cvs, read-only test - test repository, contains an early sip-router version, it has the same access rules as sip-router (if you have something you want to test, please use it rather then trying directly on sip-router). Special thanks go to Jan, who not only did setup git.sip-router.org (including automatic cvs sync for some of the repos), but he's also hosting it on one of his private machines. Andrei _______________________________________________ sr-dev mailing list sr-dev(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev -- Daniel-Constantin Mierla http://www.asipto.com

1 0

[Kamailio-Users] Question about the statistics module.
by Ricardo Martinez 17 Nov '08

17 Nov '08

Hello. Where can I see the variables defined in the statistics module updated in real time? Thanks Ricardo Martinez

2 1

[Kamailio-Users] Issues with OpenSER 1.3.2
by Chris Tooley 17 Nov '08

17 Nov '08

I'm having an issue with 1.3.2 where it's adding "100rel" to the Supported header when it wasn't previously there. I'm sure this is something I'm doing wrong, but I can't tell what it would be.

3 2

[Kamailio-Users] Problems with counter $var(i)
by Ricardo Martinez 17 Nov '08

17 Nov '08

Sorry ¡ i forgot to put the subject. Hello list. I'm having some problems trying to build a counter for my kamailio.cfg file. This is what I have.. main() ... load avp from radius} var(i)=0; route(3); ... route[1] { t_on_failure("1"); if (!t_relay()) { sl_reply_error(); }; xlog("L_INFO","[$ci] $rm t_relay a $ru"); exit; } route(3) ... $var(nr)=$avp(s:caller_nr); If ( var(i) < $var(nr) ); $var(i) = $var(i) + 1; route(1); else exit; failure_route[1] { xlog("L_INFO", "[$ci] $rm:$ru failure_route\n"); if (t_was_cancelled()) { xlog("L_INFO", "[$ci] $rm:$ru t_was_cancelled en failure_route\n"); exit; } if (!next_gw()) { xlog("L_INFO", "[$ci] No hay mas gateways para $rm:$ou\n"); route(3); } else { xlog("L_INFO", "XXXXX"); } t_on_failure("1"); t_relay(); } After I restart the service the first time a call arrives the counter seems to go OK, the counter goes from 0 to 2 (if the caller_nr=3). But the second time the $var(i) at the main and route(3) it's = 0, but in the failure_route it keeps the value = 3. What I'm doing wrong? Can someone help me here? Thanks Ricardo Martinez.-

2 4

[Kamailio-Users] rtpproxy
by michel freiha 17 Nov '08

17 Nov '08

Hi all, I installed OpenSer on my Centos machine and everything worked fine...I need now to install rtpproxy on the same machine but did not find any good documentation that can help me about that... I need to know please from where I can download the rtpproxy package and how I can configure it Regards

4 3

[Kamailio-Users] Problems with USRLOC not being 0, can not make p2p calls
by Ali Jawad 17 Nov '08

17 Nov '08

Hi All If I have modparam("usrloc", "db_mode", 0) I can make calls between two users that are currently using my openser installation. If I set modparam("usrloc", "db_mode", 1) or modparam("usrloc", "db_mode", 2) It does not work any more and I get 408 errors, although the entries are written to the location table in the database and openserctl ul show -brief does show the users. Any ideas ? Thanks

3 3

[Kamailio-Users] Engaging rtpproxy
by Graham Wooden 16 Nov '08

16 Nov '08

Hi list, I currently don¹t proxy audio nor have any plans to for all calls, except for the "302 Redirect", where I need kamailio to become a b2bua with RTPproxy (or for the record CALEA). However, I can¹t seem to get the ³if² statement down on where ³engage_media_proxy² gets called without doing it for all outbound calls. What is the best way to identify a call that was from a SIP client that issued a 302? My last effort was: if ( uri == mysqlf && is_method("INVITE") ){ But that seemed to get every call. Any guidance would be appreciated, thanks. -graham

2 5

Re: [Kamailio-Users] [OpenSIPS-Users] [OT] about scalability, experiences, demands
by Alex G 16 Nov '08

16 Nov '08

well put dan! I really don't understand why you would bother bringing this to our attention at all Henning. On Fri, Nov 14, 2008 at 11:12 PM, Dan Pascu <dan(a)ag-projects.com> wrote: > > I fail to see what worries you if all is fine and dandy in paradise. Don't > mind us, we are just a bunch of loonies with weird ideas anyway. > > On Friday 14 November 2008, Henning Westerholt wrote: > > Hello all, > > > > recently some statement came to my attention that "there is a common > > consent that the current design/architecture of [..] OpenSER (inherited > > from SER) is no longer able to deliver and to meet the present > > requirements and demands". > > > > I don't want to argue that much about this opinion, in fact the demands > > to a Voice over IP solution depends very much on the certain setup. But > > i want to share some details from my experiences in developing and > > operating a big VoIP infrastructure here at 1&1. > > > > We've about 2 million customers on our platform, that uses over 5 > > million individual numbers and terminate about 1 billion minutes per > > month. We're able to provide a good service with the actual > > architecture of OpenSER without any real problems. Of course there is > > always some room for improvements, but so far the main challenges we > > faced were not in the scalability or performance areas. More important > > issues are e.g. the inherent complexity of the SIP protocol and the > > maintainance of a good quality assurance and integration process. > > > > We started some years ago with OpenSER 0.9.5, which we then extended a > > lot in house. For example we implemented more than 25 own modules, a > > own path implementation, did a lot of bug fixing and workarounds for > > certain problems we've found. We're able to reduce this amount of > > proprietary code a lot in the past, because of progress in the OpenSER > > development, intregration of our "key" modules and a lot of other > > contributions. We're using now something between OpenSER 1.3 and > > Kamailio 1.4 with only a few private extensions. > > > > So in my opinion the actual design of our server is not "[..] an > > inevitable dead-end that needs to be avoided.". I rather think that > > we'll be able with continuing improvements to tackle the upcoming > > challenges well, especially as we will work together in the future with > > the SER developers in improving important areas of this software. > > > > But this is just my personal opinion, everybody is of course free to > > have their own position. > > > > With best regards, > > > > Henning Westerholt > > > > -- > Dan > > _______________________________________________ > Users mailing list > Users(a)lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users >

1 0

Re: [Kamailio-Users] [presence] NOTIFY sent over UDP when UA is waiting on TCP - (New bug reported)
by Pascal Maugeri 15 Nov '08

15 Nov '08

I think so. I've filled in a new issue in the tracker system (#2291718). Regards, Pascal On Fri, Nov 14, 2008 at 11:37 PM, Klaus Darilion < klaus.mailinglists(a)pernau.at> wrote: > looks like a bug in the presence module .... > > Pascal Maugeri wrote: > >> Hi >> >> We've seen the following problem: >> >> 1) the UA subscribe to a presentity with a SUBSCRIBE that contains this >> Contact header: >> "p1i" <sip:p1i@88.30.104.13:1414;transport=tcp> >> >> 2) then the presence module outputs in log file: >> >> INFO:presence:send_notify_request: NOTIFY sip:p1i@genaker.net<sip%3Ap1i(a)genaker.net><mailto: >> sip%3Ap1i(a)genaker.net <sip%253Ap1i(a)genaker.net>> via >> sip:p1i@88.30.104.13:1414;transport=tcp on behalf of >> sip:pascal@genaker.net <sip%3Apascal(a)genaker.net> <mailto: >> sip%3Apascal(a)genaker.net <sip%253Apascal(a)genaker.net>> for event presence >> >> 3) but the user agent receives the NOTIFY over UDP when it should be sent >> over TCP. >> >> Any idea of what could be wrong ? >> Is there any workaround to force sending NOTIFY messages over TCP ? >> >> Regards, >> Pascal >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Users mailing list >> Users(a)lists.kamailio.org >> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users >> >

1 0

[Kamailio-Users] [presence] NOTIFY sent over UDP when UA is waiting on TCP
by Pascal Maugeri 14 Nov '08

14 Nov '08

Hi We've seen the following problem: 1) the UA subscribe to a presentity with a SUBSCRIBE that contains this Contact header: "p1i" <sip:p1i@88.30.104.13:1414;transport=tcp> 2) then the presence module outputs in log file: INFO:presence:send_notify_request: NOTIFY sip:p1i@genaker.net<sip%3Ap1i(a)genaker.net>via sip:p1i@88.30.104.13:1414;transport=tcp on behalf of sip:pascal@genaker.net <sip%3Apascal(a)genaker.net> for event presence 3) but the user agent receives the NOTIFY over UDP when it should be sent over TCP. Any idea of what could be wrong ? Is there any workaround to force sending NOTIFY messages over TCP ? Regards, Pascal

2 1

[Kamailio-Users] [presence] getting "record not found in hash_table" error
by Pascal Maugeri 14 Nov '08

14 Nov '08

Hi We get very ofter this error message when subscribing to presence: Nov 14 16:20:01 server2-operations /usr/local/sbin/kamailio[6224]: ERROR:presence:get_stored_info: record not found in hash_table Nov 14 16:20:01 server2-operations /usr/local/sbin/kamailio[6224]: ERROR:presence:handle_subscribe: getting stored info ... using kamailio 1.4 So far I haven't managed to find a way to reproduce it. Is there any solution or workaround ? Regards, Pascal

2 2

[Kamailio-Users] How can i use the FIFO
by ALAEDDINE abbech 14 Nov '08

14 Nov '08

hi all I read the doc but i don't understand how can i use the FIFO to have many statistc. Can you give me a simple exemple. thanks.

2 4

[Kamailio-Users] [OT] about scalability, experiences, demands
by Henning Westerholt 14 Nov '08

14 Nov '08

Hello all, recently some statement came to my attention that "there is a common consent that the current design/architecture of [..] OpenSER (inherited from SER) is no longer able to deliver and to meet the present requirements and demands". I don't want to argue that much about this opinion, in fact the demands to a Voice over IP solution depends very much on the certain setup. But i want to share some details from my experiences in developing and operating a big VoIP infrastructure here at 1&1. We've about 2 million customers on our platform, that uses over 5 million individual numbers and terminate about 1 billion minutes per month. We're able to provide a good service with the actual architecture of OpenSER without any real problems. Of course there is always some room for improvements, but so far the main challenges we faced were not in the scalability or performance areas. More important issues are e.g. the inherent complexity of the SIP protocol and the maintainance of a good quality assurance and integration process. We started some years ago with OpenSER 0.9.5, which we then extended a lot in house. For example we implemented more than 25 own modules, a own path implementation, did a lot of bug fixing and workarounds for certain problems we've found. We're able to reduce this amount of proprietary code a lot in the past, because of progress in the OpenSER development, intregration of our "key" modules and a lot of other contributions. We're using now something between OpenSER 1.3 and Kamailio 1.4 with only a few private extensions. So in my opinion the actual design of our server is not "[..] an inevitable dead-end that needs to be avoided.". I rather think that we'll be able with continuing improvements to tackle the upcoming challenges well, especially as we will work together in the future with the SER developers in improving important areas of this software. But this is just my personal opinion, everybody is of course free to have their own position. With best regards, Henning Westerholt -- Henning Westerholt - Development Consumer Products / DSL Core 1&1 Internet AG, Ernst-Frey-Str. 9, 76135 Karlsruhe, Germany Vorstände: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Thomas Gottschlich, Robert Hoffmann, Markus Huhn, Hans-Henning Kettler, Dr. Oliver Mauss, Jan Oetjen - Aufsichtsratsvorsitzender: Michael Scheeren Amtsgericht Montabaur / HRB 6484

2 1

Re: [Kamailio-Users] Problems with counter $var(i)
by ingdavidcespedes＠cable.net.co 14 Nov '08

14 Nov '08

Ok, now I understand. So the answer is, that you can't do that with script variables (http://www.kamailio.net/dokuwiki/doku.php/pseudovariables:1.4.x#script_vari…) there it says: Note: A script variable persists over the OpenSER process in which it was initialized, so be sure of giving it a new value before reading it or you'll get the value asigned in any other previous message processed by the same OpenSER process (pid). ----- Mensaje original ----- De: Ricardo Martinez <rmartinez(a)redvoiss.net> Fecha: Jueves, Noviembre 13, 2008 2:07 pm Asunto: Re: [Kamailio-Users] Problems with counter $var(i) > Hi David. > Yes, that exactly what i want, set the variable to 0 in the main > route,so every call that arrive it start the process again... > The problem is that in the failure_route the variable keeps the > value..and is not resetting to 0 > > Ricardo.- > > -----Mensaje original----- > De: ingdavidcespedes(a)cable.net.co [ingdavidcespedes(a)cable.net.co] > > Enviado el: jueves, 13 de noviembre de 2008 16:15 > Para: Ricardo Martinez > CC: users(a)lists.kamailio.org > Asunto: Re: [Kamailio-Users] Problems with counter $var(i) > > Hi > > In which place of your main route are you writing var(i)=0. Maybe > that'sthe problem, each time you enter in the main route you are > setting the i > variable to 0. > > David Cespedes > > _______________________________________________ > Users mailing list > Users(a)lists.kamailio.org > http://lists.kamailio.org/cgi-bin/mailman/listinfo/users >

1 0

Re: [Kamailio-Users] Problems with counter $var(i)
by ingdavidcespedes＠cable.net.co 13 Nov '08

13 Nov '08

Hi In which place of your main route are you writing var(i)=0. Maybe that's the problem, each time you enter in the main route you are setting the i variable to 0. David Cespedes Hello I realized that the counter $var(i) in the failure_route[1] seems not to be resetting to 0 when the 2nd , 3th ..etc call arrive. So for the second call I have the counter 0 in the main route, the route(3), route(1) but in the failure_route is set to 3 (the last values from the last call) I keep trying to figure it out why this is happening.. Anyone? Thanks, Ricardo.- De: users-bounces(a)lists.kamailio.org [mailto:users-bounces@lists.kamailio.org] En nombre de Ricardo Martinez Enviado el: jueves, 13 de noviembre de 2008 11:46 Para: users(a)lists.kamailio.org Asunto: [Kamailio-Users] Problems with counter $var(i) Sorry ¡ i forgot to put the subject. Hello list. I'm having some problems trying to build a counter for my kamailio.cfg file. This is what I have.. main() ... load avp from radius} var(i)=0; route(3); ... route[1] { t_on_failure("1"); if (!t_relay()) { sl_reply_error(); }; xlog("L_INFO","[$ci] $rm t_relay a $ru"); exit; } route(3) ... $var(nr)=$avp(s:caller_nr); If ( var(i) < $var(nr) ); $var(i) = $var(i) + 1; route(1); else exit; failure_route[1] { xlog("L_INFO", "[$ci] $rm:$ru failure_route\n"); if (t_was_cancelled()) { xlog("L_INFO", "[$ci] $rm:$ru t_was_cancelled en failure_route\n"); exit; } if (!next_gw()) { xlog("L_INFO", "[$ci] No hay mas gateways para $rm:$ou\n"); route(3); } else { xlog("L_INFO", "XXXXX"); } t_on_failure("1"); t_relay(); } After I restart the service the first time a call arrives the counter seems to go OK, the counter goes from 0 to 2 (if the caller_nr=3). But the second time the $var(i) at the main and route(3) it's = 0, but in the failure_route it keeps the value = 3. What I'm doing wrong? Can someone help me here? Thanks Ricardo Martinez.- _______________________________________________ Users mailing list Users(a)lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users

2 1

[Kamailio-Users] Using other media gateways
by Ruchir 13 Nov '08

13 Nov '08

I have a question. We can use media proxy to handle media through media proxies. I was wondering if it is possible to use any media servers for rtp by just specifying ip address of the media gateway.

2 1

[Kamailio-Users] help understanding kamailio.cfg and processing call flow
by Fabian Borot 13 Nov '08

13 Nov '08

hello I have been struggling to get the grasp on kamailio for weeks now. My prob is not understanding the call flow but how to translate it using the functions provided by the modules and the core. I do not have clear the scope or reach of several functions,provided by either the core or the modules. Example: Register with Auth: 1- user sends REGISTER request w/o the encripted credentials 2- kamailio answers with 401 and sends the challenge 3- the uac sends the REGISTER again, this time with the right credentials and after verifying kamailio sends 200 OK 4- if the user is behind a NAT we can fix the contact info before saving it to the location db. With the help of the forum and the tutorials I have found in the internet I have been able to accomplish it with these commands: route{ if (uri==myself) { if (method=="REGISTER") { xlog("L_INFO","mylog: starting to process REGISTER.Info.\n"); if (!www_authorize("", "subscriber")) { xlog("L_INFO","mylog: REGISTER came without auth, sending challenge.\n"); www_challenge("", "0"); exit; }; if (nat_uac_test("1")){ xlog("L_INFO","mylog: REGISTER-Device behind NAT.\n"); fix_nated_register(); } force_rport(); save("location"); xlog("L_INFO","mylog: save-location successful.\n"); exit; } route(1); } route[1] { if (t_relay()) { xlog("L_INFO","mylog: Route 1 section. Method [$rm]."); } else { sl_reply_error(); xlog("L_INFO","mylog: Route 1 section. T_Relay failed. Method [$rm]."); }; exit; } but here come the first questions: 1- when the uac sends the first REGISTER, the function www_challenge() is the one that actually sends the "401" message? or the "exit" just exit out the "if" block and the script will continue with route(1) which in turns executes "t_relay()? ++from the doc, www_challenge() function++++ The function challenges a user agent. It will generate a WWW-Authorize header field containing a digest challenge, it will put the header field into a response generated from the request the server is processing and send the reply. +++++++++++++++++++++++++++++++++ 2- the "exit" after the save("location") function I assume would stop the execution of the script and at that point kamailio responds with "200 ok"? or just exit out the "if" block, the script then reaches the "route(1)" section and the "t_relay()" sends the "200 ok"? ++ from the doc, core-cookbook, exit() function+++++++ Stop the execution of the configuration script – it has the same behaviour as return(0). It does not affect the implicit action to be taken after script execution. ++++++++++++++++++++++++++++ 3- the "t_relay" function: does that function creates and sends the approriate response for each request? ex1: an INVITE is received, does t_relay() "know" that it can send "100 trying" automatically? ex2: a "200 OK" is received as a response to an INVITE, does t_relay knows that it has to send an "ACK"? ++++++from the doc, t_relay() funcion ++++++++++ >From user's perspective, the major function is t_relay(). It setup transaction state, absorb retransmissions from upstream, generate downstream retransmissions and correlate replies to requests. +++++++++++++++++++++++++++++ 4- why do I see ";" even after a "}", is it needed sometimes? 5- is "exit" the same as "exit()"? These may sound like dumb questions for some of the experienced users, but for a newbie they are not. Also, if this sounds like " hey, code my config file for me" I assure you that that is not the intended purpose. I would appreciate any help and thank everybody in advance. Fabian _________________________________________________________________ Color coding for safety: Windows Live Hotmail alerts you to suspicious email. http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_safety…

2 2

[Serusers] Fw: SER COLP & COLR implementation
by Erman ÇAKMAK 13 Nov '08

13 Nov '08

Hello all, I could not find any information about SER whether it supports the COLP & COLR call features or not. Does anyone have an idea about it? Regards, Erman Cakmak

1 0

[Kamailio-Users] 488 Not acceptable here
by Ricky Gutierrez 13 Nov '08

13 Nov '08

Hi list, I am giving him returned script from openser trying to find the problem to this message " 488 acceptable Not here" , I have my openser integrated recently with asterisk and the voicemail recently adds rtpproxy to solve problems of nat and was almost a success, some details to improve, but after adding the rtpproxy when I call to UAC and it does not answer the call on the telephone shows a 488 message to me No Aceptable, it does not jump to the voicemai.. I have 2 networks cards in my server, and looking at the sip log, I see twice in the sdp the interfaz it public any idea as solving this problem? regards rickygm # U +1.675624 192.168.10.1:5060 -> 192.168.10.1:5070 INVITE sip:u120@192.168.10.1:5070 SIP/2.0 Record-Route: <sip:192.168.10.1;lr=on;ftag=69372fe200a41663> Via: SIP/2.0/UDP 192.168.10.1;branch=z9hG4bK78e7.cd89b213.1 Via: SIP/2.0/UDP 192.168.10.28:5060;rport=5060;branch=z9hG4bK286620c52595f4b3 From: <sip:119@192.168.10.1>;tag=69372fe200a41663 To: <sip:120@192.168.10.1> Contact: <sip:119@192.168.10.28:5060;nat=yes;nat=yes> Supported: replaces, timer, path Call-ID: 7c55e4667d473f76(a)192.168.10.28 CSeq: 12216 INVITE User-Agent: Grandstream GXV3000 1.1.3.14 Max-Forwards: 69 Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK Content-Type: application/sdp Content-Length: 604 P-hint: inbound->inbound P-hint: Route[20]: Rtpproxy P-hint: Route[20]: Rtpproxy v=0 o=119 8000 8001 IN IP4 192.168.10.28 s=SIP Call c=IN IP4 192.168.1.64192.168.1.64 t=0 0 m=audio 3504835048 RTP/AVP 18 4 3 2 0 101 a=sendrecv a=rtpmap:18 G729/8000 a=rtpmap:4 G723/8000 a=rtpmap:3 GSM/8000 a=rtpmap:2 G726-32/8000 a=rtpmap:0 PCMU/8000 a=ptime:20 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-11 m=video 3505035050 RTP/AVP 99 34 a=sendrecv a=rtpmap:99 H264/90000 a=fmtp:99 profile-level-id=428014; packetization-mode=0; sprop-parameter-sets=Z0KADJWgUH5A,aM4CXID= a=rtpmap:34 H263/90000 a=fmtp:34 CIF=2 MaxBR=1280 a=framerate:20 a=nortpproxy:yes a=nortpproxy:yes # U +0.000052 192.168.10.1:5060 -> 192.168.10.27:5060 CANCEL sip:120@192.168.10.27:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.10.1;branch=z9hG4bK78e7.cd89b213.0 From: <sip:119@192.168.10.1>;tag=69372fe200a41663 Call-ID: 7c55e4667d473f76(a)192.168.10.28 To: <sip:120@192.168.10.1> CSeq: 12216 CANCEL Max-Forwards: 70 User-Agent: OpenSER (1.3.2-notls (i386/linux)) Content-Length: 0 # U +0.000411 192.168.10.1:5070 -> 192.168.10.1:5060 SIP/2.0 488 Not acceptable here Via: SIP/2.0/UDP 192.168.10.1;branch=z9hG4bK78e7.cd89b213.1;received=192.168.10.1 Via: SIP/2.0/UDP 192.168.10.28:5060;rport=5060;branch=z9hG4bK286620c52595f4b3 From: <sip:119@192.168.10.1>;tag=69372fe200a41663 To: <sip:120@192.168.10.1>;tag=as4f1165d5 Call-ID: 7c55e4667d473f76(a)192.168.10.28 CSeq: 12216 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Content-Length: 0 # U +0.000120 192.168.10.1:5060 -> 192.168.10.1:5070 ACK sip:u120@192.168.10.1:5070 SIP/2.0 Via: SIP/2.0/UDP 192.168.10.1;branch=z9hG4bK78e7.cd89b213.1 From: <sip:119@192.168.10.1>;tag=69372fe200a41663 Call-ID: 7c55e4667d473f76(a)192.168.10.28 To: <sip:120@192.168.10.1>;tag=as4f1165d5 CSeq: 12216 ACK Max-Forwards: 70 User-Agent: OpenSER (1.3.2-notls (i386/linux)) Content-Length: 0 # U +0.000144 192.168.10.1:5060 -> 192.168.10.28:5060 SIP/2.0 488 Not acceptable here Via: SIP/2.0/UDP 192.168.10.28:5060;rport=5060;branch=z9hG4bK286620c52595f4b3 From: <sip:119@192.168.10.1>;tag=69372fe200a41663 To: <sip:120@192.168.10.1>;tag=as4f1165d5 Call-ID: 7c55e4667d473f76(a)192.168.10.28 CSeq: 12216 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Content-Length: 0 P-hint: Onreply-route - fixcontact # U +0.000787 192.168.10.27:5060 -> 192.168.10.1:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.10.1;branch=z9hG4bK78e7.cd89b213.0 From: <sip:119@192.168.10.1>;tag=69372fe200a41663 To: <sip:120@192.168.10.1>;tag=fb538483d0333de1 Call-ID: 7c55e4667d473f76(a)192.168.10.28 CSeq: 12216 CANCEL User-Agent: Grandstream GXV3000 1.1.3.14 Supported: replaces, timer, 100rel, path Content-Length: 0 # U +0.000544 192.168.10.27:5060 -> 192.168.10.1:5060 SIP/2.0 487 Request Cancelled Via: SIP/2.0/UDP 192.168.10.1;branch=z9hG4bK78e7.cd89b213.0 Via: SIP/2.0/UDP 192.168.10.28:5060;rport=5060;branch=z9hG4bK286620c52595f4b3 Record-Route: <sip:192.168.10.1;lr=on;ftag=69372fe200a41663> From: <sip:119@192.168.10.1>;tag=69372fe200a41663 To: <sip:120@192.168.10.1>;tag=fb538483d0333de1 Call-ID: 7c55e4667d473f76(a)192.168.10.28 CSeq: 12216 INVITE User-Agent: Grandstream GXV3000 1.1.3.14 Content-Length: 0 # U +0.000067 192.168.10.1:5060 -> 192.168.10.27:5060 ACK sip:120@192.168.10.27:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.10.1;branch=z9hG4bK78e7.cd89b213.0 From: <sip:119@192.168.10.1>;tag=69372fe200a41663 Call-ID: 7c55e4667d473f76(a)192.168.10.28 To: <sip:120@192.168.10.1>;tag=fb538483d0333de1 CSeq: 12216 ACK Max-Forwards: 70 User-Agent: OpenSER (1.3.2-notls (i386/linux)) Content-Length: 0 # U +0.001390 192.168.10.28:5060 -> 192.168.10.1:5060 ACK sip:120@192.168.10.1 SIP/2.0 Via: SIP/2.0/UDP 192.168.10.28:5060;branch=z9hG4bK286620c52595f4b3 From: <sip:119@192.168.10.1>;tag=69372fe200a41663 To: <sip:120@192.168.10.1>;tag=as4f1165d5 Contact: <sip:119@192.168.10.28:5060> Proxy-Authorization: Digest username="119", realm="192.168.10.1", algorithm=MD5, uri="sip:120@192.168.10.1", nonce="4919edaf0a873106bfd0b18f347709360f00f7eb", response="a5a26c257b491718def2b43488a39853" Call-ID: 7c55e4667d473f76(a)192.168.10.28 CSeq: 12216 ACK User-Agent: Grandstream GXV3000 1.1.3.14 Max-Forwards: 70 Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK Content-Length: 0 # U +0.497023 192.168.10.1:5060 -> 192.168.10.28:5060 SIP/2.0 488 Not acceptable here Via: SIP/2.0/UDP 192.168.10.28:5060;rport=5060;branch=z9hG4bK286620c52595f4b3 From: <sip:119@192.168.10.1>;tag=69372fe200a41663 To: <sip:120@192.168.10.1>;tag=as4f1165d5 Call-ID: 7c55e4667d473f76(a)192.168.10.28 CSeq: 12216 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Content-Length: 0 P-hint: Onreply-route - fixcontact # U +0.999813 192.168.10.1:5060 -> 192.168.10.28:5060 SIP/2.0 488 Not acceptable here Via: SIP/2.0/UDP 192.168.10.28:5060;rport=5060;branch=z9hG4bK286620c52595f4b3 From: <sip:119@192.168.10.1>;tag=69372fe200a41663 To: <sip:120@192.168.10.1>;tag=as4f1165d5 Call-ID: 7c55e4667d473f76(a)192.168.10.28 CSeq: 12216 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Content-Length: 0 P-hint: Onreply-route - fixcontact exit 67 received, 0 dropped

2 3

[Kamailio-Users] issues with rtpproxy and kamailio
by Fabian Borot 13 Nov '08

13 Nov '08

I am trying to set up rtpproxy with kamailio and are having these 2 issues: 1- the BYEs are not relayed to the other party, I have to hang up the call at both ends 2- kamailio receives the INVITE from the calling party [behind a nat] and relays it to the called party but the connection information in the SDP has to IPs [the source IP and the RTPproxy IP together c=IN IP4 204.9.239.6765.111.185.187 user 100 is behind a NAT and user 101 is not but I want to force the RTPs to go thru the rtpproxy server [ in the same IP as kamailio] the good and weird thing is that there is audio both ways. this is my config file: if (loose_route()) { # mark routing logic in request xlog("L_INFO","mylog: Loose Route section. Method: [$rm].\n"); append_hf("P-hint: rr-enforced\r\n"); route(1); }; if (uri==myself) { if (method=="REGISTER") { xlog("L_INFO","mylog: starting to process REGISTER.Info: [$au].\n"); if (!www_authorize("", "subscriber")) { xlog("L_INFO","mylog: REGISTER came without auth, sending challenge.\n"); www_challenge("", "0"); exit; }; if (nat_uac_test("1")){ xlog("L_INFO","mylog: REGISTER-Device behind NAT.\n"); fix_nated_register(); } force_rport(); save("location"); xlog("L_INFO","mylog: save-location successful.\n"); exit; } else if (method=="INVITE") { xlog("L_INFO","mylog: Processing INVITE.\n"); if (!proxy_authorize("","subscriber")) { xlog("L_INFO","mylog: INVITE came without auth, sending challenge.\n"); proxy_challenge("","0"); exit; }; consume_credentials(); if (nat_uac_test("1")){ xlog("L_INFO","mylog: INVITE-Device behind NAT.\n"); #fix_nated_contact(); fix_nated_sdp("10"); } force_rtp_proxy(); if (!lookup("location")) { sl_send_reply("404", "Not Found"); xlog("L_INFO","mylog: lookup-location failed, sending 404 Not Found. Method: [$rm].\n"); exit; }; append_hf("P-hint: usrloc applied\r\n"); }; }; route(1); } route[1] { # send it out now; use stateful forwarding as it works reliably # even for UDP2TCP t_on_reply("1"); if (t_relay()) { xlog("L_INFO","mylog: Route 1 section. Method [$rm]."); } else { sl_reply_error(); xlog("L_INFO","mylog: Route 1 section. T_Relay failed. Method [$rm]."); }; exit; } onreply_route[1] { force_rtp_proxy("","65.111.185.187"); } thank you in advance Fabian _________________________________________________________________ Stay up to date on your PC, the Web, and your mobile phone with Windows Live http://clk.atdmt.com/MRT/go/119462413/direct/01/

3 4

[Kamailio-Users] problem with fix_nated_register() function
by Fabian Borot 13 Nov '08

13 Nov '08

Hello, I am having probs with the fix_nated_register() function, I still see the private IP, even thought the nat_uac_test(31) shows the user behind a NAT This is the REGISTER section in kamailio.cfg: if (method=="REGISTER") { xlog("L_INFO","mylog: starting to process REGISTER.Info: [$au].\n"); if (!www_authorize("", "subscriber")) { xlog("L_INFO","mylog: REGISTER came without auth, sending challenge.\n"); www_challenge("", "0"); exit; }; if (nat_uac_test("31")){ xlog("L_INFO","mylog: Device behind NAT.\n"); fix_nated_register(); force_rport(); } save("location"); xlog("L_INFO","mylog: save-location successful.\n"); exit; this is the debug log [level 6], it shows the via with a public IP Nov 11 17:09:04 sp1094a ../../sbin/kamailio[14219]: mylog: starting to process REGISTER.Info: [100]. Nov 11 17:09:04 sp1094a ../../sbin/kamailio[14219]: DBG:auth:check_nonce: comparing [491a03a9000000041ba5231fd93870c44415f01d1a0d1963] and [491a03a9000000041ba5231fd93870c44415f01d1a0d1963] Nov 11 17:09:04 sp1094a ../../sbin/kamailio[14219]: DBG:core:db_new_result: allocate 28 bytes for result set at 0x81ab8a0 Nov 11 17:09:04 sp1094a ../../sbin/kamailio[14219]: DBG:db_mysql:db_mysql_get_columns: 1 columns returned from the query Nov 11 17:09:04 sp1094a ../../sbin/kamailio[14219]: DBG:core:db_allocate_columns: allocate 4 bytes for result names at 0x81a7288 Nov 11 17:09:04 sp1094a ../../sbin/kamailio[14219]: DBG:core:db_allocate_columns: allocate 4 bytes for result types at 0x81a7258 Nov 11 17:09:04 sp1094a ../../sbin/kamailio[14219]: DBG:db_mysql:db_mysql_get_columns: allocate 8 bytes for RES_NAMES[0] at 0x81a7268 Nov 11 17:09:04 sp1094a ../../sbin/kamailio[14219]: DBG:db_mysql:db_mysql_get_columns: RES_NAMES(0x81a7268)[0]=[password] Nov 11 17:09:04 sp1094a ../../sbin/kamailio[14219]: DBG:db_mysql:db_mysql_get_columns: use DB_STRING result type Nov 11 17:09:04 sp1094a ../../sbin/kamailio[14219]: DBG:db_mysql:db_mysql_convert_rows: allocate 8 bytes for rows at 0x81a7278 Nov 11 17:09:04 sp1094a ../../sbin/kamailio[14219]: DBG:db_mysql:db_mysql_convert_row: allocate 20 bytes for row values at 0x81ab880 Nov 11 17:09:04 sp1094a ../../sbin/kamailio[14219]: DBG:db_mysql:db_mysql_str2val: converting STRING [100] Nov 11 17:09:04 sp1094a ../../sbin/kamailio[14219]: DBG:auth_db:get_ha1: HA1 string calculated: e8f9a8a478e49a182e9cceeb3e43277f Nov 11 17:09:04 sp1094a ../../sbin/kamailio[14219]: DBG:auth:check_response: our result = '84a320db7e04e3ddd3ef84a5173187cd' Nov 11 17:09:04 sp1094a ../../sbin/kamailio[14219]: DBG:auth:check_response: authorization is OK Nov 11 17:09:04 sp1094a ../../sbin/kamailio[14219]: DBG:auth:post_auth: nonce index= 4 Nov 11 17:09:04 sp1094a ../../sbin/kamailio[14219]: DBG:core:db_free_columns: freeing 1 columns Nov 11 17:09:04 sp1094a ../../sbin/kamailio[14219]: DBG:core:db_free_columns: freeing RES_NAMES[0] at 0x81a7268 Nov 11 17:09:04 sp1094a ../../sbin/kamailio[14219]: DBG:core:db_free_columns: freeing result names at 0x81a7288 Nov 11 17:09:04 sp1094a ../../sbin/kamailio[14219]: DBG:core:db_free_columns: freeing result types at 0x81a7258 Nov 11 17:09:04 sp1094a ../../sbin/kamailio[14219]: DBG:core:db_free_rows: freeing 1 rows Nov 11 17:09:05 sp1094a ../../sbin/kamailio[14219]: DBG:core:db_free_row: freeing row values at 0x81ab880 Nov 11 17:09:05 sp1094a ../../sbin/kamailio[14219]: DBG:core:db_free_rows: freeing rows at 0x81a7278 Nov 11 17:09:05 sp1094a ../../sbin/kamailio[14219]: DBG:core:db_free_result: freeing result set at 0x81ab8a0 Nov 11 17:09:05 sp1094a ../../sbin/kamailio[14219]: DBG:core:check_via_address: params 204.9.239.67, 192.168.1.108, 0 Nov 11 17:09:05 sp1094a ../../sbin/kamailio[14219]: mylog: Device behind NAT. Nov 11 17:09:05 sp1094a ../../sbin/kamailio[14219]: DBG:core:parse_headers: flags=ffffffffffffffff Nov 11 17:09:05 sp1094a ../../sbin/kamailio[14219]: DBG:core:parse_headers: flags=8000000 Nov 11 17:09:05 sp1094a ../../sbin/kamailio[14219]: DBG:registrar:build_contact: created Contact HF: Contact: <sip:100@192.168.1.108 7566;rinstance=89990b40ab560825>;expires=3341, <sip:100@192.168.1.108:44568;rinstance=f0942ae1a596ea83>;expires=3597 Nov 11 17:09:05 sp1094a ../../sbin/kamailio[14219]: DBG:core:parse_headers: flags=ffffffffffffffff Nov 11 17:09:05 sp1094a ../../sbin/kamailio[14219]: DBG:core:check_via_address: params 204.9.239.67, 192.168.1.108, 0 Nov 11 17:09:05 sp1094a ../../sbin/kamailio[14219]: mylog: save-location successful. Nov 11 17:09:05 sp1094a ../../sbin/kamailio[14219]: DBG:core:destroy_avp_list: destroying list 0xb60e11c0 Nov 11 17:09:05 sp1094a ../../sbin/kamailio[14219]: DBG:core:receive_msg: cleaning up and this is how the AOR is stored in the location db [ private IP] [root@sp1094a kamailio]# ../../sbin/kamctl ul show database engine 'MYSQL' loaded Control engine 'FIFO' loaded entering fifo_cmd ul_dump Domain:: location table=512 records=1 max_slot=1 AOR:: 100 Contact:: sip:100@192.168.1.108:44568;rinstance=f0942ae1a596ea83 Q= Expires:: 3365 Callid:: 7a32d234b04d4b69M2IzODRhODkwM2M5NTM0MzUwMGM4ODY3NTgzYzFjMmE. Cseq:: 2 User-agent:: eyeBeam release 1003l stamp 30937 State:: CS_SYNC Flags:: 0 Cflag:: 0 Socket:: udp:65.111.185.187:5060 Methods:: 5951 FIFO command was: :ul_dump:openser_receiver_14270 [root@sp1094a kamailio]# Am I missing something? Thanks in advance Fabian _________________________________________________________________ Get 5 GB of storage with Windows Live Hotmail. http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_5gb_11…

6 18

[Kamailio-Users] Tomcat won't start serMyAdmin - SEVERE: Error listenerStart
by rjreb 13 Nov '08

13 Nov '08

I'm trying to install serMyAdmin but it refuses to start. In the logs I see the following: Nov 12, 2008 2:25:31 AM org.apache.catalina.startup.HostConfig deployWAR INFO: Deploying web application archive serMyAdmin.war Nov 12, 2008 2:25:34 AM org.apache.catalina.core.StandardContext start SEVERE: Error listenerStart Nov 12, 2008 2:25:34 AM org.apache.catalina.core.StandardContext start SEVERE: Context [/serMyAdmin] startup failed due to previous errors I've been searching for this for a day now and I can't find where anyone else is having this problem. Any suggestions? Debian Etch Sun Java 1.5.0-16-3 Tomcat 6.0.16 -- View this message in context: http://www.nabble.com/Tomcat-won%27t-start-serMyAdmin---SEVERE%3A-Error-lis… Sent from the OpenSER Users Mailing List mailing list archive at Nabble.com.

2 1

[Serusers] Is msilo module necessary to make IM work in SER? SER doesn't forward MESSAGE
by lin9k＠yahoo.com 12 Nov '08

12 Nov '08

Hi, I used two IM (SIMPLE based) clients to communicate through SER. However, I could only see clients kept sending MESSAGE to SER but SER never forwarded them to the peer. I was not using msilo. I am not sure if that's the cause that SER didn't forward to the other end. Or, do I need any special configuration in ser.cfg, or any different version of SER? I was using ser-0.9.6. Thanks in advance! Ling

2 2

[Serusers] compiling ser from source in ubuntu
by amar mahmoud 12 Nov '08

12 Nov '08

Hi, when i compile SER from the debian packages embedded with ubuntu it works fine, but i want to compile from the source because i want to add one module i have invented. my problem is : when i compile from source mysql module does not get compiled, i have tried to change the Makefile and delete mysql module from those excluded modules, also i have tried to compile it alone with the command: make modules=modules/mysql modules but still there is problem. does any one met that before. thanks Amar _________________________________________________________________ Windows Live Hotmail now works up to 70% faster. http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_faster…

2 1

[Kamailio-Users] Dialog profile persistence - DB vs. memory.
by Alex Balashov 12 Nov '08

12 Nov '08

Greetings, Is some of the dialog profile information kept in in-memory structures inside the Kamailio instance even when one is using a database? I am using the dialog module in an HA configuration and fail over the database and proxy between two machines. The database and the proxy are both started on the secondary node during failover, and the database uses on-disk data and indices on a shared filesystem. What I am finding is that if I initiate some dialogs on the primary and then trigger the failover, the proxy on the secondary node is not aware of them. I see the entries for them in the database table from the secondary node - they're definitely there, and I am using db_mode 1 (real-time). However, the profile sizes are all showing as 0. I have also tried it with different match_modes with the same results whether I am using the RR cookie or SIP attributes purely. It's rather important that I get this working because I require dialog tracking for secure loose-routing of subsequent (non-initial) in-dialog requests and for concurrent call limit control. I was imagining that storing all the dialog info in the database would create the necessary persistence layer for another proxy instance to have the exact same profile information as the first. Is this a bug, or is it supposed to work this way? Cheers, -- Alex -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599

4 6

[Kamailio-Users] question about register
by Fabian Borot 12 Nov '08

12 Nov '08

Hello I am having an issue handling UN-REGISTERs. This is my config file: route{ xlog("L_INFO", "mylog: starting_main_logic.\n"); if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); xlog("L_INFO","mylog: Too Many Hops.\n"); exit; }; if (msg:len >= 2048 ) { sl_send_reply("513", "Message too big"); xlog("L_INFO","mylog: Message too big.\n"); exit; }; if (!method=="REGISTER") { xlog("L_INFO","mylog: Recording Route. Method: [$rm].\n"); record_route(); } if (loose_route()) { # mark routing logic in request xlog("L_INFO","mylog: Loose Route section. Method: [$rm].\n"); append_hf("P-hint: rr-enforced\r\n"); route(1); }; if (uri==myself) { if (method=="REGISTER" && (!search("expires=0"))) { xlog("L_INFO","mylog: starting to process REGISTER.Info: [$au].\n"); if (!www_authorize("", "subscriber")) { xlog("L_INFO","mylog: REGISTER came without auth, sending challenge.\n"); www_challenge("", "0"); exit; }; save("location"); xlog("L_INFO","mylog: save-location successful.\n"); exit; } else if (method=="INVITE") { xlog("L_INFO","mylog: Processing INVITE.\n"); if (!proxy_authorize("","subscriber")) { xlog("L_INFO","mylog: INVITE came without auth, sending challenge.\n"); proxy_challenge("","0"); exit; }; consume_credentials(); }; # native SIP destinations are handled using our USRLOC DB if (!lookup("location")) { sl_send_reply("404", "Not Found"); xlog("L_INFO","mylog: lookup-location failed, sending 404 Not Found. Method: [$rm].\n"); exit; }; append_hf("P-hint: usrloc applied\r\n"); }; route(1); } route[1] { # send it out now; use stateful forwarding as it works reliably # even for UDP2TCP if (t_relay()) { xlog("L_INFO","mylog: Route 1 section. Method [$rm]."); } else { sl_reply_error(); xlog("L_INFO","mylog: Route 1 section. T_Relay failed. Method [$rm]."); }; exit; } I added the "&& (!search("expires=0"))" to make sure that only the REGISTER requests will be processed by the next lines and the AOR will be saved in those cases. The X-lite sends "expires=0" in the Contact HF when it is unregistering. This is how the processing of a REGISTER looks like as per my code: Nov 10 12:33:08 sp1094a ../../sbin/kamailio[26069]: mylog: starting_main_logic. Nov 10 12:33:08 sp1094a ../../sbin/kamailio[26069]: mylog: starting to process REGISTER.Info: [<null>]. Nov 10 12:33:08 sp1094a ../../sbin/kamailio[26069]: mylog: REGISTER came without auth, sending challenge. Nov 10 12:33:08 sp1094a ../../sbin/kamailio[26069]: mylog: starting_main_logic. Nov 10 12:33:08 sp1094a ../../sbin/kamailio[26069]: mylog: starting to process REGISTER.Info: [101]. Nov 10 12:33:08 sp1094a ../../sbin/kamailio[26069]: mylog: save-location successful. and when the phone UN-REGISTERs this is what I see: Nov 10 12:33:17 sp1094a ../../sbin/kamailio[26069]: mylog: starting_main_logic. Nov 10 12:33:17 sp1094a ../../sbin/kamailio[26069]: mylog: lookup-location failed, sending 404 Not Found. Method: [REGISTER]. My question is, do I need to use the lookup section for REGISTERs and UN-REGISTERs? If I comment out that part this is how the log looks like: #if (!lookup("location")) { # sl_send_reply("404", "Not Found"); # xlog("L_INFO","mylog: lookup-location failed, sending 404 Not Found. Method: [$rm].\n"); # exit; #}; log: the 1st part [REGISTER] looks the same [root@sp1094a kamailio]# tail -f /var/log/kamailio_logs | grep mylog Nov 10 12:36:35 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic. Nov 10 12:36:35 sp1094a ../../sbin/kamailio[26203]: mylog: starting to process REGISTER.Info: [<null>]. Nov 10 12:36:35 sp1094a ../../sbin/kamailio[26203]: mylog: REGISTER came without auth, sending challenge. Nov 10 12:36:35 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic. Nov 10 12:36:35 sp1094a ../../sbin/kamailio[26203]: mylog: starting to process REGISTER.Info: [101]. Nov 10 12:36:35 sp1094a ../../sbin/kamailio[26203]: mylog: save-location successful. and this is what the log shows when the phone is UN-REGISTERING Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic. Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: Route 1 section. Method [REGISTER]. Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic. Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: Route 1 section. Method [REGISTER]. Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic. Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: Route 1 section. Method [REGISTER]. Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic. Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: Route 1 section. Method [REGISTER]. Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic. Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: Route 1 section. Method [REGISTER]. Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic. Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: Route 1 section. Method [REGISTER]. Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic. Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: Route 1 section. Method [REGISTER]. Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic. Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: Route 1 section. Method [REGISTER]. Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic. Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: Route 1 section. Method [REGISTER]. Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic. Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: Route 1 section. Method [REGISTER]. Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic. Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: Route 1 section. Method [REGISTER]. Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic. Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: Route 1 section. Method [REGISTER]. Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic. Nov 10 12:36:42 sp1094a ../../sbin/kamailio[26203]: mylog: Route 1 section. Method [REGISTER]. Nov 10 12:36:43 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic. Nov 10 12:36:43 sp1094a ../../sbin/kamailio[26203]: mylog: Route 1 section. Method [REGISTER]. Nov 10 12:36:43 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic. Nov 10 12:36:43 sp1094a ../../sbin/kamailio[26203]: mylog: Route 1 section. Method [REGISTER]. Nov 10 12:36:43 sp1094a ../../sbin/kamailio[26203]: mylog: starting_main_logic. Nov 10 12:36:43 sp1094a ../../sbin/kamailio[26203]: mylog: Message too big. [root@sp1094a kamailio]# Regards Fabian _________________________________________________________________ Stay up to date on your PC, the Web, and your mobile phone with Windows Live http://clk.atdmt.com/MRT/go/119462413/direct/01/

2 4

[Kamailio-Users] sip router meeting in Karlsruhe
by Daniel-Constantin Mierla 12 Nov '08

12 Nov '08

Hello, because of taking several days off, a complete report might show up a bit later, apologizes for that. Now a (short) summary... First, many thanks thanks to 1&1 for hosting the event and everyone that participated in such short notice. There were representatives from 10 companies: - 1&1 - FhG Fokus - Telio - Asipto - iptelorg/Tekelec - Voztelecom - Iptego - Itsyscom - Longphone - Basis AudioNet Some pictures should be published in the near future. After going in short introduction and presentation of the goals from the point of view of each project, we focused on: - identification of potential points of conflicts and how to get to a resolution in such case - code integration for common layer of the first phase - future development and proposals of new features - management of the larger eco-system that includes related projects and business entities I will send several emails detailing what was discussed and proposed there in few days. meanwhile, the outlines: - it is hard to avoid conflicts just by some clear and strict rules, so the common sense should lead the collaboration and discussions - GIT repository should be up in several days so the work can start, with a time line of 2-3 months from now to get core and tm in a very good shape of integration - another meeting shall be set in about 3 months time, to allow enough time for people to be able to attend, adjust the development and look more deep at the future. While the a lot of focus in the next months will be on integration, development of new features won't stop -- for examples, steps to a partial asynchronous processing are undertaking, couple of new modules are planned for release, several other modules to bring new functionalities - we should encourage and promote the development of related applications, like web interfaces, management tools, applications servers -- the add value for community and business Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

1 0

[Kamailio-Users] irc devel meeting summary
by Daniel-Constantin Mierla 11 Nov '08

11 Nov '08

Hello, sorry for delay... but better later than never, so I am trying to summarize the outcome of the IRC devel meeting from last Thursday, Nov 06, 2008. The log is available at: http://www.kamailio.org/dokuwiki/doku.php/development:irc-meeting-minutes-0… Regarding the 1.3.x series, we set the 2oth of November as the date for 1.3.4 release. There are several fixes and this branch is still used in many production environments, so it worths investing time in it. There are some updates in 1.4.x to be ported and some issues to be investigated. For a new 1.4.x release (the 1.4.3) we look for the beginning of December as the time frame for setting the date of the release. The 1.5.x rises in the first phase the question of a shorter time release, as we have lot of new features already implemented, see: http://www.kamailio.org/dokuwiki/doku.php/features:new-in-1.5.x http://www.kamailio.org/dokuwiki/doku.php/roadmap:1.5.x Unfortunately some of the new features are not completed yet (e.g., htable, carrierroute updates, PV migration) so we will stick to 6-8 months release cycle. The next major one that will use the common layer (core and tm) from sip-router could be done in a shorter time than usual. So, beginning to mid of January should be the time to freeze the code for a release date somewhere in end of January or February. An important aspect approached during the discussions was the release management and testing management. Perhaps we need to appoint a person to manage releasing process in order to have a better synchronization of the developers. As everyone agrees, testing is very important and we try to improve it. There is a testing suite included in the source tree right now, used for static testing. The idea of a dynamic testing and testing community was introduced and hopefully we can attract people and build a group of beta testers. There is a proposal of how to implement and what to take care of, probably this one has to continue on devel and users mailing lists for a proper organizational structure. GIT became as a subject of migrating from SVN, because of its features for a distributed development environment. However, sourceforge does not have such offerings, so it is not possible now anyhow. However the sip-router.org will use it. Regarding the sip-router.org project, we focused on short term goals, acknowledging that we have several modules offering same functionality but relying on different underlaying data structures, this have to co-exists for a longer time. For the first phase, core + tm the overlapping is rather small, the two projects insisting in the past to improve different aspects of them. Unfortunately I forgot to bring up some punctual topics proposed, mainly related to tm failure route calling in case of sending error and reply handling/dropping in onreply_routes. We can continue those subjects on the mailing lists. Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

1 0

[Kamailio-Users] Question regarding config file operation
by Siddhardha Garige 11 Nov '08

11 Nov '08

Hello all, I have a basic question regarding config file operation. Here is my understanding. At build time bison and flex work on config file and generates cfg.tab.c. This file is equivalent to c version of config file. Make uses cfg.tab.c along with other files and loads a series of actions into action structures. These actions will be performed on messages in a predefined order. If i make a change to config file, do I have to rebuild openser? But I do see just by stopping and starting these changes get reflected in operation. How does these changes get into action structure with out bison and flex generating cfg.tab.c file and make compiling with other files? Any help in this regard is appreciated. Thanks Sid

3 2

[Serusers] Information request about IPv6
by Mary Allen (mrallen) 11 Nov '08

11 Nov '08

Hi, If somebody is using SERi as a Proxy with IPv6, would you please let me know the modifications/additions needed to have it working with the IPv6 and IPv4. We have three type of trunks to the Proxy (IPv4, IPv6 and Dual). IPv4 and IPv6 are configured for the machine. For the Config file do we just have to add another line for listening on one for the IPv4 and another for the IPv6? and for the routes based on the phone number I will have to entered one for an IPv6. Will that be all? Thanks, Mary

3 2

[Kamailio-Users] OpenSER HA example with vrrp/ucarp?
by sergejf 11 Nov '08

11 Nov '08

We would like to set up two OpenSER 1.4.x servers in a failover configuration. The active (primary) server has two main roles: 1) load balancing SIP INVITEs between SBCs from various carriers using the CarrierRoute module 2) collecting CDRs from all these PSTN calls using the Acc module and storing them in a MySQL database for later billing reconciliation. Right now we're using a F5 Big-IP load balancer to handle the pool of two SIP proxies which receives the SIP INVITEs from our Media Servers and dispatches them to the SBCs. However, should the primary proxy fail, the secondary proxy would never receive (for example) the SIP BYE from an SBC. Solving that issue with the Big-IP seems complicated and a simpler vrrp/ucarp solution looks attractive. Any (hands-on) advice on how to set up vrrp/ucarp to advertise a single virtual IP address, then detect that the active SIP proxy has gone down and switch to the secondary IP, would be most welcome. We're using Centos 5.x (64 bit) on our servers. Thanks a lot. Serge -- View this message in context: http://www.nabble.com/OpenSER-HA-example-with-vrrp-ucarp--tp20443679p204436… Sent from the OpenSER Users Mailing List mailing list archive at Nabble.com.

2 1

[Serusers] SIP/2.0 500 Server Internal Error using Mysql
by Nel Tulaylay 11 Nov '08

11 Nov '08

Hi Tech support, I just completed configuring my SER SIP Server, I'm experiencing an intermittent error of "SIP/2.0 500 Server Internal Error" during REGISTER and whenever im using a mysql server for authentication. Most of the time, i can register successfully to the SIP Server but there are times i encounter error "SIP/2.0 500 Server Internal Error". Do you have an idea what's causing this error. I have here a trace log of SIP Messages. I will greatly appreciate any support from you. Thanks Nel U CLIENT-IP:1384 -> SERVER-IP:5060 REGISTER sip:SERVER-IP SIP/2.0..Via: SIP/2.0/UDP 192.168.1.136:5060;br anch=z9hG4bK63235644e9b491928f5..From: 638871680007 <sip:638871680007@116.6 8.141.251>;tag=63283ff..To: 638871680007 <sip:638871680007@SERVER-IP>. .Call-ID: 321f3c-24e8a-491928f0@SERVER-IP..CSeq: 6 REGISTER..Contact: "638871680007" <sip:638871680007@192.168.1.136:5060>..Authorization: Digest username="638871680007", realm="SERVER-IP", nonce="49199956fed351b86a 5c11c83d849a62144c5dcd", uri="sip:SERVER-IP", response="6a29e5839028f9 bc690c77fda9031054", algorithm=MD5..User-Agent: VaxSIPUserAgent/3.0..Expire s: 3600..Max-Forwards: 70..Content-Length: 0.... U SERVER-IP:5060 -> CLIENT-IP:5060 SIP/2.0 100 Trying..Via: SIP/2.0/UDP 192.168.1.136:5060 ;branch=z9hG4bK63235 644e9b491928f5;received=CLIENT-IP..From: 638871680007 <sip:638871680007 @SERVER-IP>;tag=63283ff..To: 638871680007 <sip:638871680007@116.68.141 .251>..Call-ID: 321f3c-24e8a-491928f0@SERVER-IP..CSeq: 6 REGISTER..Ser ver: Sip EXpress router (0.9.6 (x86_64/linux))..Content-Length: 0..Warning: 392 SERVER-IP:5060 "Noisy feedback tells: pid=16275 req_src_ip=203.1 89.8.149 req_src_port=1384 in_uri=sip:SERVER-IP out_uri=sip:116.68.141 .251 via_cnt==1".... U SERVER-IP:5060 -> CLIENT-IP:1384 SIP/2.0 500 Server Internal Error..Via: SIP/2.0/UDP 192.168.1.136:5060 ;bran ch=z9hG4bK63235644e9b491928f5;rport=1384;received=CLIENT-IP..From: 6388 71680007 <sip:638871680007@SERVER-IP>;tag=63283ff..To: 638871680007 <s ip:638871680007@SERVER-IP>;tag=04b7610a616ee809532470b3b2dd8840.0e13.. Call-ID: 321f3c-24e8a-491928f0@SERVER-IP..CSeq: 6 REGISTER..Server: Si

1 0

[Serusers] SIP/2.0 500 Server Internal Error using Mysql
by Nel Tulaylay 11 Nov '08

11 Nov '08

Hi Tech support, I just completed configuring my SER SIP Server, I'm experiencing an intermittent error of "SIP/2.0 500 Server Internal Error" during REGISTER and whenever im using a mysql server for authentication. Most of the time, i can register successfully to the SIP Server but there are times i encounter error "SIP/2.0 500 Server Internal Error". Do you have an idea what's causing this error. I have here a trace log of SIP Messages. I will greatly appreciate any support from you. Thanks Nel U CLIENT-IP:1384 -> SERVER-IP:5060 REGISTER sip:SERVER-IP SIP/2.0..Via: SIP/2.0/UDP 192.168.1.136:5060;br anch=z9hG4bK63235644e9b491928f5..From: 638871680007 <sip:638871680007@116.6 8.141.251>;tag=63283ff..To: 638871680007 <sip:638871680007@SERVER-IP>. .Call-ID: 321f3c-24e8a-491928f0@SERVER-IP..CSeq: 6 REGISTER..Contact: "638871680007" <sip:638871680007@192.168.1.136:5060>..Authorization: Digest username="638871680007", realm="SERVER-IP", nonce="49199956fed351b86a 5c11c83d849a62144c5dcd", uri="sip:SERVER-IP", response="6a29e5839028f9 bc690c77fda9031054", algorithm=MD5..User-Agent: VaxSIPUserAgent/3.0..Expire s: 3600..Max-Forwards: 70..Content-Length: 0.... U SERVER-IP:5060 -> CLIENT-IP:5060 SIP/2.0 100 Trying..Via: SIP/2.0/UDP 192.168.1.136:5060 ;branch=z9hG4bK63235 644e9b491928f5;received=CLIENT-IP..From: 638871680007 <sip:638871680007 @SERVER-IP>;tag=63283ff..To: 638871680007 <sip:638871680007@116.68.141 .251>..Call-ID: 321f3c-24e8a-491928f0@SERVER-IP..CSeq: 6 REGISTER..Ser ver: Sip EXpress router (0.9.6 (x86_64/linux))..Content-Length: 0..Warning: 392 SERVER-IP:5060 "Noisy feedback tells: pid=16275 req_src_ip=203.1 89.8.149 req_src_port=1384 in_uri=sip:SERVER-IP out_uri=sip:116.68.141 .251 via_cnt==1".... U SERVER-IP:5060 -> CLIENT-IP:1384 SIP/2.0 500 Server Internal Error..Via: SIP/2.0/UDP 192.168.1.136:5060 ;bran ch=z9hG4bK63235644e9b491928f5;rport=1384;received=CLIENT-IP..From: 6388 71680007 <sip:638871680007@SERVER-IP>;tag=63283ff..To: 638871680007 <s ip:638871680007@SERVER-IP>;tag=04b7610a616ee809532470b3b2dd8840.0e13.. Call-ID: 321f3c-24e8a-491928f0@SERVER-IP..CSeq: 6 REGISTER..Server: Si p EXpress router (0.9.6 (x86_64/linux))..Content-Length: 0..Warning: 392 11 6.68.141.251:5060 "Noisy feedback tells: pid=16275 req_src_ip= 203.189.8.14 9 req_src_port=1384 in_uri=sip:SERVER-IP out_uri=sip:SERVER-IP vi a_cnt==1"....

1 0

Re: [Kamailio-Users] CDRTool problem
by Ricky Gutierrez 10 Nov '08

10 Nov '08

hello, I change the values inside the section db_class, but it follows me showing the error class DB_radius extends DB_Sql { var $Host = "localhost"; var $Database = "radius"; var $User = "radius"; var $Password = "mypassword"; var $Halt_On_Error ="no"; } class DB_radius2 extends DB_Sql { var $Host = "localhost"; var $Database = "radius"; var $User = "radius"; var $Password = "mypassword"; var $Halt_On_Error ="no"; } "ser_radius"=>array( "name" => "OpenSER", "class" => "CDRS_ser_radius", "table" => "radacct", # "table" => "radacct".date("Ym"), # "db_class" => array("DB_radius2","DB_radius"), "db_class" => "DB_radius", "rating" => "1", "normalizedField" => "Normalized", "UserQuotaClass" => "OpenSERQuota", "AccountsDBClass" => "DB_openser", "UserQuotaNotify" => "1", "purgeCDRsAfter" => 120, // how many days to keep the CDRs "SIPProxies" => array("10.0.0.1" => "node01", // friendly names in sip trace table "10.0.0.2" => "node02", ), "db_class_siponline" => "DB_openser", "mediaDispatcher" => "10.0.0.1" // where to get the active media sessions from MediaProxy 2.0 I am using the version of freeradius 1.1.3 and cdrtool 6.6.10 greetingss ________________________________ Sunday, November 9, 2008 4:45:43 PM Tiago Rés Wrote: Hello, I had the same error. The problem is in the section db_class in global.inc. The default config file has in that section an array with radius1 and radius2. You have to configure it properly. That problem didn't occur more, but now When I try to read the tables it always checks cdrtool.radacct instead of radius.radacct. I don't know why it happens but I think someone else had that problem. Hope I helped.

1 1

[Serusers] Instant Messaging? Too Many Hops
by lin9k＠yahoo.com 10 Nov '08

10 Nov '08

Hi, How do I set up the instant messaging in my SER? When I use a SIP client to send a simple message the SER responds back "Too Many Hops". How do I make it work in my SER? Ling

1 0

[Serusers] RTP Proxy used without NAT
by Marc Bechtel 10 Nov '08

10 Nov '08

Hi, we are testing the iptel.org service using the sip server provided by iptel (213.192.59.75). Sjphonev. 1.65 is used as client. We noticed a strange behavior concerning the RTP Proxy. All SIP messages pass the iptel sip proxy as record route is used. Also all RTP packets pass the sip/rtp proxy. The question bothering us is why the RTP packets are using a proxy? (sniffs show that all RTP packets are send to the proxy) To make our case clear I will explain some details: 1. We are definitely using public IP addresses. (no RFC 1918 addresses) 2. There is no NAT. 3. Sniffs show that in the first invite packet the SDP media attribute is set to nortpproxy:yes 4. In the Sip Header via section the "rport" attribute is used. (not sure why) As I understand the SER documentation RTP proxy should only be used, if the nat_uac_test function in the nathelper module returns true. This function is checking for RFC 1918 addresses and differences in IP and port values. Thanks a lot for the help. Marc

1 0

[Kamailio-Users] branch route
by Alex R.S.M 10 Nov '08

10 Nov '08

Hi, I am trying to modify the header of both main and the branch routes, more specifically trying to modify FROM field on both routes to different values. The change on main route is fine but couldn't make the change on the branch side. if (is_method("INVITE")) { .... seturi("sip:1111111111@x.x.x.x:5060;transport=UDP"); // main route append_branch("sip:2222222222@y.y.y.y:5060"); // branch route if ( uri=~"sip:.+@x.x.x.x.*" ) { uac_replace_from("..."); // make changes on main route, works } if ( uri=~"sip:.+@y.y.y.y.*" ) { uac_replace_from("..."); // make changes on the branch, not working } .... When I move the logic for the branch into "branch_route" it would created two FROM fields. Is this a bug? Thanks, Alex _________________________________________________________________ Stay up to date on your PC, the Web, and your mobile phone with Windows Live http://clk.atdmt.com/MRT/go/119462413/direct/01/

2 1

[Serusers] STUN servers?
by SIP 10 Nov '08

10 Nov '08

Until recently, we've been using the Mystun server because it was a much more stable and reliable version of a stun server than the Vovida implementation (which hasn't been developed in a LONG time). The Mystun server, however, doesn't support XOR_MAPPED_ADDRESS or some of the other new things from the draft-ietf-behave-rfc3489bis-15. I'm wondering if anyone knows of any good stun servers out there that do. N.

1 0

[Kamailio-Users] Routing Call
by paulo leonardo 10 Nov '08

10 Nov '08

Good Morning list, i have kamailio installed in my LAN (192.168.170.101 - machine 1), and i have eyebeam (192.168.46.101 - machine 2) registred in my kamailio, when eyebeam make a call i would like to route this call to a gateway (XXX.XXX.XXX.XXX - machine 3), how can i do that? i would like to read a practical manual. thanks

3 2

[Kamailio-Users] Core dump on writing dialog profile size into script var.
by Alex Balashov 09 Nov '08

09 Nov '08

I also have another interesting problem with the aforementioned configuration (http://pastebin.com/f28051a5). When I write the dialog profile size into an AVP, it works fine. When I write it into a script var, i.e. replace $avp(S:dlg_sz) with $var(dlg_sz), it crashes: Relaying INVITE from 210.23.22.23 to sip:2122222322@210.23.22.23:5060 [D] Added new dialog for 7709600101 [ONREPLY-ROUTE 1] Provisional reply 100 received. [ONREPLY-ROUTE 1] 200 OK received for 7709600101 [ONREPLY-ROUTE 1] INVITE/200 is part of dialog for 7709600101 Segmentation fault (core dumped) GDB reveals: Program received signal SIGSEGV, Segmentation fault. 0xb7e7f2f8 in strncpy () from /lib/i686/nosegneg/libc.so.6 (gdb) where #0 0xb7e7f2f8 in strncpy () from /lib/i686/nosegneg/libc.so.6 #1 0x080a4a07 in set_var_value (var=0x8188d98, value=0xbfae5f28, flags=<value o at script_var.c:122 #2 0xb7d6c4fe in w_get_profile_size (msg=0x81902b8, profile=0xb5ede180 "\034??\ value=0x818b6b8 "@?\030\b", result=0x818b6f8 "N") at dialog.c:668 #3 0x08054f15 in do_action (a=0x818b850, msg=0x81902b8) at action.c:850 #4 0x08053ed2 in run_action_list (a=0x818b5c8, msg=0x81902b8) at action.c:138 #5 0x08056365 in do_action (a=0x818bab8, msg=0x81902b8) at action.c:722 #6 0x08053ed2 in run_action_list (a=0x818b178, msg=0x81902b8) at action.c:138 #7 0x080572c2 in run_top_route (a=0x818b178, msg=0x81902b8) at action.c:118 #8 0xb7de3a64 in reply_received (p_msg=0x81902b8) at t_reply.c:1361 #9 0x08064793 in forward_reply (msg=0x81902b8) at forward.c:507 #10 0x08090d5b in receive_msg ( buf=0x81600e0 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP 215.22.22.22;branch=z9hG4 08.52.173.18\r\nVia: SIP/2.0/UDP 198.225.86.10:5060;branch=z9hG4bKragjo0207gm0dc p:208.52."..., len=814, rcv_info=0xbfae65d4) at receive.c:203 #11 0x080cccfb in udp_rcv_loop () at udp_server.c:449 #12 0x0806b78d in main (argc=1, argv=0xbfae6764) at main.c:693 It would seem to me that there is some sort of buffer overflow issue that results in the garbage seen above. Not sure that it makes a difference, but the glibc being linked against is a Xen-safe one that disables TLS functionality. This is all running inside a Xen DomU. -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599

4 9

[Serusers] Assistance with SER setup
by Scott Seltzer 09 Nov '08

09 Nov '08

Hello, my name is Scott Seltzer, from ConnectMe (www.connectmevoice.com <http://www.connectmevoice.com/> ) Connectme is currently in the process of setting up SER for use as a Proxy and Registrar. We will ultimately need to be able to use an API to setup new SIP URIs for each new customer. We are not familiar at all with SER, and would like to find out what support options there may be out there. We would also be interested in using some consulting services to help get us started, and support us along the way. Please let me know if there is anybody that can help us out with this. Thanks! Scott Seltzer

2 1

[Kamailio-Users] CDRTool problem
by Ricky Gutierrez 09 Nov '08

09 Nov '08

Hi forum, I am trying to configure cdrtool with openser and radius, but in the administration console it shows me this message: "Error instantiating db class: ". I have created the radius database and I see that the openser with the I modulate ACC, he writes data in the chart radacct any suggestion?, something that me this forgetting the file global.inc? best regards rickygm

1 0

[Kamailio-Users] About 'avp_check' and strings formed with pseudo-variables
by Iñaki Baz Castillo 08 Nov '08

08 Nov '08

Hi, I've stored in "usr_preferences" some entries with: - attribute: 'bla' - value: 'alice(a)domain.org' <--- With no "sip:" in front. I use 'avp_db_load' to get that value and compare using 'avp_check' with the To uri without protocol (without "sip:"). I get this behaviour by doing: -------------------------- if avp_db_load("$fu/uri", "$avp(s:bla)") { $var(To) = $tU + '@' + $td; if avp_check("$avp(s:bla)","eq/$var(To)/gi") { [...] -------------------------- But I would like to avoid using a variable $var(To), something as: -------------------------- if avp_db_load("$fu/uri", "$avp(s:bla)") { if avp_check("$avp(s:bla)","eq/$tU + '@' + $td/gi") { # or: if avp_check("$avp(s:bla)","eq/$tU@$td/gi") { [...] -------------------------- Unfortunatelly it doesn't work, it's not valid. Do I really need to use a variable (or AVP) for "avp_check"? Thanks. -- Iñaki Baz Castillo

1 0

[Kamailio-Users] Openser configured as outbound proxy - retransmissions issue.
by Siddhardha Garige 08 Nov '08

08 Nov '08

Hello all, I am working on configuring openser as a outbound proxy. User agents register to service provider through openser outbound proxy. I am experiencing issues with retransmissions. Case 1. UA sends an INVITE to Proxy and proxy is down. Openser sends 100 Trying to UA and retransmits INVITE messages to proxy. After 8 retry attempts sends 408 Request time out to handset. All as expected. Case 2: Openser received INVITE for UA from proxy. UA is down. Openser sent 100 Trying to proxy and routes reqest to UA. No response from UA and ** Openser did not send any retransmissions of INVITE to UA**. After a while CANCLE arrived at openser and cleared transaction. why openser does retransmissions in Case 1 and why not in case 2? Can openser proxy be operated in stateful outbound proxy to take care of retransmissions? I am using default openser config file. Is there any thing I am doing wrong? Any help is greatly appreciated. Thanks Sid

2 2

[Kamailio-Users] [Fwd: Re: [Sip-implementors] REGISTER R-URI with port parameter]
by Alex Balashov 07 Nov '08

07 Nov '08

Does Kamailio match 'uri == myself' if the domain is the same as the canonical hostnames/aliases but the port is different than the one Kamailio knows itself to be listening on? -------- Original Message -------- Subject: Re: [Sip-implementors] REGISTER R-URI with port parameter Date: Tue, 28 Oct 2008 16:46:04 -0500 From: Dale.Worley(a)comcast.net To: sip-implementors(a)lists.cs.columbia.edu References: <00D42150952F70458C66072322F7FE2502EDA940(a)saturn2.aculab.com> <200810241652.m9OGqx6s027493(a)dragon.ariadne.com> <200810241902.43581.ibc(a)aliax.net> From: =?iso-8859-1?q?I=F1aki_Baz_Castillo?= <ibc(a)aliax.net> El Viernes, 24 de Octubre de 2008, Dale.Worley(a)comcast.net escribió: > sip:xxx@host:5060 > sip:xxx@host:15060 > sip:xxx@host:25060 > sip:xxx@host:35060 > > In that case, the request-URI of the REGISTER needs to contain the > proper port number. Well, not totally needed. A UA could construct a REGISTER like this: REGISTER sip:xxx@host SIP/2.0 and sent it to host:15060. You can't depend on that working -- It's never been settled what must happen if a SIP message arrives at a UAS which isn't the UAS that the RFC 3263 rules would send it to. It's possible that the UAS will forward it based on the request-URI. It's safer to include the port, if the destination port is not 5060. For example Twinkle does it if you set the registrar in a port different than 5060. I wouldn't depend on that working. Dale _______________________________________________ Sip-implementors mailing list Sip-implementors(a)lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599

3 3

[Kamailio-Users] Passing REGISTERs up stream
by Daniel Corbe 07 Nov '08

07 Nov '08

Guys, When attempting to pass REGISTER requests up stream I get the following error messages on the console (below). This also brings up the question of "what is the best way to simply pass REGISTER requests on to an upstream registrar?" Thanks for the help. -Daniel REGISTER: NATed client, enabling NAT Oct 29 18:03:58 [48175] ERROR:tm:t_forward_nonack: no branch for forwarding Oct 29 18:03:58 [48175] ERROR:tm:w_t_relay: t_forward_nonack failed Oct 29 18:03:58 [48175] ERROR:tm:t_forward_nonack: no branch for forwarding Oct 29 18:03:58 [48175] ERROR:tm:w_t_relay: t_forward_nonack failed Oct 29 18:03:59 [48175] CRITICAL:tm:t_should_relay_response: pick_branch failed (lowest==-1) for code 401 Here's the relevant parts of my ser config; in route[1] route[1] { ... if (method == "REGISTER") { route(2); } route(1); } route[2] { # Check to see if the UAC is trying to UNREGISTER. If not test # for NAT. If NAT is present, we mark it as such before we save() # the location, that way flag 6 is always set for NATed UAs. if (!search("^Contact:[ ]*\*") && nat_uac_test("19")) { xlog("L_NOTICE", "REGISTER: NATed client, enabling NAT\n"); setflag(6); fix_nated_register(); force_rport(); }; # We must handle replies for registrations, for caching and location # tracking purposes. t_on_reply("1"); t_on_failure("1"); # Check for digest #if (radius_www_authorize("")) #{ # xlog("L_NOTICE", "REGISTER: No Digest, sending challenge\n"); # www_challenge("", "0"); # exit; #} # Digest was good if we get here #save("location"); # Relay register to porta t_relay("216.151.143.69"); } onreply_route[2] { if (status =~ "2[0-9][0-9]") { # save("location"); }; }

3 3

[Serusers] Problem with SIP Identity
by jerome.herve＠orange-ftgroup.com 07 Nov '08

07 Nov '08

> Hello everyone, > I'm currently working on the implementation of RFC4474 in SER. > I didn't manage to set up the auth_identity module in SER. > Is there someone able to tell me what do I have to write in ser.cfg to make this possible? > An example of an entire ser.cfg will be great. > I hope you will help me. > Thanks & regards, > > Jérôme HERVE > tél. 02 96 05 27 41 > mob. 06 76 15 18 49 > >

3 2

[Serusers] Problem with SIP Identity
by jerome.herve＠orange-ftgroup.com 07 Nov '08

07 Nov '08

Hello everyone, I'm currently working on the implementation of RFC4474 in SER. I didn't manage to set up the auth_identity module in SER. Is there someone able to tell me what do I have to write in ser.cfg to make this possible? An example of an entire ser.cfg will be great. I hope you will help me. Thanks & regards, Jérôme HERVE tél. 02 96 05 27 41 mob. 06 76 15 18 49

2 1

[Kamailio-Users] $du has no effect in failure route
by jh＠tutpro.com 07 Nov '08

07 Nov '08

i have in failure route: t_on_branch("0"); $du = "sip:127.0.0.1:5070"; xlog("L_INFO", "Pseudo variable du has value <$du>\n"); t_relay("0x01"); and i get to syslog: Nov 6 16:33:15 test /usr/sbin/kamailio[22539]: Pseudo variable du has value <sip:127.0.0.1:5070> but wireshark shows that the invite is sent according to uri host of the branch added in failure route and not to 127.0.0.1:5070. is this a bug or is it so that $du is not supposed to have any effect in failure route? -- juha

3 3

[Kamailio-Users] Kamailio + eyebeam + TLS
by paulo leonardo 07 Nov '08

07 Nov '08

Hi list, I have a litle problem, i would like to setup eyebeam with kamailio using TLS, but i always get *Registration error: 503 - certificate validation failure* =( !! I read the README of TLS. How certificate (.crt) i need to install in eyebeam? # kamailio -V ------------------------------------------------------------------------------------------- version: kamailio 1.4.1-tls (i386/linux) flags: STATS: Off, USE_IPV6, USE_TCP,* USE_TLS*, DISABLE_NAGLE, USE_MCAST, SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. svnrevision: unknown @(#) $Id: main.c 4623 2008-08-07 07:31:30Z miconda $ main.c compiled on 16:31:23 Oct 24 2008 with gcc 4.2.3 ------------------------------------------------------------------------------------------ disable_tls = 0 listen = tls:192.168.170.101:5061 tls_port_no = 5061 tls_verify_server = 1 tls_verify_client = 1 tls_require_client_certificate = 1 tls_method = TLSv1 tls_certificate = "/usr/local/etc/kamailio/tls/user/user-cert.pem" tls_private_key = "/usr/local/etc/kamailio/tls/user/user-privkey.pem" tls_ca_list = "/usr/local/etc/kamailio/tls/user/user-calist.pem" ------------------------------------------------------------------------------------------------------------ thanks list!

2 1

Re: [Kamailio-Users] Remote-Party-ID header
by ingdavidcespedes＠cable.net.co 07 Nov '08

07 Nov '08

2 1

Re: [Kamailio-Users] CANCEL and 487 Request Terminated
by ingdavidcespedes＠cable.net.co 06 Nov '08

06 Nov '08

I think that's the way it should be. First it receive 487 from SBC and immediately it responds it to SBC with the ACK. Then it passes the 487 to the UAC and receive the ACK, that's all. It doesn't have to forward that last ACK to the SBC. ----- Mensaje original ----- De: Krom <kyle.romulas(a)gmail.com> Fecha: Jueves, Noviembre 6, 2008 4:06 pm Asunto: Re: [Kamailio-Users] CANCEL and 487 Request Terminated > My apologies for the drawing. Openser is receiving the 487 from the > SBC, ACKing back to the SBC and then passing the 487 to the UAC and > the the UAC ACK's back to Openser. At which time the error occurs > because the ACK will not be forwarded since it already ACK'd for the > 487 to the SBC. > > -Kyle > > On Thu, Nov 6, 2008 at 2:42 PM, <ingdavidcespedes(a)cable.net.co> > wrote:> The final 487 should go from openser to UAC, not from SBC > to UAC. That's why the final ACK is getting lost, because it was > allready ACK'd by openser. > > > > ----- Mensaje original ----- > > De: Krom <kyle.romulas(a)gmail.com> > > Fecha: Jueves, Noviembre 6, 2008 1:18 pm > > Asunto: Re: [Kamailio-Users] CANCEL and 487 Request Terminated > > > >> Klaus, > >> > >> Some additional information. After viewing a trace I can see > that the > >> error is being generated from the last ACK received from the UAC. > >> OpenSER/Kamailio is ACK'ing to the 487 from the PSTN provider > and then > >> relaying the 487 to the UAC which in turn ACK's back. It is the > last>> ACK from the UAC that is getting the error on t_relay. I > can assume > >> because the ACK to the 487 was already sent by OpenSER/Kamailio > to the > >> PSTN upon receiving the initial 487. Something in the script I can > >> change to prevent this or just ignore the error and move on. :-) > >> > >> UAC OSER SBC > >> > >> CANCEL ---> | > >> > >> CANCEL ---> | > >> > >> <--- 200 canceling > >> > >> | <--- 200 OK > >> > >> | <--- 487 Request Terminated > >> > >> ACK ---> > >> > >> <--- 487 Reqest Terminated > >> > >> ACK ---> | > >> > >> > >> Regards, > >> -Kyle > >> > >> > >> On Thu, Nov 6, 2008 at 9:05 AM, Krom <kyle.romulas(a)gmail.com> > wrote:>> > Klaus, > >> > > >> > Thank you for the reply and the link. The link help in > checking my > >> > work. My script is very simple and even checking against the > >> compiled> scripted from sipwise.com the error persists. > >> > > >> > Here is my CANCEL and ACK handling. > >> > if(is_method("CANCEL") || is_method("ACK")) { > >> > if(t_check_trans()) { > >> > if(!t_relay()) sl_reply_error(); > >> > } > >> > exit; > >> > } > >> > > >> > Here is my route block for PSTN calls. > >> > route[4] > >> > { > >> > if (!load_gws()) { > >> > sl_send_reply("500", "Server Internal Error"); > >> > exit; > >> > } > >> > if (!next_gw()) { > >> > sl_send_reply("503", "Service Unavailable"); > >> > exit; > >> > } > >> > t_on_failure("2"); > >> > t_relay("udp:<IPADDR>:5060"); # Relay to the Session Boarder > >> Controller> > >> > exit; > >> > > >> > } > >> > > >> > Here is my failure route. > >> > failure_route[2] > >> > { > >> > > >> > if(t_check_status("408|500|503")) { > >> > if (!next_gw()) { > >> > t_reply("503", "Service Unavailable"); > >> > exit; > >> > } > >> > t_on_failure("2"); > >> > t_relay("udp:<IPADDR>:5060"); # Relay to the Session Boarder > >> Controller> } > >> > > >> > exit; > >> > > >> > } > >> > > >> > Any thoughts or errors you see? > >> > > >> > Regards. > >> > > >> > > >> > On Thu, Nov 6, 2008 at 3:56 AM, Klaus Darilion > >> > <klaus.mailinglists(a)pernau.at> wrote: > >> >> looks like the ACK is miss-routed. > >> >> > >> >> Usually calling t_relay() for ACK is sufficient (take a look at > >> the config > >> >> file generated with sipwise.com wizard for correct CANCEL/ACK > >> handling.>> > >> >> regards > >> >> klaus > >> >> > >> >> Krom schrieb: > >> >>> > >> >>> Et al, > >> >>> > >> >>> Version: openser-1.1.1-notls > >> >>> > >> >>> I am receiving the following after calling t_relay within the > >> default>>> route block. > >> >>> ERROR: t_newtran: transaction already in process 0xb0139638 > >> >>> WARNING:sl:sl_send_reply: I won't send a reply for ACK!! > >> >>> WARNING: script writer didn't release transaction > >> >>> > >> >>> This is happening when a downstream UAC dials outbound to the > >> PSTN and > >> >>> then terminates the call prior to the far ending answering. > >> >>> > >> >>> UAC send a CANCEL to the proxy, the proxy responds to the UAC > >> with a > >> >>> '200 canceling' and forwards the CANCEL to the PSTN provider. > >> >>> The PSTN provider sends 487 Request Terminated to the proxy and > >> the>>> proxy sends it on to the UAC. UAC responds with an ACK to > >> the proxy. > >> >>> > >> >>> Is this an issue? How do I handle this dialog withou > getting the > >> >>> t_relay error message? > >> >>> > >> >>> > >> >> > >> > > >> > > >> > > >> > -- > >> > Thanks, > >> > -- Kyle > >> > > >> > >> > >> > >> -- > >> Thanks, > >> -- Kyle > >> > >> _______________________________________________ > >> Users mailing list > >> Users(a)lists.kamailio.org > >> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users > >> > > > > > > > > -- > Thanks, > -- Kyle >

2 1

Re: [Kamailio-Users] CANCEL and 487 Request Terminated
by Krom 06 Nov '08

06 Nov '08

My apologies for the drawing. Openser is receiving the 487 from the SBC, ACKing back to the SBC and then passing the 487 to the UAC and the the UAC ACK's back to Openser. At which time the error occurs because the ACK will not be forwarded since it already ACK'd for the 487 to the SBC. -Kyle On Thu, Nov 6, 2008 at 2:42 PM, <ingdavidcespedes(a)cable.net.co> wrote: > The final 487 should go from openser to UAC, not from SBC to UAC. That's why the final ACK is getting lost, because it was allready ACK'd by openser. > > ----- Mensaje original ----- > De: Krom <kyle.romulas(a)gmail.com> > Fecha: Jueves, Noviembre 6, 2008 1:18 pm > Asunto: Re: [Kamailio-Users] CANCEL and 487 Request Terminated > >> Klaus, >> >> Some additional information. After viewing a trace I can see that the >> error is being generated from the last ACK received from the UAC. >> OpenSER/Kamailio is ACK'ing to the 487 from the PSTN provider and then >> relaying the 487 to the UAC which in turn ACK's back. It is the last >> ACK from the UAC that is getting the error on t_relay. I can assume >> because the ACK to the 487 was already sent by OpenSER/Kamailio to the >> PSTN upon receiving the initial 487. Something in the script I can >> change to prevent this or just ignore the error and move on. :-) >> >> UAC OSER SBC >> >> CANCEL ---> | >> >> CANCEL ---> | >> >> <--- 200 canceling >> >> | <--- 200 OK >> >> | <--- 487 Request Terminated >> >> ACK ---> >> >> <--- 487 Reqest Terminated >> >> ACK ---> | >> >> >> Regards, >> -Kyle >> >> >> On Thu, Nov 6, 2008 at 9:05 AM, Krom <kyle.romulas(a)gmail.com> wrote: >> > Klaus, >> > >> > Thank you for the reply and the link. The link help in checking my >> > work. My script is very simple and even checking against the >> compiled> scripted from sipwise.com the error persists. >> > >> > Here is my CANCEL and ACK handling. >> > if(is_method("CANCEL") || is_method("ACK")) { >> > if(t_check_trans()) { >> > if(!t_relay()) sl_reply_error(); >> > } >> > exit; >> > } >> > >> > Here is my route block for PSTN calls. >> > route[4] >> > { >> > if (!load_gws()) { >> > sl_send_reply("500", "Server Internal Error"); >> > exit; >> > } >> > if (!next_gw()) { >> > sl_send_reply("503", "Service Unavailable"); >> > exit; >> > } >> > t_on_failure("2"); >> > t_relay("udp:<IPADDR>:5060"); # Relay to the Session Boarder >> Controller> >> > exit; >> > >> > } >> > >> > Here is my failure route. >> > failure_route[2] >> > { >> > >> > if(t_check_status("408|500|503")) { >> > if (!next_gw()) { >> > t_reply("503", "Service Unavailable"); >> > exit; >> > } >> > t_on_failure("2"); >> > t_relay("udp:<IPADDR>:5060"); # Relay to the Session Boarder >> Controller> } >> > >> > exit; >> > >> > } >> > >> > Any thoughts or errors you see? >> > >> > Regards. >> > >> > >> > On Thu, Nov 6, 2008 at 3:56 AM, Klaus Darilion >> > <klaus.mailinglists(a)pernau.at> wrote: >> >> looks like the ACK is miss-routed. >> >> >> >> Usually calling t_relay() for ACK is sufficient (take a look at >> the config >> >> file generated with sipwise.com wizard for correct CANCEL/ACK >> handling.>> >> >> regards >> >> klaus >> >> >> >> Krom schrieb: >> >>> >> >>> Et al, >> >>> >> >>> Version: openser-1.1.1-notls >> >>> >> >>> I am receiving the following after calling t_relay within the >> default>>> route block. >> >>> ERROR: t_newtran: transaction already in process 0xb0139638 >> >>> WARNING:sl:sl_send_reply: I won't send a reply for ACK!! >> >>> WARNING: script writer didn't release transaction >> >>> >> >>> This is happening when a downstream UAC dials outbound to the >> PSTN and >> >>> then terminates the call prior to the far ending answering. >> >>> >> >>> UAC send a CANCEL to the proxy, the proxy responds to the UAC >> with a >> >>> '200 canceling' and forwards the CANCEL to the PSTN provider. >> >>> The PSTN provider sends 487 Request Terminated to the proxy and >> the>>> proxy sends it on to the UAC. UAC responds with an ACK to >> the proxy. >> >>> >> >>> Is this an issue? How do I handle this dialog withou getting the >> >>> t_relay error message? >> >>> >> >>> >> >> >> > >> > >> > >> > -- >> > Thanks, >> > -- Kyle >> > >> >> >> >> -- >> Thanks, >> -- Kyle >> >> _______________________________________________ >> Users mailing list >> Users(a)lists.kamailio.org >> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users >> > > -- Thanks, -- Kyle

1 0

[Kamailio-Users] CANCEL and 487 Request Terminated
by Krom 06 Nov '08

06 Nov '08

Et al, Version: openser-1.1.1-notls I am receiving the following after calling t_relay within the default route block. ERROR: t_newtran: transaction already in process 0xb0139638 WARNING:sl:sl_send_reply: I won't send a reply for ACK!! WARNING: script writer didn't release transaction This is happening when a downstream UAC dials outbound to the PSTN and then terminates the call prior to the far ending answering. UAC send a CANCEL to the proxy, the proxy responds to the UAC with a '200 canceling' and forwards the CANCEL to the PSTN provider. The PSTN provider sends 487 Request Terminated to the proxy and the proxy sends it on to the UAC. UAC responds with an ACK to the proxy. Is this an issue? How do I handle this dialog withou getting the t_relay error message? -- Thanks, -- Kyle

2 3

[Serusers] Assistance with SER setup
by Scott Seltzer 06 Nov '08

06 Nov '08

Hello, my name is Scott Seltzer, from ConnectMe (www.connectmevoice.com <http://www.connectmevoice.com/> ) Connectme is currently in the process of setting up SER for use as a Proxy and Registrar. We will ultimately need to be able to use an API to setup new SIP URIs for each new customer. We are not familiar at all with SER, and would like to find out what support options there may be out there. We would also be interested in using some consulting services to help get us started, and support us along the way. Please let me know if there is anybody that can help us out with this. Thanks! Scott Seltzer

1 0

[Serusers] FW: Support for SER setup
by Scott Seltzer 06 Nov '08

06 Nov '08

Hello, my name is Scott Seltzer, from ConnectMe (www.connectmevoice.com <http://www.connectmevoice.com> ) Connectme is currently in the process of setting up SER for use as a Proxy and Registrar. We will ultimately need to be able to use an API to setup new SIP URIs for each new customer. We are not familiar at all with SER, and would like to find out what support options there may be out there. We would also be interested in using some consulting services to help get us started, and support us along the way. Please let me know if there is anybody that can help us out with this. Thanks! Scott Seltzer

1 0

[Kamailio-Users] two endpoints
by Alex R.S.M 06 Nov '08

06 Nov '08

Hi, If ENUM lookup returns 2 destinations, does kamailio fork the message and send two INVITE? What function can be used to force kamailio to fork a message? Regards, Alex _________________________________________________________________ Windows Live Hotmail now works up to 70% faster. http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_faster…

2 1

[Kamailio-Users] rewriteuser with AVP
by Samuel Muller 06 Nov '08

06 Nov '08

Hello all, I've a little question : I got a username in an AVP by avp_load_radius, and I would rewrite the uri with it. The objectives is to replace the r-uri by an ipbx uri, then forward the call to it by a new branch (to not loose the phone number requested). in this case : 0123452000 is behind a spa9000. The user 0123452000 has an AVP called "ipbx", that i'm using to do some groups and permissions (plus the rewrite). actually, it does not work, i tried many ways : # load radius attributes of the callee if (!avp_load_radius("callee")) { xlog("L_INFO","-> user unknown in radius usr db : $ru"); route(15); # route PSTN } # verify the AVPs we got (caller and callee) xlog("L_INFO", " -AVP------------------------------------- "); avp_print(); xlog("L_INFO", " ----------------------------------------- "); # callee is behind an ipbx (avp ipbx) ? if (is_avp_set("$avp(s:callee_ipbx)")) { xlog("L_INFO", "-> callee is behind an ipbx : $avp(s:callee_ipbx)"); setflag(14); # flag IPBX #subst_user('/$rU$/$avp(s:callee_ipbx)/'); #rewriteuri("sip:$avp(s:callee_ipbx)@$rd"**); rewriteuser($avp(s:callee_ipbx)); } # callee in usrloc ? if (lookup("location")) { append_hf("P-hint: usrloc applied\r\n"); xlog("L_INFO","-> registered user called : $tu"); route(7); # route FORWARD } else { xlog("L_INFO","-> 480: local user not found in usrloc : $tu"); sl_send_reply("480","Temporarily Unavailable"); drop; } and in the debugs log : Nov 5 13:04:51 ser0 kamailio[2930]: -ROUTE--INBOUND-------------------------- Nov 5 13:04:51 ser0 kamailio[2930]: DBG:avp_radius:load_avp_user: rc_auth Success Nov 5 13:04:51 ser0 kamailio[2930]: DBG:avp_radius:load_avp_user: AVP 'callee_asserted_id'/0='0123452000'/0 has been added Nov 5 13:04:51 ser0 kamailio[2930]: DBG:avp_radius:load_avp_user: AVP 'callee_ipbx'/0='spa9000'/0 has been added Nov 5 13:04:51 ser0 kamailio[2930]: -AVP------------------------------------- Nov 5 13:04:51 ser0 kamailio[2930]: INFO:avpops:ops_print_avp: p=0x7fb3d7e5cfe8, flags=0x0003 Nov 5 13:04:51 ser0 kamailio[2930]: INFO:avpops:ops_print_avp: ^I^I^Iname=<callee_ipbx> Nov 5 13:04:51 ser0 kamailio[2930]: INFO:avpops:ops_print_avp: ^I^I^Ival_str=<spa9000 / 7> Nov 5 13:04:51 ser0 kamailio[2930]: INFO:avpops:ops_print_avp: p=0x7fb3d7e5cf88, flags=0x0003 Nov 5 13:04:51 ser0 kamailio[2930]: INFO:avpops:ops_print_avp: ^I^I^Iname=<callee_asserted_id> Nov 5 13:04:51 ser0 kamailio[2930]: INFO:avpops:ops_print_avp: ^I^I^Ival_str=<0123452000 / 10> Nov 5 13:04:51 ser0 kamailio[2930]: INFO:avpops:ops_print_avp: p=0x7fb3d7e5ced8, flags=0x0003 Nov 5 13:04:51 ser0 kamailio[2930]: INFO:avpops:ops_print_avp: ^I^I^Iname=<caller_asserted_id> Nov 5 13:04:51 ser0 kamailio[2930]: INFO:avpops:ops_print_avp: ^I^I^Ival_str=<0123451011 / 10> Nov 5 13:04:51 ser0 kamailio[2930]: INFO:avpops:ops_print_avp: p=0x7fb3d7e5ce38, flags=0x0003 Nov 5 13:04:51 ser0 kamailio[2930]: ----------------------------------------- Nov 5 13:04:51 ser0 kamailio[2930]: -> callee is behind an ipbx : spa9000 Nov 5 13:04:51 ser0 kamailio[2930]: DBG:registrar:lookup: '$avp( s(a)sip.720.fr' Not found in usrloc Nov 5 13:04:51 ser0 kamailio[2930]: -> 480: local user not found in usrloc : sip:0123452000@sip.720.fr <sip%3A0123452000(a)sip.720.fr> Nov 5 13:04:51 ser0 kamailio[2930]: DBG:core:parse_headers: flags=ffffffffffffffff Nov 5 13:04:51 ser0 kamailio[2930]: DBG:core:check_via_address: params 77.246.81.162, 192.168.0.134, 0 Nov 5 13:04:51 ser0 kamailio[2930]: DBG:core:destroy_avp_list: destroying list 0x7fb3d7e5d040 Nov 5 13:04:51 ser0 kamailio[2930]: DBG:core:receive_msg: cleaning up -> But, if I did it by : if (uri =~ "^sip:012345200{1}") { rewriteuri("sip:spa9000@sip.720.fr<sip%3Aspa9000(a)sip.720.fr> "); } if (lookup("location")) { append_hf("P-hint: usrloc applied\r\n"); xlog("L_INFO","-> registered user called : $tu"); route(7); # route FORWARD } it works great, and the call is ok (the ipbx forward correctly the request the phone behind him). Anyone has an idea ? thanks in advance ! -- Samuel MULLER

2 3

[Kamailio-Users] Fwd: Openser as Proxy and Asterisk as Registrar
by Cosimo Fadda 06 Nov '08

06 Nov '08

Hi David, thank you for you answer, 2008/11/6, ingdavidcespedes(a)cable.net.co <ingdavidcespedes(a)cable.net.co>: > > Hi! > > I had the same problem (My PC was responding everything it receives through > the default gateway "eth0" ). Everybody say that it was an Asterisk bug, > but it was a problem in the routing table. Yes, I'm new to Openser but I know quite well Asterisk, and I don't think it is a bug or a misconfiguration . Type route in a terminal and check if they are the way you are thinking. If > not, add the correct route. Tell me if it solve your problem. The route table is correct, but a strange thing happens since the SIP packet is sent from the correct nic, but un the UDP header of that packet I see as source the IP of the other nic (the one that received the orinal packet) I have to investigate a little more on this aspect anyway. C. David Cespedes > > ----- Mensaje original ----- > De: Cosimo Fadda <cfadda.lists(a)gmail.com> > Fecha: Miércoles, Noviembre 5, 2008 9:36 am > Asunto: [Kamailio-Users] Openser as Proxy and Asterisk as Registrar > > > Hi everybody > > I'd like to implement this scenario: > > > > ----------- ------------------- ---------- > > ----- > > | GW/FW > > |<----LAN1---->|eth0|Openser|eth1|<----LAN2---->|eth0|asterisk| -- > > >PSTN----------- ------------------- | ----- > > ---------- > > |_______________________________________________| > > > > > > > > > > > > Where: > > - Openser is reachable from the outside with a public IP > > forwarded to > > eth0 private address; > > > > - Asterisk is connected to Openser using another separated LAN > > - Openser acts as proxy (for requests coming from the outside) and > > Asterisk act as registrar and gateway. > > > > > > This is the description, now the questions: > > -since opneser has two different nics, how can configure it to > > properly > > send register request to asterisk? > > This is what currently happens: > > 192.168.40.68:5060: is eth0 Openser Address > > 192.168.12.165 is eth1 Openser Address > > 192.168.12.106 is Asterisk address > > 82.187.X.X is Openser public address > > Network 192.168.40.X is not reachable from net 192.168.12.X > > > > <-- SIP read from 192.168.40.68:5060: REGISTER sip:192.168.12.106 > > SIP/2.0 // 12.106 is Asterisk address > > Via: SIP/2.0/UDP 82.187.X.X;branch=z9hG4bKfe0f.21364c47.0 Via: > > SIP/2.0/UDP > > 192.168.40.254:2660 > ;rport=2265;received=82.187.Y.Ybranch=z9hG4bK532058BAC7C544E0961E038CC29B2106 > > > > From: Cfadda <sip:225@82.187.90.68 <sip%3A225(a)82.187.90.68> > >;tag=3189722840 > > To: Cfadda <sip:225@82.187.90.68 <sip%3A225(a)82.187.90.68>> > > Contact: "Cfadda" <sip:225@192.168.40.254:2660> > > Call-ID: 487DA353295C484FA58B2FB1464A2210(a)82.187.X.X > > CSeq: 65140 REGISTER > > Expires: 1800 > > Max-Forwards: 69 > > User-Agent: X-PRO release 1105x > > Content-Length: 0 > > > > > > Nov 5 10:37:28 VERBOSE[23848] logger.c: --- (12 headers 0 lines) -- > > - > > Nov 5 10:37:28 VERBOSE[23848] logger.c: Using latest REGISTER > > request > > as basis request > > Nov 5 10:37:28 VERBOSE[23848] logger.c: Sending to 82.187.X.X : > > 5060 > > (non-NAT) > > Nov 5 10:37:28 VERBOSE[23848] logger.c: Transmitting (NAT) to > > 192.168.40.68:5060: > > SIP/2.0 100 Trying > > Via: SIP/2.0/UDP 82.187.X.X > > ;branch=z9hG4bKfe0f.21364c47.0;received=192.168.40.68 > > Via: SIP/2.0/UDP > > 192.168.40.254:2660 > ;rport=2265;received=82.187.Y.Y;branch=z9hG4bK532058BAC7C544E0961E038CC29B2106 > > > > From: Cfadda <sip:225@82.187.90.68 <sip%3A225(a)82.187.90.68> > >;tag=3189722840 > > To: Cfadda <sip:225@82.187.X.X > > > Call-ID: 487DA353295C484FA58B2FB1464A2210(a)82.187.X.X > > CSeq: 65140 REGISTER > > User-Agent: Asterisk PBX > > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY > > Contact: <sip:225@192.168.12.106 <sip%3A225(a)192.168.12.106>> > > Content-Length: 0 > > > > > > --- > > Nov 5 10:37:28 VERBOSE[23848] logger.c: Transmitting (NAT) to > > 192.168.40.68:5060: > > SIP/2.0 401 Unauthorized > > Via: SIP/2.0/UDP 82.187.X.X > > ;branch=z9hG4bKfe0f.21364c47.0;received=192.168.40.68 > > Via: SIP/2.0/UDP > > 192.168.40.254:2660 > ;rport=2265;received=82.187.Y.Y;branch=z9hG4bK532058BAC7C544E0961E038CC29B2106 > > > > From: Cfadda <sip:225@82.187.X.X >;tag=3189722840 > > To: Cfadda <sip:225@82.187.X.X >;tag=as4c420a53 > > Call-ID: 487DA353295C484FA58B2FB1464A2210(a)82.187.X.X > > CSeq: 65140 REGISTER > > User-Agent: Asterisk PBX > > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY > > WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", > > nonce="05f14a3e"Content-Length: 0 > > > > So asterisk sends response to the wrong interface. > > > > How can I solve this? > > > > Thanks in advance, > > > > C. > > > > _______________________________________________ > > Users mailing list > > Users(a)lists.kamailio.org > > http://lists.kamailio.org/cgi-bin/mailman/listinfo/users > > > >

1 0

[Kamailio-Users] Fwd: Openser as Proxy and Asterisk as Registrar
by Cosimo Fadda 06 Nov '08

06 Nov '08

Hi Daniel, I'll try to use the force_send_sock function, maybe this solve the issue; btw I don't think it is a strictly Asterisk related problem, thank you for the hint, C. 2008/11/5, Daniel-Constantin Mierla <miconda(a)gmail.com>: > > Hello, > > On 11/05/08 16:36, Cosimo Fadda wrote: > >> Hi everybody >> I'd like to implement this scenario: >> >> ----------- ------------------- --------------- >> | GW/FW |<----LAN1---->|eth0|Openser|eth1|<----LAN2---->|eth0|asterisk| >> -->PSTN >> ----------- ------------------- | --------------- >> |_______________________________________________| >> >> >> >> Where: >> - Openser is reachable from the outside with a public IP forwarded to >> eth0 private address; >> >> - Asterisk is connected to Openser using another separated LAN >> - Openser acts as proxy (for requests coming from the outside) and >> Asterisk act as registrar and gateway. >> >> >> This is the description, now the questions: >> -since opneser has two different nics, how can configure it to properly >> send register request to asterisk? >> >> > if you want to force an interface for outgoing sip requests, see > force_send_sock() function: > > http://www.kamailio.org/dokuwiki/doku.php/core-cookbook:1.4.x#force_send_so… > > This is what currently happens: >> 192.168.40.68:5060: is eth0 Openser Address >> 192.168.12.165 is eth1 Openser Address >> 192.168.12.106 is Asterisk address >> 82.187.X.X is Openser public address >> Network 192.168.40.X is not reachable from net 192.168.12.X >> >> <-- SIP read from 192.168.40.68:5060: REGISTER sip:192.168.12.106SIP/2.0 // 12.106 is Asterisk address >> Via: SIP/2.0/UDP 82.187.X.X;branch=z9hG4bKfe0f.21364c47.0 Via: SIP/2.0/UDP >> 192.168.40.254:2660;rport=2265;received=82.187.Y.Ybranch=z9hG4bK532058BAC7C544E0961E038CC29B2106 >> >> From: Cfadda <sip:225@82.187.90.68 <sip%3A225(a)82.187.90.68> >> >;tag=3189722840 >> To: Cfadda <sip:225@82.187.90.68 <sip%3A225(a)82.187.90.68>> >> Contact: "Cfadda" <sip:225@192.168.40.254:2660> >> Call-ID: 487DA353295C484FA58B2FB1464A2210(a)82.187.X.X >> CSeq: 65140 REGISTER >> Expires: 1800 >> Max-Forwards: 69 >> User-Agent: X-PRO release 1105x >> Content-Length: 0 >> >> >> Nov 5 10:37:28 VERBOSE[23848] logger.c: --- (12 headers 0 lines) --- >> Nov 5 10:37:28 VERBOSE[23848] logger.c: Using latest REGISTER request as >> basis request >> Nov 5 10:37:28 VERBOSE[23848] logger.c: Sending to 82.187.X.X : 5060 >> (non-NAT) >> Nov 5 10:37:28 VERBOSE[23848] logger.c: Transmitting (NAT) to >> 192.168.40.68:5060: >> SIP/2.0 100 Trying >> Via: SIP/2.0/UDP 82.187.X.X ;branch=z9hG4bKfe0f.21364c47.0;received= >> 192.168.40.68 >> Via: SIP/2.0/UDP 192.168.40.254:2660;rport=2265;received=82.187.Y.Y;branch=z9hG4bK532058BAC7C544E0961E038CC29B2106 >> >> From: Cfadda <sip:225@82.187.90.68 <sip%3A225(a)82.187.90.68> >> >;tag=3189722840 >> To: Cfadda <sip:225@82.187.X.X > >> Call-ID: 487DA353295C484FA58B2FB1464A2210(a)82.187.X.X >> CSeq: 65140 REGISTER >> User-Agent: Asterisk PBX >> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY >> Contact: <sip:225@192.168.12.106 <sip%3A225(a)192.168.12.106>> >> Content-Length: 0 >> >> >> --- >> Nov 5 10:37:28 VERBOSE[23848] logger.c: Transmitting (NAT) to >> 192.168.40.68:5060: >> SIP/2.0 401 Unauthorized >> Via: SIP/2.0/UDP 82.187.X.X ;branch=z9hG4bKfe0f.21364c47.0;received= >> 192.168.40.68 >> Via: SIP/2.0/UDP 192.168.40.254:2660;rport=2265;received=82.187.Y.Y;branch=z9hG4bK532058BAC7C544E0961E038CC29B2106 >> >> From: Cfadda <sip:225@82.187.X.X >;tag=3189722840 >> To: Cfadda <sip:225@82.187.X.X >;tag=as4c420a53 >> Call-ID: 487DA353295C484FA58B2FB1464A2210(a)82.187.X.X >> CSeq: 65140 REGISTER >> User-Agent: Asterisk PBX >> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY >> WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="05f14a3e" >> Content-Length: 0 >> >> So asterisk sends response to the wrong interface. >> >> How can I solve this? >> >> > > Probably the right answer you will get on the asterisk mailing lists. > > Cheers, > Daniel > > -- > Daniel-Constantin Mierla > http://www.asipto.com > >

1 0

[Kamailio-Users] reminder: irc devel meeting in 1h20
by Daniel-Constantin Mierla 06 Nov '08

06 Nov '08

Hello, just a quick reminder about the irc devel meeting: - channel: #kamailio - server: irc.freenode.net - time: 15:00UTC Deatils and agenda: http://www.kamailio.org/dokuwiki/doku.php/development:irc-meeting-agenda-dr… Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

1 0

Re: [Kamailio-Users] SER/Asterisk interworking mailing list
by luzango mfupe 06 Nov '08

06 Nov '08

Hi Alex,This is good news coming from you!!! Yes We Can....!!! Rgds, Lu. On Wed, Nov 5, 2008 at 7:48 PM, <users-request(a)lists.kamailio.org> wrote: > Send Users mailing list submissions to > users(a)lists.kamailio.org > > > 5. SER/Asterisk interworking mailing list. (Alex Balashov) > > > Message: 5 > Date: Wed, 05 Nov 2008 12:04:32 -0500 > From: Alex Balashov <abalashov(a)evaristesys.com> > Subject: [Kamailio-Users] SER/Asterisk interworking mailing list. > To: Asterisk Users Mailing List - Non-Commercial Discussion > <asterisk-users(a)lists.digium.com>, Commercial and > Business-Oriented > Asterisk Discussion <asterisk-biz(a)lists.digium.com>, users > <users(a)lists.kamailio.org>, openser users < > users(a)lists.opensips.org> > Message-ID: <4911D220.1040506(a)evaristesys.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Greetings, > > As a developer and consultant who spends considerable time on projects > involving the fusion of Asterisk and products derived from the SER > ecosystem (OpenSER, Kamailio, OpenSIPS, the new SIP-Router), I have > found that there is a great volume of interest in this topic on the > mailing lists associated with all communities involved, but a > comparative lack of focus that results in duplicated effort and lack of > specialised response. > > This is mainly due, I think, to the fact that detailed Asterisk > experience - while common - is not a prerequisite for working with the > SER products, while for Asterisk people SER can often be a next step in > scalability and VoIP service delivery platform enhancement that they are > just getting into. And so on. There's pollution in the respective > discursive spaces; a lot of Asterisk people posting to the SER lists > ask a lot of Asterisk-specific questions in addition to any they may > have about SER which can be construed as potentially off-topic by some > members, and the opposite is true on the Asterisk lists when detailed, > involved discussion about SER occurs. > > We need to capture that discussion that exists at the overlap and is > specifically concerned with making these two systems work together, > requiring somewhat detailed and esoteric understanding of both and a > community of user support and knowledge that focuses on both of these > conceptual and product universes. > > Toward that end, I am hosting a new mailing list with this succinct > purpose, if slightly unwieldy name, and encourage all interested to > join. It is called 'SER-Asterisk-Interwork' and can be accessed for > subscription here: > > http://lists.evaristesys.com/mailman/listinfo/ser-asterisk-interwork > > The archives are available here: > > http://lists.evaristesys.com/pipermail/ser-asterisk-interwork/ > > You can post to the list at: > > ser-asterisk-interwork(a)lists.evaristesys.com > > It's the same GNU Mailman stuff you are already used to. > > While it could be argued that this cross-product discussion is valuable > to retain in both communities, I think there is considerable benefit to > creating a specialised mailing list that focuses specifically on this > integration path and the unique interoperation and configuration issues > it creates. I think it would be good to get some of this discussion off > of the SER and Asterisk-specific mailing lists where it has somewhat > marginal relevance at times and refocus it. If you agree and are > interested in this topic, you are invited to join the list. > > One last note: The SER/OpenSER community has been in a state of flux > recently, with OpenSER undergoing a name change to Kamailio and > subsequently seeing a fork. The incumbent Kamailio project is now > in the process of merging with the original SER project. The choice of > nomenclature for list is not meant to imply an endorsement of or > affinity for the IPTel SER project per se. It is just that right now it > serves the aim of terseness to use a common denominator, to refer to > this family of projects as the "SER ecosystem." Whether you are a SER, > OpenSER, Kamailio, or OpenSIPS user, you are part of that "SER > ecosystem." That is why the list is named what it is. > > Thank you, > > -- Alex > > -- > Alex Balashov > Evariste Systems > Web : http://www.evaristesys.com/ > Tel : (+1) (678) 954-0670 > Direct : (+1) (678) 954-0671 > Mobile : (+1) (706) 338-8599 > > > > ------------------------------ > > _______________________________________________ > Users mailing list > Users(a)lists.kamailio.org > http://lists.kamailio.org/cgi-bin/mailman/listinfo/users > > > End of Users Digest, Vol 42, Issue 15 > ************************************* > -- Luzango Mfupe TUUNE MOBILE Tel:0128440528/0123825710 Tshwane-RSA "...Ships are safe in harbor, but they were never meant to stay there......."

1 0

Re: [Kamailio-Users] Is it possible to break a "if" stament?
by ingdavidcespedes＠cable.net.co 06 Nov '08

06 Nov '08

----- Mensaje original ----- De: Iñaki Baz Castillo <ibc(a)aliax.net> Fecha: Miércoles, Noviembre 5, 2008 6:50 pm Asunto: [Kamailio-Users] Is it possible to break a "if" stament? > Hi, is it possible to break the body of an "if"? something like: > > -------------- > if $fU == "alice" { > xlog "hello"; > break; > xlog "bye"; > } > xlog "this is after the 'if'" > -------------- > > So the result would be: > > ------- > hello > this is after the 'if' > ------- > > Is it possible? > Not, you can't do brake inside an If, only for Switch. Why don't you do if $fU == "alice" { xlog "hello"; } else{ xlog "bye"; } xlog "this is after the 'if'" > -- > Iñaki Baz Castillo > > _______________________________________________ > Users mailing list > Users(a)lists.kamailio.org > http://lists.kamailio.org/cgi-bin/mailman/listinfo/users >

2 1

[Kamailio-Users] high processing delay
by Fabian Borot 06 Nov '08

06 Nov '08

hello All my Register request take longer than normal to process, what I mean is that an UAC sends a Register and kamailio responds almost 0.5 secs later, causing the UAC to re-transmit its request several times 0.000000 192.168.10.10 -> 192.168.1.20 SIP Request: REGISTER sip:192.168.1.20 0.469256 192.168.1.20 -> 192.168.10.10 SIP Status: 401 Unauthorized (0 bindings) 0.518263 192.168.10.10 -> 192.168.1.20 SIP Request: REGISTER sip:192.168.1.20 0.628294 192.168.10.10 -> 192.168.1.20 SIP Request: REGISTER sip:192.168.1.20 1.130722 192.168.10.10 -> 192.168.1.20 SIP Request: REGISTER sip:192.168.1.20 1.269301 192.168.1.20 -> 192.168.10.10 SIP Status: 401 Unauthorized (0 bindings) 2.224942 192.168.10.10 -> 192.168.1.20 SIP Request: REGISTER sip:192.168.1.20 2.325358 192.168.1.20 -> 192.168.10.10 SIP Status: 200 OK (1 bindings) 3.457509 192.168.1.20 -> 192.168.10.10 SIP Status: 200 OK (1 bindings) 4.497532 192.168.1.20 -> 192.168.10.10 SIP Status: 200 OK (1 bindings) the cpu shows almost 100 % idle at that time and the pc were kamailio is running has nothing else running but kamailio. this is my config file: ####### Routing Logic ######## # main request routing logic route{ # initial sanity checks -- messages with # max_forwards==0, or excessively long requests xlog("L_DBG", "mylog, time [$Tf] : starting_main_logic.\n"); if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); xlog("L_DGB","mylog, time [$Tf] : Too Many Hops.\n"); exit; }; if (msg:len >= 2048 ) { sl_send_reply("513", "Message too big"); xlog("L_DGB","mylog, time [$Tf] : Message too big.\n"); exit; }; if (!method=="REGISTER") record_route(); if (loose_route()) { # mark routing logic in request append_hf("P-hint: rr-enforced\r\n"); route(1); }; if (uri==myself) { if (method=="REGISTER") { xlog("L_DGB","mylog, time [$Tf] : starting to process REGISTER.Info: [$au,$ad,$ci,$ct,$cs,$rd,$si,$sp].\n"); if (!www_authorize("", "subscriber")) { xlog("L_DGB","mylog, time [$Tf] : REGISTER came without auth, sending challenge.\n"); www_challenge("", "0"); exit; }; save("location"); xlog("L_DBG","mylog, time [$Tf] : save-location successful.\n"); exit; }; if (!lookup("location")) { sl_send_reply("404", "Not Found"); xlog("L_DGB","mylog, time [$Tf] : lookup-location failed, sending 404 Not Found.\n"); exit; }; append_hf("P-hint: usrloc applied\r\n"); }; route(1); } route[1] { if (!t_relay()) { sl_reply_error(); }; exit; } _________________________________________________________________ Stay up to date on your PC, the Web, and your mobile phone with Windows Live http://clk.atdmt.com/MRT/go/119462413/direct/01/

3 2

[Kamailio-Users] Is it possible to break a "if" stament?
by Iñaki Baz Castillo 05 Nov '08

05 Nov '08

Hi, is it possible to break the body of an "if"? something like: -------------- if $fU == "alice" { xlog "hello"; break; xlog "bye"; } xlog "this is after the 'if'" -------------- So the result would be: ------- hello this is after the 'if' ------- Is it possible? -- Iñaki Baz Castillo

1 0

Re: [Kamailio-Users] high processing delay
by Daniel-Constantin Mierla 05 Nov '08

05 Nov '08

On 11/05/08 20:15, Fabian Borot wrote: > debug was set to 9, I commented that line out and now it is fine: ok > > > 0.000000 192.168.10.10 -> 192.168.1.20 SIP Request: REGISTER > sip:192.168.1.20 > 0.001650 192.168.1.20 -> 192.168.10.10 SIP Status: 401 > Unauthorized (0 bindings) > 0.191670 192.168.10.10 -> 192.168.1.20 SIP Request: REGISTER > sip:192.168.1.20 > 0.192518 192.168.1.20 -> 192.168.10.10 SIP Status: 200 OK (1 > bindings) > > but how can I check about this "syslog set to asynchronous mode" ? check your syslog.conf or so, depends on you distribution. Probably the safest is to check the manual, the usual way for old versions of syslog was to put a - (dash) in front of the file for logging. Cheers, Daniel > > regards > fabian > > > > > > Date: Wed, 5 Nov 2008 19:37:35 +0200 > > From: miconda(a)gmail.com > > To: fborot(a)hotmail.com > > CC: users(a)lists.kamailio.org > > Subject: Re: [Kamailio-Users] high processing delay > > > > hello, > > > > what is the debug level? is you syslog set to asynchronous mode? > > > > Cheers, > > Daniel > > > > > > On 11/05/08 17:43, Fabian Borot wrote: > > > hello > > > > > > All my Register request take longer than normal to process, what I > > > mean is that an UAC sends a Register and kamailio responds almost 0.5 > > > secs later, causing the UAC to re-transmit its request several times > > > > > > 0.000000 192.168.10.10 -> 192.168.1.20 SIP Request: REGISTER > > > sip:192.168.1.20 > > > 0.469256 192.168.1.20 -> 192.168.10.10 SIP Status: 401 > > > Unauthorized (0 bindings) > > > 0.518263 192.168.10.10 -> 192.168.1.20 SIP Request: REGISTER > > > sip:192.168.1.20 > > > 0.628294 192.168.10.10 -> 192.168.1.20 SIP Request: REGISTER > > > sip:192.168.1.20 > > > 1.130722 192.168.10.10 -> 192.168.1.20 SIP Request: REGISTER > > > sip:192.168.1.20 > > > 1.269301 192.168.1.20 -> 192.168.10.10 SIP Status: 401 > > > Unauthorized (0 bindings) > > > 2.224942 192.168.10.10 -> 192.168.1.20 SIP Request: REGISTER > > > sip:192.168.1.20 > > > 2.325358 192.168.1.20 -> 192.168.10.10 SIP Status: 200 OK (1 > > > bindings) > > > 3.457509 192.168.1.20 -> 192.168.10.10 SIP Status: 200 OK (1 > > > bindings) > > > 4.497532 192.168.1.20 -> 192.168.10.10 SIP Status: 200 OK (1 > > > bindings) > > > > > > > > > the cpu shows almost 100 % idle at that time and the pc were kamailio > > > is running has nothing else running but kamailio. this is my > config file: > > > > > > > > > > > > ####### Routing Logic ######## > > > > > > > > > # main request routing logic > > > > > > > > > route{ > > > # initial sanity checks -- messages with > > > # max_forwards==0, or excessively long requests > > > xlog("L_DBG", "mylog, time [$Tf] : starting_main_logic.\n"); > > > if (!mf_process_maxfwd_header("10")) { > > > sl_send_reply("483","Too Many Hops"); > > > xlog("L_DGB","mylog, time [$Tf] : Too Many Hops.\n"); > > > exit; > > > }; > > > > > > if (msg:len >= 2048 ) { > > > sl_send_reply("513", "Message too big"); > > > xlog("L_DGB","mylog, time [$Tf] : Message too big.\n"); > > > exit; > > > }; > > > > > > > > > if (!method=="REGISTER") > > > record_route(); > > > > > > if (loose_route()) { > > > # mark routing logic in request > > > append_hf("P-hint: rr-enforced\r\n"); > > > route(1); > > > }; > > > > > > > > > if (uri==myself) { > > > if (method=="REGISTER") { > > > xlog("L_DGB","mylog, time [$Tf] : starting to > > > process REGISTER.Info: [$au,$ad,$ci,$ct,$cs,$rd,$si,$sp].\n"); > > > if (!www_authorize("", "subscriber")) { > > > xlog("L_DGB","mylog, time [$Tf] : REGISTER > > > came without auth, sending challenge.\n"); > > > www_challenge("", "0"); > > > exit; > > > }; > > > save("location"); > > > xlog("L_DBG","mylog, time [$Tf] : save-location successful.\n"); > > > exit; > > > }; > > > > > > > > > if (!lookup("location")) { > > > sl_send_reply("404", "Not Found"); > > > xlog("L_DGB","mylog, time [$Tf] : lookup-location > > > failed, sending 404 Not Found.\n"); > > > exit; > > > }; > > > append_hf("P-hint: usrloc applied\r\n"); > > > }; > > > route(1); > > > } > > > > > > route[1] { > > > if (!t_relay()) { > > > sl_reply_error(); > > > }; > > > exit; > > > } > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > Stay up to date on your PC, the Web, and your mobile phone with > > > Windows Live Click here > > > <http://clk.atdmt.com/MRT/go/119462413/direct/01/> > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > Users mailing list > > > Users(a)lists.kamailio.org > > > http://lists.kamailio.org/cgi-bin/mailman/listinfo/users > > > > > > > -- > > Daniel-Constantin Mierla > > http://www.asipto.com > > > > ------------------------------------------------------------------------ > Color coding for safety: Windows Live Hotmail alerts you to suspicious > email. Sign up today. > <http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_safety…> -- Daniel-Constantin Mierla http://www.asipto.com

1 0

[Kamailio-Users] Openser as Proxy and Asterisk as Registrar
by Cosimo Fadda 05 Nov '08

05 Nov '08

Hi everybody I'd like to implement this scenario: ----------- ------------------- --------------- | GW/FW |<----LAN1---->|eth0|Openser|eth1|<----LAN2---->|eth0|asterisk| -->PSTN ----------- ------------------- | --------------- |_______________________________________________| Where: - Openser is reachable from the outside with a public IP forwarded to eth0 private address; - Asterisk is connected to Openser using another separated LAN - Openser acts as proxy (for requests coming from the outside) and Asterisk act as registrar and gateway. This is the description, now the questions: -since opneser has two different nics, how can configure it to properly send register request to asterisk? This is what currently happens: 192.168.40.68:5060: is eth0 Openser Address 192.168.12.165 is eth1 Openser Address 192.168.12.106 is Asterisk address 82.187.X.X is Openser public address Network 192.168.40.X is not reachable from net 192.168.12.X <-- SIP read from 192.168.40.68:5060: REGISTER sip:192.168.12.106 SIP/2.0 // 12.106 is Asterisk address Via: SIP/2.0/UDP 82.187.X.X;branch=z9hG4bKfe0f.21364c47.0 Via: SIP/2.0/UDP 192.168.40.254:2660;rport=2265;received=82.187.Y.Ybranch=z9hG4bK532058BAC7C544E0961E038CC29B2106 From: Cfadda <sip:225@82.187.90.68>;tag=3189722840 To: Cfadda <sip:225@82.187.90.68> Contact: "Cfadda" <sip:225@192.168.40.254:2660> Call-ID: 487DA353295C484FA58B2FB1464A2210(a)82.187.X.X CSeq: 65140 REGISTER Expires: 1800 Max-Forwards: 69 User-Agent: X-PRO release 1105x Content-Length: 0 Nov 5 10:37:28 VERBOSE[23848] logger.c: --- (12 headers 0 lines) --- Nov 5 10:37:28 VERBOSE[23848] logger.c: Using latest REGISTER request as basis request Nov 5 10:37:28 VERBOSE[23848] logger.c: Sending to 82.187.X.X : 5060 (non-NAT) Nov 5 10:37:28 VERBOSE[23848] logger.c: Transmitting (NAT) to 192.168.40.68:5060: SIP/2.0 100 Trying Via: SIP/2.0/UDP 82.187.X.X ;branch=z9hG4bKfe0f.21364c47.0;received=192.168.40.68 Via: SIP/2.0/UDP 192.168.40.254:2660;rport=2265;received=82.187.Y.Y;branch=z9hG4bK532058BAC7C544E0961E038CC29B2106 From: Cfadda <sip:225@82.187.90.68>;tag=3189722840 To: Cfadda <sip:225@82.187.X.X > Call-ID: 487DA353295C484FA58B2FB1464A2210(a)82.187.X.X CSeq: 65140 REGISTER User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Contact: <sip:225@192.168.12.106> Content-Length: 0 --- Nov 5 10:37:28 VERBOSE[23848] logger.c: Transmitting (NAT) to 192.168.40.68:5060: SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP 82.187.X.X ;branch=z9hG4bKfe0f.21364c47.0;received=192.168.40.68 Via: SIP/2.0/UDP 192.168.40.254:2660;rport=2265;received=82.187.Y.Y;branch=z9hG4bK532058BAC7C544E0961E038CC29B2106 From: Cfadda <sip:225@82.187.X.X >;tag=3189722840 To: Cfadda <sip:225@82.187.X.X >;tag=as4c420a53 Call-ID: 487DA353295C484FA58B2FB1464A2210(a)82.187.X.X CSeq: 65140 REGISTER User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="05f14a3e" Content-Length: 0 So asterisk sends response to the wrong interface. How can I solve this? Thanks in advance, C.

2 1

[Serusers] DNS failover
by Nuno Ribeiro 05 Nov '08

05 Nov '08

Hi all, I have a scenario where I was testing DNS failover and this feature seems to fail. I will try to explain the scenario: I'm trying to establish a call between two user Agents, where one of the users has services associated (trigger to ASs) to the session establishment signaling (INVITE). So when SER makes the DNS query receives 2 ip addresses for this AS. The sip message will be correctly forwarded to one of this two entries and if in case of failure it will try to send the message to the next entry (second ip address). But when we are triggering to the AS we will add a route header and this header is not created in the second case, i.e. after DNS failover as the SIP INVITE will be created based in the SIP message received and not in the SIP message sent in the first place. So anyone has any thoughts about this question and a solution to it? Thanks in any advance. Best Regards -- Nuno Ribeiro

2 2

[Kamailio-Users] SER/Asterisk interworking mailing list.
by Alex Balashov 05 Nov '08

05 Nov '08

Greetings, As a developer and consultant who spends considerable time on projects involving the fusion of Asterisk and products derived from the SER ecosystem (OpenSER, Kamailio, OpenSIPS, the new SIP-Router), I have found that there is a great volume of interest in this topic on the mailing lists associated with all communities involved, but a comparative lack of focus that results in duplicated effort and lack of specialised response. This is mainly due, I think, to the fact that detailed Asterisk experience - while common - is not a prerequisite for working with the SER products, while for Asterisk people SER can often be a next step in scalability and VoIP service delivery platform enhancement that they are just getting into. And so on. There's pollution in the respective discursive spaces; a lot of Asterisk people posting to the SER lists ask a lot of Asterisk-specific questions in addition to any they may have about SER which can be construed as potentially off-topic by some members, and the opposite is true on the Asterisk lists when detailed, involved discussion about SER occurs. We need to capture that discussion that exists at the overlap and is specifically concerned with making these two systems work together, requiring somewhat detailed and esoteric understanding of both and a community of user support and knowledge that focuses on both of these conceptual and product universes. Toward that end, I am hosting a new mailing list with this succinct purpose, if slightly unwieldy name, and encourage all interested to join. It is called 'SER-Asterisk-Interwork' and can be accessed for subscription here: http://lists.evaristesys.com/mailman/listinfo/ser-asterisk-interwork The archives are available here: http://lists.evaristesys.com/pipermail/ser-asterisk-interwork/ You can post to the list at: ser-asterisk-interwork(a)lists.evaristesys.com It's the same GNU Mailman stuff you are already used to. While it could be argued that this cross-product discussion is valuable to retain in both communities, I think there is considerable benefit to creating a specialised mailing list that focuses specifically on this integration path and the unique interoperation and configuration issues it creates. I think it would be good to get some of this discussion off of the SER and Asterisk-specific mailing lists where it has somewhat marginal relevance at times and refocus it. If you agree and are interested in this topic, you are invited to join the list. One last note: The SER/OpenSER community has been in a state of flux recently, with OpenSER undergoing a name change to Kamailio and subsequently seeing a fork. The incumbent Kamailio project is now in the process of merging with the original SER project. The choice of nomenclature for list is not meant to imply an endorsement of or affinity for the IPTel SER project per se. It is just that right now it serves the aim of terseness to use a common denominator, to refer to this family of projects as the "SER ecosystem." Whether you are a SER, OpenSER, Kamailio, or OpenSIPS user, you are part of that "SER ecosystem." That is why the list is named what it is. Thank you, -- Alex -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599

1 0

[Kamailio-Users] Load userblacklist table to cache w/o restarting?
by Pablo Bertuzzi 05 Nov '08

05 Nov '08

Hello forum, I was wondering whether there is a fifo command or workaround to load the userblacklist table into memory without restarting. I have a large carrierroute table and it takes about 20 secs to start. best regards, PB

2 3

Re: [Kamailio-Users] rewriteuser with AVP
by Samuel Muller 05 Nov '08

05 Nov '08

Hello Ravi , i'm using radiator but not freeradius, actually my users are stored into an user flat file. here you can have an example of user : 0123452000(a)sip.720.fr User-Password = "2000" User-Name = "0123452000", Sip-User-ID = "0123452000", Sip-User-Realm = "sip.720.fr", Sip-URI-User = "0123452000(a)sip.720.fr", Sip-Rpid = "0123452000", Sip-Group = "full", Sip-AVP = "asserted_id:0123452000" and concerning services attributes, you have to declare them like this : => in kamailio.cfg (or openser.cfg, ser.cfg, opensips.cfg) : modparam("acc|auth_radius", "service_type", 15) modparam("avp_radius", "caller_service_type", 30) modparam("avp_radius", "callee_service_type", 31) if you're using peering module : modparam("peering", "verify_destination_service_type", 21) modparam("peering", "verify_source_service_type", 22) => in the radius dictionary (for radiusclient-ng, and the dictionary used by your radius server) ### Service-Type Values ### VALUE Service-Type Call-Check 10 # RFC2865, uri_radius VALUE Service-Type Group-Check 12 # Proprietary, group_radius VALUE Service-Type Sip-Session 15 # Schulzrinne, acc/auth radius VALUE Service-Type Sip-Verify-Destination 20 # Proprietary, peering VALUE Service-Type Sip-Verify-Source 21 # Proprietary, peering VALUE Service-Type Sip-Caller-AVPs 30 # Proprietary, avp_radius VALUE Service-Type Sip-Callee-AVPs 31 # Proprietary, avp_radius => then, in your radius server config, you must add one handler per service-type example for radiator, just a base config based on flat user file: <Handler Service-Type=Sip-Verify-Destination> RewriteUsername s/^sip:(.*)/$1/ <AuthBy FILE> NoCheckPassword Filename %D/user.peer NoDefault </AuthBy> </Handler> I can't help you actually for a radius DB, 'cause i'm working on it. cheers, .Sam. -- Samuel MULLER Ingénieur Reseaux & Telecom 720 DEGRES +33 (0)663 128 505 sml(a)720.fr On Wed, Nov 5, 2008 at 1:28 PM, LetMeKnow < sunkara.raviprakash.feb14(a)gmail.com> wrote: > Hello Samuel, > Can you check the radius services attributes > > is you using users.conf or radius databases. > > can see this url > http://www.kamailio.org/docs/openser-radius-1.0.x.html#freeradius_users > > > > Thanks &Regards > Ravi Prakash Sunkara > VoIP Architect & JAVA-SIP Developer > +91-9999882776 > > > 2008/11/5 Samuel Muller <sml(a)720.fr> > >> Hello all, >> >> I've a little question : >> I got a username in an AVP by avp_load_radius, and I would rewrite the uri >> with it. >> >> The objectives is to replace the r-uri by an ipbx uri, then forward the >> call to it by a new branch (to not loose the phone number requested). >> in this case : 0123452000 is behind a spa9000. The user 0123452000 has an >> AVP called "ipbx", that i'm using to do some groups and permissions (plus >> the rewrite). >> >> actually, it does not work, i tried many ways : >> >> # load radius attributes of the callee >> if (!avp_load_radius("callee")) >> { >> xlog("L_INFO","-> user unknown in radius usr db : $ru"); >> route(15); # route PSTN >> } >> >> # verify the AVPs we got (caller and callee) >> xlog("L_INFO", " -AVP------------------------------------- "); >> avp_print(); >> xlog("L_INFO", " ----------------------------------------- "); >> >> # callee is behind an ipbx (avp ipbx) ? >> if (is_avp_set("$avp(s:callee_ipbx)")) >> { >> xlog("L_INFO", "-> callee is behind an ipbx : >> $avp(s:callee_ipbx)"); >> setflag(14); # flag IPBX >> #subst_user('/$rU$/$avp(s:callee_ipbx)/'); >> #rewriteuri("sip:$avp(s:callee_ipbx)@$rd"**); >> rewriteuser($avp(s:callee_ipbx)); >> } >> >> # callee in usrloc ? >> if (lookup("location")) >> { >> append_hf("P-hint: usrloc applied\r\n"); >> xlog("L_INFO","-> registered user called : $tu"); >> route(7); # route FORWARD >> } >> else >> { >> xlog("L_INFO","-> 480: local user not found in usrloc : >> $tu"); >> sl_send_reply("480","Temporarily Unavailable"); >> drop; >> } >> >> and in the debugs log : >> >> Nov 5 13:04:51 ser0 kamailio[2930]: >> -ROUTE--INBOUND-------------------------- >> Nov 5 13:04:51 ser0 kamailio[2930]: DBG:avp_radius:load_avp_user: rc_auth >> Success >> Nov 5 13:04:51 ser0 kamailio[2930]: DBG:avp_radius:load_avp_user: AVP >> 'callee_asserted_id'/0='0123452000'/0 has been added >> Nov 5 13:04:51 ser0 kamailio[2930]: DBG:avp_radius:load_avp_user: AVP >> 'callee_ipbx'/0='spa9000'/0 has been added >> Nov 5 13:04:51 ser0 kamailio[2930]: >> -AVP------------------------------------- >> Nov 5 13:04:51 ser0 kamailio[2930]: INFO:avpops:ops_print_avp: >> p=0x7fb3d7e5cfe8, flags=0x0003 >> Nov 5 13:04:51 ser0 kamailio[2930]: INFO:avpops:ops_print_avp: >> ^I^I^Iname=<callee_ipbx> >> Nov 5 13:04:51 ser0 kamailio[2930]: INFO:avpops:ops_print_avp: >> ^I^I^Ival_str=<spa9000 / 7> >> Nov 5 13:04:51 ser0 kamailio[2930]: INFO:avpops:ops_print_avp: >> p=0x7fb3d7e5cf88, flags=0x0003 >> Nov 5 13:04:51 ser0 kamailio[2930]: INFO:avpops:ops_print_avp: >> ^I^I^Iname=<callee_asserted_id> >> Nov 5 13:04:51 ser0 kamailio[2930]: INFO:avpops:ops_print_avp: >> ^I^I^Ival_str=<0123452000 / 10> >> Nov 5 13:04:51 ser0 kamailio[2930]: INFO:avpops:ops_print_avp: >> p=0x7fb3d7e5ced8, flags=0x0003 >> Nov 5 13:04:51 ser0 kamailio[2930]: INFO:avpops:ops_print_avp: >> ^I^I^Iname=<caller_asserted_id> >> Nov 5 13:04:51 ser0 kamailio[2930]: INFO:avpops:ops_print_avp: >> ^I^I^Ival_str=<0123451011 / 10> >> Nov 5 13:04:51 ser0 kamailio[2930]: INFO:avpops:ops_print_avp: >> p=0x7fb3d7e5ce38, flags=0x0003 >> Nov 5 13:04:51 ser0 kamailio[2930]: >> ----------------------------------------- >> Nov 5 13:04:51 ser0 kamailio[2930]: -> callee is behind an ipbx : spa9000 >> Nov 5 13:04:51 ser0 kamailio[2930]: DBG:registrar:lookup: '$avp( >> s(a)sip.720.fr' Not found in usrloc >> Nov 5 13:04:51 ser0 kamailio[2930]: -> 480: local user not found in >> usrloc : sip:0123452000@sip.720.fr <sip%3A0123452000(a)sip.720.fr> >> Nov 5 13:04:51 ser0 kamailio[2930]: DBG:core:parse_headers: >> flags=ffffffffffffffff >> Nov 5 13:04:51 ser0 kamailio[2930]: DBG:core:check_via_address: params >> 77.246.81.162, 192.168.0.134, 0 >> Nov 5 13:04:51 ser0 kamailio[2930]: DBG:core:destroy_avp_list: destroying >> list 0x7fb3d7e5d040 >> Nov 5 13:04:51 ser0 kamailio[2930]: DBG:core:receive_msg: cleaning up >> >> >> -> But, if I did it by : >> >> if (uri =~ "^sip:012345200{1}") >> { >> rewriteuri("sip:spa9000@sip.720.fr<sip%3Aspa9000(a)sip.720.fr> >> "); >> } >> if (lookup("location")) >> { >> append_hf("P-hint: usrloc applied\r\n"); >> xlog("L_INFO","-> registered user called : $tu"); >> route(7); # route FORWARD >> } >> >> it works great, and the call is ok (the ipbx forward correctly the request >> the phone behind him). >> >> >> Anyone has an idea ? thanks in advance ! >> >> >> -- >> Samuel MULLER >> >> >> _______________________________________________ >> Users mailing list >> Users(a)lists.kamailio.org >> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users >> >> >

1 0

Re: [Kamailio-Users] Users Digest, Vol 42, Issue 11
by luzango mfupe 04 Nov '08

04 Nov '08

> 9. Re: the sip router project (Bogdan-Andrei Iancu) > > > Mmmh! guys, i am missing some points here, does this has anything to do > with OPENSIPS-YATE Collabo? a counter attack move of some sort??? > > > ------------------------------ > > Message: 9 > Date: Tue, 04 Nov 2008 17:24:15 +0200 > From: Bogdan-Andrei Iancu <bogdan(a)voice-system.ro> > Subject: Re: [Kamailio-Users] the sip router project > To: Johansson Olle E <oej(a)edvina.net> > Cc: devel <devel(a)lists.kamailio.org>, serusers(a)lists.iptel.org, > sr-dev(a)lists.sip-router.org, users <users(a)lists.kamailio.org>, SER > developer mailing list <serdev(a)iptel.org>, > business(a)lists.kamailio.org > Message-ID: <4910691F.9020509(a)voice-system.ro> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi Olle, > > Thank you for your thoughts. On a first view, it looks interesting, but I'm > missing some points here (important points): > > 1) as OpenSER was forked from SER because different views (and the OpenSER > view proved to be a very popular and successful one), I wonder > why, Kamilio is getting back to SER? not sharing any more the OpenSER view > as claimed? because such merging will definitely have a great > impact on the dynamical and openness of the projects (like releases, > contributions, driving the project) > > 2) this major change of perspective (at least for kamilio) was a backstage > decision, kept secret from the community - shouldn't be in the > interest of the community to say if going back to the roots (merging into > SER) is something wanted or not? it somehow contradicts the self > existence of OpenSER, right? > > 3) the benefits you mentions are mainly optimization of the internal > project activities and not optimizations of the outcome - what the > project will deliver. And I guess this is the most important. We already > went though the experience of large devel community, frameworks, etc but > with no outcome for more than 2 years... > > >From my personal perspective, the new project looks more like SER > absorbing Kamilio (considering the sizes, the companies behind each > project, the resources, and the man-power behind each project). > > And at the moment I would like preserve the OpenSER vision and to have an > open source project (a standalone one), far away from the "control" of any > Big Brother ;) > > Regards, > Bogdan > > > > Johansson Olle E wrote: > > Congratulations to both projects! > > > > I think this is very beneificial for both communities as well as for > > all the companies out there using the two products. > > > > I am very happy with this result and hope that the third kid in the > > SER family - OpenSIPS - will consider joining the effort too. > > > > Best regards, > > /Olle > > > > _______________________________________________ > > Users mailing list > > Users(a)lists.kamailio.org > > http://lists.kamailio.org/cgi-bin/mailman/listinfo/users > > > > > > > > > ------------------------------ > > _______________________________________________ > Users mailing list > Users(a)lists.kamailio.org > http://lists.kamailio.org/cgi-bin/mailman/listinfo/users > > > End of Users Digest, Vol 42, Issue 11 > ************************************* > -- Luzango Mfupe TUUNE MOBILE Tel:0128440528/0123825710 Tshwane-RSA "...Ships are safe in harbor, but they were never meant to stay there......."

2 1

[Kamailio-Users] the sip router project
by Daniel-Constantin Mierla 04 Nov '08

04 Nov '08

Hello Everybody, We are pleased to announce to you the SIP Router project. It aims to build a solid open source SIP routing platform, based on collaboration of the SIP Express Router (SER) and Kamailio (OpenSER) teams. Developers of these two projects believe that an united and non-conflicting environment will bring many benefits to them, community members and companies: * bring together the developers and user communities of both projects * reduce maintenance overhead * avoid duplicated efforts in development * develop a core framework that is flexible, extensible and scalable * promote and build a solid open source SIP server project * ensure business credibility * make future forking undesirable, this harms everybody, affects credibility and business You are welcome to join! Visit the web site at: http://sip-router.org There is a meeting in Karlsruhe, Germany, on Nov 10, 2008, hosted by 1&1, where the developers and community members have the chance to discuss and tune the last aspects of the new project. We are looking to see many of you there: http://sip-router.org/index.php/meeting/ We hope this is a great news for you, thanks to the effort of main developers and management teams of the two projects. We invite you to join the new mailing list for further discussions: http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev Daniel, Jiri Kamailio Management Team SER Management Team

13 20

[Kamailio-Users] Unknown column 'from_uri' in 'field list'
by Kaeman Chris 04 Nov '08

04 Nov '08

Hello, modparam("acc", "db_extra", "from_uri=$fu; to_uri=$tu") added 2 new fields in the acc table. Logs giving following errors while making calls Nov 4 07:14:11 [4567] ERROR:db_mysql:db_mysql_submit_query: driver error on query: Unknown column 'from_uri' in 'field list' Nov 4 07:14:11 [4567] ERROR:core:db_do_insert: error while submitting query Nov 4 07:14:11 [4567] ERROR:acc:acc_db_request: failed to insert into database Is this error due to the added fields? Thanks, KChris Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/

3 2

[Kamailio-Users] SER config file adaptation to Kamailio ?
by Samuel Muller 04 Nov '08

04 Nov '08

Hello all, I tried during one week to adapt my old SER configuration file (ser.cfg, for SER 2.0.0), who works really great, to Kamailio v1.4.2. I used to change all the stuff needed (many functions, onsend route, ... disappeared or was replaced, ...). That's ok, concepts are the same - registration are ok, NAT (seems to) works with rtpproxy, and I'm using radius server (Radiator). MySQL is only here to store locations, domains, and trusted stuff like gateways. Everything looks fine (load kamalio : no pbm, REGISTER, OPTIONS methods and SIP ping ok, ...) Right now, RTP does not work, and no SIP phone (linksys spa9xx, thomson st2030, ...) can't call - there's no ringing, even if all the sip phones are registered and known by OpenSER ... It seems OpenSER can't send the SIP requests to the callee ??? Did anyone had the same problem and resolved it ? Or, eventually anyone does have some config sample config file (as you can have in SER examples stuff) ? I would like to let here a debug log of a call from a linksys spa942 to a sjphone but it's a bit enormous (debug log + config file) ... so i let it in attached file. the scenario is : 0123451011 (sjphone) calls 0123451012 (linksys spa9xx) the 2 UACs are on the same LAN, through the same router, with the same realm. there're registered and are stored into the location table in mySQL. but the problem is present in all the case we can have (different realms, different WAN connections, different SIP UACs ...) Thanks in advance ! -- Samuel MULLER

2 2

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