Re: [SR-Users] Does forking impact max_inv_lifetime?
Maybe I should ask this question another way that is more applicable to my end-goal: What exactly happens when max_inv_lifetime is reached without a final response? Is a failure_route invoked? If so, is the appropriate means of dealing with this to check t_is_expired() and handle it at that level? -- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/ ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Possible memory leak dealing with presence in kamailio
Hello all. Just want to tell you that the problem remains even after the patch Daniel add to the latest 4.2. I've sent another email yesterday (partially quoted bellow) to the mailing list which was already answered by Juha Heinanen in cc regarding an odd behavior (seems odd to me) i'm seeing. I've been testing presence module for a while and I do notice that presentity table grows endlessly over time. Each time a call is made a new record is added in presentity with a different etag. In documentation, namely developers guide we can read this: int etag_not_new; /* * 0 - the standard mechanism (allocating new etag for each Publish) * 1 - allocating an etag only for an initial Publish */ How can I tell the presence module in kamailio config to work using the second form of the above? I have a small production environment with ~70 extensions and in less than 24H (~20H), the presentity table grew from 0 to about ~2000 records, pua table grew to about ~850 records and kamailio memory usage grew from 600MB to 2GB on a 4G Linux server. Yesterday Juha said and I'll quote: presence module does not do anything with calls. it handles publish and subscriber requests and generates notifies. when publish is handled, it is the job of the publisher to place correct etag in subsequent refresh publish requests. -- juha Here my publisher is Kamailio itself. Can someone elaborate a bit more on this issue and maybe we can get to bottom of it? Thanks. Cheers, -- *Nuno Miguel Reis* | *Unified Communication** Systems* M. +351 913907481 | nr...@wavecom.pt WAVECOM-Soluções Rádio, S.A. Cacia Park | Rua do Progresso, Lote 15 3800-639 AVEIRO | Portugal T. +351 309 700 225 | F. +351 234 919 191 *GPS http://maps.google.com/maps/ms?msa=0msid=202333747613191340808.0004b4b227a6144f0df88 | www.wavecom.pt http://www.wavecom.pt/** http://www.wavecom.pt/* [image: Description: Description: WavecomSignature] http://www.wavecom.pt/pt/wavecom/premios.php [image: Publicity] http://www.wavecom.pt/pt/mail_eventos.php On Thu, Jan 15, 2015 at 4:56 PM, Daniel-Constantin Mierla mico...@gmail.com wrote: Hello, I applied the patch, with some adjustments. Now in master, to be backported to stable branches soon. Cheers, Daniel On 13/01/15 20:16, Nuno Reis wrote: Hi Kristian and Daniel. Kristian, hhanks for you feedback and patch. I'll try your patch here and will let you know the outcome soon. Thanks again guys. Cheers, -- *Nuno Miguel Reis* | *Unified Communication** Systems* M. +351 913907481 | nr...@wavecom.pt WAVECOM-Soluções Rádio, S.A. Cacia Park | Rua do Progresso, Lote 15 3800-639 AVEIRO | Portugal T. +351 309 700 225 | F. +351 234 919 191 *GPS http://maps.google.com/maps/ms?msa=0msid=202333747613191340808.0004b4b227a6144f0df88 | www.wavecom.pt http://www.wavecom.pt/** http://www.wavecom.pt/* [image: Description: Description: WavecomSignature] http://www.wavecom.pt/pt/wavecom/premios.php [image: Publicity] http://www.wavecom.pt/pt/mail_eventos.php On Tue, Jan 13, 2015 at 10:00 AM, Daniel-Constantin Mierla mico...@gmail.com wrote: Hello, thanks for the details and patch. I will try to look at later today. Cheers, Daniel On 13/01/15 08:35, Kristian F. Høgh wrote: Hi, I've been hunting a memory error in publish handling the last couple of days. The error is on our old but good 3.1.x presence server. Using memory debug, I located the memory leak in modules/presence/hash.c, function insert_phtable, line 492 (in trunk): p= (pres_entry_t*)shm_malloc(size); As far I can see there are two errors when deleting publish htable entries 1. When calling delete_phtable pres.event-type is used instead of pres.event-evp-type 2. When creating publish hashtable, p-publ_count is not set. (defaults to 0) In delete_phtable, the following code is present p-publ_count--; if(p-publ_count== 0) p-publ_count is probably decremented to -1 (unless the user have two active dialogs) I attach a patch, which I would carefully test in a test environment :-) Regards, Kristian Høgh Uni-tel On Monday 12 January 2015 15:39:27 Nuno Reis wrote: Hello all. I'm consistently watching a memory increase in kamailio when dealing with PRESENCE events, namely SIP PUBLISH events. The system eventually hangs running out of memory. This behavior is seen at least in kamailio 4.1 and 4.2. I'm currently using the latest stable 4.2.2. If I disable the SIP PUBLISH handling in kamailio i don't observe the issue anymore but as a side effect I don't have presence (name BLFs) also. What do you think can be the right approach here? Should I open an issue in github for this? Should I run kamailio under valgrind for some time? Are there any other possible debug hints here? Please find attached a code snippet with the presence related parts I'm using
[SR-Users] Does forking impact max_inv_lifetime?
Hi, In this serial forking-based failover scenario UAC -- Proxy -- UAS 1 UAS 2 ... UAS 3 I've got a requirement to terminate the call and return an error to the UAC if there is no final response within 60 seconds. The usual fr_inv_timer / restart_fr_on_each_reply combination won't do, because even when restart_fr_on_each_reply == 0, the timer is still restarted on provisional replies of increasing response code value (e.g. 183 after 180). As the documentation states, fr_inv_timer is a branch-level construct anyway, so this approach doesn't make sense here. That's why I looked into max_inv_lifetime. However, when I set it to 6, I still get the same result, but only when there are new branches being formed on the proxy - UAS side. It works fine if there is no forking and a single gateway does not provide a final reply within 60 seconds. So, my sense is that the max_inv_lifetime timeout is reset when a new branch is created to UAS 2...UAS N. Is this accurate? Thanks, -- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/ ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] How to make presence module allocating an etag only for an initial Publish??
Hi Juha. Thanks for answering me back. In my particular case my publisher is Kamailio itself. You can see a code snippet for my presence configs (attached) in my kamailio config file. I'm using pua to generate SIP PUBLISH messages on 127.0.0.1 and probably that isn't the best approach, but I don't have other. Any suggestions? Cheers, -- *Nuno Miguel Reis* | *Unified Communication** Systems* M. +351 913907481 | nr...@wavecom.pt WAVECOM-Soluções Rádio, S.A. Cacia Park | Rua do Progresso, Lote 15 3800-639 AVEIRO | Portugal T. +351 309 700 225 | F. +351 234 919 191 *GPS http://maps.google.com/maps/ms?msa=0msid=202333747613191340808.0004b4b227a6144f0df88 | www.wavecom.pt http://www.wavecom.pt/** http://www.wavecom.pt/* [image: Description: Description: WavecomSignature] http://www.wavecom.pt/pt/wavecom/premios.php [image: Publicity] http://www.wavecom.pt/pt/mail_eventos.php On Tue, Jan 20, 2015 at 7:37 PM, Juha Heinanen j...@tutpro.com wrote: Nuno Reis writes: I've been testing presence module for a while and I do notice that presentity table grows endlessly over time. Each time a call is made a new record is added in presentity with a different etag. presence module does not do anything with calls. it handles publish and subscriber requests and generates notifies. when publish is handled, it is the job of the publisher to place correct etag in subsequent refresh publish requests. -- juha presence.cfg Description: Binary data ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] Dialog variable lost in ACC
Hi , I've updated kamailio from 4.1.4 to 4.1.7 and some times dialog variables are not writed on the db by the ACC module. The variable that is not writed ,is setted in the on reply route ,when it receive the 200ok and method is invite. If i come back to the 4.1.4 all is ok. If i patch kamailio 4.1.4 with the code dialog: Set the dialog context on incoming replies (commit:b12a01e553699786953ec601197669314bf414c7) sometime the variable are not writed. Any ideas? Thanks ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] topoh ACK Call-ID mismatch
It is an ACK for a negative response, therefore it is hop-by-hop (received and discared by kamailio, then a new one is generated to the next hop). The information of direction which was detected with Route header ftag cannot be done in this case. I will try to figure out how can be solved... Cheers, Daniel On 21/01/15 12:12, Daniel Tryba wrote: On Wednesday 21 January 2015 08:45:59 Daniel-Constantin Mierla wrote: To understand properly, this is after the re-INVITE from B to A? I will look in the code as I get a chance, being out of the office for few days... Yes. Full trace below. Only the ACK to SIP_A for the 488 has the wrong Call- ID. Disabling masking fixes the problem, but I need topoh with callerid masking to enable an Avaya IP Office to make calls to itself via its external extensions. There is no hurry, it appears have been broken for a long time, a few weeks extra makes no difference to me :) I'll try a test server with a more recent version to see if the problem was fixed since 4.0.3. U SIP_A:5060 - KAMAILIO:5060 INVITE sip:+31880100...@sip.pocos.nl:5060 SIP/2.0. Via: SIP/2.0/UDP SIP_A:5060;branch=z9hG4bK396cd222;rport. From: +31880100705 sip:+31880100...@sip.pocos.nl;tag=as1b0b8097. To: sip:+31880100...@sip.pocos.nl:5060. Contact: sip:+31880100705@sipA. Call-ID: 0b5946b977210450571f767a19cd6...@99sip.pocos.nl. U KAMAILIO:5060 - SIP_A:5060 SIP/2.0 100 trying -- your call is important to us. Via: SIP/2.0/UDP SIP_A:5060;branch=z9hG4bK396cd222;rport=5060. From: +31880100705 sip:+31880100...@sip.pocos.nl;tag=as1b0b8097. To: sip:+31880100...@sip.pocos.nl:5060. Call-ID: 0b5946b977210450571f767a19cd6...@99sip.pocos.nl. U KAMAILIO:5060 - SIP_B:5060 INVITE sip:+31880100...@fax.pocos.nl SIP/2.0. Record-Route: sip:KAMAILIO;lr;ftag=as1b0b8097;did=fc2.c39. Via: SIP/2.0/UDP KAMAILIO;branch=z9hG4bK0a1a.d2ac1e03.0. Via: SIP/2.0/UDP 172.19.162.1;branch=pocos- rS4MusXox1l5QHyNxRy6uAXsEOdsxidSWGktxGZKWtQX- DQV9Acim8HoZpNlaA4kQsQiOsx6E8EnxAXfWgeKCgeS-RrKEAy*. From: +31880100705 sip:+31880100...@sip.pocos.nl;tag=as1b0b8097. To: sip:+31880100...@sip.pocos.nl:5060. Contact: sip:172.19.162.1;line=pcs-mp4KWiTsxRNdxG7KxGmKEry3xGnoxAxtuAxfuAMd. Call-ID: !!:xqXtWRMpZAngEsX3xGMtxGrgxDZgEA9JxR4AzGz8ZRIyWR4sh.yomqlACgxoC8K*. U SIP_B:5060 - KAMAILIO:5060 SIP/2.0 100 Trying. Via: SIP/2.0/UDP KAMAILIO;branch=z9hG4bK0a1a.d2ac1e03.0;received=KAMAILIO. Via: SIP/2.0/UDP 172.19.162.1;branch=pocos- rS4MusXox1l5QHyNxRy6uAXsEOdsxidSWGktxGZKWtQX- DQV9Acim8HoZpNlaA4kQsQiOsx6E8EnxAXfWgeKCgeS-RrKEAy*. Record-Route: sip:KAMAILIO;lr;ftag=as1b0b8097;did=fc2.c39. From: +31880100705 sip:+31880100...@sip.pocos.nl;tag=as1b0b8097. To: sip:+31880100...@sip.pocos.nl:5060. Call-ID: !!:xqXtWRMpZAngEsX3xGMtxGrgxDZgEA9JxR4AzGz8ZRIyWR4sh.yomqlACgxoC8K*. U SIP_B:5060 - KAMAILIO:5060 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP KAMAILIO;branch=z9hG4bK0a1a.d2ac1e03.0;received=KAMAILIO. Via: SIP/2.0/UDP 172.19.162.1;branch=pocos- rS4MusXox1l5QHyNxRy6uAXsEOdsxidSWGktxGZKWtQX- DQV9Acim8HoZpNlaA4kQsQiOsx6E8EnxAXfWgeK CgeS-RrKEAy*. Record-Route: sip:KAMAILIO;lr;ftag=as1b0b8097;did=fc2.c39. From: +31880100705 sip:+31880100...@sip.pocos.nl;tag=as1b0b8097. To: sip:+31880100...@sip.pocos.nl:5060;tag=as3869fe2a. Call-ID: !!:xqXtWRMpZAngEsX3xGMtxGrgxDZgEA9JxR4AzGz8ZRIyWR4sh.yomqlACgxoC8K*. U KAMAILIO:5060 - SIP_A:5060 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP SIP_A:5060;branch=z9hG4bK396cd222;rport=5060. Record-Route: sip:KAMAILIO;lr;ftag=as1b0b8097;did=fc2.c39. From: +31880100705 sip:+31880100...@sip.pocos.nl;tag=as1b0b8097. To: sip:+31880100...@sip.pocos.nl:5060;tag=as3869fe2a. Call-ID: 0b5946b977210450571f767a19cd6...@99sip.pocos.nl. U SIP_B:5060 - KAMAILIO:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP KAMAILIO;branch=z9hG4bK0a1a.d2ac1e03.0;received=KAMAILIO. Via: SIP/2.0/UDP 172.19.162.1;branch=pocos- rS4MusXox1l5QHyNxRy6uAXsEOdsxidSWGktxGZKWtQX- DQV9Acim8HoZpNlaA4kQsQiOsx6E8EnxAXfWgeKCgeS-RrKEAy*. Record-Route: sip:KAMAILIO;lr;ftag=as1b0b8097;did=fc2.c39. From: +31880100705 sip:+31880100...@sip.pocos.nl;tag=as1b0b8097. To: sip:+31880100...@sip.pocos.nl:5060;tag=as3869fe2a. Call-ID: !!:xqXtWRMpZAngEsX3xGMtxGrgxDZgEA9JxR4AzGz8ZRIyWR4sh.yomqlACgxoC8K*. U KAMAILIO:5060 - SIP_A:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP SIP_A:5060;branch=z9hG4bK396cd222;rport=5060. Record-Route: sip:KAMAILIO;lr;ftag=as1b0b8097;did=fc2.c39. From: +31880100705 sip:+31880100...@sip.pocos.nl;tag=as1b0b8097. To: sip:+31880100...@sip.pocos.nl:5060;tag=as3869fe2a. Call-ID: 0b5946b977210450571f767a19cd6...@99sip.pocos.nl. U SIP_A:5060 - KAMAILIO:5060 ACK sip:172.19.162.1;line=pcs-mp4KWiTsxRNdxG7KxGm6Wry3xGnoxAxtuAxfuAMpWArKEAy* SIP/2.0. Via: SIP/2.0/UDP SIP_A:5060;branch=z9hG4bK766d39a2;rport. Route: sip:KAMAILIO;lr;ftag=as1b0b8097;did=fc2.c39. From: +31880100705 sip:+31880100...@sip.pocos.nl;tag=as1b0b8097. To: sip:+31880100...@sip.pocos.nl:5060;tag=as3869fe2a. Contact: sip:+31880100705@sipA. Call-ID:
Re: [SR-Users] Does forking impact max_inv_lifetime?
Hello, somehow your emails are a bit confusing, in first one you say that you cannot get max_inv_lifetime as per transaction, being reset by a new branch, is that still true? The failure route should be called when the transaction is expired. Cheers, Daniel On 21/01/15 18:16, Alex Balashov wrote: Maybe I should ask this question another way that is more applicable to my end-goal: What exactly happens when max_inv_lifetime is reached without a final response? Is a failure_route invoked? If so, is the appropriate means of dealing with this to check t_is_expired() and handle it at that level? -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Does forking impact max_inv_lifetime?
Daniel, Will failure_route will be called immediately when the transaction expires? I tried a call where max_inv_lifetime was set at 5 ms and fr_inv_timer at 4 ms. Several new branches were attempted, each sending some 183s or 180s, and Kamailio did not CANCEL the last pending branch until 83 sec into the call. Is there something I'm missing about how to handle the transaction expiration in real time? -- Sent from my BlackBerry. Please excuse errors and brevity. Original Message From: Daniel-Constantin Mierla Sent: Wednesday, January 21, 2015 5:59 PM To: Kamailio (SER) - Users Mailing List Reply To: mico...@gmail.com Subject: Re: [SR-Users] Does forking impact max_inv_lifetime? Hello, somehow your emails are a bit confusing, in first one you say that you cannot get max_inv_lifetime as per transaction, being reset by a new branch, is that still true? The failure route should be called when the transaction is expired. Cheers, Daniel On 21/01/15 18:16, Alex Balashov wrote: Maybe I should ask this question another way that is more applicable to my end-goal: What exactly happens when max_inv_lifetime is reached without a final response? Is a failure_route invoked? If so, is the appropriate means of dealing with this to check t_is_expired() and handle it at that level? -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] Kamailio doesn't response to some INVITE packages
My Kamailio box works very well for a year, in front of a Freeswitch box. Nowadays, some of my users live problems about receiving calls. But this problem occurs on a couple of specific users. %1 of users complain about it. When I capture the traffic, I see that, Kamailio receives an invite package from freeswitch but takes no action. Normally it should response with a 100 trying message. Here is the INVITE package. 1.2.3.6 is the Freeswitch box and 1.2.3.2 is the Kamailio box. I captured this package on Kamailio box. U 1.2.3.6:5060 - 1.2.3.2:5060 INVITE sip:2...@test.example.net SIP/2.0. Via: SIP/2.0/UDP 1.2.3.6;rport;branch=z9hG4bKZU1Z76FvDZ26r. Route: sip:1.2.3.2;lr. Max-Forwards: 65. From: 90850885 sip:908508850...@test.example.net;tag=KjcgDe0NyKN0B. To: sip:2000@88.235.112.33:1028. Call-ID: 72b344f4-1c09-1233-ad8d-0050568e9066. CSeq: 70585075 INVITE. Contact: sip:mod_sofia@1.2.3.6:5060. User-Agent: FreeSWITCH-mod_sofia/1.4.14+git~20141119T221113Z~ca1d990cfc~64bit. Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE. Supported: timer, path, replaces. Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer. Content-Type: application/sdp. Content-Disposition: session. Content-Length: 270. X-AUTH-IP: 159.253.40.138. X-BF-SRC: 2. X-FS-Support: update_display,send_info. Remote-Party-ID: 90850885 sip:908508850...@test.example.net ;party=calling;screen=yes;privacy=off. . v=0. o=FreeSWITCH 1421813895 1421813896 IN IP4 1.2.3.6. s=FreeSWITCH. c=IN IP4 1.2.3.6. t=0 0. m=audio 28384 RTP/AVP 3 8 0 101 13. a=rtpmap:3 GSM/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=ptime:20. I use standart location lookup and relay procedure in Kamailio default script. Is there anything wrong with this INVITE package and how can I trace this issue on Kamailio box? Thank you. ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio doesn't response to some INVITE packages
Thank you Daniel, The weird thing is, this problem is not persistent. Now it works as usual and I can't reproduce the problem. According to your reply, problem may be at Freeswitch box. How can I calculate Content Length from capture? And if this is a message size issue, how can I fix it? /Volkan 2015-01-21 14:58 GMT+02:00 Daniel Tryba d.tr...@pocos.nl: On Wednesday 21 January 2015 13:42:07 Volkan Oransoy wrote: Content-Length: 270. v=0. o=FreeSWITCH 1421813895 1421813896 IN IP4 1.2.3.6. s=FreeSWITCH. c=IN IP4 1.2.3.6. t=0 0. m=audio 28384 RTP/AVP 3 8 0 101 13. a=rtpmap:3 GSM/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=ptime:20. Is there anything wrong with this INVITE package and how can I trace this issue on Kamailio box? Content-Length = 270 bytes. I count 248 if line endings are \n, or 260 is lines end in \r\n. Packet is incomplete, looks like something is breaking when you are going over +/- 1300bytes per invite. Make a capture with tcpdump/tshark/wireshark to see if there is more. -- Telefoon: 088 0100 700 Sales: sa...@pocos.nl | Service: serviced...@pocos.nl http://www.pocos.nl/ | Croy 9c, 5653 LC Eindhoven | Kamer van Koophandel 17097024 ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Possible memory leak dealing with presence in kamailio
Nuno Reis writes: Here my publisher is Kamailio itself. Can someone elaborate a bit more on this issue and maybe we can get to bottom of it? when your application issues initial publish request, it does so without SIP-If-Match header. 200 ok from presence server then contains an etag in SIP-ETag header. when your application refreshes the publish, it must place this etag in SIP-If-Match header to prevent presence server from creating a new publication. for subscribes, your application must place in re-subscribe the same event header id param as the previous one had in order for the presence server to know that subscribe was not a new subscription. -- juha ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] topoh ACK Call-ID mismatch
On Wednesday 21 January 2015 08:45:59 Daniel-Constantin Mierla wrote: To understand properly, this is after the re-INVITE from B to A? I will look in the code as I get a chance, being out of the office for few days... Yes. Full trace below. Only the ACK to SIP_A for the 488 has the wrong Call- ID. Disabling masking fixes the problem, but I need topoh with callerid masking to enable an Avaya IP Office to make calls to itself via its external extensions. There is no hurry, it appears have been broken for a long time, a few weeks extra makes no difference to me :) I'll try a test server with a more recent version to see if the problem was fixed since 4.0.3. U SIP_A:5060 - KAMAILIO:5060 INVITE sip:+31880100...@sip.pocos.nl:5060 SIP/2.0. Via: SIP/2.0/UDP SIP_A:5060;branch=z9hG4bK396cd222;rport. From: +31880100705 sip:+31880100...@sip.pocos.nl;tag=as1b0b8097. To: sip:+31880100...@sip.pocos.nl:5060. Contact: sip:+31880100705@sipA. Call-ID: 0b5946b977210450571f767a19cd6...@99sip.pocos.nl. U KAMAILIO:5060 - SIP_A:5060 SIP/2.0 100 trying -- your call is important to us. Via: SIP/2.0/UDP SIP_A:5060;branch=z9hG4bK396cd222;rport=5060. From: +31880100705 sip:+31880100...@sip.pocos.nl;tag=as1b0b8097. To: sip:+31880100...@sip.pocos.nl:5060. Call-ID: 0b5946b977210450571f767a19cd6...@99sip.pocos.nl. U KAMAILIO:5060 - SIP_B:5060 INVITE sip:+31880100...@fax.pocos.nl SIP/2.0. Record-Route: sip:KAMAILIO;lr;ftag=as1b0b8097;did=fc2.c39. Via: SIP/2.0/UDP KAMAILIO;branch=z9hG4bK0a1a.d2ac1e03.0. Via: SIP/2.0/UDP 172.19.162.1;branch=pocos- rS4MusXox1l5QHyNxRy6uAXsEOdsxidSWGktxGZKWtQX- DQV9Acim8HoZpNlaA4kQsQiOsx6E8EnxAXfWgeKCgeS-RrKEAy*. From: +31880100705 sip:+31880100...@sip.pocos.nl;tag=as1b0b8097. To: sip:+31880100...@sip.pocos.nl:5060. Contact: sip:172.19.162.1;line=pcs-mp4KWiTsxRNdxG7KxGmKEry3xGnoxAxtuAxfuAMd. Call-ID: !!:xqXtWRMpZAngEsX3xGMtxGrgxDZgEA9JxR4AzGz8ZRIyWR4sh.yomqlACgxoC8K*. U SIP_B:5060 - KAMAILIO:5060 SIP/2.0 100 Trying. Via: SIP/2.0/UDP KAMAILIO;branch=z9hG4bK0a1a.d2ac1e03.0;received=KAMAILIO. Via: SIP/2.0/UDP 172.19.162.1;branch=pocos- rS4MusXox1l5QHyNxRy6uAXsEOdsxidSWGktxGZKWtQX- DQV9Acim8HoZpNlaA4kQsQiOsx6E8EnxAXfWgeKCgeS-RrKEAy*. Record-Route: sip:KAMAILIO;lr;ftag=as1b0b8097;did=fc2.c39. From: +31880100705 sip:+31880100...@sip.pocos.nl;tag=as1b0b8097. To: sip:+31880100...@sip.pocos.nl:5060. Call-ID: !!:xqXtWRMpZAngEsX3xGMtxGrgxDZgEA9JxR4AzGz8ZRIyWR4sh.yomqlACgxoC8K*. U SIP_B:5060 - KAMAILIO:5060 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP KAMAILIO;branch=z9hG4bK0a1a.d2ac1e03.0;received=KAMAILIO. Via: SIP/2.0/UDP 172.19.162.1;branch=pocos- rS4MusXox1l5QHyNxRy6uAXsEOdsxidSWGktxGZKWtQX- DQV9Acim8HoZpNlaA4kQsQiOsx6E8EnxAXfWgeK CgeS-RrKEAy*. Record-Route: sip:KAMAILIO;lr;ftag=as1b0b8097;did=fc2.c39. From: +31880100705 sip:+31880100...@sip.pocos.nl;tag=as1b0b8097. To: sip:+31880100...@sip.pocos.nl:5060;tag=as3869fe2a. Call-ID: !!:xqXtWRMpZAngEsX3xGMtxGrgxDZgEA9JxR4AzGz8ZRIyWR4sh.yomqlACgxoC8K*. U KAMAILIO:5060 - SIP_A:5060 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP SIP_A:5060;branch=z9hG4bK396cd222;rport=5060. Record-Route: sip:KAMAILIO;lr;ftag=as1b0b8097;did=fc2.c39. From: +31880100705 sip:+31880100...@sip.pocos.nl;tag=as1b0b8097. To: sip:+31880100...@sip.pocos.nl:5060;tag=as3869fe2a. Call-ID: 0b5946b977210450571f767a19cd6...@99sip.pocos.nl. U SIP_B:5060 - KAMAILIO:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP KAMAILIO;branch=z9hG4bK0a1a.d2ac1e03.0;received=KAMAILIO. Via: SIP/2.0/UDP 172.19.162.1;branch=pocos- rS4MusXox1l5QHyNxRy6uAXsEOdsxidSWGktxGZKWtQX- DQV9Acim8HoZpNlaA4kQsQiOsx6E8EnxAXfWgeKCgeS-RrKEAy*. Record-Route: sip:KAMAILIO;lr;ftag=as1b0b8097;did=fc2.c39. From: +31880100705 sip:+31880100...@sip.pocos.nl;tag=as1b0b8097. To: sip:+31880100...@sip.pocos.nl:5060;tag=as3869fe2a. Call-ID: !!:xqXtWRMpZAngEsX3xGMtxGrgxDZgEA9JxR4AzGz8ZRIyWR4sh.yomqlACgxoC8K*. U KAMAILIO:5060 - SIP_A:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP SIP_A:5060;branch=z9hG4bK396cd222;rport=5060. Record-Route: sip:KAMAILIO;lr;ftag=as1b0b8097;did=fc2.c39. From: +31880100705 sip:+31880100...@sip.pocos.nl;tag=as1b0b8097. To: sip:+31880100...@sip.pocos.nl:5060;tag=as3869fe2a. Call-ID: 0b5946b977210450571f767a19cd6...@99sip.pocos.nl. U SIP_A:5060 - KAMAILIO:5060 ACK sip:172.19.162.1;line=pcs-mp4KWiTsxRNdxG7KxGm6Wry3xGnoxAxtuAxfuAMpWArKEAy* SIP/2.0. Via: SIP/2.0/UDP SIP_A:5060;branch=z9hG4bK766d39a2;rport. Route: sip:KAMAILIO;lr;ftag=as1b0b8097;did=fc2.c39. From: +31880100705 sip:+31880100...@sip.pocos.nl;tag=as1b0b8097. To: sip:+31880100...@sip.pocos.nl:5060;tag=as3869fe2a. Contact: sip:+31880100705@sipA. Call-ID: 0b5946b977210450571f767a19cd6...@99sip.pocos.nl. U KAMAILIO:5060 - SIP_B:5060 ACK sip:+31880100799@SIP_B:5060 SIP/2.0. Via: SIP/2.0/UDP KAMAILIO;branch=z9hG4bKcydzigwkX. Via: SIP/2.0/UDP 172.19.162.1;branch=pocos- rS4MusXox1l5QHyNxRy6uAXsEOdsxidSWGktxGZKWtQX- DQA9Acim8HoZpNlaA4kQsQiOsmpE8MsWD7fWgeKCgeS-RrKEAy*. From: +31880100705 sip:+31880100...@sip.pocos.nl;tag=as1b0b8097. To: sip:+31880100...@sip.pocos.nl:5060;tag=as3869fe2a. Contact:
[SR-Users] Removing unwanted characters from From-header
Hi, Hello! I'm having trouble with matching massages for some Patton equipment, from the looks of it, Patton don't like / in headers. The initial INVITE from Patton is sent without / in To and From-headers. In the logs from Patton I can see that it matches the 100 trying that Kamailio sends back to it, and this message has To and From-headers without /, but the 180 Ringing and 200 OK that Kamailio sends is not matched, and these two has /. I would like to remove and in my onreply_route, how can I do this? Or does anyone have experience on how Patton matches messages? Br Sebastian Thörn ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] FW: KAMAILIO IMS Questions
Hello Folks:
Hope you can see this and share your ideas as to how to fix it?
Thanks and regards,
Zaka
From: Zaka Ul Isam
Sent: Wednesday, January 21, 2015 12:20 PM
To: Carsten Bock
Cc: mico...@gmail.com
Subject: RE: KAMAILIO IMS Questions
hello All:
First of all many thanks for your kind response. In fact my last few emails
did not make it to the list (and nor bounced). It seems there is an error on
the receiving mail server! However, I am regularly receiving list emails and
can respond to threads but due to unknown reason, can not initiate a thread!
Yes, it is an install from stable version source. Inorder to bouble check, we
even compiled this module from source and copied to the kamailio modules folder
replacing the actual module,but without luck!
Please suggest the fix.
Thanks and regards,
Zaka
From: Carsten Bock [cars...@ng-voice.com]
Sent: Wednesday, January 21, 2015 11:56 AM
To: Zaka Ul Isam
Cc: mico...@gmail.com
Subject: Re: KAMAILIO IMS Questions
Hi Zaka,
please forward the request to the sr-users list, as neither me or
Daniel provide direct support.
How did you install Kamailio? Are you sure, that you have the
SIP-Trace in (/usr/local/lib64/kamailio/modules/)?
From your log, i can see, that you did not install it from the
Debian-Packages
Thanks,
Carsten
2015-01-21 12:17 GMT+02:00 Zaka Ul Isam zaka...@albtelecom.al:
Hi Gentlemen:
Yet another stumbling block!
Now it is not setting module parameters or finding module SIPTRACE
The module is there, I have confirmed it. Below is the error log relevant
code snippet:
Error LOG
kamailio -cf /usr/local/etc/kamailio/pcscf/kamailio.cfg
loading modules under config path: /usr/local/lib64/kamailio/modules/
0(22035) ERROR: core [modparam.c:166]: set_mod_param_regex(): No module
matching siptrace found
0(22035) : core [cfg.y:3439]: yyerror_at(): parse error in config file
/usr/local/etc/kamailio/pcscf/kamailio.cfg, line 366, column 42: Can't set
module parameter
0(22035) ERROR: core [modparam.c:166]: set_mod_param_regex(): No module
matching siptrace found
0(22035) : core [cfg.y:3439]: yyerror_at(): parse error in config file
/usr/local/etc/kamailio/pcscf/kamailio.cfg, line 368, column 35: Can't set
module parameter
0(22035) ERROR: core [modparam.c:166]: set_mod_param_regex(): No module
matching siptrace found
0(22035) : core [cfg.y:3439]: yyerror_at(): parse error in config file
/usr/local/etc/kamailio/pcscf/kamailio.cfg, line 369, column 44: Can't set
module parameter
0(22035) ERROR: core [modparam.c:166]: set_mod_param_regex(): No module
matching siptrace found
0(22035) : core [cfg.y:3439]: yyerror_at(): parse error in config file
/usr/local/etc/kamailio/pcscf/kamailio.cfg, line 370, column 37: Can't set
module parameter
0(22035) ERROR: core [modparam.c:166]: set_mod_param_regex(): No module
matching siptrace found
0(22035) : core [cfg.y:3439]: yyerror_at(): parse error in config file
/usr/local/etc/kamailio/pcscf/kamailio.cfg, line 371, column 38: Can't set
module parameter
0(22035) : core [cfg.y:3439]: yyerror_at(): parse error in config file
/usr/local/etc/kamailio/pcscf/kamailio.cfg, line 372, column 1: syntax error
0(22035) : core [cfg.y:3439]: yyerror_at(): parse error in config file
/usr/local/etc/kamailio/pcscf/kamailio.cfg, line 372, column 1:
ERROR: bad config file (7 errors)
0(22035) WARNING: core [ppcfg.c:219]: pp_ifdef_level_check(): different
number of preprocessor directives: N(#!IF[N]DEF) - N(#!ENDIF) = 1
[root@IMS-dta1 pcscf]# locate modparam.c
bash: locate: command not found
Source File
}
regfree(preg);
pkg_free(reg);
if (!mod_found) {
LM_ERR(No module matching %s found\n, regex);
return -4;
}
return 0;
}
Please advise!
Kindest regards,
Zaka
From: Zaka Ul Isam
Sent: Friday, January 09, 2015 4:07 PM
To: Carsten Bock
Subject: RE: KAMAILIO IMS Questions
Hi Carsten:
Thanks a lot for your quick response and elaboration.
As regards HSS, for testbed, we plan to use FOKUS HSS, Hope it will serve
the purpose. Please note that in addition to DIALOG_NG old DIALOG Module was
also required!
Thanks again regards,
Zaka
From: Carsten Bock [cars...@ng-voice.com]
Sent: Friday, January 09, 2015 3:05 PM
To: Zaka Ul Isam
Subject: Re: KAMAILIO IMS Questions
Hi Zaka,
Thanks :-)
You questions:
1) you should be able to start the three components with kamailio -f
/path/to/kamailio.cfg.
You may need to modify the following line:
# -- module loading --
mpath=/usr/lib64/kamailio/modules_k/:/usr/lib64/kamailio/modules/:/usr/lib/kamailio/modules_k/:/usr/lib/kamailio/modules/
This defines, where Kamailio will
[SR-Users] Kamailio doesn't response to some INVITE packages
Hi, My Kamailio box works very well for a year, in front of a Freeswitch box. Nowadays, some of my users live problems about receiving calls. But this problem occurs on a couple of specific users. %1 of users complain about it. When I capture the traffic, I see that, Kamailio receives an invite package from freeswitch but takes no action. Normally it should response with a 100 trying message. Here is the INVITE package. 1.2.3.6 is the Freeswitch box and 1.2.3.2 is the Kamailio box. I captured this package on Kamailio box. U 1.2.3.6:5060 - 1.2.3.2:5060 INVITE sip:2...@test.example.net SIP/2.0. Via: SIP/2.0/UDP 1.2.3.6;rport;branch=z9hG4bKZU1Z76FvDZ26r. Route: sip:1.2.3.2;lr. Max-Forwards: 65. From: 90850885 sip:908508850...@test.example.net;tag=KjcgDe0NyKN0B. To: sip:2000@88.235.112.33:1028. Call-ID: 72b344f4-1c09-1233-ad8d-0050568e9066. CSeq: 70585075 INVITE. Contact: sip:mod_sofia@1.2.3.6:5060. User-Agent: FreeSWITCH-mod_sofia/1.4.14+git~20141119T221113Z~ca1d990cfc~64bit. Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE. Supported: timer, path, replaces. Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer. Content-Type: application/sdp. Content-Disposition: session. Content-Length: 270. X-AUTH-IP: 159.253.40.138. X-BF-SRC: 2. X-FS-Support: update_display,send_info. Remote-Party-ID: 90850885 sip:908508850...@test.example.net ;party=calling;screen=yes;privacy=off. . v=0. o=FreeSWITCH 1421813895 1421813896 IN IP4 1.2.3.6. s=FreeSWITCH. c=IN IP4 1.2.3.6. t=0 0. m=audio 28384 RTP/AVP 3 8 0 101 13. a=rtpmap:3 GSM/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=ptime:20. I use standart location lookup and relay procedure in Kamailio default script. Is there anything wrong with this INVITE package and how can I trace this issue on Kamailio box? Thank you. /Volkan ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio doesn't response to some INVITE packages
On Wednesday 21 January 2015 13:42:07 Volkan Oransoy wrote: Content-Length: 270. v=0. o=FreeSWITCH 1421813895 1421813896 IN IP4 1.2.3.6. s=FreeSWITCH. c=IN IP4 1.2.3.6. t=0 0. m=audio 28384 RTP/AVP 3 8 0 101 13. a=rtpmap:3 GSM/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=ptime:20. Is there anything wrong with this INVITE package and how can I trace this issue on Kamailio box? Content-Length = 270 bytes. I count 248 if line endings are \n, or 260 is lines end in \r\n. Packet is incomplete, looks like something is breaking when you are going over +/- 1300bytes per invite. Make a capture with tcpdump/tshark/wireshark to see if there is more. -- Telefoon: 088 0100 700 Sales: sa...@pocos.nl | Service: serviced...@pocos.nl http://www.pocos.nl/ | Croy 9c, 5653 LC Eindhoven | Kamer van Koophandel 17097024 ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio doesn't response to some INVITE packages
On Wednesday 21 January 2015 15:10:07 Volkan Oransoy wrote: The weird thing is, this problem is not persistent. Now it works as usual and I can't reproduce the problem. According to your reply, problem may be at Freeswitch box. It is to early to conclude, the ngrep outpout isn't complete. If an invite is fragmented and transmitted with UDP my experience is that you will not see the other fragments with ngrep. tcpdump/tshark will capture them (and may or may not show them properly in wireshark). How can I calculate Content Length from capture? And if this is a message size issue, how can I fix it? Content-Length is the size of the body, which starts after the first empty line. So from v=0 to a=ptime:20. The dots at the end of the lines are \r characters and an invisible \n you have to count too. Simpelest way is to save it to a file and look at the filesize :) -- Telefoon: 088 0100 700 Sales: sa...@pocos.nl | Service: serviced...@pocos.nl http://www.pocos.nl/ | Croy 9c, 5653 LC Eindhoven | Kamer van Koophandel 17097024 ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
