sr-users

sr-users@lists.kamailio.org

46 participants
37553 discussions

Drops on async_route with delay
by Alex Balashov 07 Feb '23

07 Feb '23

Hi, Some percentage of requests processed with async_route("REQ_PROCESS", "5") seem to end up with a resumed transaction, though most do. Not sure what the exact percentage is. The ones that don't Is this due to excessive requests? Is there a limit on internal IPC queue depth? Is it conceptually similar to a generic shared blocking queue internally, along the lines of 'mqueue'? Is there any reasonable way to troubleshoot this? Thanks! -- Alex -- Alex Balashov Principal Consultant … [View More]

3 3

Dispatcher + ENUM
by Jawaid Bazyar 07 Feb '23

07 Feb '23

Hi, Can DISPATCHER be used in conjunction with ENUM? E.g., to avoid sending requests to SIP destinations that are returned by ENUM, but, which DISPATCHER knows are down? Thanks, Jawaid

2 1

nating private uas to public ip addr
by Jack Murphy 06 Feb '23

06 Feb '23

I have a multi-homed kam with a uas behind one private interface and a public interface for the uac+sip provider. When the uac initiates a call, kam sends the invite to the private uas which sets up a b-leg call back to kam with a Contact header that has the uas' private ip address. I want to change that private ip address to be Kamailio's advertised/public ip address before it gets forwarded to the sip provider. I am rewriting Contact in a route from request_route like this: > if ($rP != … [View More]

2 2

htable: autoexpire vs updatedelete
by Дилян Палаузов 06 Feb '23

06 Feb '23

Hello, https://www.kamailio.org/docs/modules/devel/modules/htable#htable.p.htable says for modparam('htable', 'htable', '…autoexpire … updateexpire…') autoexpire -time in seconds to delete an item from a hash table if no update was done to it. If is missing or set to 0, the items won't expire. updateexpire - if set to 1 (default), the time until expiration of an item is reset when that item is updated. Certain uses of htable may dictate that updates should not reset the expiration timeout, … [View More]

2 2

Depending on topoh.mask_key Kamailio either cannot parse RURIs or reads invalid data
by Дилян Палаузов 06 Feb '23

06 Feb '23

Hello, when I use dns_try_naptr=on corelog=-1 debug=-1 enable_tls=yes use_dns_cache=off dns_cache_init=off modparam("topoh", "mask_key", "TEAI32l)- eauiDEUIA!?()") and run Kamailio under valgrind, Kamailio logs: 20(21) ERROR: kemix [kemix_mod.c:229]: ki_kx_get_ruri_attr(): failed to parse the R-URI 20(21) ERROR: rr [loose.c:1011]: loose_route_mode(): failed to parse Request URI The workflow is: I start Kamailio. A UDP-client registers. Then a websocket client calls the UDP-client. … [View More]Finally the websocket client hangs up. Valgrind does not report anything suspicious. When I use instead modparam("topoh", "mask_key", "TEAI32l") for the same workflow, with the same configuration, valgrind logs: ==14== Invalid read of size 4 ==14== at 0x4867E5: atomic_cmpxchg_int (atomic_x86.h:224) ==14== by 0x486830: futex_get (futexlock.h:99) ==14== by 0x490CE4: dns_hash_get (dns_cache.c:673) ==14== by 0x4972A6: dns_get_entry (dns_cache.c:2001) ==14== by 0x499288: dns_srv_get_he (dns_cache.c:2455) ==14== by 0x597AAD: no_naptr_srv_sip_resolvehost (resolve.c:1599) ==14== by 0x598332: naptr_sip_resolvehost (resolve.c:1675) ==14== by 0x5983C5: _sip_resolvehost (resolve.c:1707) ==14== by 0x49943B: dns_srv_sip_resolvehost (dns_cache.c:2516) ==14== by 0x49B3DD: dns_sip_resolvehost (dns_cache.c:2738) ==14== by 0x59846A: sip_hostport2su (resolve.c:1727) ==14== by 0x4CB951: forward_request (forward.c:515) ==14== by 0x99993CD: t_relay_to (t_funcs.c:300) ==14== by 0x99EBA32: _w_t_relay_to (tm.c:1764) ==14== by 0x99F4DEB: ki_t_relay (tm.c:2917) ==14== by 0xA80A94B: sr_kemi_lua_exec_func_ex (app_lua_api.c:1022) ==14== by 0xA81237D: sr_kemi_lua_exec_func (app_lua_api.c:1706) ==14== by 0xA81B93F: sr_kemi_lua_exec_func_209 (app_lua_kemi_export.c:1717) ==14== by 0xA8383C0: luaD_precall (in /lib64/kamailio/modules/app_lua.so) ==14== by 0xA84C4CA: luaV_execute (in /lib64/kamailio/modules/app_lua.so) ==14== by 0xA838C90: luaD_callnoyield (in /lib64/kamailio/modules/app_lua.so) ==14== by 0xA837029: luaD_rawrunprotected (in /lib64/kamailio/modules/app_lua.so) ==14== by 0xA8391DF: luaD_pcall (in /lib64/kamailio/modules/app_lua.so) ==14== by 0xA8333DE: lua_pcallk (in /lib64/kamailio/modules/app_lua.so) ==14== by 0xA806F0C: app_lua_run_ex (app_lua_api.c:773) ==14== by 0xA825F06: sr_kemi_config_engine_lua (app_lua_mod.c:119) ==14== by 0x5048BE: sr_kemi_route (kemi.c:3784) ==14== by 0x588909: receive_msg (receive.c:502) ==14== by 0xA609ADF: ws_frame_receive (ws_frame.c:644) ==14== by 0x4BCAAB: sr_event_exec (events.c:299) ==14== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==14== ==14== ==14== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==14== Access not within mapped region at address 0x0 ==14== at 0x4867E5: atomic_cmpxchg_int (atomic_x86.h:224) ==14== by 0x486830: futex_get (futexlock.h:99) ==14== by 0x490CE4: dns_hash_get (dns_cache.c:673) ==14== by 0x4972A6: dns_get_entry (dns_cache.c:2001) ==14== by 0x499288: dns_srv_get_he (dns_cache.c:2455) ==14== by 0x597AAD: no_naptr_srv_sip_resolvehost (resolve.c:1599) ==14== by 0x598332: naptr_sip_resolvehost (resolve.c:1675) ==14== by 0x5983C5: _sip_resolvehost (resolve.c:1707) ==14== by 0x49943B: dns_srv_sip_resolvehost (dns_cache.c:2516) ==14== by 0x49B3DD: dns_sip_resolvehost (dns_cache.c:2738) ==14== by 0x59846A: sip_hostport2su (resolve.c:1727) ==14== by 0x4CB951: forward_request (forward.c:515) ==14== by 0x99993CD: t_relay_to (t_funcs.c:300) ==14== by 0x99EBA32: _w_t_relay_to (tm.c:1764) ==14== by 0x99F4DEB: ki_t_relay (tm.c:2917) ==14== by 0xA80A94B: sr_kemi_lua_exec_func_ex (app_lua_api.c:1022) ==14== by 0xA81237D: sr_kemi_lua_exec_func (app_lua_api.c:1706) ==14== by 0xA81B93F: sr_kemi_lua_exec_func_209 (app_lua_kemi_export.c:1717) ==14== by 0xA8383C0: luaD_precall (in /lib64/kamailio/modules/app_lua.so) ==14== by 0xA84C4CA: luaV_execute (in /lib64/kamailio/modules/app_lua.so) ==14== by 0xA838C90: luaD_callnoyield (in /lib64/kamailio/modules/app_lua.so) ==14== by 0xA837029: luaD_rawrunprotected (in /lib64/kamailio/modules/app_lua.so) ==14== by 0xA8391DF: luaD_pcall (in /lib64/kamailio/modules/app_lua.so) ==14== by 0xA8333DE: lua_pcallk (in /lib64/kamailio/modules/app_lua.so) ==14== by 0xA806F0C: app_lua_run_ex (app_lua_api.c:773) ==14== by 0xA825F06: sr_kemi_config_engine_lua (app_lua_mod.c:119) ==14== by 0x5048BE: sr_kemi_route (kemi.c:3784) ==14== by 0x588909: receive_msg (receive.c:502) ==14== by 0xA609ADF: ws_frame_receive (ws_frame.c:644) ==14== by 0x4BCAAB: sr_event_exec (events.c:299) The stacktrace with the values of the variables is available at https://github.com/kamailio/kamailio/issues/3350 . Or at least these things seem very similar to me. Any idea? I can share the OCI-image and the full configuration. Greetings Дилян [View Less]

3 4

topoh: th_mask_decode (th_mask_encode (x)) ≠ x
by Дилян Палаузов 06 Feb '23

06 Feb '23

Hello, after receiving INVITE sip:test-gnome-calls@bapha.be SIP/2.0 Via: SIP/2.0/WSS bapha.be;branch=z9hG4bK974100 Max-Forwards: 70 To: <sip:test-gnome-calls@bapha.be> From: "Online https://sip.bapha.be" <sip:online@bapha.be>;tag=12q2efc423 Call-ID: fkhe8faq0fh80glmq59i CSeq: 5622 INVITE Contact: <sip:4q5ne5no@bapha.be;transport=ws;ob> Allow: ACK,CANCEL,INVITE,MESSAGE,BYE,OPTIONS,INFO,NOTIFY,REFER Supported: outbound User-Agent: SIP.js/0.7.8 Content-Type: application/sdp … [View More]Content-Length: 1964 v=0 o=mozilla...THIS_IS_SDPARTA-99.0 8263261229339246488 0 IN IP4 0.0.0.0 s=- … kamailio calls th_mask_encode( char *in = "sip:test-gnome-calls@bapha.be;gr=urn:uuid:f2f5a3cf-a0fb-0047-be50- 740fb9bdc562;alias=87.118.146.153~60722~2>;+sip.instance=\"<urn:uuid:f2f5a3cf-a0fb-0047-be50- 740fb9bdc562>";+org.linphone.specs=\"conference/1.0,ephemeral/1.1,groupchat/1.1,groupchat/1.2,lime\n"\ "Content-Type: application/sdp and so on", int ilen = 107, str prefix = { .len = 23, .s ="sip:127.3.4.84;line=sr-" }, int *olen). It returns olen=167, and the string "sip:127.3.4.84;line=sr- if7s1mg7i36PNf0AbdwPpfzlbqWEpLzsSGItpLwyN39ZMY4t1mCTSd6DNo4LWdIOpfpPp5FLpUQscX63Kd47W5EPWO6sNL90pLgoW5p-1fzlSdzO25n3KoIk1vHkWXptc5wOeopsWO9-eo9*". Then Kamailio forwards (sends): Contact: <sip:127.3.4.84;line=sr-if7s1mg7i36PNf0AbdwPpfzlbqWEpLzsSGItpLwyN39ZMY4t1mCTSd6DNo4LWdIOpfpPp5FLpUQscX63Kd47W5EPWO6sNL90pLgoW5p- 1fzlSdzO25n3KoIk1vHkWXptc5wOeopsWO9-eo9*>;+sip.instance="<urn:uuid:f2f5a3cf-a0fb-0047-be50- 740fb9bdc562>";+org.linphone.specs="conference/1.0,ephemeral/1.1,groupchat/1.1,groupchat/1.2,lime" which at some point leads to ACK sip:127.3.4.84;line=sr-if7s1mg7i36pnf0abdwppfzlbqweplzssgitplwyn39zmy4t1mctsd6dno4lwdiopfppp5flpuqscx63kd47w5epwo6snl90plgow5p- 1fzlsdzo25n3koik1vhkwxptc5woeopswo9-eo9* SIP/2.0 and BYE sip:127.3.4.84;line=sr-if7s1mg7i36pnf0abdwppfzlbqweplzssgitplwyn39zmy4t1mctsd6dno4lwdiopfppp5flpuqscx63kd47w5epwo6snl90plgow5p- 1fzlsdzo25n3koik1vhkwxptc5woeopswo9-eo9* SIP/2.0 Below you can find th_test.c . The functions th_mask_encode() and th_mask_decode() there are identical to the same functions in src/modules/topoh/th_mask.c . main() provides some tests: Passing «sip:test-gnome-calls@bapha.be;gr=urn:uuid:f2f5a3cf-a0fb-0047-be50- 740fb9bdc562;alias=87.118.146.153~60472~2>;+sip.instance="<urn:uuid:f2f5a3cf-a0fb-0047-be50- 740fb9bdc562>";+org.linphone.specs="conference/1.0,ephemeral/1.1,groupchat/1.1,groupchat/1.2,lime» to th_mask_encode() returns sip:127.3.4.84;line=sr-if7s1mg7i36PNf0AbdwPpfzlbqWEpLzsSGItpLwyN39ZMY4t1mCTSd6DNo4LWdIOpfpPp5FLpUQscX63Kd47W5EPWO6sNL90pLgoW5p- 1fzlSdzO25n3KoIk1vHkWXptc5wOeopsWXi-eo9* (this is what Kamailio does send out). Passing the last string to th_mask_decode() returns sip:test-gnome-calls@bapha.be;gr=urn:uuid:f2f5a3cf-a0fb-0047-be50-740fb9bdc562;alias=87.118.1 the ;alias= is incomplete, compared to the origin. The above ACK leads to passing "sr-if7s1mg7i36pnf0abdwppfzlbqweplzssgitplwyn39zmy4t1mctsd6dno4lwdiopfppp5flpuqscx63kd47w5epwo6snl90plgow5p-1fzlsdzo25n3koik1vhkwxptc5woeopswo9-eo9* SIP/2.0\n"\ "Route: <sip:Q+L06HX94DMPtQWQTI5OE8SQTI5O4MY=@144.76.142.78;transport=ws;r2=on;lr;nat=yes>\n"\ "Route: <sip:127.3.4.84;line=sr-if7s17IB5XEfVzn0WIgWwqggCTzwV5C2g5R5wCg4WwrQ5CuZ6XIQWvH3WUHkWX9tWOnyMq4RbmWsb34Q2YgoiXP-coTAboPlioPtpY6Z8dCO>\n"\ to th_mask_decode() and the result is callub.p.b;rn:s.d2lQg#cfa=bA07beQ7R409bcQ62;alac=87718*1P.15#~60R22~2 with the dots being unprintable characters. (result is garbage). I have seen that callub.p.b in the unparsable R-URI reports from Kamailio. That is an indication that th_mask_decode() does not decode the Contact encoded by th_mask_encode() correctly. Valgrind does not report improper memory usage. Greetings Dilyan gcc -g -o th-test ./th-test.c && ./th-test th-test.c #include <stdio.h> #include <stdlib.h> #include <string.h> #define TH_EB64I \ "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789.-" char _th_EB64[65] = "EFvXIzGq94xKcW126gV5wCdYpNSbiM8enRUou7LmhajBlPtAsk-OQTf3H0DyrZ.J"; int _th_DB64[256]; char *_th_PD64 = "*"; struct str_ { char* s; /**< Pointer to the first character of the string */ int len; /**< Length of the string */ }; typedef struct str_ str; str prefix = { .len = 23, .s ="sip:127.3.4.84;line=sr-" }; char* th_mask_encode(char *in, int ilen, const str *prefix, int *olen); char* th_mask_decode(char *in, int ilen, const str *prefix, int extra, int *olen); char* th_mask_encode(char *in, int ilen, const str *prefix, int *olen) { char *out; int left; int idx; int i; int r; char *p; int block; *olen = (((ilen+2)/3)<<2) + ((prefix!=NULL&&prefix->len>0)?prefix->len:0); out = (char*)malloc((*olen+1)*sizeof(char)); if(out==NULL) { fprintf(stderr, "malloc error\n"); *olen = 0; return NULL; } memset(out, 0, (*olen+1)*sizeof(char)); if(prefix!=NULL&&prefix->len>0) memcpy(out, prefix->s, prefix->len); p = out + (int)((prefix!=NULL&&prefix->len>0)?prefix->len:0); for(idx=0; idx<ilen; idx+=3) { left = ilen - idx - 1 ; left = (left>1)?2:left; block = 0; for(i=0, r=16; i<=left; i++, r-=8) block += ((unsigned char)in[idx+i]) << r; *(p++) = _th_EB64[(block >> 18) & 0x3f]; *(p++) = _th_EB64[(block >> 12) & 0x3f]; *(p++) = (left>0)?_th_EB64[(block >> 6) & 0x3f]:_th_PD64[0]; *(p++) = (left>1)?_th_EB64[block & 0x3f]:_th_PD64[0]; } return out; } char* th_mask_decode(char *in, int ilen, const str *prefix, int extra, int *olen) { char *out; int n; int block; int idx; int i; int j; int end; char c; for(n=0,i=ilen-1; in[i]==_th_PD64[0]; i--) n++; *olen = (((ilen-((prefix!=NULL&&prefix->len>0)?prefix->len:0)) * 6) >> 3) - n; if (*olen<=0) { return NULL; } out = (char*)malloc((*olen+1+extra)*sizeof(char)); if(out==NULL) { fprintf(stderr, "malloc error\n"); *olen = 0; return NULL; } memset(out, 0, (*olen+1+extra)*sizeof(char)); end = ilen - n; i = (prefix!=NULL&&prefix->len>0)?prefix->len:0; for(idx=0; i<end; idx+=3) { block = 0; for(j=0; j<4 && i<end ; j++) { c = _th_DB64[(int)in[i++]]; if(c<0) { free(out); *olen = 0; return NULL; } block += c << (18 - 6*j); } for(j=0, n=16; j<3 && idx+j< *olen; j++, n-=8) out[idx+j] = (char)((block >> n) & 0xff); } return out; } int main() { //this is from th_mask_init for(int i=0; i<256; i++) _th_DB64[i] = -1; for(int i=0; i<64; i++) _th_DB64[(int)_th_EB64[i]] = i; int olen, o2; char *end; char *input = "sip:test-gnome-calls@bapha.be;gr=urn:uuid:f2f5a3cf-a0fb-0047-be50- 740fb9bdc562;alias=87.118.146.153~60472~2>;+sip.instance=\"<urn:uuid:f2f5a3cf-a0fb-0047-be50- 740fb9bdc562>\";+org.linphone.specs=\"conference/1.0,ephemeral/1.1,groupchat/1.1,groupchat/1.2,lime\""; printf("input=[%s]\n", input); char* middle = th_mask_encode (input, 107, &prefix, &olen); printf("olen = %i, middle=[%s]\n", olen, middle); end = th_mask_decode(middle, 147, &prefix, 0, &o2); printf("o2 = %i, end=[%s]\n", o2, end); char * b1 = "sr-if7s1mg7i36pnf0abdwppfzlbqweplzssgitplwyn39zmy4t1mctsd6dno4lwdiopfppp5flpuqscx63kd47w5epwo6snl90plgow5p- 1fzlsdzo25n3koik1vhkwxptc5woeopswo9-eo9*"; o2 = 0; end = th_mask_decode(b1, 147, &prefix, 0, &o2); printf("o2 = %i, end=[%s]\n", o2, end); char* b2 = "sr-if7s1mg7i36pnf0abdwppfzlbqweplzssgitplwyn39zmy4t1mctsd6dno4lwdiopfppp5flpuqscx63kd47w5epwo6snl90plgow5p-1fzlsdzo25n3koik1vhkwxptc5woeopswo9-eo9* SIP/2.0\n"\ "Route: <sip:Q+L06HX94DMPtQWQTI5OE8SQTI5O4MY=@144.76.142.78;transport=ws;r2=on;lr;nat=yes>\n"\ "Route: <sip:127.3.4.84;line=sr-if7s17IB5XEfVzn0WIgWwqggCTzwV5C2g5R5wCg4WwrQ5CuZ6XIQWvH3WUHkWX9tWOnyMq4RbmWsb34Q2YgoiXP-coTAboPlioPtpY6Z8dCO>\n"\ "Via: SIP/2.0/WSS bapha.be;branch=z9hG4bK9069155\n"\ "Max-Forwards: 70\n"\ "To: <sip:test-gnome-calls@bapha.be>;tag=Pn4npAj\n"\ "From: \"Online https://sip.bapha.be\" <sip:online@bapha.be>;tag=12q2efc423\n"\ "Call-ID: fkhe8faq0fh80glmq59i\n"\ "CSeq: 5623 ACK\n"\ "Supported: outbound\n"\ "User-Agent: SIP.js/0.7.8\n"\ "Content-Length: 0\n"\ "\n"; o2 = 0; end = th_mask_decode(b2, 147, &prefix, 0, &o2); printf("o2 = %i, end=[%s]\n", o2, end); return 0; } [View Less]

