sr-users July 2013

sr-users@lists.kamailio.org

92 participants
148 discussions

by Ovidiu Sas

I've seen a lot of discussions about running rtpproxy behind NAT. The fact is that standard vanilla rtpproxy can run behind NAT without any issues (no patches required). A few things must be addressed: - the proper ports must be forwarded from the public IP to the private IP; - when calling rtpproxy_offer/answer, the second parameter must be properly populated with the external public IP for streams from public network. I hope this brings some light over this highly debated topic. Regards, Ovidiu Sas -- VoIP Embedded, Inc. http://www.voipembedded.com

10 years, 9 months

RTPProxy in bridge mode with distributed kamailio (loadbalance and proxies)

by Nguyen Anh Tuan

Hi all, I have a question about Control RTPProxy in Bridge mode with distributed Kamalio topology, including a SIP Load Balance, RTPProxies and some SIP Proxies behind. SIPProxies control RTPProxy by Route [NATMANAGE]. PUBLIC IP ---- Load Balance -----> SIP Proxies | | control socket PUBLIC IP < ----- RTPProxy <-----------------| In the standalone Kamailio solution (only one SIP Server - without Load Balance), I configured RTPProxy bridge mode, works PERFECTLY!!! , BUT in the distributed Kamailio solution (LoadBalance -> Proxies) has big issue with RTP: - UA in front of NAT has only upload direction (1 way RTP) but UA behind NAT has both direction (2 ways RTP). RTP stream from UAC ------ > NAT ------ > RTPProxy Public Interface ------ > RTPProxy Local Interface -------> UAS in local area network RTP stream from UAS in local area network ------ > RTPProxy Local Interface -------> STOPs HERE!!!, NOT Transfers out The RTPProxy control is performed on the SIP Proxy (Route NATMANAGE has many cases with flags WFROCEE, WFROCEI, WFROCIE). In the case the same UA in front of NAT call (RTPProxy mode "WEE"), the call occurs normally, RTP Streams is OK on both sides, but the call in cases EI and IE has problems above. What could be going on? Thanks, Nguyen Anh Tuan

10 years, 9 months

Empty location table

by Alexey Rybalko

Hello! /kamilio 4.1.0/ Can anyone suggest why "location" table is empty despite that user registration works? save("location") return positive value. kamctl shows online users but if I look into kamailio.location it's empty anytime. # ----- registrar params ----- modparam("registrar", "method_filtering", 0) modparam("registrar", "append_branches", 1) modparam("registrar", "max_contacts", 10) modparam("registrar", "max_expires", 3600) ... Other strange the strange thing is that $rU is <null>. regards, Alexey

10 years, 9 months

Get duration in cnxcc:call-shutdown event

by Jayesh Nambiar

Hello, Is there a straight forward way of getting the duration of the call in cnxcc-call-shutdown event. The $DLG_lifetime returns NULL as the dialog does not exist. I dont get the value of $DLG_lifetime even in dialog:end event when the call ends through cnxcc module. Even the cdr flag of acc module doesn't get the duration and it logs, invalid values !! Currently, I am storing the timestamp in htable when the call is answered and then subtract it from the current timestamp in the cnxcc:shutdown event route to get the duration. Something like this: onreply_route[MANAGE_REPLY] { xdbg("incoming reply\n"); if(status=="200") { $sht(ts=>$ci) = $Ts; } } event_route[cnxcc:call-shutdown] { $var(duration) = $TS-$sht(ts=>$ci); sht_rm_name_re("ts=>$ci"); xlog("L_INFO", "Duration of call was $var(duration)"); } Any more correct way of doing this would be very helpful. Thanks, --- Jayesh

10 years, 9 months

nathelper and TCP

by Alex Balashov

Hi, fix_nated_contact() and fix_nated_register() don't appear to change the Contact at all when the source of the message is TCP. I log the value of $ct before and after, and there is no change. Kamailio tries to send to the original private IP, as well. The transport=TCP attribute is present in the Contact header in all cases. Is there something I should know about how to make these functions work with TCP? If not, what's the solution? Thank you, -- Alex -- Sent from my mobile, and thus lacking in the refinement one might expect from a fully fledged keyboard. 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

10 years, 10 months

Re: [SR-Users] Best Practice for Routing Trusted Peers to PSTN

by Daniel-Constantin Mierla

