sr-users

sr-users@lists.kamailio.org

19 participants
37571 discussions

[Kamailio-Users] Generating SIP /TLS Certificate
by Meftah Tayeb 17 Aug '09

17 Aug '09

hello all please how i can generate a certificate to do sip / tls? and how to configure my kamailio? try to help me please thanks __________ Information from ESET NOD32 Antivirus, version of virus signature database 4341 (20090817) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com

2 1

Re: [Kamailio-Users] presence_dialoginfo context
by David 17 Aug '09

17 Aug '09

Hey, I definitely have an exit(), but even if I didn't most of the message is changed, an exit would not change that would it? David Klaus Darilion wrote: > Very strange. > > Maybe exit(); is missing after t_relay() loop and both PUBLISHs are > processed? I think I forgot the exit() in the config snippet. > > Yes, on the server. And please attach the trace as attachment - inline > is difficult to read > > klaus > > David schrieb: >> Hey, >> >> Here is an expert from the /var/log/messsages : >> >> Aug 14 10:16:42 kamailio-dev /usr/sbin/kamailio[28924]: New request - >> M=PUBLISH RURI=sip:group1.105@mydomain.tld >> F=sip:group1.105@mydomain.tld T=sip:group1.105@mydomain.tld >> IP=72.55.182.125 ID=7bddec01-28924(a)72.55.182.125 >> Aug 14 10:16:42 kamailio-dev /usr/sbin/kamailio[28924]: Publish >> rewritten forwarded for ext=group1.105 >> ruri=sip:group1.105@mydomain.tld duri=<null> body=<?xml >> version="1.0"?> <dialog-info >> xmlns="urn:ietf:params:xml:ns:dialog-info" version="0" state="full" >> entity="sip:group1.105@mydomain.tld"> <dialog >> id="5a9207de129fc16f49cafaa425e312f1(a)mydomain.tld" >> call-id="5a9207de129fc16f49cafaa425e312f1(a)mydomain.tld" >> local-tag="4fbrxu9548" remote-tag="as4fb63283" >> direction="recipient"> <state>early</state> <remote> >> <identity>sip:103@mydomain.tld</identity> <target >> uri="sip:103@mydomain.tld"/> </remote> <local> >> <identity>sip:group1.105@mydomain.tld</identity> <target >> uri="sip:group1.105@mydomain.tld"/> </local> </dialog> >> </dialog-info> >> Aug 14 10:16:42 kamailio-dev /usr/sbin/kamailio[28932]: New request - >> M=PUBLISH RURI=sip:group1.105@mydomain.tld >> F=sip:group1.105@mydomain.tld T=sip:group1.105@mydomain.tld >> IP=72.55.182.125 ID=7bddec01-28924(a)72.55.182.125 >> Aug 14 10:16:42 kamailio-dev /usr/sbin/kamailio[28932]: Publish >> accepted for ext=group1.105 ruri=sip:group1.105@mydomain.tld >> duri=<null> body=<?xml version="1.0"?> <dialog-info >> xmlns="urn:ietf:params:xml:ns:dialog-info" version="0" state="full" >> entity="sip:105@mydomain.tld"> <dialog >> id="5a9207de129fc16f49cafaa425e312f1(a)mydomain.tld" >> call-id="5a9207de129fc16f49cafaa425e312f1(a)mydomain.tld" >> local-tag="4fbrxu9548" remote-tag="as4fb63283" >> direction="recipient"> <state>early</state> <remote> >> <identity>sip:103@mydomain.tld</identity> <target >> uri="sip:103@mydomain.tld"/> </remote> <local> >> <identity>sip:105@mydomain.tld</identity> <target >> uri="sip:105@mydomain.tld"/> </local> </dialog> </dialog-info> >> Aug 14 10:16:42 kamailio-dev /usr/sbin/kamailio[28932]: >> INFO:presence:send_notify_request: NOTIFY sip:group1.101@mydomain.tld >> via sip:group1.101@phone.ip:57234 on behalf of sip:105@mydomain.tld >> for event dialog >> >> But the phone's syslog shows this : >> >> Aug 14 10:16:21 linksys [0:57234]<<server.ip:5060 >> Aug 14 10:16:21 linksys [0:57234]<<server.ip:5060 >> Aug 14 10:16:21 linksys NOTIFY sip:group1.101@phone.ip:57234 >> SIP/2.0^M Via: SIP/2.0/UDP >> 72.55.182.125;branch=z9hG4bK0b0a.9725e23.0^M To: >> sip:group1.101@mydomain.tld;tag=1c32db3af4d889ac^M From: >> sip:105@mydomain.tld;tag=6d6077e15fecee48b2721a5e94bf8883-91a8^M >> CSeq: 12 NOTIFY^M Call-ID: 984d4cd2-37b04f4(a)192.168.1.104^M >> Content-Length: 655^M User-Agent: Kamailio (1.5.2-tls (i386/linux))^M >> Max-Forwards: 70^M Event: dialog^M Contact: <sip:mydomain.tld:5060>^M >> Subscription-State: active;expires=1470^M Content-Type: >> application/dialog-info+xml^M ^M <?xml version="1.0"?> <dialog-info >> xmlns="urn:ietf:params:xml:ns:dialog-info" version="11" >> state="full" entity="group1.105(a)mydomain.tld"> <dialog >> id="0b5776fb2ea599c429038414054eb383(a)mydomain.tld" >> call-id="0b5776fb2ea599c429038414054eb383(a)mydomain.tld" >> local-tag="loto7h3i9a" remote-tag="as4f284f05" >> direction="recipient"> <state>early</state> <remote> >> <identity>sip:103@mydomain.tld</identity> <target uri=" >> >> Everything is good, but notice the entity is somehow back to group1.105. >> >> Where do you want me to run the traceroute? On the server? >> >> David >> >> Klaus Darilion wrote: >>> >>> >>> David schrieb: >>>> Hey, >>>> >>>> I tried that, but it did not seem to change anything. I saw the >>>> message change on the second loop, but it seems that the presence >>>> module figure out my tactic and fixed the message. >>> >>> That's not possible. The presence module does not alter the received >>> body. I think the problem is somewhere else. >>> >>> Can you send me a trace? >>> >>> ngrep -t -P "" -W byline -d any port 5060 >>> >>> regards >>> klaus >>> >>> >>>> >>>> David >>>> >>>> Klaus Darilion wrote: >>>>> That does not work: presence_server always uses the original >>>>> received body, the modifications applied by you are not seen by >>>>> the presence server. >>>>> >>>>> The workaround would be to "loop" the modified PUBLISH to Kamailio >>>>> again, e.g.: >>>>> >>>>> listen=.......:5060 >>>>> listen=.......:5050 >>>>> >>>>> route{ >>>>> ... >>>>> if (is_method("PUBLISH")) { >>>>> if (dst_port==5060) { >>>>> subst_body('/group1[.]//'); >>>>> t_relay("udp:127.0.0.1:5050); >>>>> } else if (dst_port==5050) { >>>>> handle_publish(); >>>>> t_release(); >>>>> } >>>>> } >>>>> ... >>>>> } >>>>> >>>>> >>>>> klaus >>>>> David schrieb: >>>>>> Hey, >>>>>> >>>>>> I tried doing a subst or replace_body_all to change the entity="" >>>>>> value, >>>>>> >>>>>> if (is_method("PUBLISH") ) >>>>>> { >>>>>> subst_body('/group1[.]//'); >>>>>> handle_publish(); >>>>>> t_release(); >>>>>> } >>>>>> >>>>>> It did not work, the $rb variable still shows the old body and >>>>>> the NOTIFY received on the phone is the old body as well. >>>>>> >>>>>> I thought about doing a string replace on the outbound NOTIFY but >>>>>> it never hits my routing script, so I can't. >>>>>> >>>>>> I read textops and it does not list any limitations relating to me. >>>>>> >>>>>> Any ideas? >>>>>> >>>>>> David >>>>>> >>>>>> Klaus Darilion wrote: >>>>>>> I think the problem lies within the dialog module. Dialog module >>>>>>> stores from/to URI. Both, from and to URI are derived from the >>>>>>> headers. We could extend the dialog module to store request-URI >>>>>>> in the dialog-info structure too, and add an option to >>>>>>> pua_dialoginfo to use RURI instead of To-URI. >>>>>>> >>>>>>> regards >>>>>>> klaus >>>>>>> >>>>>>> David schrieb: >>>>>>>> Hey, >>>>>>>> >>>>>>>> I think I am doing something wrong, because here is the NOTIFY >>>>>>>> that comes to the phone : >>>>>>>> >>>>>>>> NOTIFY sip:group1.101@my.home.ip:57234 SIP/2.0 >>>>>>>> Via: SIP/2.0/UDP my.kamailio.ip;branch=z9hG4bK3cab.78e494a4.0 >>>>>>>> To: sip:group1.101@my.kamailio.domain.name;tag=b2514519391e8b4d >>>>>>>> From: >>>>>>>> sip:102@my.kamailio.domain.name;tag=6d6077e15fecee48b2721a5e94bf8883-f712 >>>>>>>> >>>>>>>> CSeq: 12 NOTIFY^M Call-ID: 24db3209-611c031d(a)192.168.1.104 >>>>>>>> Content-Length: 298 >>>>>>>> User-Agent: MyServer 1.0 >>>>>>>> Max-Forwards: 70 >>>>>>>> Event: dialog >>>>>>>> Contact: <sip:my.kamailio.domain.name:5060> >>>>>>>> Subscription-State: active;expires=1570 >>>>>>>> Content-Type: application/dialog-info+xml >>>>>>>> >>>>>>>> <?xml version="1.0"?> <dialog-info >>>>>>>> xmlns="urn:ietf:params:xml:ns:dialog-info" >>>>>>>> version="11" state="full" >>>>>>>> entity="group1.102(a)my.kamailio.domain.name"> <dialog >>>>>>>> id="7aaa32e84362a246716009175ad670be(a)domain.tld" >>>>>>>> direction="recipient"> <state>early</state> </dialog> >>>>>>>> </dialog-info> >>>>>>>> >>>>>>>> The phone ( I tested with a GXP2000, GXP2020 and SPA962 + >>>>>>>> SPA932) does not flash lights or anything. Since you suggested >>>>>>>> that a solid kamailio would work out of the box, I suspect that >>>>>>>> either I miscommunicated my setup or did something really >>>>>>>> wrong. The notify definitely gets to the phone and the phone >>>>>>>> replies 200/OK when it receives the NOTIFY. But I think that >>>>>>>> the telephone is not understanding the request because it >>>>>>>> subscribed to '102' but received a notification for >>>>>>>> 'group1.102'. The funny thing is, the From header matches the >>>>>>>> subscribe To header, it's just the XML has the full name >>>>>>>> instead of the shortened name. >>>>>>>> >>>>>>>> To: >>>>>>>> <sip:102@my.kamailio.domain.name>;tag=6d6077e15fecee48b2721a5e94bf8883-f712 >>>>>>>> >>>>>>>> >>>>>>>> I see this in my ( on kamailio ) /var/log/messages : >>>>>>>> >>>>>>>> Aug 13 09:55:24 kamailio-dev /usr/sbin/kamailio[25449]: >>>>>>>> INFO:presence:send_notify_request: NOTIFY >>>>>>>> sip:group1.101@my.kamailio.domain.name via >>>>>>>> sip:group1.101@my.home.ip.where.phone.is:57234 on behalf of >>>>>>>> sip:102@my.kamailio.domain.name for event dialog >>>>>>>> >>>>>>>> I should also mention that the NOTIFY sent out by presence >>>>>>>> bypasses my routing scripts. So I have the PUBLISH come through >>>>>>>> ( which I leave alone ) and the NOTIFY is sent according to the >>>>>>>> location table without ever consulting my routing script. >>>>>>>> >>>>>>>> So everything amazingly worked out well, except that the lights >>>>>>>> are not changing status which I think is related to the XML >>>>>>>> document dialog-info entity attribute containing the group >>>>>>>> name, sent from my server. >>>>>>>> >>>>>>>> Any ideas or suggestions ? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>> Other information : >>>>>>>> >>>>>>>> if ( is_method("SUBSCRIBE") ) >>>>>>>> { >>>>>>>> avp_db_query("select groupname from sometable ", >>>>>>>> "$avp(s:groupname)"); >>>>>>>> avp_printf("$ru", >>>>>>>> "sip:$avp(s:zone).$tU@my.kamailio.domain.name"); >>>>>>>> xlog("L_INFO", "Subscribe rewritten from $tU to >>>>>>>> $ru - M=$rm \n"); >>>>>>>> xlog("L_INFO", "Handling SUBSCRIBE - $fU - >>>>>>>> $avp(s:zone) - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); >>>>>>>> handle_subscribe(); >>>>>>>> t_release(); >>>>>>>> exit; >>>>>>>> } >>>>>>>> >>>>>>>> Kamailio compiled from sources : >>>>>>>> >>>>>>>> Path: /usr/src/kamailio >>>>>>>> URL: >>>>>>>> https://openser.svn.sourceforge.net/svnroot/openser/branches/1.5 >>>>>>>> Repository Root: >>>>>>>> https://openser.svn.sourceforge.net/svnroot/openser >>>>>>>> Repository UUID: 689a6050-402a-0410-94f2-e92a70836424 >>>>>>>> Revision: 5910 >>>>>>>> Node Kind: directory >>>>>>>> Schedule: normal >>>>>>>> Last Changed Author: henningw >>>>>>>> Last Changed Rev: 5910 >>>>>>>> Last Changed Date: 2009-08-06 13:08:30 -0400 (Thu, 06 Aug 2009) >>>>>>>> >>>>>>>> >>>>>>>> Klaus Darilion wrote: >>>>>>>>> notifies are generated by the presence module, based on the >>>>>>>>> subscription. So, there is nothing you have to do with NOTIFY. >>>>>>>>> Also PUBLISHs are created internally. Depending on your >>>>>>>>> concrete setup (e.g. format of the SIP user names) it should >>>>>>>>> work out of the box. >>>>>>>>> >>>>>>>>> klaus >>>>>>>>> >>>>>>>>> dlublink schrieb: >>>>>>>>>> What about the notifies? >>>>>>>>>> >>>>>>>>>> Klaus Darilion wrote: >>>>>>>>>>> dlublink wrote: >>>>>>>>>>>> Hello, >>>>>>>>>>>> >>>>>>>>>>>> I have three different groups of extensions on my kamailio >>>>>>>>>>>> I want to be able to separate them, so I prefixed a name to >>>>>>>>>>>> the extensions, so I have : >>>>>>>>>>>> >>>>>>>>>>>> 1. group1.101 >>>>>>>>>>>> 2. group1.102 >>>>>>>>>>>> 3. group2.101 >>>>>>>>>>>> 4. group2.102 >>>>>>>>>>>> 5. group3.102 >>>>>>>>>>>> 6. group3.103. >>>>>>>>>>>> >>>>>>>>>>>> The phones from different groups can not call each other, I >>>>>>>>>>>> found a pseudo variable that I use to rewrite the >>>>>>>>>>>> destination url, so if user group1.101 dials 102 I rewrite >>>>>>>>>>>> it to group1.102. >>>>>>>>>>>> >>>>>>>>>>>> I want to do the same thing for presence_dialog info, how >>>>>>>>>>>> can I rewrite the subscribe, presence and and notify >>>>>>>>>>>> messages to append the appropriate prefix ? >>>>>>>>>>> >>>>>>>>>>> Just apply the same rewrite you have already done for the >>>>>>>>>>> INVITE also for the SUBSCRIBE >>>>>>>>>>> >>>>>>>>>>> regards >>>>>>>>>>> klaus >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Kamailio (OpenSER) - Users mailing list >>>>>>>>>>>> Users(a)lists.kamailio.org >>>>>>>>>>>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users >>>>>>>>>>>> http://lists.openser-project.org/cgi-bin/mailman/listinfo/users >>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>> >>

2 1

[Serusers] 200 OK not being ACKnowledged
by Steven C. Blair 14 Aug '09

14 Aug '09

I'm testing SIP trunking connectivity to an ITSP through a Covergence (CXC)/ACME Packet session border controller. Calls from an IP phone to the PSTN through SER and the CXC are being dropped 15 seconds after the initial call is setup and just after a cal l is answered. We do not have this problem with calls which reach the PSTN via local gateways. It seems that SER is not relaying an ACK which it receives from the phone which causes the SBC to resend a 200 OK message until finally the connection times out. I've checked the call routing and do not see any issue however I do notice the following in the SER logs. Aug 13 13:07:24 vidar /usr/local/sbin/ser[19053]: [SER]: --ACK--: Time: [Thu Aug 13 13:07:24 2009] From: <sip:89390@vidar.net.isc.upenn.edu> To <sip:92155738396@vidar.net.isc.upenn.edu;user=phone> Src IP <128.91.2.223> Method:<ACK> Aug 13 13:07:24 vidar /usr/local/sbin/ser[19053]: [SER]: [Thu Aug 13 13:07:24 2009] [453a4bbf-90848c86-ea3a8091(a)128.91.56.18] <sip:92155738396@vidar.net.isc.upenn.edu:5060;user=phone;maddr=128.91.56.242;transport=udp> Starting PRESENCE/BLA section Aug 13 13:07:24 vidar /usr/local/sbin/ser[19053]: [SER]: [Thu Aug 13 13:07:24 2009] [453a4bbf-90848c86-ea3a8091(a)128.91.56.18] <sip:92155738396@vidar.net.isc.upenn.edu:5060;user=phone;maddr=128.91.56.242;transport=udp> End PRESENCE/BLA section Aug 13 13:07:24 vidar /usr/local/sbin/ser[19053]: [SER]: [Thu Aug 13 13:07:24 2009] [453a4bbf-90848c86-ea3a8091(a)128.91.56.18] --URI match--. Method: <ACK> R-uri: <sip:92155738396@vidar.net.isc.upenn.edu:5060;user=phone;maddr=128.91.56.242;transport=udp> Contact Header: <<sip:89390@128.91.56.18:5060>> From: <sip:89390@vidar.net.isc.upenn.edu> To <sip:92155738396@vidar.net.isc.upenn.edu;user=phone> IP source address <128.91.2.223> Aug 13 13:07:24 vidar /usr/local/sbin/ser[19053]: [SER]: --ACK--: Time: [Thu Aug 13 13:07:24 2009] From: <sip:89390@vidar.net.isc.upenn.edu> To <sip:92155738396@vidar.net.isc.upenn.edu;user=phone> Src IP <128.91.2.223> Method:<ACK> Aug 13 13:07:24 vidar /usr/local/sbin/ser[19053]: [SER]: Too many hops Aug 13 13:07:24 vidar /usr/local/sbin/ser[19053]: Warning: sl_send_reply: I won't send a reply for ACK!! User 89390 is a local subscriber and the phone initiating the call. The recipient of the call is my desk phone 215-573-8396 which is on a different, unrelated SER service. We do record_route traffic through SER for call control and accounting reasons. It seems like the ACK is looping through SER and therefore never being sent to the SBC but I cannot see why. Does anyone have any thoughts on this issue? Thanks,Steve

3 5

Re: [Kamailio-Users] presence_dialoginfo context
by David 14 Aug '09

14 Aug '09

Hey, Apparently the list did not accept the previous message... Here is the code you suggested with my modifications, it'll help put the log extracts in context : else if ( dst_port == 5060 ) { xlog("L_INFO", "Publish rewritten forwarded for ext=$tU ruri=$ru duri=$du body=$rb"); subst_body('/group1[.]//g' ) ; t_relay("udp:127.0.0.1:5050"); exit ; } else { xlog("L_INFO", "Publish accepted for ext=$tU ruri=$ru duri=$du body=$rb"); handle_publish(); t_release(); exit; } Here is an expert from the /var/log/messsages : Aug 14 10:16:42 kamailio-dev /usr/sbin/kamailio[28924]: New request - M=PUBLISH RURI=sip:group1.105@mydomain.tld F=sip:group1.105@mydomain.tld T=sip:group1.105@mydomain.tld IP=72.55.182.125 ID=7bddec01-28924(a)72.55.182.125 Aug 14 10:16:42 kamailio-dev /usr/sbin/kamailio[28924]: Publish rewritten forwarded for ext=group1.105 ruri=sip:group1.105@mydomain.tld duri=<null> body=<?xml version="1.0"?> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="0" state="full" entity="sip:group1.105@mydomain.tld"> <dialog id="5a9207de129fc16f49cafaa425e312f1(a)mydomain.tld" call-id="5a9207de129fc16f49cafaa425e312f1(a)mydomain.tld" local-tag="4fbrxu9548" remote-tag="as4fb63283" direction="recipient"> <state>early</state> <remote> <identity>sip:103@mydomain.tld</identity> <target uri="sip:103@mydomain.tld"/> </remote> <local> <identity>sip:group1.105@mydomain.tld</identity> <target uri="sip:group1.105@mydomain.tld"/> </local> </dialog> </dialog-info> Aug 14 10:16:42 kamailio-dev /usr/sbin/kamailio[28932]: New request - M=PUBLISH RURI=sip:group1.105@mydomain.tld F=sip:group1.105@mydomain.tld T=sip:group1.105@mydomain.tld IP=72.55.182.125 ID=7bddec01-28924(a)72.55.182.125 Aug 14 10:16:42 kamailio-dev /usr/sbin/kamailio[28932]: Publish accepted for ext=group1.105 ruri=sip:group1.105@mydomain.tld duri=<null> body=<?xml version="1.0"?> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="0" state="full" entity="sip:105@mydomain.tld"> <dialog id="5a9207de129fc16f49cafaa425e312f1(a)mydomain.tld" call-id="5a9207de129fc16f49cafaa425e312f1(a)mydomain.tld" local-tag="4fbrxu9548" remote-tag="as4fb63283" direction="recipient"> <state>early</state> <remote> <identity>sip:103@mydomain.tld</identity> <target uri="sip:103@mydomain.tld"/> </remote> <local> <identity>sip:105@mydomain.tld</identity> <target uri="sip:105@mydomain.tld"/> </local> </dialog> </dialog-info> Aug 14 10:16:42 kamailio-dev /usr/sbin/kamailio[28932]: INFO:presence:send_notify_request: NOTIFY sip:group1.101@mydomain.tld via sip:group1.101@phone.ip:57234 on behalf of sip:105@mydomain.tld for event dialog But the phone's syslog shows this : Aug 14 10:16:21 linksys [0:57234]<<server.ip:5060 Aug 14 10:16:21 linksys [0:57234]<<server.ip:5060 Aug 14 10:16:21 linksys NOTIFY sip:group1.101@phone.ip:57234 SIP/2.0^M Via: SIP/2.0/UDP 72.55.182.125;branch=z9hG4bK0b0a.9725e23.0^M To: sip:group1.101@mydomain.tld;tag=1c32db3af4d889ac^M From: sip:105@mydomain.tld;tag=6d6077e15fecee48b2721a5e94bf8883-91a8^M CSeq: 12 NOTIFY^M Call-ID: 984d4cd2-37b04f4(a)192.168.1.104^M Content-Length: 655^M User-Agent: Kamailio (1.5.2-tls (i386/linux))^M Max-Forwards: 70^M Event: dialog^M Contact: <sip:mydomain.tld:5060>^M Subscription-State: active;expires=1470^M Content-Type: application/dialog-info+xml^M ^M <?xml version="1.0"?> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="11" state="full" entity="group1.105(a)mydomain.tld"> <dialog id="0b5776fb2ea599c429038414054eb383(a)mydomain.tld" call-id="0b5776fb2ea599c429038414054eb383(a)mydomain.tld" local-tag="loto7h3i9a" remote-tag="as4f284f05" direction="recipient"> <state>early</state> <remote> <identity>sip:103@mydomain.tld</identity> <target uri=" Everything is good, but notice the entity is somehow back to group1.105. Where do you want me to run the traceroute? On the server? David Klaus Darilion wrote: > > > David schrieb: >> Hey, >> >> I tried that, but it did not seem to change anything. I saw the >> message change on the second loop, but it seems that the presence >> module figure out my tactic and fixed the message. > > That's not possible. The presence module does not alter the received > body. I think the problem is somewhere else. > > Can you send me a trace? > > ngrep -t -P "" -W byline -d any port 5060 > > regards > klaus > > >> >> David >> >> Klaus Darilion wrote: >>> That does not work: presence_server always uses the original >>> received body, the modifications applied by you are not seen by the >>> presence server. >>> >>> The workaround would be to "loop" the modified PUBLISH to Kamailio >>> again, e.g.: >>> >>> listen=.......:5060 >>> listen=.......:5050 >>> >>> route{ >>> ... >>> if (is_method("PUBLISH")) { >>> if (dst_port==5060) { >>> subst_body('/group1[.]//'); >>> t_relay("udp:127.0.0.1:5050); >>> } else if (dst_port==5050) { >>> handle_publish(); >>> t_release(); >>> } >>> } >>> ... >>> } >>> >>> >>> klaus >>> David schrieb: >>>> Hey, >>>> >>>> I tried doing a subst or replace_body_all to change the entity="" >>>> value, >>>> >>>> if (is_method("PUBLISH") ) >>>> { >>>> subst_body('/group1[.]//'); >>>> handle_publish(); >>>> t_release(); >>>> } >>>> >>>> It did not work, the $rb variable still shows the old body and the >>>> NOTIFY received on the phone is the old body as well. >>>> >>>> I thought about doing a string replace on the outbound NOTIFY but >>>> it never hits my routing script, so I can't. >>>> >>>> I read textops and it does not list any limitations relating to me. >>>> >>>> Any ideas? >>>> >>>> David >>>> >>>> Klaus Darilion wrote: >>>>> I think the problem lies within the dialog module. Dialog module >>>>> stores from/to URI. Both, from and to URI are derived from the >>>>> headers. We could extend the dialog module to store request-URI in >>>>> the dialog-info structure too, and add an option to pua_dialoginfo >>>>> to use RURI instead of To-URI. >>>>> >>>>> regards >>>>> klaus >>>>> >>>>> David schrieb: >>>>>> Hey, >>>>>> >>>>>> I think I am doing something wrong, because here is the NOTIFY >>>>>> that comes to the phone : >>>>>> >>>>>> NOTIFY sip:group1.101@my.home.ip:57234 SIP/2.0 >>>>>> Via: SIP/2.0/UDP my.kamailio.ip;branch=z9hG4bK3cab.78e494a4.0 >>>>>> To: sip:group1.101@my.kamailio.domain.name;tag=b2514519391e8b4d >>>>>> From: >>>>>> sip:102@my.kamailio.domain.name;tag=6d6077e15fecee48b2721a5e94bf8883-f712 >>>>>> >>>>>> CSeq: 12 NOTIFY^M Call-ID: 24db3209-611c031d(a)192.168.1.104 >>>>>> Content-Length: 298 >>>>>> User-Agent: MyServer 1.0 >>>>>> Max-Forwards: 70 >>>>>> Event: dialog >>>>>> Contact: <sip:my.kamailio.domain.name:5060> >>>>>> Subscription-State: active;expires=1570 >>>>>> Content-Type: application/dialog-info+xml >>>>>> >>>>>> <?xml version="1.0"?> <dialog-info >>>>>> xmlns="urn:ietf:params:xml:ns:dialog-info" version="11" >>>>>> state="full" entity="group1.102(a)my.kamailio.domain.name"> >>>>>> <dialog id="7aaa32e84362a246716009175ad670be(a)domain.tld" >>>>>> direction="recipient"> <state>early</state> </dialog> >>>>>> </dialog-info> >>>>>> >>>>>> The phone ( I tested with a GXP2000, GXP2020 and SPA962 + SPA932) >>>>>> does not flash lights or anything. Since you suggested that a >>>>>> solid kamailio would work out of the box, I suspect that either I >>>>>> miscommunicated my setup or did something really wrong. The >>>>>> notify definitely gets to the phone and the phone replies 200/OK >>>>>> when it receives the NOTIFY. But I think that the telephone is >>>>>> not understanding the request because it subscribed to '102' but >>>>>> received a notification for 'group1.102'. The funny thing is, the >>>>>> From header matches the subscribe To header, it's just the XML >>>>>> has the full name instead of the shortened name. >>>>>> >>>>>> To: >>>>>> <sip:102@my.kamailio.domain.name>;tag=6d6077e15fecee48b2721a5e94bf8883-f712 >>>>>> >>>>>> >>>>>> I see this in my ( on kamailio ) /var/log/messages : >>>>>> >>>>>> Aug 13 09:55:24 kamailio-dev /usr/sbin/kamailio[25449]: >>>>>> INFO:presence:send_notify_request: NOTIFY >>>>>> sip:group1.101@my.kamailio.domain.name via >>>>>> sip:group1.101@my.home.ip.where.phone.is:57234 on behalf of >>>>>> sip:102@my.kamailio.domain.name for event dialog >>>>>> >>>>>> I should also mention that the NOTIFY sent out by presence >>>>>> bypasses my routing scripts. So I have the PUBLISH come through ( >>>>>> which I leave alone ) and the NOTIFY is sent according to the >>>>>> location table without ever consulting my routing script. >>>>>> >>>>>> So everything amazingly worked out well, except that the lights >>>>>> are not changing status which I think is related to the XML >>>>>> document dialog-info entity attribute containing the group name, >>>>>> sent from my server. >>>>>> >>>>>> Any ideas or suggestions ? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> David >>>>>> >>>>>> Other information : >>>>>> >>>>>> if ( is_method("SUBSCRIBE") ) >>>>>> { >>>>>> avp_db_query("select groupname from sometable ", >>>>>> "$avp(s:groupname)"); >>>>>> avp_printf("$ru", >>>>>> "sip:$avp(s:zone).$tU@my.kamailio.domain.name"); >>>>>> xlog("L_INFO", "Subscribe rewritten from $tU to $ru >>>>>> - M=$rm \n"); >>>>>> xlog("L_INFO", "Handling SUBSCRIBE - $fU - >>>>>> $avp(s:zone) - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); >>>>>> handle_subscribe(); >>>>>> t_release(); >>>>>> exit; >>>>>> } >>>>>> >>>>>> Kamailio compiled from sources : >>>>>> >>>>>> Path: /usr/src/kamailio >>>>>> URL: >>>>>> https://openser.svn.sourceforge.net/svnroot/openser/branches/1.5 >>>>>> Repository Root: https://openser.svn.sourceforge.net/svnroot/openser >>>>>> Repository UUID: 689a6050-402a-0410-94f2-e92a70836424 >>>>>> Revision: 5910 >>>>>> Node Kind: directory >>>>>> Schedule: normal >>>>>> Last Changed Author: henningw >>>>>> Last Changed Rev: 5910 >>>>>> Last Changed Date: 2009-08-06 13:08:30 -0400 (Thu, 06 Aug 2009) >>>>>> >>>>>> >>>>>> Klaus Darilion wrote: >>>>>>> notifies are generated by the presence module, based on the >>>>>>> subscription. So, there is nothing you have to do with NOTIFY. >>>>>>> Also PUBLISHs are created internally. Depending on your concrete >>>>>>> setup (e.g. format of the SIP user names) it should work out of >>>>>>> the box. >>>>>>> >>>>>>> klaus >>>>>>> >>>>>>> dlublink schrieb: >>>>>>>> What about the notifies? >>>>>>>> >>>>>>>> Klaus Darilion wrote: >>>>>>>>> dlublink wrote: >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> I have three different groups of extensions on my kamailio I >>>>>>>>>> want to be able to separate them, so I prefixed a name to the >>>>>>>>>> extensions, so I have : >>>>>>>>>> >>>>>>>>>> 1. group1.101 >>>>>>>>>> 2. group1.102 >>>>>>>>>> 3. group2.101 >>>>>>>>>> 4. group2.102 >>>>>>>>>> 5. group3.102 >>>>>>>>>> 6. group3.103. >>>>>>>>>> >>>>>>>>>> The phones from different groups can not call each other, I >>>>>>>>>> found a pseudo variable that I use to rewrite the destination >>>>>>>>>> url, so if user group1.101 dials 102 I rewrite it to group1.102. >>>>>>>>>> >>>>>>>>>> I want to do the same thing for presence_dialog info, how can >>>>>>>>>> I rewrite the subscribe, presence and and notify messages to >>>>>>>>>> append the appropriate prefix ? >>>>>>>>> >>>>>>>>> Just apply the same rewrite you have already done for the >>>>>>>>> INVITE also for the SUBSCRIBE >>>>>>>>> >>>>>>>>> regards >>>>>>>>> klaus >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Kamailio (OpenSER) - Users mailing list >>>>>>>>>> Users(a)lists.kamailio.org >>>>>>>>>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users >>>>>>>>>> http://lists.openser-project.org/cgi-bin/mailman/listinfo/users >>>>>>>> >>>>>> >>>> >>

1 0

Re: [Kamailio-Users] presence_dialoginfo context
by David 14 Aug '09

14 Aug '09

Hey, Here is an expert from the /var/log/messsages : Aug 14 10:16:42 kamailio-dev /usr/sbin/kamailio[28924]: New request - M=PUBLISH RURI=sip:group1.105@mydomain.tld F=sip:group1.105@mydomain.tld T=sip:group1.105@mydomain.tld IP=72.55.182.125 ID=7bddec01-28924(a)72.55.182.125 Aug 14 10:16:42 kamailio-dev /usr/sbin/kamailio[28924]: Publish rewritten forwarded for ext=group1.105 ruri=sip:group1.105@mydomain.tld duri=<null> body=<?xml version="1.0"?> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="0" state="full" entity="sip:group1.105@mydomain.tld"> <dialog id="5a9207de129fc16f49cafaa425e312f1(a)mydomain.tld" call-id="5a9207de129fc16f49cafaa425e312f1(a)mydomain.tld" local-tag="4fbrxu9548" remote-tag="as4fb63283" direction="recipient"> <state>early</state> <remote> <identity>sip:103@mydomain.tld</identity> <target uri="sip:103@mydomain.tld"/> </remote> <local> <identity>sip:group1.105@mydomain.tld</identity> <target uri="sip:group1.105@mydomain.tld"/> </local> </dialog> </dialog-info> Aug 14 10:16:42 kamailio-dev /usr/sbin/kamailio[28932]: New request - M=PUBLISH RURI=sip:group1.105@mydomain.tld F=sip:group1.105@mydomain.tld T=sip:group1.105@mydomain.tld IP=72.55.182.125 ID=7bddec01-28924(a)72.55.182.125 Aug 14 10:16:42 kamailio-dev /usr/sbin/kamailio[28932]: Publish accepted for ext=group1.105 ruri=sip:group1.105@mydomain.tld duri=<null> body=<?xml version="1.0"?> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="0" state="full" entity="sip:105@mydomain.tld"> <dialog id="5a9207de129fc16f49cafaa425e312f1(a)mydomain.tld" call-id="5a9207de129fc16f49cafaa425e312f1(a)mydomain.tld" local-tag="4fbrxu9548" remote-tag="as4fb63283" direction="recipient"> <state>early</state> <remote> <identity>sip:103@mydomain.tld</identity> <target uri="sip:103@mydomain.tld"/> </remote> <local> <identity>sip:105@mydomain.tld</identity> <target uri="sip:105@mydomain.tld"/> </local> </dialog> </dialog-info> Aug 14 10:16:42 kamailio-dev /usr/sbin/kamailio[28932]: INFO:presence:send_notify_request: NOTIFY sip:group1.101@mydomain.tld via sip:group1.101@phone.ip:57234 on behalf of sip:105@mydomain.tld for event dialog But the phone's syslog shows this : Aug 14 10:16:21 linksys [0:57234]<<server.ip:5060 Aug 14 10:16:21 linksys [0:57234]<<server.ip:5060 Aug 14 10:16:21 linksys NOTIFY sip:group1.101@phone.ip:57234 SIP/2.0^M Via: SIP/2.0/UDP 72.55.182.125;branch=z9hG4bK0b0a.9725e23.0^M To: sip:group1.101@mydomain.tld;tag=1c32db3af4d889ac^M From: sip:105@mydomain.tld;tag=6d6077e15fecee48b2721a5e94bf8883-91a8^M CSeq: 12 NOTIFY^M Call-ID: 984d4cd2-37b04f4(a)192.168.1.104^M Content-Length: 655^M User-Agent: Kamailio (1.5.2-tls (i386/linux))^M Max-Forwards: 70^M Event: dialog^M Contact: <sip:mydomain.tld:5060>^M Subscription-State: active;expires=1470^M Content-Type: application/dialog-info+xml^M ^M <?xml version="1.0"?> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="11" state="full" entity="group1.105(a)mydomain.tld"> <dialog id="0b5776fb2ea599c429038414054eb383(a)mydomain.tld" call-id="0b5776fb2ea599c429038414054eb383(a)mydomain.tld" local-tag="loto7h3i9a" remote-tag="as4f284f05" direction="recipient"> <state>early</state> <remote> <identity>sip:103@mydomain.tld</identity> <target uri=" Everything is good, but notice the entity is somehow back to group1.105. Where do you want me to run the traceroute? On the server? David Klaus Darilion wrote: > > > David schrieb: >> Hey, >> >> I tried that, but it did not seem to change anything. I saw the >> message change on the second loop, but it seems that the presence >> module figure out my tactic and fixed the message. > > That's not possible. The presence module does not alter the received > body. I think the problem is somewhere else. > > Can you send me a trace? > > ngrep -t -P "" -W byline -d any port 5060 > > regards > klaus > > >> >> David >> >> Klaus Darilion wrote: >>> That does not work: presence_server always uses the original >>> received body, the modifications applied by you are not seen by the >>> presence server. >>> >>> The workaround would be to "loop" the modified PUBLISH to Kamailio >>> again, e.g.: >>> >>> listen=.......:5060 >>> listen=.......:5050 >>> >>> route{ >>> ... >>> if (is_method("PUBLISH")) { >>> if (dst_port==5060) { >>> subst_body('/group1[.]//'); >>> t_relay("udp:127.0.0.1:5050); >>> } else if (dst_port==5050) { >>> handle_publish(); >>> t_release(); >>> } >>> } >>> ... >>> } >>> >>> >>> klaus >>> David schrieb: >>>> Hey, >>>> >>>> I tried doing a subst or replace_body_all to change the entity="" >>>> value, >>>> >>>> if (is_method("PUBLISH") ) >>>> { >>>> subst_body('/group1[.]//'); >>>> handle_publish(); >>>> t_release(); >>>> } >>>> >>>> It did not work, the $rb variable still shows the old body and the >>>> NOTIFY received on the phone is the old body as well. >>>> >>>> I thought about doing a string replace on the outbound NOTIFY but >>>> it never hits my routing script, so I can't. >>>> >>>> I read textops and it does not list any limitations relating to me. >>>> >>>> Any ideas? >>>> >>>> David >>>> >>>> Klaus Darilion wrote: >>>>> I think the problem lies within the dialog module. Dialog module >>>>> stores from/to URI. Both, from and to URI are derived from the >>>>> headers. We could extend the dialog module to store request-URI in >>>>> the dialog-info structure too, and add an option to pua_dialoginfo >>>>> to use RURI instead of To-URI. >>>>> >>>>> regards >>>>> klaus >>>>> >>>>> David schrieb: >>>>>> Hey, >>>>>> >>>>>> I think I am doing something wrong, because here is the NOTIFY >>>>>> that comes to the phone : >>>>>> >>>>>> NOTIFY sip:group1.101@my.home.ip:57234 SIP/2.0 >>>>>> Via: SIP/2.0/UDP my.kamailio.ip;branch=z9hG4bK3cab.78e494a4.0 >>>>>> To: sip:group1.101@my.kamailio.domain.name;tag=b2514519391e8b4d >>>>>> From: >>>>>> sip:102@my.kamailio.domain.name;tag=6d6077e15fecee48b2721a5e94bf8883-f712 >>>>>> >>>>>> CSeq: 12 NOTIFY^M Call-ID: 24db3209-611c031d(a)192.168.1.104 >>>>>> Content-Length: 298 >>>>>> User-Agent: MyServer 1.0 >>>>>> Max-Forwards: 70 >>>>>> Event: dialog >>>>>> Contact: <sip:my.kamailio.domain.name:5060> >>>>>> Subscription-State: active;expires=1570 >>>>>> Content-Type: application/dialog-info+xml >>>>>> >>>>>> <?xml version="1.0"?> <dialog-info >>>>>> xmlns="urn:ietf:params:xml:ns:dialog-info" version="11" >>>>>> state="full" entity="group1.102(a)my.kamailio.domain.name"> >>>>>> <dialog id="7aaa32e84362a246716009175ad670be(a)domain.tld" >>>>>> direction="recipient"> <state>early</state> </dialog> >>>>>> </dialog-info> >>>>>> >>>>>> The phone ( I tested with a GXP2000, GXP2020 and SPA962 + SPA932) >>>>>> does not flash lights or anything. Since you suggested that a >>>>>> solid kamailio would work out of the box, I suspect that either I >>>>>> miscommunicated my setup or did something really wrong. The >>>>>> notify definitely gets to the phone and the phone replies 200/OK >>>>>> when it receives the NOTIFY. But I think that the telephone is >>>>>> not understanding the request because it subscribed to '102' but >>>>>> received a notification for 'group1.102'. The funny thing is, the >>>>>> From header matches the subscribe To header, it's just the XML >>>>>> has the full name instead of the shortened name. >>>>>> >>>>>> To: >>>>>> <sip:102@my.kamailio.domain.name>;tag=6d6077e15fecee48b2721a5e94bf8883-f712 >>>>>> >>>>>> >>>>>> I see this in my ( on kamailio ) /var/log/messages : >>>>>> >>>>>> Aug 13 09:55:24 kamailio-dev /usr/sbin/kamailio[25449]: >>>>>> INFO:presence:send_notify_request: NOTIFY >>>>>> sip:group1.101@my.kamailio.domain.name via >>>>>> sip:group1.101@my.home.ip.where.phone.is:57234 on behalf of >>>>>> sip:102@my.kamailio.domain.name for event dialog >>>>>> >>>>>> I should also mention that the NOTIFY sent out by presence >>>>>> bypasses my routing scripts. So I have the PUBLISH come through ( >>>>>> which I leave alone ) and the NOTIFY is sent according to the >>>>>> location table without ever consulting my routing script. >>>>>> >>>>>> So everything amazingly worked out well, except that the lights >>>>>> are not changing status which I think is related to the XML >>>>>> document dialog-info entity attribute containing the group name, >>>>>> sent from my server. >>>>>> >>>>>> Any ideas or suggestions ? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> David >>>>>> >>>>>> Other information : >>>>>> >>>>>> if ( is_method("SUBSCRIBE") ) >>>>>> { >>>>>> avp_db_query("select groupname from sometable ", >>>>>> "$avp(s:groupname)"); >>>>>> avp_printf("$ru", >>>>>> "sip:$avp(s:zone).$tU@my.kamailio.domain.name"); >>>>>> xlog("L_INFO", "Subscribe rewritten from $tU to $ru >>>>>> - M=$rm \n"); >>>>>> xlog("L_INFO", "Handling SUBSCRIBE - $fU - >>>>>> $avp(s:zone) - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); >>>>>> handle_subscribe(); >>>>>> t_release(); >>>>>> exit; >>>>>> } >>>>>> >>>>>> Kamailio compiled from sources : >>>>>> >>>>>> Path: /usr/src/kamailio >>>>>> URL: >>>>>> https://openser.svn.sourceforge.net/svnroot/openser/branches/1.5 >>>>>> Repository Root: https://openser.svn.sourceforge.net/svnroot/openser >>>>>> Repository UUID: 689a6050-402a-0410-94f2-e92a70836424 >>>>>> Revision: 5910 >>>>>> Node Kind: directory >>>>>> Schedule: normal >>>>>> Last Changed Author: henningw >>>>>> Last Changed Rev: 5910 >>>>>> Last Changed Date: 2009-08-06 13:08:30 -0400 (Thu, 06 Aug 2009) >>>>>> >>>>>> >>>>>> Klaus Darilion wrote: >>>>>>> notifies are generated by the presence module, based on the >>>>>>> subscription. So, there is nothing you have to do with NOTIFY. >>>>>>> Also PUBLISHs are created internally. Depending on your concrete >>>>>>> setup (e.g. format of the SIP user names) it should work out of >>>>>>> the box. >>>>>>> >>>>>>> klaus >>>>>>> >>>>>>> dlublink schrieb: >>>>>>>> What about the notifies? >>>>>>>> >>>>>>>> Klaus Darilion wrote: >>>>>>>>> dlublink wrote: >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> I have three different groups of extensions on my kamailio I >>>>>>>>>> want to be able to separate them, so I prefixed a name to the >>>>>>>>>> extensions, so I have : >>>>>>>>>> >>>>>>>>>> 1. group1.101 >>>>>>>>>> 2. group1.102 >>>>>>>>>> 3. group2.101 >>>>>>>>>> 4. group2.102 >>>>>>>>>> 5. group3.102 >>>>>>>>>> 6. group3.103. >>>>>>>>>> >>>>>>>>>> The phones from different groups can not call each other, I >>>>>>>>>> found a pseudo variable that I use to rewrite the destination >>>>>>>>>> url, so if user group1.101 dials 102 I rewrite it to group1.102. >>>>>>>>>> >>>>>>>>>> I want to do the same thing for presence_dialog info, how can >>>>>>>>>> I rewrite the subscribe, presence and and notify messages to >>>>>>>>>> append the appropriate prefix ? >>>>>>>>> >>>>>>>>> Just apply the same rewrite you have already done for the >>>>>>>>> INVITE also for the SUBSCRIBE >>>>>>>>> >>>>>>>>> regards >>>>>>>>> klaus >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Kamailio (OpenSER) - Users mailing list >>>>>>>>>> Users(a)lists.kamailio.org >>>>>>>>>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users >>>>>>>>>> http://lists.openser-project.org/cgi-bin/mailman/listinfo/users >>>>>>>> >>>>>> >>>> >>

1 0

[Kamailio-Users] Generate INVITE from Openser
by ALAEDDINE abbech 14 Aug '09

14 Aug '09

Hello all How can i generate an INVITE from OpenSER. That means that Openser make the role of UAC. Who have an idea for this pb. Thanks Regards Aladin

6 9

[Kamailio-Users] presence_dialoginfo context
by dlublink 14 Aug '09

14 Aug '09

Hello, I have three different groups of extensions on my kamailio I want to be able to separate them, so I prefixed a name to the extensions, so I have : 1. group1.101 2. group1.102 3. group2.101 4. group2.102 5. group3.102 6. group3.103. The phones from different groups can not call each other, I found a pseudo variable that I use to rewrite the destination url, so if user group1.101 dials 102 I rewrite it to group1.102. I want to do the same thing for presence_dialog info, how can I rewrite the subscribe, presence and and notify messages to append the appropriate prefix ? Thanks, David

4 10

[Kamailio-Users] Load Balancing Asterisk using Kamailio
by Kurt Weasel 14 Aug '09

14 Aug '09

Hi, I searched around the web to load balance asterisk servers and found Kamailio for possible solution. Let's say I have two identical asterisk servers with same dialplan and configuration and I want both servers look like they have same IP address from clients. Based on my understanding, we need 1 Kamailio as load balancer and 2 Asterisk servers as the real servers. Let's say the setup is : Kamailio load balancer 192.168.2.1 Asterisk Server #1 192.168.2.2 Asterisk Server #2 192.168.2.3 My question is, X-Lite softphone Configuration should be set to domain 192.168.2.1, right? I also want to know the step by step configuration to set kamailio as load balancer. I have not used Kamailio before. However after searching the documentation, the step (based on my understanding) is somewhat like this : 1. Install Kamailio. I will use the step by step here : http://kamailio.org/dokuwiki/doku.php/install:kamailio-1.5.x-from-svn 2. Then, using dipatcher module, I will configure it using this guide here : http://kamailio.org/dokuwiki/doku.php/asterisk:load-balancing-and-ha Then modify the dispatcher.list file to match the IP address of my asterisk servers : *1 sip:192.168.2.2:5060 1 sip:192.168.2.3:5060* Am I missing some steps? Do I also need to configure dialplan or any other file at Kamailio load balancer? Or those two steps basically done it all for simple load balancing configuration? Thanks for your responses. Best Regard, Kurt Weasel.

5 8

[Kamailio-Users] OpenSER without MYSQL
by Ratheendran R 13 Aug '09

13 Aug '09

Hello everyone, I want to port openSER on an embedded board,I need configure the openser without MySQL due to space constraint. So can you let me know whether this is possible also can you give any reference document on how to port on ARM 9 based boad. Regards, Rathndran <users(a)lists.kamailio.org>

7 9

[Kamailio-Users] Fwd: dialog info + Grandstreams = freezing
by Daniel-Constantin Mierla 13 Aug '09

13 Aug '09

.. fwd to list ... reply all button mismatch ... ---------- Forwarded message ---------- From: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Wed, Aug 12, 2009 at 9:20 AM Subject: Re: [Kamailio-Users] dialog info + Grandstreams = freezing To: David <kamailio.org(a)spam.lublink.net> Hello, On Tue, Aug 11, 2009 at 2:18 PM, David <kamailio.org(a)spam.lublink.net>wrote: > Hey, > > I am not good at diagrams, but here goes : > > > [ Asterisk] [ Asterisk ] ================> [ MySQL ] > / \ / \ > [ Kamailio ] ============/\ > / \ / \ / \ > [ Extension ] [ Extension ] [ Extension ] > > Here is a simple flow : > > 1. Extension 1 is plugged in > 2. It registers to Kamailio and Kamailio stores to Location > 3. Extension 1 subscribes to all the other extensions > 4. Kamailio calls handle_publish() and t_release() > 5. Extension 1 dials '102' > 6. Kamailio receives the INVITE chooses an asterisk server and relays the > INVITE ( t_relay ) > 7. Asterisk does some checking, starts monitor ( if needed ) and some other > stuff > 8. Asterisk sends INVITE to Kamailio for testspace.102 > 9. Kamailio finds testspace.102 in database and forwards INVITE to the > appropriate extension > 10. Extension replies 'OK' > 11. Kamailio, using reply-route, sends it back to asterisk > 12. Asterisk bridges the call with 101 > 13. Asterisk sends an OK back through Kamailio to Extension 1. > 14. Asterisk tries to reinvite the audio ( if not monitoring ) > 15. Audio bypasses Asterisk, but the SIP still is making the full trip. > > Does this answer your question? Do you do call tracking with dialog for both legs (inbond: phone to asterisk; outbound: asterisk to phone)? You should do it for one, outbound is the best, in case asterisk auto-answers the inbound leg. Cheers, Daniel > > David > > > > Daniel-Constantin Mierla wrote: > >> Hello, >> >> I am using the module with snom 370 and works ok. The BLF is on for >> Polycoms but they do not implement the call pickup properly (they have >> direct call pickup as far as I could get). >> >> Please take latest kamailio 1.5 from svn branch 1.5 as there were >> committed some updates (maybe they don't affect you, being mainly to rls, >> but is better to have the latest stable so we refer to same source code). >> >> What would be good is to have a diagram of the signaling, since you say >> there are lot of messages sent around. >> http://callflow.sourceforge.net/ >> >> Cheers, >> Daniel >> >> >> On 11.08.2009 5:03 Uhr, David wrote: >> >>> Hello, >>> >>> I am having this problem on kamailio 1.5.2-tls compiled on Ubuntu 8.04, >>> 1.5.1-tls ( compiled with no tls ) on Ubuntu 8.04 and with OpenSIPS >>> 1.5.2-tls compilde on Ubuntu 8.04 >>> >>> I am trying to setup presence_dialoginfo with my Grandstreams, Snom and >>> Linksys. I have a 4 phones on the server. >>> >>> 101 - Linksys SPA962 ( 6.1.5a ) >>> 102 - Grandstream GXP2020 ( 1.2.1.4 ) >>> 103 - Grandstream GXP2000 ( 1.2.1.4 ) >>> 104 - Grandstream GXP2000 ( 1.1.6.46 ) >>> 105 - Snom 360 ( 7.3.23 ) >>> >>> My Kamailio deals with registrations, NAT and BLF everything else is sent >>> to one of two asterisk boxes. I use the dispatcher module for this. This >>> means that when I call one extension to the other, both call legs from >>> asterisk are going through Kamailio as separate calls. But to divide my >>> customers, the usernames are different from the URL that the user types. For >>> example the customer dials '101' but it is changed to testspace.101 when it >>> comes back from asterisk. So Kamailio would have two calls in the event that >>> 101 dials 102. >>> >>> sip:testspace.101@myserver to 102 ( this is sent to asterisk ) >>> sip:testspace.101@myserver to testspace.102 ( this is coming back from >>> asterisk ) >>> >>> Something is horribly wrong. I have the following problems : >>> >>> 1. If 102 calls 103, when 103 answers both phones hang for about 2 >>> minutes >>> 2. If 105 calls 101, 101 BLF comes back to the inactive state ( green on >>> the Linksys and dark on the Snom), but the orange light stays on on the Snom >>> and it thinks the call is still active ( the light is on, but the call is >>> over ) >>> 3. If any extension calls any extension and I try a call pickup, it >>> fails. It looks like the Linksys is sending a NOTIFY to pickup the call ( I >>> thought it was supposed to send an invite... ? ) >>> >>> Looking at the logs it looks like Kamailio is sending out so many NOTIFYs >>> that it is crashing the Grandstreams, and causing the Snom to act funny. >>> >>> Here are some experts from my config file : >>> >>> root@kamailio-dev:/etc/kamailio# grep dialog * >>> kamailio.cfg:# * avp value for dialogs is still not correct >>> kamailio.cfg:loadmodule "dialog.so" >>> kamailio.cfg:loadmodule "presence_dialoginfo.so" >>> kamailio.cfg:loadmodule "pua_dialoginfo.so" >>> kamailio.cfg:#modparam("pua_dialoginfo", "include_localremote", 0) >>> kamailio.cfg:#modparam("pua_dialoginfo", "include_tags", 0) >>> kamailio.cfg:#modparam("pua_dialoginfo", "include_callid", 0) >>> kamailio.cfg:modparam("dialog", "dlg_flag", 4) >>> kamailio.cfg:modparam("dialog", "db_mode", 1) >>> kamailio.cfg:modparam("dialog", "timeout_avp", "$avp(i:10)") # I still >>> haven't figured out how to set $avp(i:10) >>> kamailio.cfg:modparam("pua_dialoginfo", "override_lifetime", 300) >>> kamailio.cfg:modparam("presence_dialoginfo", "force_single_dialog", 1) >>> kamailio.cfg:modparam("pua_dialoginfo", "caller_confirmed", 1) >>> kamailio.cfg:modparam("auth_db|usrloc|acc|domain|avpops|presence|presence_xml|pua|dialog", >>> "db_url", >>> kamailio.cfg:# Flag 4 = Mark the current request for a dialog >>> kamailio.cfg: # sequential request withing a dialog should >>> >>> the set flag looks like this : >>> if ( ds_is_from_list() ) >>> { >>> xlog("L_INFO", "Coming from asterisk"); >>> if ( is_method("INVITE")) >>> { >>> setflag(4); >>> } >>> } >>> >>> So the dialog flag is only set for the leg coming back from asterisk. >>> >>> When a notify comes in : >>> >>> if(is_method("NOTIFY") ) >>> { >>> if (! t_newtran()) >>> { >>> sl_reply_error(); >>> exit; >>> }; >>> >>> t_reply("200", "OK"); >>> t_release(); >>> exit ; >>> } >>> >>> Publish and subscribe are like this : >>> >>> >>> if( is_method("PUBLISH") || is_method("SUBSCRIBE") ) >>> { >>> route(5); >>> exit; >>> } >>> >>> route[5] >>> { >>> # absorb retransmissions >>> if (! t_newtran()) >>> { >>> xlog("L_INFO", "Ignoring PUBLISH/SUBSCRIBE on retransmition - >>> M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); >>> sl_reply_error(); >>> exit; >>> }; >>> >>> append_to_reply("Contact: <sip:myserver.tld:5060>\r\n"); >>> >>> if(is_method("PUBLISH")) >>> { >>> handle_publish(); >>> t_release(); >>> >>> } else if( is_method("SUBSCRIBE")) { >>> handle_subscribe(); >>> t_release(); >>> } >>> else >>> { >>> } >>> >>> exit; >>> } >>> >>> I also have NAT checking for those telephones where stun isn't enough. >>> Before I reach publish/subscribe/invite/notify, I also call setbflag() and >>> sometimes call fix_nated_contact(). Additionnally, I have a block if code >>> before my presence stuff if ( has_totag() && loose_route()) { t_relay(); }. >>> >>> If sip.conf:canreinvite=yes, the grandstreams freeze so long that the >>> server times out, and the BLFs get really messed up. if sip:canreinvite=no >>> the grandstreams only freeze for about 30 seconds. >>> >>> Obviously I am doing something wrong, but despite having searched google >>> for endless hours, and poured over documentation, I can not seem to find >>> what I did wrong. >>> >>> I would really appreciate if someone could shed light on my problem. >>> >>> I am having this problem on kamailio 1.5.2-tls compiled on Ubuntu 8.04, >>> 1.5.1-tls ( compiled with no tls ) on Ubuntu 8.04 and with OpenSIPS >>> 1.5.2-tls compilde on Ubuntu 8.04 >>> >>> Thanks, >>> >>> David >>> >>> _______________________________________________ >>> Kamailio (OpenSER) - Users mailing list >>> Users(a)lists.kamailio.org >>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users >>> http://lists.openser-project.org/cgi-bin/mailman/listinfo/users >>> >>> >> > > _______________________________________________ > Kamailio (OpenSER) - Users mailing list > Users(a)lists.kamailio.org > http://lists.kamailio.org/cgi-bin/mailman/listinfo/users > http://lists.openser-project.org/cgi-bin/mailman/listinfo/users > -- Daniel-Constantin Mierla http://www.asipto.com -- Daniel-Constantin Mierla http://www.asipto.com

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users