sr-users December 2016

sr-users@lists.kamailio.org

71 participants
101 discussions

by José Seabra

Hello there, I have a Kamailio server acting as registrar server and when the subscriber has more than 1 AOR, kamailio sends an INVITES to each AOR, if one of them replies 404 what should be the kamailio behavior: 1. should Kamailio reply with an ACK and not pass the 404 to UAC? 2. should Kamailio forward the 404 to UAC? I'm asking this because i'm facing the second behavior, that is, kamailio is forwarding the 404 to UAC and the call is terminated. -- Regards José Seabra

7 years, 4 months

RFC: renaming the modules with - (dash) in name

by Daniel-Constantin Mierla

Hello, given the work for 5.0 which will bring major changes on source tree structure, I am considering to remove the - (dash) from the modules that have it in the name. There are 4 of them now: cpl-c janssonrpc-c jsonrpc-c jsonrpc-s One of the reasons is that this kind of name doesn't work for the feature of defining MOD_modname for each loaded module, because - is a separator for ids in config language grammar, so for example, MOD_jsonrpc-c cannot be used in an #!ifdef. More over, for embedded interpreters, most of exported functions there use kamailio module name as package name, and again this will break. Of course, a different package name can be defined, but won't be coherent anymore. Anyone against this renaming? Cheers, Daniel -- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com

7 years, 4 months

Re: [SR-Users] Question on multiple 200OK received after forking

by Daniel-Constantin Mierla

Hello, well, the specs say that all 200ok must be forwarded to the caller, because a middle point cannot decide for the user making the call. Even sending an ACK for the 200ok from a middle point is not enough because the callee of that branch will think it is in an active call. The caller can take different actions, the usual is to ACK the 2nd 200ok and then immediately send BYE. But it can also decide to end previous branch and switch to this one (e.g., uses better codecs, or has video, etc...). Cheers, Daniel On 14/12/2016 15:05, Marino Mileti wrote: > > Hi guys, > > > > I've a Kamailio instance listening on both eth0 and wlan0. > > Kamailio forks call to two branches, so both clients rings together. > > > > In case (very very very rare J) of simultaneous answers is there any > way to kill/hangup/destroy/cancel the "slowest" leg? I've tried to > arrange a semaphore with lock/unlock capabilities of cfgutils, I've > used the drop command but client still sending the 200OK because it's > waiting for an ACK L > > > > Any help will be very appreciated J > > > > /Marino Maria Mileti/// > > /marino.mileti(a)alice.it/ <mailto:marino.mileti@alice.it>// > > / / > > /cid:006a01cb6b0e$67eecdae$_CDOSYS2.0//Reduce your energy consumption > and keep polar bears on ice!/ > > > > > > ------------------------------------------------------------------------ > Avast logo > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> > > > Questa e-mail è stata controllata per individuare virus con Avast > antivirus. > www.avast.com > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> > > > > > > _______________________________________________ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users(a)lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users -- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com

7 years, 4 months

(Correction) unusual characters added to reINVITE message

by AL S

Hi, An INVITE with following FROM and TO headers received by Kamailio: From: <sip:+11111111111@10.10.10.10;user=phone>;tag=gK006cb08b To: <sip:+12222222222@20.20.20.20;user=phone> Kamailio forward it to next node with following FROM and TO headers: From: <sip:+11111111111@10.10.10.10>;tag=gK006cb08b To: <sip:+12222222222@20.20.20.20;user=phone> After 15 min, reINVITE for the same call received by Kamailio with following FROM and TO headers: From: <sip:12222222222@20.20.20.20;user=phone>;tag=gK04c77151 To: <sip:11111111111@10.10.10.10>;tag=gK006cb08b Kamailio forward reINVITE to next node with following unusual characters in TO headers From: <sip:12222222222@20.20.20.20;user=phone>;tag=gK04c77151 To: <sip:11111111111@10.10.10.10\000\000;user=phone>;tag=gK006cb08b I was wondering if there is a bug in Kamailio to insert these unusual characters. Thanks, AS

7 years, 4 months

Limiting calls based on CLI and dst number

by Cibin Paul