Hello, On 7/11/13 1:50 PM, Tony Turner wrote: > > Hi > > I am fine with registered users sending and receiving calls from/to PSTN. > > > Now I route registered users calls to/from PSTN fine > > Kamailailio<----->freeswitch<------------>IVR (PSTN) > > Best Practice for routing Trusted peers (inbound) to IVR/PSTN (SIP > Trunking Service) > > Trusted peer1 -----> Kamailio -----> freeswitch ------------> IVR (PSTN) > > Where do I/ how do I route calls from trusted peers not to users but > down to PSTN IVR? > > Say for example Trusted Peer 1 sends to my Kamailio IP > sip:398998xxxx@xx.xx.xx.xx:5060 > > As I add a Trusted peer I would like to add a route and insert prefix > for when it routes to freeswitch ---> > > Do I use carrier route or LCR etc, I want to be able to add trusted > peers but add routes without editing the config file and restarting > Kamailio. > > The reason I ask is I'd prefer to do it correct method at the start as > it's a nightmare changing once I have lots of trusted peers. > one way to do it is to use permissions modules to match the trusted peers using the address table (with allow_source_address(...)). In the address table, you can set the tag column to a value that you check in config and decide what to do further with routing. For example, the tag can be the LCR id or dispatcher setid. You don't need to restart with above solution, just issue mi/rpc reload commands for address and lcr/dispatcher whenever you change records in database. Cheers, Daniel -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

10 years, 10 months

TLS module fail to load

by Slava Bendersky

Hello Everyone, TLS module failing to load on Fedora 18 x86_64. [root@casipgw01 kamailio]# rpm -qa | grep openssl openssl-libs-1.0.1e-4.fc18.x86_64 openssl-1.0.1e-4.fc18.x86_64 openssl-devel-1.0.1e-4.fc18.x86_64 [root@casipgw01 kamailio]# rpm -qa | grep kamailio kamailio-tls-4.0.2-1.1.x86_64 kamailio-outbound-4.0.2-1.1.x86_64 kamailio-4.0.2-1.1.x86_64 kamailio-ldap-4.0.2-1.1.x86_64 0(10817) DEBUG: <core> [cfg.y:1791]: yyparse(): loading module tls.so 0(10817) DEBUG: <core> [sr_module.c:564]: load_module(): load_module: trying to load </usr/lib64/kamailio/modules/tls.so> 0(10817) DEBUG: <core> [mem/q_malloc.c:202]: qm_malloc_init(): qm_malloc_init: QM_OPTIMIZE=16384, /ROUNDTO=1024 0(10817) DEBUG: <core> [mem/q_malloc.c:204]: qm_malloc_init(): qm_malloc_init: QM_HASH_SIZE=1075, qm_block size=43048 0(10817) DEBUG: <core> [mem/q_malloc.c:205]: qm_malloc_init(): qm_malloc_init(0x7f2f21d56000, 33554432), start=0x7f2f21d56000 0(10817) DEBUG: <core> [mem/q_malloc.c:213]: qm_malloc_init(): qm_malloc_init: size= 33554432, init_overhead=43088 0(10817) DEBUG: <core> [mem/shm_mem.c:203]: shm_mem_init_mallocs(): shm_mem_init: success 0(10817) ERROR: tls [tls_init.c:471]: tls_pre_init(): Unable to set the memory allocation functions 0(10817) ERROR: <core> [sr_module.c:600]: load_module(): ERROR: load_module: /usr/lib64/kamailio/modules/tls.so: mod_register failed 0(10817) : <core> [cfg.y:3567]: yyerror_at(): parse error in config file //etc/kamailio/kamailio.cfg, line 154, column 12-19: failed to load module Any help thank you in advance.

10 years, 10 months

Problem with calling - SL local ACK found -> dropping it!

by Ismir Saljic

