sr-users December 2016

sr-users@lists.kamailio.org

71 participants
102 discussions

INFO: jsonrpcs used instead of mi_fifo in the default kamailio.cfg and kamctl
by Daniel-Constantin Mierla 19 Dec '16

19 Dec '16

Hello, with MI code planned to be removed, I updated the kamctl and default kamailio.cfg to use jsonrpcs (jsonrpc server) module instead of mi_fifo to interact with kamailio at runtime. The default fifo file for rpc command is /var/run/kamailio/kamailio_rpc.fifo and expects JSONRPC commands as described at: - http://kamailio.org/docs/modules/devel/modules/jsonrpcs.html#idp31525708 Switching back to mi_fifo is still possible by loading the module and editing kamctlrc, but the module might not make it to 5.0, so for new installations and testing is better not to use it. Few rpc commands are missing in carrierroute, otherwise the kamctl commands should work just as before, but be aware that the output is now in json format. Testing of the master branch with the latest kamctl and providing feedback will be really appreciated -- I could do tests only for the modules I typically use. Cheers, Daniel -- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com

1 0

Forking with 404 replies
by José Seabra 19 Dec '16

19 Dec '16

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

2 3

RFC: renaming the modules with - (dash) in name
by Daniel-Constantin Mierla 19 Dec '16

19 Dec '16

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

1 1

Re: [SR-Users] Question on multiple 200OK received after forking
by Daniel-Constantin Mierla 19 Dec '16

19 Dec '16

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

1 0

(Correction) unusual characters added to reINVITE message
by AL S 19 Dec '16

19 Dec '16

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

2 1

Limiting calls based on CLI and dst number
by Cibin Paul 19 Dec '16

19 Dec '16

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

4 9

http_async_client - queries
by Ramachandran, Agalya (Contractor) 17 Dec '16

17 Dec '16

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

2 2

sipp dead calls
by Diego Nadares 16 Dec '16

16 Dec '16

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.

2 3

unusual characters added to reINVITE message by Kamailio
by AL S 16 Dec '16

16 Dec '16

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

1 0

ACK not routed to destination
by Wim Van Cauwenbergh 16 Dec '16

16 Dec '16

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)

3 3

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

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