2 1

no autocomplete for kamcmd for latest debian packages
by Ovidiu Sas 04 Feb '23

04 Feb '23

Hello, The latest debian packages are built without autocomplete for kamcmd. Do we have the libreadline-dev package installed on the build machine? I know that we have kamctl rpc and kamcli, but if we are still shipping kamcmd, it should have the autocomplete feature enabled. Regards, Ovidiu Sas -- VoIP Embedded, Inc. http://www.voipembedded.com

3 2

Sip messages responses counters per interface
by Patrick Karton 02 Feb '23

02 Feb '23

2 1

rtpengine - SRTP <> RTP
by kdrewicz+kamailio＠cludo.pl 01 Feb '23

01 Feb '23

I try to workout if - currently it would work, or - where and how to debug more: I face - 2 interfacec - public internet (so, TLS + sRTP) is desired and private - old infrastructure - i mus only use plain RTP 172.23.9.70 - private ip - from this endpoint of kamailio and rtpengine should send only basic RTP 172.23.210.75:5060 private - target for kamailio 1.2.3.24 obfuscated public IP (TLS + sRTP required) kamailio 5.4.4 (x86_64/linux) rtpengine -v Version: 11.1.1.4-1~bpo11+1 all i do … [View More]is: if (proto==TLS) { rtpengine_manage("RTP/AVP ICE=remove replace-session-connection replace-origin pad-crypto ptime=20 codec-transcode-PCMA record-call=on allow-transcoding direction=external direction=internal record-call=on"); } else if ($ru =~ "transport=tls") { rtpengine_manage("DTLS=on SRTP AVPF ICE=remove replace-session-connection replace-origin pad-crypto ptime=20 codec-transcode-PCMA record-call=on allow-transcoding direction=internal direction=external record-call=on media-address=1.2.3.24"); } # 1.2.3.24 obfuscated public IP 172.23.210.75:5060 is in dispatch.cfg, as '11' route[SBC_CORE] { append_hf("X-My-SRTP: removed31337\r\n"); ### i see this text in invtes from kamailio 172.23.9.70 towards 172.23.210.75:5060 ### i see only RTP, so as expected if (!ds_select_dst("11", "0")) { xwarn("I:$var(i) DROP(DOWN!) FWD:$rm [$fU->$tU] [SBCVIP] to $du\n"); sl_send_reply("503", "Destination down"); exit; } what i did: certificate is a paid one (the public party needs it) TLS works i deleted - entries in (not kamailo) cryptosuite that caused this: 13:08:05 localhost rtpengine[15140]: ERR: [51ad8758-b64d-4d2f-9fd0-41d03a38f74d]: [core] Failed to parse a=crypto attribute, ignoring: unknown crypto suite Tried to search for any "ready" examples for this - only found old threads and - that this should be possible, but - no example for woking config. what i see: Jan 19 19:00:57 localhost rtpengine[17301]: DEBUG: [core] timer run time = 0.000038 sec Jan 19 19:00:58 localhost rtpengine[17301]: DEBUG: [core] timer run time = 0.000036 sec Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] Closing call due to timeout Jan 19 19:00:59 localhost rtpengine[17301]: DEBUG: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] Redis delete_async=0 Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] Final packet stats: Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] --- Tag 'JVR5LTs', created 60:00 ago for branch '' Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] --- subscribed to '' Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] --- subscription for '' Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] ------ Media #1 (audio over RTP/SAVP) using unknown codec Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] --------- Port 1.2.3.24:30136 <> 52.129.106.28:17030, SSRC 0, in 0 p, 0 b, 0 e, 3600 ts, out 0 p, 0 b, 0 e Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] --------- Port 1.2.3.24:30137 <> 52.129.106.28:17031 (RTCP), SSRC 0, in 0 p, 0 b, 0 e, 3600 ts, out 0 p, 0 b, 0 e Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] --- Tag '', created 60:00 ago for branch '' Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] --- subscribed to 'JVR5LTs' Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] --- subscription for 'JVR5LTs' Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] ------ Media #1 (audio over RTP/AVP) using unknown codec Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] --------- Port 172.23.9.70:30014 <> :0 , SSRC 0, in 0 p, 0 b, 0 e, 3600 ts, out 0 p, 0 b, 0 e Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] --------- Port 172.23.9.70:30015 <> :0 (RTCP), SSRC 0, in 0 p, 0 b, 0 e, 3600 ts, out 0 p, 0 b, 0 e Jan 19 19:00:59 localhost rtpengine[17301]: INFO: [c17bab16-5eea-492e-b1c4-ac9387f3e265]: [core] Moved metadata file "/var/spool/rtpengine/tmp/rtpengine-meta-c17bab16-5eea-492e-b1c4-ac9387f3e265-7003946f152c6c8d.tmp" to "/var/spool/rtpengine/metadata" Jan 19 19:00:59 localhost rtpengine[17301]: DEBUG: [core] timer run time = 0.000828 sec Jan 19 19:01:00 localhost rtpengine[17301]: DEBUG: [core] timer run time = 0.000053 sec route(SBC_CORE); maybe any hint or - someone has working exmaple of kamailio config + rtpengine settings ? i use only userspace daemon rtp forwarding (this is a test, dont need any performance here) Thanks, [View Less]

5 9

transport=ws causing kamailio to use wrong listen socket
by nathan.bruning＠talksome.com 31 Jan '23

31 Jan '23

Hi all, We're hitting an issue while integrating secure websockets in our existing SIP infrastructure using Kamailio. When the registration comes in, it causes an entry in our AOR table, with ";transport=ws" appended. When we want to send a message to this client (using t_relay), kamailio seems to take 'ws' as being *unsecure* websockets. In turn, this makes Kamailio try to send out the message using a TCP listener - while it should have picked the TLS listener. There are some remarks in the … [View More]

6 7

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users