Hi, i have some strange problem with calling using kamailio 3.3.3. From the same client somethimes calls work well and after 2 or 3 successful calls I get this scenario. After receiving ACK as response to 407 Authentication Required Message, kamailio drops that ACK message and I got "SL local ACK found -> dropping it!" message in debug file. After this ACK message I get also 7 INVITES from client but there is no response from kamailio. I got this problem with clients that is behind multiple NATs. Other clients works well. Any advice would be appreciated. Thanks Ismir This debug log and SIP trace: Jul 15 15:42:16 www /usr/local/sbin/kamailio[31893]: DEBUG: <core> [parser/msg_parser.c:626]: method: <INVITE> Jul 15 15:42:16 www /usr/local/sbin/kamailio[31893]: DEBUG: <core> [parser/msg_parser.c:628]: uri: <sip:18@xxxxxxxxxxxxxxxx:51313> Jul 15 15:42:16 www /usr/local/sbin/kamailio[31893]: DEBUG: <core> [parser/msg_parser.c:630]: version: <SIP/2.0> Jul 15 15:42:16 www /usr/local/sbin/kamailio[31893]: DEBUG: <core> [parser/parse_via.c:1286]: Found param type 235, <rport> = <n/a>; state=6 Jul 15 15:42:16 www /usr/local/sbin/kamailio[31893]: DEBUG: <core> [parser/parse_via.c:1286]: Found param type 232, <branch> = <z9hG4bKPjae181f78c1b9456da09ed7b34575c0e3>; state=16 Jul 15 15:42:16 www /usr/local/sbin/kamailio[31893]: DEBUG: <core> [parser/parse_via.c:2561]: end of header reached, state=5 Jul 15 15:42:16 www /usr/local/sbin/kamailio[31893]: DEBUG: <core> [parser/msg_parser.c:511]: parse_headers: Via found, flags=2 Jul 15 15:42:16 www /usr/local/sbin/kamailio[31893]: DEBUG: <core> [parser/msg_parser.c:513]: parse_headers: this is the first via Jul 15 15:42:16 www /usr/local/sbin/kamailio[31893]: DEBUG: <core> [receive.c:149]: After parse_msg... Jul 15 15:42:16 www /usr/local/sbin/kamailio[31893]: DEBUG: <core> [receive.c:190]: preparing to run routing scripts... Jul 15 15:42:16 www /usr/local/sbin/kamailio[31893]: DEBUG: maxfwd [mf_funcs.c:85]: value = 70 Jul 15 15:42:16 www /usr/local/sbin/kamailio[31893]: DEBUG: <core> [parser/parse_to.c:802]: end of header reached, state=9 Jul 15 15:42:16 www /usr/local/sbin/kamailio[31893]: DEBUG: <core> [parser/msg_parser.c:188]: DEBUG: get_hdr_field: <To> [30]; uri=[sip:18@xxxxxxxxxxxxxxxx] Jul 15 15:42:16 www /usr/local/sbin/kamailio[31893]: DEBUG: <core> [parser/msg_parser.c:190]: DEBUG: to body [sip:18@xxxxxxxxxxxxxxxx#015#012] Jul 15 15:42:16 www /usr/local/sbin/kamailio[31893]: DEBUG: <core> [parser/msg_parser.c:168]: get_hdr_field: cseq <CSeq>: <23125> <INVITE> Jul 15 15:42:16 www /usr/local/sbin/kamailio[31893]: DEBUG: <core> [parser/msg_parser.c:202]: DEBUG: get_hdr_body : content_length=728 Jul 15 15:42:16 www /usr/local/sbin/kamailio[31893]: DEBUG: <core> [parser/msg_parser.c:104]: found end of header Jul 15 15:42:16 www /usr/local/sbin/kamailio[31893]: DEBUG: <core> [parser/parse_to.c:178]: DEBUG: add_param: tag=33fff09131774cf5a738a74919c50c90 Jul 15 15:42:16 www /usr/local/sbin/kamailio[31893]: DEBUG: <core> [parser/parse_to.c:802]: end of header reached, state=29 Jul 15 15:42:16 www /usr/local/sbin/kamailio[31893]: DEBUG: sanity [mod_sanity.c:255]: sanity checks result: 1 Jul 15 15:42:16 www /usr/local/sbin/kamailio[31893]: DEBUG: <core> [msg_translator.c:206]: check_via_address(64.61.94.148, 64.61.94.148, 0) Jul 15 15:42:16 www /usr/local/sbin/kamailio[31893]: DEBUG: siputils [checks.c:103]: no totag Jul 15 15:42:16 www /usr/local/sbin/kamailio[31893]: DEBUG: tm [t_lookup.c:1079]: DEBUG: t_check_msg: msg id=4 global id=3 T start=(nil) Jul 15 15:42:16 www /usr/local/sbin/kamailio[31893]: DEBUG: tm [t_lookup.c:527]: t_lookup_request: start searching: hash=63666, isACK=0 Jul 15 15:42:16 www /usr/local/sbin/kamailio[31893]: DEBUG: tm [t_lookup.c:485]: DEBUG: RFC3261 transaction matching failed Jul 15 15:42:16 www /usr/local/sbin/kamailio[31893]: DEBUG: tm [t_lookup.c:709]: DEBUG: t_lookup_request: no transaction found Jul 15 15:42:16 www /usr/local/sbin/kamailio[31893]: DEBUG: tm [t_lookup.c:1148]: DEBUG: t_check_msg: msg id=4 global id=4 T end=(nil) Jul 15 15:42:16 www /usr/local/sbin/kamailio[31893]: DEBUG: <core> [socket_info.c:583]: grep_sock_info - checking if host==us: 21==14 && [xxxxxxxxxxxxxxxx] == [xxxxxxxxxxxxxxxx] Jul 15 15:42:16 www /usr/local/sbin/kamailio[31893]: DEBUG: <core> [socket_info.c:587]: grep_sock_info - checking if port 51313 (advertise 0) matches port 5060 Jul 15 15:42:16 www /usr/local/sbin/kamailio[31893]: DEBUG: <core> [socket_info.c:583]: grep_sock_info - checking if host==us: 21==14 && [xxxxxxxxxxxxxxxx] == [xxxxxxxxxxxxxxxx] Jul 15 15:42:16 www /usr/local/sbin/kamailio[31893]: DEBUG: <core> [socket_info.c:587]: grep_sock_info - checking if port 51313 (advertise 0) matches port 5060 Jul 15 15:42:16 www /usr/local/sbin/kamailio[31893]: DEBUG: auth_db [authorize.c:363]: realm [xxxxxxxxxxxxxxxx] table [subscriber] flags [1] Jul 15 15:42:16 www /usr/local/sbin/kamailio[31893]: DEBUG: auth [api.c:86]: auth:pre_auth: Credentials with realm 'xxxxxxxxxxxxxxxx' not found Jul 15 15:42:16 www /usr/local/sbin/kamailio[31893]: DEBUG: auth_db [authorize.c:180]: no credentials Jul 15 15:42:16 www /usr/local/sbin/kamailio[31893]: DEBUG: auth [challenge.c:128]: build_challenge_hf: realm='xxxxxxxxxxxxxxxx' Jul 15 15:42:16 www /usr/local/sbin/kamailio[31893]: DEBUG: auth [challenge.c:270]: auth: 'Proxy-Authenticate: Digest realm="xxxxxxxxxxxxxxxx", nonce="UeRf01HkXqcKFA6LGeN8ssw6rbUNtt9N"#015#012' Jul 15 15:42:16 www /usr/local/sbin/kamailio[31893]: DEBUG: sl [sl.c:278]: reply in stateless mode (sl) Jul 15 15:42:16 www /usr/local/sbin/kamailio[31893]: DEBUG: <core> [msg_translator.c:206]: check_via_address(64.61.94.148, 64.61.94.148, 0) Jul 15 15:42:16 www /usr/local/sbin/kamailio[31893]: DEBUG: <core> [usr_avp.c:644]: DEBUG:destroy_avp_list: destroying list (nil) Jul 15 15:42:16 www /usr/local/sbin/kamailio[31893]: DEBUG: <core> [usr_avp.c:644]: DEBUG:destroy_avp_list: destroying list (nil) Jul 15 15:42:16 www /usr/local/sbin/kamailio[31893]: DEBUG: <core> [usr_avp.c:644]: DEBUG:destroy_avp_list: destroying list (nil) Jul 15 15:42:16 www /usr/local/sbin/kamailio[31893]: DEBUG: <core> [usr_avp.c:644]: DEBUG:destroy_avp_list: destroying list (nil) Jul 15 15:42:16 www /usr/local/sbin/kamailio[31893]: DEBUG: <core> [usr_avp.c:644]: DEBUG:destroy_avp_list: destroying list (nil) Jul 15 15:42:16 www /usr/local/sbin/kamailio[31893]: DEBUG: <core> [usr_avp.c:644]: DEBUG:destroy_avp_list: destroying list (nil) Jul 15 15:42:16 www /usr/local/sbin/kamailio[31893]: DEBUG: <core> [xavp.c:365]: destroying xavp list (nil) Jul 15 15:42:16 www /usr/local/sbin/kamailio[31893]: DEBUG: <core> [receive.c:293]: receive_msg: cleaning up Jul 15 15:42:16 www /usr/local/sbin/kamailio[31892]: DEBUG: <core> [parser/msg_parser.c:624]: SIP Request: Jul 15 15:42:16 www /usr/local/sbin/kamailio[31892]: DEBUG: <core> [parser/msg_parser.c:626]: method: <ACK> Jul 15 15:42:16 www /usr/local/sbin/kamailio[31892]: DEBUG: <core> [parser/msg_parser.c:628]: uri: <sip:18@xxxxxxxxxxxxxxxx:51313> Jul 15 15:42:16 www /usr/local/sbin/kamailio[31892]: DEBUG: <core> [parser/msg_parser.c:630]: version: <SIP/2.0> Jul 15 15:42:16 www /usr/local/sbin/kamailio[31892]: DEBUG: <core> [parser/parse_via.c:1286]: Found param type 235, <rport> = <n/a>; state=6 Jul 15 15:42:16 www /usr/local/sbin/kamailio[31892]: DEBUG: <core> [parser/parse_via.c:1286]: Found param type 232, <branch> = <z9hG4bKPjae181f78c1b9456da09ed7b34575c0e3>; state=16 Jul 15 15:42:16 www /usr/local/sbin/kamailio[31892]: DEBUG: <core> [parser/parse_via.c:2561]: end of header reached, state=5 Jul 15 15:42:16 www /usr/local/sbin/kamailio[31892]: DEBUG: <core> [parser/msg_parser.c:511]: parse_headers: Via found, flags=2 Jul 15 15:42:16 www /usr/local/sbin/kamailio[31892]: DEBUG: <core> [parser/msg_parser.c:513]: parse_headers: this is the first via Jul 15 15:42:16 www /usr/local/sbin/kamailio[31892]: DEBUG: <core> [receive.c:149]: After parse_msg... Jul 15 15:42:16 www /usr/local/sbin/kamailio[31892]: DEBUG: <core> [receive.c:190]: preparing to run routing scripts... Jul 15 15:42:16 www /usr/local/sbin/kamailio[31892]: DEBUG: <core> [parser/parse_to.c:178]: DEBUG: add_param: tag=2551d5cef8d8d01ed7d219eb9d65ff77.495f Jul 15 15:42:16 www /usr/local/sbin/kamailio[31892]: DEBUG: <core> [parser/parse_to.c:802]: end of header reached, state=29 Jul 15 15:42:16 www /usr/local/sbin/kamailio[31892]: DEBUG: <core> [parser/msg_parser.c:188]: DEBUG: get_hdr_field: <To> [72]; uri=[sip:18@xxxxxxxxxxxxxxxx] Jul 15 15:42:16 www /usr/local/sbin/kamailio[31892]: DEBUG: <core> [parser/msg_parser.c:190]: DEBUG: to body [sip:18@xxxxxxxxxxxxxxxx] *Jul 15 15:42:16 www /usr/local/sbin/kamailio[31892]: DEBUG: sl [sl_funcs.c:415]: SL **local ACK found -> dropping it!* Jul 15 15:42:16 www /usr/local/sbin/kamailio[31892]: DEBUG: <core> [usr_avp.c:644]: DEBUG:destroy_avp_list: destroying list (nil) Jul 15 15:42:16 www /usr/local/sbin/kamailio[31892]: DEBUG: <core> [usr_avp.c:644]: DEBUG:destroy_avp_list: destroying list (nil) Jul 15 15:42:16 www /usr/local/sbin/kamailio[31892]: DEBUG: <core> [usr_avp.c:644]: DEBUG:destroy_avp_list: destroying list (nil) Jul 15 15:42:16 www /usr/local/sbin/kamailio[31892]: DEBUG: <core> [usr_avp.c:644]: DEBUG:destroy_avp_list: destroying list (nil) Jul 15 15:42:16 www /usr/local/sbin/kamailio[31892]: DEBUG: <core> [usr_avp.c:644]: DEBUG:destroy_avp_list: destroying list (nil) Jul 15 15:42:16 www /usr/local/sbin/kamailio[31892]: DEBUG: <core> [usr_avp.c:644]: DEBUG:destroy_avp_list: destroying list (nil) Jul 15 15:42:16 www /usr/local/sbin/kamailio[31892]: DEBUG: <core> [xavp.c:365]: destroying xavp list (nil) Jul 15 15:42:16 www /usr/local/sbin/kamailio[31892]: DEBUG: <core> [receive.c:293]: receive_msg: cleaning up Jul 15 15:42:17 www rsyslogd-2177: imuxsock lost 198 messages from pid 31904 due to rate-limiting * * This is SIP trace from wireshark exported like text file. Session Initiation Protocol Request-Line: INVITE sip:18@xxxxxxxx:51414 SIP/2.0 Via: SIP/2.0/UDP 64.61.94.148:34402 ;rport;branch=z9hG4bKPjca2e03042a3541e2a0e7c99ae186e391 Max-Forwards: 70 From: <sip:tin4@xxxxxxx>;tag=cb5a108eb1be4bbd9487d18dab422f01 To: sip:18@xxxxxxxxxxxx Contact: <sip:tin4@64.61.94.148:34402;ob> Call-ID: 730a5b16f91e4031a6b2c082d77528de CSeq: 836 INVITE Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS Supported: replaces, 100rel, timer, norefersub Session-Expires: 1800 Min-SE: 90 Content-Type: application/sdp Content-Length: 728 Message Body Session Description Protocol Session Description Protocol Version (v): 0 Owner/Creator, Session Id (o): - 3582902074 3582902074 IN IP4 192.168.1.189 Session Name (s): pjmedia Bandwidth Information (b): AS:352 Time Description, active time (t): 0 0 Session Attribute (a): X-nat:0 Media Description, name and address (m): audio 40012 RTP/AVP 98 97 99 104 3 0 8 9 96 Connection Information (c): IN IP4 192.168.1.189 Bandwidth Information (b): TIAS:64000 Media Attribute (a): rtcp:40013 IN IP4 192.168.1.189 Media Attribute (a): sendrecv Media Attribute (a): rtpmap:98 speex/16000 Media Attribute (a): rtpmap:97 speex/8000 Media Attribute (a): rtpmap:99 speex/32000 Media Attribute (a): rtpmap:104 iLBC/8000 Media Attribute (a): fmtp:104 mode=30 Media Attribute (a): rtpmap:3 GSM/8000 Media Attribute (a): rtpmap:0 PCMU/8000 Media Attribute (a): rtpmap:8 PCMA/8000 Media Attribute (a): rtpmap:9 G722/8000 Media Attribute (a): rtpmap:96 telephone-event/8000 Media Attribute (a): fmtp:96 0-15 Media Description, name and address (m): video 40014 RTP/AVP 97 96 Connection Information (c): IN IP4 192.168.1.189 Bandwidth Information (b): TIAS:256000 Media Attribute (a): rtcp:40015 IN IP4 192.168.1.189 Media Attribute (a): sendrecv Media Attribute (a): rtpmap:97 H264/90000 Media Attribute (a): fmtp:97 profile-level-id=42e01e; packetization-mode=1 Media Attribute (a): rtpmap:96 H263-1998/90000 Media Attribute (a): fmtp:96 CIF=1;QCIF=1 Status-Line: SIP/2.0 407 Proxy Authentication Required Via: SIP/2.0/UDP 64.61.94.148:34402 ;rport=34402;branch=z9hG4bKPjca2e03042a3541e2a0e7c99ae186e391 From: <sip:tin4@xxxxxxxxxxxx>;tag=cb5a108eb1be4bbd9487d18dab422f01 To: sip:18@xxxxxxxxxxxx;tag=2551d5cef8d8d01ed7d219eb9d65ff77.6100 Call-ID: 730a5b16f91e4031a6b2c082d77528de CSeq: 836 INVITE Proxy-Authenticate: Digest realm="xxxxxxxxxxxx", nonce="UeR6JVHkePlxwVxs8eXM+HEbe9pFHRZR" Server: kamailio (3.3.3 (x86_64/linux)) Content-Length: 0 Request-Line: ACK sip:18@xxxxxxxxxxxx:51414 SIP/2.0 Via: SIP/2.0/UDP 64.61.94.148:34402 ;rport;branch=z9hG4bKPjca2e03042a3541e2a0e7c99ae186e391 Max-Forwards: 70 From: <sip:tin4@xxxxxxxxxxxx>;tag=cb5a108eb1be4bbd9487d18dab422f01 To: sip:18@xxxxxxxxxxxx;tag=2551d5cef8d8d01ed7d219eb9d65ff77.6100 Call-ID: 730a5b16f91e4031a6b2c082d77528de CSeq: 836 ACK Sequence Number: 836 Method: ACK Content-Length: 0 Request-Line: INVITE sip:18@xxxxxxxxxxxx:51414 SIP/2.0 Via: SIP/2.0/UDP 64.61.94.148:34402 ;rport;branch=z9hG4bKPjb155205250d944078ed58fef7aa8e1c0 Max-Forwards: 70 From: <sip:tin4@xxxxxxxxxxxx>;tag=cb5a108eb1be4bbd9487d18dab422f01 To: sip:18@xxxxxxxxxxxx Contact: <sip:tin4@64.61.94.148:34402;ob> Call-ID: 730a5b16f91e4031a6b2c082d77528de CSeq: 837 INVITE Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS Supported: replaces, 100rel, timer, norefersub Session-Expires: 1800 Min-SE: 90 Proxy-Authorization: Digest username="tin4", realm="xxxxxxxxxxxx", nonce="UeR6JVHkePlxwVxs8eXM+HEbe9pFHRZR", uri="sip:18@xxxxxxxxxxxx:51414", response="7e98dbc33c039e358728a08e8582c990" Content-Type: application/sdp Content-Length: 728 Message Body Session Description Protocol Session Description Protocol Version (v): 0 Owner/Creator, Session Id (o): - 3582902074 3582902074 IN IP4 192.168.1.189 Session Name (s): pjmedia Bandwidth Information (b): AS:352 Time Description, active time (t): 0 0 Session Attribute (a): X-nat:0 Media Description, name and address (m): audio 40012 RTP/AVP 98 97 99 104 3 0 8 9 96 Connection Information (c): IN IP4 192.168.1.189 Bandwidth Information (b): TIAS:64000 Media Attribute (a): rtcp:40013 IN IP4 192.168.1.189 Media Attribute (a): sendrecv Media Attribute (a): rtpmap:98 speex/16000 Media Attribute (a): rtpmap:97 speex/8000 Media Attribute (a): rtpmap:99 speex/32000 Media Attribute (a): rtpmap:104 iLBC/8000 Media Attribute (a): fmtp:104 mode=30 Media Attribute (a): rtpmap:3 GSM/8000 Media Attribute (a): rtpmap:0 PCMU/8000 Media Attribute (a): rtpmap:8 PCMA/8000 Media Attribute (a): rtpmap:9 G722/8000 Media Attribute (a): rtpmap:96 telephone-event/8000 Media Attribute (a): fmtp:96 0-15 Media Description, name and address (m): video 40014 RTP/AVP 97 96 Connection Information (c): IN IP4 192.168.1.189 Bandwidth Information (b): TIAS:256000 Media Attribute (a): rtcp:40015 IN IP4 192.168.1.189 Media Attribute (a): sendrecv Media Attribute (a): rtpmap:97 H264/90000 Media Attribute (a): fmtp:97 profile-level-id=42e01e; packetization-mode=1 Media Attribute (a): rtpmap:96 H263-1998/90000 Media Attribute (a): fmtp:96 CIF=1;QCIF=1 ......i deleted other INVITES (there was 7 INVITES) Request-Line: INVITE sip:18@xxxxxxxxxxxx:51414 SIP/2.0 Via: SIP/2.0/UDP 64.61.94.148:34402 ;rport;branch=z9hG4bKPjb155205250d944078ed58fef7aa8e1c0 Max-Forwards: 70 From: <sip:tin4@xxxxxxxxxxxx>;tag=cb5a108eb1be4bbd9487d18dab422f01 To: sip:18@xxxxxxxxxxx Contact: <sip:tin4@64.61.94.148:34402;ob> Call-ID: 730a5b16f91e4031a6b2c082d77528de CSeq: 837 INVITE Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS Supported: replaces, 100rel, timer, norefersub Session-Expires: 1800 Min-SE: 90 Proxy-Authorization: Digest username="tin4", realm="xxxxxxxxxxxx", nonce="UeR6JVHkePlxwVxs8eXM+HEbe9pFHRZR", uri="sip:18@xxxxxxxxxxxx:51414", response="7e98dbc33c039e358728a08e8582c990" Content-Type: application/sdp Content-Length: 728 Message Body Session Description Protocol Session Description Protocol Version (v): 0 Owner/Creator, Session Id (o): - 3582902074 3582902074 IN IP4 192.168.1.189 Session Name (s): pjmedia Bandwidth Information (b): AS:352 Time Description, active time (t): 0 0 Session Attribute (a): X-nat:0 Media Description, name and address (m): audio 40012 RTP/AVP 98 97 99 104 3 0 8 9 96 Connection Information (c): IN IP4 192.168.1.189 Bandwidth Information (b): TIAS:64000 Media Attribute (a): rtcp:40013 IN IP4 192.168.1.189 Media Attribute (a): sendrecv Media Attribute (a): rtpmap:98 speex/16000 Media Attribute (a): rtpmap:97 speex/8000 Media Attribute (a): rtpmap:99 speex/32000 Media Attribute (a): rtpmap:104 iLBC/8000 Media Attribute (a): fmtp:104 mode=30 Media Attribute (a): rtpmap:3 GSM/8000 Media Attribute (a): rtpmap:0 PCMU/8000 Media Attribute (a): rtpmap:8 PCMA/8000 Media Attribute (a): rtpmap:9 G722/8000 Media Attribute (a): rtpmap:96 telephone-event/8000 Media Attribute (a): fmtp:96 0-15 Media Description, name and address (m): video 40014 RTP/AVP 97 96 Connection Information (c): IN IP4 192.168.1.189 Bandwidth Information (b): TIAS:256000 Media Attribute (a): rtcp:40015 IN IP4 192.168.1.189 Media Attribute (a): sendrecv Media Attribute (a): rtpmap:97 H264/90000 Media Attribute (a): fmtp:97 profile-level-id=42e01e; packetization-mode=1 Media Attribute (a): rtpmap:96 H263-1998/90000 Media Attribute (a): fmtp:96 CIF=1;QCIF=1

10 years, 10 months

Asterisk and Kamailio Failover-Failback

by Rafael Carvallo

Hi everyone, currently i am running 2 Asterisk Servers that share the same dialplan and sip users, also they connect through DUNDi. Right now i need that the users on certain network register to one of the 2 servers and in case it fails, then kamailio should tell the phone to log in to the backup server. After the main server for that location is restored the phones should connect again to the main server. something like this: Location A Location B network: 192.168.1.0/24 network: 192.168.2.0/24 main asterisk server: 192.168.1.1 main asterisk server: 192.168.2.1 backup asterisk server: 192.168.2.1 backup asterisk server: 192.168.1.1 Unless there's a failover situation the phones on Location A (network: 192.168.1.0/24) should login to their main server, same with Location B , as soon the problem is fixed they should failback to their main server again, as i said both asterisk server share the same dialplan and sip-users. I don't want to let kamailio handle the user registration, i just need it to tell the phones which asterisk server should they contact based on their IP and main/backup server status. I tried to do it using DNS-SRV instead of Kamalio, it worked, but the phones never failback, also, DNS-SRV doesn't tell what server should be used based on the network the request came from. I've been trying to do this and really need help, any example would be appreciated, thanks in advance. Also i'd like to know if this is possible using H.323 protocol suit instead of SIP.

10 years, 10 months

Replication problems Registration Using t_replicate ().

by Raphael Borges

*Hello,* I have two servers in kamailio duality, I am using the function t_replicate () for replication log as below: Server 1 active t_replicate ("xxx.xxx.xxx.2", "5060"); Server 2 reserves t_replicate ("xxx.xxx.xxx.1", "5060"); But when the record is replicated to the standby server the parameter received is being filled with the active server IP, where the IP would Correro UAC, registry problems generating the backup server. Example Server 1 active xxx.xxx.xxx.1 $ Kamctl ul show Domain :: location table = 512 records = 1 = 1 max_slot AOR :: 4301 Contact :: sip: 4301(a)yyy.yyy.yyy.100; transport = udp Q = Expires :: 4566 Callid :: ccd0431c-6a4c-1231-0a94-7356c4f466e6 CSeq :: 46740150 User-agent :: stepo_LITE Received :: sip: yyy.yyy.yyy.100: 5060 State :: CS_SYNC Flags :: 0 CFLAG :: 0 Socket :: udp: xxx.xxx.xxx.1: 5060 Methods :: 8159 Server 2 Reserve xxx.xxx.xxx.2 $ Kamctl ul show Domain :: location table = 512 records = 1 = 1 max_slot AOR :: 4301 Contact :: sip: 4301(a)yyy.yyy.yyy.100; transport = udp Q = Expires :: 6665 Callid :: ec7cfd42-6a7c-1231-0f94-7356c4f466e6 CSeq :: 46750472 User-agent :: stepo_LITE Received :: sip: xxx.xxx.xxx.1: 5060 State :: CS_SYNC Flags :: 0 CFLAG :: 0 Socket :: udp: xxx.xxx.xxx.2: 5060 Methods :: 8159 Tkanks Raphael

10 years, 10 months

← Newer
1
...
6
7
8
9
10
11
12
...
15
Older →

Jump to page:

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 July 2013