Hi, Is there a way to limit the number of active calls per cli or dst number basis? Yesterday my system had a ddos attack in which 123456 (CLI) was hitting 2345 (DID) at a rate of 100-200 calls per minute. I would like to restrict to 2-4 simultaneous calls per CLI/DST. Any help would be appreciated. Thanks, Cibin

7 years, 4 months

http_async_client - queries

by Ramachandran, Agalya (Contractor)

Hi team, We are trying to use kamailio for our project purpose, which will be used as a proxy server. Am trying to use "http_async_client" module to send my rest queries asynchronously. I have few queries regarding the usage of http_async_query() and using PUT method. http_append_header("Authorization: Bearer $var(auth)"); http_append_header("Content-Type: application/json"); http_set_method("PUT"); http_async_query("http://sdk-evm-wcdc-c-001.rtc.sys.comcast.net/events/createxmpprooteventfor…", "{'from_tn':'$fU','to_tn':'$tU','callid':'ci'}", "HTTP_REPLY"); Here am passing from, to, callid in post data field. Passing as 'key':'value' is mandatory or I can pass only value- ? In the file, async_http.c - in async_send_query(), if I modify the post data to the format I need, I see the value is truncated up to three fields only. How can I achieve that my payload format whatever I form in async_send_query(),doesn't get truncated and will be passed to the server-? Can you please explain how this works-? Also, I observed that kamailio is restricting the content-length of HTTP request to 256. Is this something modifiable-? If so please guide me how this can be achieved. Regards, Agalya

7 years, 4 months

sipp dead calls

by Diego Nadares

Hi guys, We are testing kamailio with sipp. We are running it with 20cps and some calls do the following. When Kamailio is processing the 'ringing' a '200ok' arrives in the middle. First, kamailio forwards the 200 ok and then the ringing. 'ACK' arrives and, I suppose, the call is established. The thing is than when the 'BYE' arrives kamailio responds with a 404. This is the summary of the call Id Time Source Destination Protocol Len Info 6483 2016-12-14 11:26:06.264697 SIPP-A KAMAILIO SIP/SDP 692 Request: INVITE sip:11111111@172.16.213.38:5060 | 6484 2016-12-14 11:26:06.264937 KAMAILIO SIPP-A SIP 367 Status: 100 trying -- your call is important to us | 6485 2016-12-14 11:26:06.266327 KAMAILIO SIPP-B SIP/SDP 1179 Request: INVITE sip:22222222@172.16.213.31:5060 | *6486 2016-12-14 11:26:06.267217 SIPP-B KAMAILIO SIP 566 Status: 180 Ringing | * 6487 2016-12-14 11:26:06.267268 SIPP-B KAMAILIO SIP/SDP 733 Status: 200 OK | 6488 2016-12-14 11:26:06.267758 KAMAILIO SIPP-A SIP/SDP 788 Status: 200 OK | *6489 2016-12-14 11:26:06.267833 *KAMAILIO SIPP-A* SIP 442 Status: 180 Ringing | * 6490 2016-12-14 11:26:06.268868 SIPP-A KAMAILIO SIP 493 Request: ACK sip:127.0.0.8;line=sr-N6IAzBFwMJZfWJZLM.M7MlF-W.y6Mx14NEt7Nw05NhPQKjaP | 6491 2016-12-14 11:26:06.269162 KAMAILIO SIPP-B SIP 609 Request: ACK sip:172.16.213.31:5060;transport=UDP | 6492 2016-12-14 11:26:06.269614 SIPP-A KAMAILIO SIP 404 Request: BYE sip:11111111@172.16.213.38:5060 | 6493 2016-12-14 11:26:06.269782 KAMAILIO SIPP-A SIP 348 Status: *404 Not here* | We are using modules rtjson, evapi, uac, topoh, rtpproxy for all calls. My debug level is -1. With higher levels this behavior increase. Kamailio is running in a virtual machine with centos7 with 8 cores and 8gb of ram. Do you need any further information? I can send you a pcap or ngrep file. Best regards, Diego.

7 years, 4 months

unusual characters added to reINVITE message by Kamailio

by AL S

Hi, An INVITE with following FROM and TO headers received by Kamailio: From: <sip:+11111111111@10.10.10.10;user=phone>;tag=gK006cb08b To: <sip:+12222222222@20.20.20.20;user=phone> Kamailio forward it to next node with following FROM and TO headers: From: <sip:+11111111111@10.10.10.10>;tag=gK006cb08b To: <sip:+12222222222@20.20.20.20;user=phone> After 15 min, reINVITE for the same call received by Kamailio with following FROM and TO headers: From: <sip:7272697443@71.44.13.84;user=phone>;tag=gK04c77151 To: <sip:2057030997@72.31.12.161>;tag=gK006cb08b Kamailio forward reINVITE to next node with following unusual characters in TO headers From: <sip:7272697443@71.44.13.84;user=phone>;tag=gK04c77151 To: <sip:2057030997@72.31.12.161\000\000;user=phone>;tag=gK006cb08b I was wondering if there is a bug in Kamailio to insert these unusual characters. Thanks, AS

7 years, 4 months

ACK not routed to destination

by Wim Van Cauwenbergh

Hi, I have setup kamailio with the dispatcher module and have a problem with the ACK in response to 200OK not being forwarded by kamailio: Scenario is very simple: sipp(.219) --> kamailio (.220) --> sipp(.239) SIP trace: root@DNS-enum-8Gb-3:/var/log# ngrep -W byline -d eth0 port 5060 interface: eth0 (10.57.26.0/255.255.255.0) filter: (ip or ip6) and ( port 5060 ) # U 10.57.26.219:5060 -> 10.57.26.220:5060 INVITE sip:service@10.57.26.220:5060 SIP/2.0. Via: SIP/2.0/UDP 10.57.26.219:5060;branch=z9hG4bK-15698-1-0. From: sipp <sip:sipp@10.57.26.219:5060>;tag=15698SIPpTag021. To: sut <sip:service@10.57.26.220:5060>. Call-ID: 1-15698(a)10.57.26.219. CSeq: 1 INVITE. Contact: sip:sipp@10.57.26.219:5060. Max-Forwards: 70. Subject: Performance Test. Content-Type: application/sdp. Content-Length: 135. . v=0. o=user1 53655765 2353687637 IN IP4 10.57.26.219. s=-. c=IN IP4 10.57.26.219. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000. # U 10.57.26.220:5060 -> 10.57.26.219:5060 SIP/2.0 100 trying -- your call is important to us. Via: SIP/2.0/UDP 10.57.26.219:5060;branch=z9hG4bK-15698-1-0. From: sipp <sip:sipp@10.57.26.219:5060>;tag=15698SIPpTag021. To: sut <sip:service@10.57.26.220:5060>. Call-ID: 1-15698(a)10.57.26.219. CSeq: 1 INVITE. Server: kamailio (4.2.0 (x86_64/linux)). Content-Length: 0. . # U 10.57.26.220:5060 -> 10.57.26.239:5060 INVITE sip:service@10.57.26.220:5060 SIP/2.0. Record-Route: <sip:10.57.26.220;lr>. Via: SIP/2.0/UDP 10.57.26.220;branch=z9hG4bKf92d.33550a94aa52aef3978cb507902d8aaa.0. Via: SIP/2.0/UDP 10.57.26.219:5060;branch=z9hG4bK-15698-1-0. From: sipp <sip:sipp@10.57.26.219:5060>;tag=15698SIPpTag021. To: sut <sip:service@10.57.26.220:5060>. Call-ID: 1-15698(a)10.57.26.219. CSeq: 1 INVITE. Contact: sip:sipp@10.57.26.219:5060. Max-Forwards: 69. Subject: Performance Test. Content-Type: application/sdp. Content-Length: 135. . v=0. o=user1 53655765 2353687637 IN IP4 10.57.26.219. s=-. c=IN IP4 10.57.26.219. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000. # U 10.57.26.239:5060 -> 10.57.26.220:5060 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP 10.57.26.220;branch=z9hG4bKf92d.33550a94aa52aef3978cb507902d8aaa.0, SIP/2.0/UDP 10.57.26.219:5060;branch=z9hG4bK-15698-1-0. From: sipp <sip:sipp@10.57.26.219:5060>;tag=15698SIPpTag021. To: sut <sip:service@10.57.26.220:5060>;tag=14783SIPpTag018. Call-ID: 1-15698(a)10.57.26.219. CSeq: 1 INVITE. Contact: <sip:10.57.26.239:5060;transport=UDP>. Content-Length: 0. . # U 10.57.26.239:5060 -> 10.57.26.220:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 10.57.26.220;branch=z9hG4bKf92d.33550a94aa52aef3978cb507902d8aaa.0, SIP/2.0/UDP 10.57.26.219:5060;branch=z9hG4bK-15698-1-0. From: sipp <sip:sipp@10.57.26.219:5060>;tag=15698SIPpTag021. To: sut <sip:service@10.57.26.220:5060>;tag=14783SIPpTag018. Call-ID: 1-15698(a)10.57.26.219. CSeq: 1 INVITE. Contact: <sip:10.57.26.239:5060;transport=UDP>. Content-Type: application/sdp. Content-Length: 135. . v=0. o=user1 53655765 2353687637 IN IP4 10.57.26.239. s=-. c=IN IP4 10.57.26.239. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000. # U 10.57.26.220:5060 -> 10.57.26.219:5060 SIP/2.0 180 Ringing. Via: SIP/2.0/UDP 10.57.26.219:5060;branch=z9hG4bK-15698-1-0. From: sipp <sip:sipp@10.57.26.219:5060>;tag=15698SIPpTag021. To: sut <sip:service@10.57.26.220:5060>;tag=14783SIPpTag018. Call-ID: 1-15698(a)10.57.26.219. CSeq: 1 INVITE. Contact: <sip:10.57.26.239:5060;transport=UDP>. Content-Length: 0. . # U 10.57.26.220:5060 -> 10.57.26.219:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 10.57.26.219:5060;branch=z9hG4bK-15698-1-0. From: sipp <sip:sipp@10.57.26.219:5060>;tag=15698SIPpTag021. To: sut <sip:service@10.57.26.220:5060>;tag=14783SIPpTag018. Call-ID: 1-15698(a)10.57.26.219. CSeq: 1 INVITE. Contact: <sip:10.57.26.239:5060;transport=UDP>. Content-Type: application/sdp. Content-Length: 135. . v=0. o=user1 53655765 2353687637 IN IP4 10.57.26.239. s=-. c=IN IP4 10.57.26.239. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000. # U 10.57.26.219:5060 -> 10.57.26.220:5060 ACK sip:10.57.26.239:5060;transport=UDP SIP/2.0. Via: SIP/2.0/UDP 10.57.26.219:5060;branch=z9hG4bK-15698-1-5. From: sipp <sip:sipp@10.57.26.219:5060>;tag=15698SIPpTag021. To: sut <sip:service@10.57.26.220:5060>;tag=14783SIPpTag018. Call-ID: 1-15698(a)10.57.26.219. CSeq: 1 ACK. Contact: sip:sipp@10.57.26.219:5060. Max-Forwards: 70. Subject: Performance Test. XContactinOK: <sip:10.57.26.239:5060;transport=UDP>. Content-Length: 0. . # U 10.57.26.239:5060 -> 10.57.26.220:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 10.57.26.220;branch=z9hG4bKf92d.33550a94aa52aef3978cb507902d8aaa.0, SIP/2.0/UDP 10.57.26.219:5060;branch=z9hG4bK-15698-1-0. From: sipp <sip:sipp@10.57.26.219:5060>;tag=15698SIPpTag021. To: sut <sip:service@10.57.26.220:5060>;tag=14783SIPpTag018. Call-ID: 1-15698(a)10.57.26.219. CSeq: 1 INVITE. Contact: <sip:10.57.26.239:5060;transport=UDP>. Content-Type: application/sdp. Content-Length: 135. . v=0. o=user1 53655765 2353687637 IN IP4 10.57.26.239. s=-. c=IN IP4 10.57.26.239. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000. # U 10.57.26.220:5060 -> 10.57.26.219:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 10.57.26.219:5060;branch=z9hG4bK-15698-1-0. From: sipp <sip:sipp@10.57.26.219:5060>;tag=15698SIPpTag021. To: sut <sip:service@10.57.26.220:5060>;tag=14783SIPpTag018. Call-ID: 1-15698(a)10.57.26.219. CSeq: 1 INVITE. Contact: <sip:10.57.26.239:5060;transport=UDP>. Content-Type: application/sdp. Content-Length: 135. . v=0. o=user1 53655765 2353687637 IN IP4 10.57.26.239. s=-. c=IN IP4 10.57.26.239. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000. # *U 10.57.26.219:5060 <http://10.57.26.219:5060> -> 10.57.26.220:5060 <http://10.57.26.220:5060>* *ACK sip:10.57.26.239:5060;transport=UDP SIP/2.0.* *Via: SIP/2.0/UDP 10.57.26.219:5060;branch=z9hG4bK-15698-1-5.* *From: sipp <sip:sipp@10.57.26.219:5060 <http://sip:sipp@10.57.26.219:5060>>;tag=15698SIPpTag021.* *To: sut <sip:service@10.57.26.220:5060 <http://sip:service@10.57.26.220:5060>>;tag=14783SIPpTag018.* *Call-ID: 1-15698(a)10.57.26.219 <1-15698(a)10.57.26.219>.* *CSeq: 1 ACK.* *Contact: sip:sipp@10.57.26.219:5060 <http://sip:sipp@10.57.26.219:5060>.* *Max-Forwards: 70.* *Subject: Performance Test.* *XContactinOK: <sip:10.57.26.239:5060;transport=UDP>.* *Content-Length: 0.* . # U 10.57.26.219:5060 -> 10.57.26.220:5060 BYE sip:10.57.26.239:5060;transport=UDP SIP/2.0. Via: SIP/2.0/UDP 10.57.26.219:5060;branch=z9hG4bK-15698-1-7. From: sipp <sip:sipp@10.57.26.219:5060>;tag=15698SIPpTag021. To: sut <sip:service@10.57.26.220:5060>;tag=14783SIPpTag018. Call-ID: 1-15698(a)10.57.26.219. CSeq: 2 BYE. Contact: sip:sipp@10.57.26.219:5060. Max-Forwards: 70. Subject: Performance Test. Content-Length: 0. . # U 10.57.26.220:5060 -> 10.57.26.219:5060 SIP/2.0 404 Not here. Via: SIP/2.0/UDP 10.57.26.219:5060;branch=z9hG4bK-15698-1-7. From: sipp <sip:sipp@10.57.26.219:5060>;tag=15698SIPpTag021. To: sut <sip:service@10.57.26.220:5060>;tag=14783SIPpTag018. Call-ID: 1-15698(a)10.57.26.219. CSeq: 2 BYE. Server: kamailio (4.2.0 (x86_64/linux)). Content-Length: 0. . # U 10.57.26.219:5060 -> 10.57.26.220:5060 BYE sip:service@10.57.26.220:5060 SIP/2.0. Via: SIP/2.0/UDP 10.57.26.219:5060;branch=z9hG4bK-15698-1--1. From: sipp <sip:sipp@10.57.26.219:5060>;tag=15698SIPpTag021. To: sut <sip:service@10.57.26.220:5060>;tag=14783SIPpTag018. Call-ID: 1-15698(a)10.57.26.219. CSeq: 3 BYE. Max-Forwards: 70. Contact: <sip:sipp@10.57.26.219:5060;transport=UDP>. Content-Length: 0. . # U 10.57.26.220:5060 -> 10.57.26.219:5060 SIP/2.0 404 Not here. Via: SIP/2.0/UDP 10.57.26.219:5060;branch=z9hG4bK-15698-1--1. From: sipp <sip:sipp@10.57.26.219:5060>;tag=15698SIPpTag021. To: sut <sip:service@10.57.26.220:5060>;tag=14783SIPpTag018. Call-ID: 1-15698(a)10.57.26.219. CSeq: 3 BYE. Server: kamailio (4.2.0 (x86_64/linux)). Content-Length: 0. . # U 10.57.26.239:5060 -> 10.57.26.220:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 10.57.26.220;branch=z9hG4bKf92d.33550a94aa52aef3978cb507902d8aaa.0, SIP/2.0/UDP 10.57.26.219:5060;branch=z9hG4bK-15698-1-0. From: sipp <sip:sipp@10.57.26.219:5060>;tag=15698SIPpTag021. To: sut <sip:service@10.57.26.220:5060>;tag=14783SIPpTag018. Call-ID: 1-15698(a)10.57.26.219. CSeq: 1 INVITE. Contact: <sip:10.57.26.239:5060;transport=UDP>. Content-Type: application/sdp. Content-Length: 135. . v=0. o=user1 53655765 2353687637 IN IP4 10.57.26.239. s=-. c=IN IP4 10.57.26.239. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000. # U 10.57.26.220:5060 -> 10.57.26.219:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 10.57.26.219:5060;branch=z9hG4bK-15698-1-0. From: sipp <sip:sipp@10.57.26.219:5060>;tag=15698SIPpTag021. To: sut <sip:service@10.57.26.220:5060>;tag=14783SIPpTag018. Call-ID: 1-15698(a)10.57.26.219. CSeq: 1 INVITE. Contact: <sip:10.57.26.239:5060;transport=UDP>. Content-Type: application/sdp. Content-Length: 135. . v=0. o=user1 53655765 2353687637 IN IP4 10.57.26.239. s=-. c=IN IP4 10.57.26.239. t=0 0. m=audio 6000 RTP/AVP 0. a=rtpmap:0 PCMU/8000. *kamailio.conf:* # ----- mi_fifo params ----- modparam("mi_fifo", "fifo_name", "/var/run/kamailio/kamailio_fifo") modparam("ctl", "binrpc", "unix:/var/run/kamailio/kamailio_ctl") # ----- rr params ----- # add value to ;lr param to cope with most of the UAs modparam("rr", "enable_full_lr", 0) # do not append from tag to the RR (no need for this script) modparam("rr", "append_fromtag", 0) # ----- acc params ----- modparam("acc", "log_flag", 1) modparam("acc", "failed_transaction_flag", 3) modparam("acc", "log_extra", "src_user=$fU;src_domain=$fd;dst_ouser=$tU;dst_user=$rU;dst_domain=$rd;src_ip=$si") # ----- tm params ----- modparam("tm", "fr_timer", 2000) modparam("tm", "fr_inv_timer", 40000) # ----- dispatcher params ----- #modparam("dispatcher", "db_url", # "mysql://openser:openserro@localhost/openser") modparam("dispatcher", "list_file", "/etc/kamailio/dispatcher.list") modparam("dispatcher", "table_name", "dispatcher") modparam("dispatcher", "flags", 2) modparam("dispatcher", "dst_avp", "$avp(AVP_DST)") modparam("dispatcher", "grp_avp", "$avp(AVP_GRP)") modparam("dispatcher", "cnt_avp", "$avp(AVP_CNT)") ####### Routing Logic ######## # main request routing logic route { # per request initial checks route(REQINIT); # handle requests within SIP dialogs route(WITHINDLG); ### only initial requests (no To tag) # CANCEL processing if (is_method("CANCEL")) { if (t_check_trans()) t_relay(); exit; } t_check_trans(); # record routing for dialog forming requests (in case they are routed) # - remove preloaded route headers remove_hf("Route"); if (is_method("INVITE|SUBSCRIBE")) record_route(); # account only INVITEs if (is_method("INVITE")) { setflag(1); # do accounting } # handle presence related requests route(PRESENCE); # handle registrations route(REGISTRAR); if ($rU==$null) { # request with no Username in RURI sl_send_reply("484","Address Incomplete"); exit; } # dispatch destinations route(DISPATCH); route(RELAY); } route[RELAY] { if (!t_relay()) { sl_reply_error(); } exit; } # Per SIP request initial checks route[REQINIT] { if (!mf_process_maxfwd_header("15")) { sl_send_reply("483","Too Many Hops"); exit; } # 1= only check the header RURI, 1126 checks some other general stuff if(!sanity_check("1126", "1")) { xlog("Malformed SIP message from $si:$sp\n"); exit; } } # Handle requests within SIP dialogs route[WITHINDLG] { if (has_totag()) { # sequential request withing a dialog should # take the path determined by record-routing xlog("#######WITHINDLG:hastotag $si:$sp\n"); if (loose_route()) { xlog("#######WITHINDLG:looseroute $si:$sp\n"); if (is_method("BYE")) { setflag(1); # do accounting ... setflag(3); # ... even if the transaction fails } route(RELAY); } else { if (is_method("SUBSCRIBE") && uri == myself) { # in-dialog subscribe requests route(PRESENCE); exit; } if ( is_method("ACK") ) { if ( t_check_trans() ) { xlog("#######WITHINDLG:ACK transaction found $si:$sp\n"); # non loose-route, but stateful ACK; # must be ACK after a 487 or e.g. 404 from upstream server t_relay(); exit; } else { # ACK without matching transaction ... ignore and discard. xlog("#######WITHINDLG:ACK no transaction found so discard $si:$sp\n"); exit; } } sl_send_reply("404","Not here"); } exit; } } Debug: Dec 15 15:12:02 DNS-enum-8Gb-3 kamailio[6864]: 1(6883) DEBUG: <core> [parser/msg_parser.c:623]: parse_msg(): SIP Request: Dec 15 15:12:02 DNS-enum-8Gb-3 kamailio[6864]: 1(6883) DEBUG: <core> [parser/msg_parser.c:625]: parse_msg(): method: <ACK> Dec 15 15:12:02 DNS-enum-8Gb-3 kamailio[6864]: 1(6883) DEBUG: <core> [parser/msg_parser.c:627]: parse_msg(): uri: <sip:10.57.26.239:5060 ;transport=UDP> Dec 15 15:12:02 DNS-enum-8Gb-3 kamailio[6864]: 1(6883) DEBUG: <core> [parser/msg_parser.c:629]: parse_msg(): version: <SIP/2.0> Dec 15 15:12:02 DNS-enum-8Gb-3 kamailio[6864]: 1(6883) DEBUG: <core> [parser/parse_via.c:1284]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-15698-1-5>; state=16 Dec 15 15:12:02 DNS-enum-8Gb-3 kamailio[6864]: 1(6883) DEBUG: <core> [parser/parse_via.c:2672]: parse_via(): end of header reached, state=5 Dec 15 15:12:02 DNS-enum-8Gb-3 kamailio[6864]: 1(6883) DEBUG: <core> [parser/msg_parser.c:513]: parse_headers(): parse_headers: Via found, flags=2 Dec 15 15:12:02 DNS-enum-8Gb-3 kamailio[6864]: 1(6883) DEBUG: <core> [parser/msg_parser.c:515]: parse_headers(): parse_headers: this is the first via Dec 15 15:12:02 DNS-enum-8Gb-3 kamailio[6864]: 1(6883) DEBUG: <core> [receive.c:154]: receive_msg(): After parse_msg... Dec 15 15:12:02 DNS-enum-8Gb-3 kamailio[6864]: 1(6883) DEBUG: <core> [receive.c:197]: receive_msg(): preparing to run routing scripts... Dec 15 15:12:02 DNS-enum-8Gb-3 kamailio[6864]: 1(6883) DEBUG: sl [sl_funcs.c:412]: sl_filter_ACK(): DEBUG : sl_filter_ACK: to late to be a local ACK! Dec 15 15:12:02 DNS-enum-8Gb-3 kamailio[6864]: 1(6883) DEBUG: <core> [parser/parse_addr_spec.c:176]: parse_to_param(): DEBUG: add_param: tag=14783SIPpTag018 Dec 15 15:12:02 DNS-enum-8Gb-3 kamailio[6864]: 1(6883) DEBUG: <core> [parser/parse_addr_spec.c:898]: parse_addr_spec(): end of header reached, state=29 Dec 15 15:12:02 DNS-enum-8Gb-3 kamailio[6864]: 1(6883) DEBUG: <core> [parser/msg_parser.c:190]: get_hdr_field(): DEBUG: get_hdr_field: <To> [57]; uri=[sip:service@10.57.26.220:5060] Dec 15 15:12:02 DNS-enum-8Gb-3 kamailio[6864]: 1(6883) DEBUG: <core> [parser/msg_parser.c:192]: get_hdr_field(): DEBUG: to body [sut < sip:service@10.57.26.220:5060>] Dec 15 15:12:02 DNS-enum-8Gb-3 kamailio[6864]: 1(6883) DEBUG: <core> [parser/msg_parser.c:170]: get_hdr_field(): get_hdr_field: cseq <CSeq>: <1> <ACK> Dec 15 15:12:02 DNS-enum-8Gb-3 kamailio[6864]: 1(6883) DEBUG: maxfwd [mf_funcs.c:85]: is_maxfwd_present(): value = 70 Dec 15 15:12:02 DNS-enum-8Gb-3 kamailio[6864]: 1(6883) DEBUG: sanity [mod_sanity.c:255]: w_sanity_check(): sanity checks result: 1 Dec 15 15:12:02 DNS-enum-8Gb-3 kamailio[6864]: 1(6883) DEBUG: siputils [checks.c:106]: has_totag(): totag found Dec 15 15:12:02 DNS-enum-8Gb-3 kamailio[6864]: 1(6883) ERROR: <script>: #######WITHINDLG:hastotag 10.57.26.219:5060 Dec 15 15:12:02 DNS-enum-8Gb-3 kamailio[6864]: 1(6883) DEBUG: <core> [parser/msg_parser.c:204]: get_hdr_field(): DEBUG: get_hdr_body : content_length=0 Dec 15 15:12:02 DNS-enum-8Gb-3 kamailio[6864]: 1(6883) DEBUG: <core> [parser/msg_parser.c:106]: get_hdr_field(): found end of header Dec 15 15:12:02 DNS-enum-8Gb-3 kamailio[6864]: 1(6883) DEBUG: rr [loose.c:113]: find_first_route(): No Route headers found Dec 15 15:12:02 DNS-enum-8Gb-3 kamailio[6864]: 1(6883) DEBUG: rr [loose.c:929]: loose_route(): There is no Route HF Dec 15 15:12:02 DNS-enum-8Gb-3 kamailio[6864]: 1(6883) DEBUG: tm [t_lookup.c:1072]: t_check_msg(): DEBUG: t_check_msg: msg id=9 global id=8 T start=(nil) Dec 15 15:12:02 DNS-enum-8Gb-3 kamailio[6864]: 1(6883) DEBUG: tm [t_lookup.c:527]: t_lookup_request(): t_lookup_request: start searching: hash=53919, isACK=1 Dec 15 15:12:02 DNS-enum-8Gb-3 kamailio[6864]: 1(6883) DEBUG: tm [t_lookup.c:485]: matching_3261(): DEBUG: RFC3261 transaction matching failed Dec 15 15:12:02 DNS-enum-8Gb-3 kamailio[6864]: 1(6883) DEBUG: tm [t_lookup.c:709]: t_lookup_request(): DEBUG: t_lookup_request: no transaction found Dec 15 15:12:02 DNS-enum-8Gb-3 kamailio[6864]: 1(6883) DEBUG: tm [t_lookup.c:1141]: t_check_msg(): DEBUG: t_check_msg: msg id=9 global id=9 T end=(nil) Dec 15 15:12:02 DNS-enum-8Gb-3 kamailio[6864]: 1(6883) ERROR: <script>: #######WITHINDLG:ACK no transaction found so discard 10.57.26.219:5060 Dec 15 15:12:02 DNS-enum-8Gb-3 kamailio[6864]: 1(6883) DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil)

7 years, 4 months

Siremis installation with postgresql.

by José Seabra

Hi there, I'm facing some issues trying to install siremis with postgresql. The file Config.xml has the correct configuration for postgresql driver but It seems that during installation phase siremis can't create database structure for postgresql. Anyone have installed siremis with postgresql, if yes can you share the steps needed for this installation. -- Cumprimentos José Seabra

7 years, 4 months

← Newer
1
2
3
4
5
6
7
8
9
10
11
Older →

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 December 2016