sr-users November 2014

sr-users@lists.kamailio.org

91 participants
129 discussions

topoh and uac_replace_from()
by Alex Balashov 13 Nov '14

13 Nov '14

Hi, If I use uac_replace_from() to alter the User part of the From URI: uac_replace_from("sip:$xavp(call=>src)@$fd"); it overwrites the domain concealment that is otherwise imparted by topoh, i.e. restores the original From domain. However, uac_replace_from() does not appear to offer the option to provide a replacement user part only, so I have to specify the domain. As far as I know, there is no means of accessing the modifications topoh has made, as this is transparent from the point of view of the config. Any way around this problem? Thanks, -- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/

2 3

kamailio does DNS lookup of from host when using TCP
by Vik Killa 12 Nov '14

12 Nov '14

Hello, I'm wondering why kamailio will try doing a DNS lookup of the from host with a REGISTER packet when using TCP? It doesn't do this with UDP. I always get this error since the host is not a valid domain: <core> [resolve.c:1726]: sip_hostport2su(): could not resolve hostname: "3.local" Here is the full log with debug (error is last line) Nov 12 15:45:19 ua01-proxy01 /usr/sbin/kamailio[3026]: DEBUG: <core> [mem/shm_mem.c:111]: _shm_resize(): WARNING:vqm_resize: resize(0) called Nov 12 15:45:19 ua01-proxy01 /usr/sbin/kamailio[3026]: DEBUG: <core> [tcp_main.c:2294]: tcpconn_send_put(): tcp_send: found fd in cache ( 10, 0x7f860bd18938, 1) Nov 12 15:45:19 ua01-proxy01 /usr/sbin/kamailio[3026]: DEBUG: <core> [tcp_main.c:2516]: tcpconn_do_send(): tcp_send: sending... Nov 12 15:45:19 ua01-proxy01 /usr/sbin/kamailio[3026]: DEBUG: <core> [tcp_main.c:2550]: tcpconn_do_send(): tcp_send: after real write: c= 0x7f860bd18938 n=639 fd=10 Nov 12 15:45:19 ua01-proxy01 /usr/sbin/kamailio[3026]: DEBUG: <core> [tcp_main.c:2551]: tcpconn_do_send(): tcp_send: buf=#012SIP/2.0 401 Unauthorized#015#012Via: SIP/2.0/TCP 192.168.16.120:53972;received=192.168.213.162;rport=53972;branch=z9hG4bKPjac894585917043d28da015d397178725;alias#015#012From: "1003" <sip:1003@3.local>;tag=dbc7a9087cb84006b65d891e5ad1f5ea#015#012To: "1003" <sip:1003@3.local>;tag=ey7D0K9DX49DF#015#012Call-ID: ee72194a1b8e4effa2948e237d804b90#015#012CSeq: 1 REGISTER#015#012User-Agent: AMPSwitch#015#012Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE#015#012Supported: timer, path, replaces#015#012WWW-Authenticate: Digest realm="3.local", nonce="cdf32dde-ab14-4265-b491-bee703e83255", algorithm=MD5, qop="auth"#015#012Content-Length: 0#015#012#015#012 Nov 12 15:45:19 ua01-proxy01 /usr/sbin/kamailio[3026]: DEBUG: tm [t_reply.c:1663]: cleanup_uac_timers(): DEBUG: cleanup_uac_timers: RETR/FR timers reset Nov 12 15:45:19 ua01-proxy01 /usr/sbin/kamailio[3026]: DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil) Nov 12 15:45:19 ua01-proxy01 /usr/sbin/kamailio[3026]: DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil) Nov 12 15:45:19 ua01-proxy01 /usr/sbin/kamailio[3026]: DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil) Nov 12 15:45:19 ua01-proxy01 /usr/sbin/kamailio[3026]: DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil) Nov 12 15:45:19 ua01-proxy01 /usr/sbin/kamailio[3026]: DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil) Nov 12 15:45:19 ua01-proxy01 /usr/sbin/kamailio[3026]: DEBUG: <core> [usr_avp.c:643]: destroy_avp_list(): DEBUG:destroy_avp_list: destroying list (nil) Nov 12 15:45:19 ua01-proxy01 /usr/sbin/kamailio[3026]: DEBUG: <core> [xavp.c:448]: xavp_destroy_list(): destroying xavp list (nil) Nov 12 15:45:19 ua01-proxy01 /usr/sbin/kamailio[3026]: DEBUG: <core> [receive.c:298]: receive_msg(): receive_msg: cleaning up Nov 12 15:45:19 ua01-proxy01 /usr/sbin/kamailio[3026]: DEBUG: <core> [io_wait.h:388]: io_watch_add(): DBG: io_watch_add(0xa2c420, 6, 2, 0x7f860bd2dbe0), fd_no=1 Nov 12 15:45:19 ua01-proxy01 /usr/sbin/kamailio[3025]: DEBUG: <core> [parser/msg_parser.c:629]: parse_msg(): version: <SIP/2.0> Nov 12 15:45:19 ua01-proxy01 /usr/sbin/kamailio[3025]: DEBUG: <core> [parser/parse_via.c:1284]: parse_via_param(): Found param type 235, <rport> = <n/a>; state=6 Nov 12 15:45:19 ua01-proxy01 /usr/sbin/kamailio[3025]: DEBUG: <core> [parser/parse_via.c:1284]: parse_via_param(): Found param type 232, <branch> = <z9hG4bKPj19019d19feaa4a06ac1d6cdc31a2e05d>; state=6 Nov 12 15:45:19 ua01-proxy01 /usr/sbin/kamailio[3025]: DEBUG: <core> [parser/parse_via.c:1284]: parse_via_param(): Found param type 237, <alias> = <n/a>; state=16 Nov 12 15:45:19 ua01-proxy01 /usr/sbin/kamailio[3025]: DEBUG: <core> [parser/parse_via.c:2672]: parse_via(): end of header reached, state=5 Nov 12 15:45:19 ua01-proxy01 /usr/sbin/kamailio[3025]: DEBUG: <core> [parser/msg_parser.c:513]: parse_headers(): parse_headers: Via found, flags=2 Nov 12 15:45:19 ua01-proxy01 /usr/sbin/kamailio[3025]: DEBUG: <core> [parser/msg_parser.c:515]: parse_headers(): parse_headers: this is the first via Nov 12 15:45:19 ua01-proxy01 /usr/sbin/kamailio[3025]: DEBUG: <core> [receive.c:154]: receive_msg(): After parse_msg... Nov 12 15:45:19 ua01-proxy01 /usr/sbin/kamailio[3025]: DEBUG: <core> [receive.c:197]: receive_msg(): preparing to run routing scripts... Nov 12 15:45:19 ua01-proxy01 /usr/sbin/kamailio[3025]: DEBUG: maxfwd [mf_funcs.c:85]: is_maxfwd_present(): value = 70 Nov 12 15:45:19 ua01-proxy01 /usr/sbin/kamailio[3025]: DEBUG: <core> [parser/parse_addr_spec.c:898]: parse_addr_spec(): end of header reached, state=10 Nov 12 15:45:19 ua01-proxy01 /usr/sbin/kamailio[3025]: DEBUG: <core> [parser/msg_parser.c:190]: get_hdr_field(): DEBUG: get_hdr_field: <To> [27]; uri=[sip:1003@3.local] Nov 12 15:45:19 ua01-proxy01 /usr/sbin/kamailio[3025]: DEBUG: <core> [parser/msg_parser.c:192]: get_hdr_field(): DEBUG: to body ["1003" <sip:1003@3.local>#015#012] Nov 12 15:45:19 ua01-proxy01 /usr/sbin/kamailio[3025]: DEBUG: <core> [parser/msg_parser.c:170]: get_hdr_field(): get_hdr_field: cseq <CSeq>: <1> <PUBLISH> Nov 12 15:45:19 ua01-proxy01 /usr/sbin/kamailio[3025]: DEBUG: <core> [parser/msg_parser.c:204]: get_hdr_field(): DEBUG: get_hdr_body : content_length=757 Nov 12 15:45:19 ua01-proxy01 /usr/sbin/kamailio[3025]: DEBUG: <core> [parser/msg_parser.c:106]: get_hdr_field(): found end of header Nov 12 15:45:19 ua01-proxy01 /usr/sbin/kamailio[3025]: DEBUG: sanity [mod_sanity.c:255]: w_sanity_check(): sanity checks result: 1 Nov 12 15:45:19 ua01-proxy01 /usr/sbin/kamailio[3025]: DEBUG: textops [textops.c:2478]: has_body_f(): content type is 196613 Nov 12 15:45:19 ua01-proxy01 /usr/sbin/kamailio[3025]: DEBUG: siputils [checks.c:103]: has_totag(): no totag Nov 12 15:45:19 ua01-proxy01 /usr/sbin/kamailio[3025]: DEBUG: tm [t_lookup.c:1072]: t_check_msg(): DEBUG: t_check_msg: msg id=10 global id=9 T start=0xffffffffffffffff Nov 12 15:45:19 ua01-proxy01 /usr/sbin/kamailio[3025]: DEBUG: tm [t_lookup.c:527]: t_lookup_request(): t_lookup_request: start searching: hash=12001, isACK=0 Nov 12 15:45:19 ua01-proxy01 /usr/sbin/kamailio[3025]: DEBUG: tm [t_lookup.c:485]: matching_3261(): DEBUG: RFC3261 transaction matching failed Nov 12 15:45:19 ua01-proxy01 /usr/sbin/kamailio[3025]: DEBUG: tm [t_lookup.c:709]: t_lookup_request(): DEBUG: t_lookup_request: no transaction found Nov 12 15:45:19 ua01-proxy01 /usr/sbin/kamailio[3025]: DEBUG: tm [t_lookup.c:1141]: t_check_msg(): DEBUG: t_check_msg: msg id=10 global id=10 T end=(nil) Nov 12 15:45:19 ua01-proxy01 /usr/sbin/kamailio[3025]: DEBUG: tm [t_lookup.c:1373]: t_newtran(): DEBUG: t_newtran: msg id=10 , global msg id=10 , T on entrance=(nil) Nov 12 15:45:19 ua01-proxy01 /usr/sbin/kamailio[3025]: DEBUG: tm [t_lookup.c:527]: t_lookup_request(): t_lookup_request: start searching: hash=12001, isACK=0 Nov 12 15:45:19 ua01-proxy01 /usr/sbin/kamailio[3025]: DEBUG: tm [t_lookup.c:485]: matching_3261(): DEBUG: RFC3261 transaction matching failed Nov 12 15:45:19 ua01-proxy01 /usr/sbin/kamailio[3025]: DEBUG: tm [t_lookup.c:709]: t_lookup_request(): DEBUG: t_lookup_request: no transaction found Nov 12 15:45:19 ua01-proxy01 /usr/sbin/kamailio[3025]: DEBUG: <core> [md5utils.c:67]: MD5StringArray(): DEBUG: MD5 calculated: d71ddc300035dfaa15e181fe4d6a9aa7 Nov 12 15:45:19 ua01-proxy01 /usr/sbin/kamailio[3025]: DEBUG: <core> [dns_cache.c:566]: _dns_hash_find(): dns_hash_find(_sip._tcp.3.local(17), 33), h=867 Nov 12 15:45:19 ua01-proxy01 /usr/sbin/kamailio[3025]: DEBUG: <core> [resolve.c:770]: get_record(): get_record: lookup(_sip._tcp.3.local, 33) failed Nov 12 15:45:19 ua01-proxy01 /usr/sbin/kamailio[3025]: DEBUG: <core> [dns_cache.c:894]: dns_cache_mk_bad_entry(): dns_cache_mk_bad_entry(_sip._tcp.3.local, 33, 60, 1) Nov 12 15:45:19 ua01-proxy01 /usr/sbin/kamailio[3025]: DEBUG: <core> [dns_cache.c:827]: dns_cache_add(): dns_cache_add: adding _sip._tcp.3.local(17) 33 (flags=1) at 867 Nov 12 15:45:19 ua01-proxy01 /usr/sbin/kamailio[3025]: DEBUG: <core> [dns_cache.c:566]: _dns_hash_find(): dns_hash_find(3.local(7), 1), h=184 Nov 12 15:45:19 ua01-proxy01 /usr/sbin/kamailio[3025]: DEBUG: <core> [resolve.c:770]: get_record(): get_record: lookup(3.local, 1) failed Nov 12 15:45:19 ua01-proxy01 /usr/sbin/kamailio[3025]: DEBUG: <core> [dns_cache.c:894]: dns_cache_mk_bad_entry(): dns_cache_mk_bad_entry(3.local, 1, 60, 1) Nov 12 15:45:19 ua01-proxy01 /usr/sbin/kamailio[3025]: DEBUG: <core> [dns_cache.c:827]: dns_cache_add(): dns_cache_add: adding 3.local(7) 1 (flags=1) at 184 Nov 12 15:45:19 ua01-proxy01 /usr/sbin/kamailio[3025]: ERROR: <core> [resolve.c:1726]: sip_hostport2su(): could not resolve hostname: "3.local"

2 4

UDP-TCP bridging in-dialog SUBSCRIBE
by Dan Christian Bogos 12 Nov '14

12 Nov '14

Hey Guys, I have the following scenario: UA1 (UDP) -> Kamailio Proxy -> (TCP) UA2 As per the signaling sample, I would expect that in-dialog SUBSCRIBEs are bridged between UDP and TCP network but for some reason this does not happen (the subscribe comes in over UDP and leaves still over UDP although tcp is present in the route headers). Are we somehow forced to mangle contact header and add transport parameter to it or the record-route headers should serve for this purpose? Any tip would be highly appreciated. Ta, DanB Bellow the traces for initial SUBSCRIBEs as well as in-dialog ones (info mangled to protect privacy). ##################################### Normally routed request (non-dialog one, correctly bridged) ##################################### """ # U 2014/11/12 19:04:51.293887 pub_ip_ua:54705 -> pub_ip_ep:5060 SUBSCRIBE sip:user1@fakedomain.com:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.243.82:5062;branch=z9hG4bK1114302228. From: "user2" <sip:user2@fakedomain.com>;tag=1003326118. To: <sip:user1@fakedomain.com>. Call-ID: 1273081718. CSeq: 2 SUBSCRIBE. Contact: <sip:user2@192.168.243.82:5062>. Accept: application/dialog-info+xml. Max-Forwards: 70. User-Agent: Tiptel IP 284 6.70.13.18 0015651b574f. Expires: 60. Event: dialog. Content-Length: 0. . # T 2014/11/12 19:04:51.295706 pub_ip_ep:34052 -> 192.168.51.168:5060 [AP] SUBSCRIBE sip:user1@192.168.51.168:5060;transport=tcp SIP/2.0. Record-Route: <sip:pub_ip_ep;transport=tcp;r2=on;lr;nat=yes>. Record-Route: <sip:pub_ip_ep;r2=on;lr;nat=yes>. Via: SIP/2.0/TCP pub_ip_ep;branch=z9hG4bKe26f.3dce66bd1976447b88f6096e926ce68c.0. Via: SIP/2.0/UDP 192.168.243.82:5062;rport=54705;received=pub_ip_ua;branch=z9hG4bK1114302228. From: "user2" <sip:user2@fakedomain.com>;tag=1003326118. To: <sip:user1@fakedomain.com>. Call-ID: 1273081718. CSeq: 2 SUBSCRIBE. Contact: <sip:user2@192.168.243.82:5062;alias=pub_ip_ua~54705~1>. Accept: application/dialog-info+xml. Max-Forwards: 65. User-Agent: Tiptel IP 284 6.70.13.18 0015651b574f. Expires: 60. Event: dialog. Content-Length: 0. . # T 2014/11/12 19:04:51.300350 192.168.51.168:5060 -> pub_ip_ep:34052 [AP] SIP/2.0 202 Accepted. Via: SIP/2.0/TCP pub_ip_ep;branch=z9hG4bKe26f.3dce66bd1976447b88f6096e926ce68c.0;rport=34052. Via: SIP/2.0/UDP 192.168.243.82:5062;rport=54705;received=pub_ip_ua;branch=z9hG4bK1114302228. Record-Route: <sip:pub_ip_ep;transport=tcp;r2=on;lr;nat=yes>. Record-Route: <sip:pub_ip_ep;r2=on;lr;nat=yes>. From: "user2" <sip:user2@fakedomain.com>;tag=1003326118. To: <sip:user1@fakedomain.com>;tag=PFxfnedC0jP7. Call-ID: 1273081718. CSeq: 2 SUBSCRIBE. Contact: <sip:user1@192.168.51.168:5060>. Expires: 60. User-Agent: Sipean-AS 1.2.10. Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE. Supported: timer, path, replaces. Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer. Subscription-State: active;expires=60. Content-Length: 0. . ## U 2014/11/12 19:04:51.300745 pub_ip_ep:5060 -> pub_ip_ua:54705 SIP/2.0 202 Accepted. Via: SIP/2.0/UDP 192.168.243.82:5062;rport=54705;received=pub_ip_ua;branch=z9hG4bK1114302228. Record-Route: <sip:pub_ip_ep;transport=tcp;r2=on;lr;nat=yes>. Record-Route: <sip:pub_ip_ep;r2=on;lr;nat=yes>. From: "user2" <sip:user2@fakedomain.com>;tag=1003326118. To: <sip:user1@fakedomain.com>;tag=PFxfnedC0jP7. Call-ID: 1273081718. CSeq: 2 SUBSCRIBE. Contact: <sip:user1@192.168.51.168:5060>. Expires: 60. User-Agent: Sipean-AS 1.2.10. Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE. Supported: timer, path, replaces. Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer. Subscription-State: active;expires=60. Content-Length: 0. """ ###################### NOT BRIDGED, IN-DIALOG requests: ###################### """ # U 2014/11/12 19:46:18.448550 pub_ip_ua:54705 -> pub_ip_ep:5060 SUBSCRIBE sip:user1@192.168.51.168:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.243.82:5062;branch=z9hG4bK459444805. Route: <sip:pub_ip_ep;r2=on;lr;nat=yes>. Route: <sip:pub_ip_ep;transport=tcp;r2=on;lr;nat=yes>. From: "user2" <sip:user2@fakedomain.com>;tag=1902678123. To: <sip:user1@fakedomain.com>;tag=2518urgZJFet. Call-ID: 2104228355. CSeq: 3 SUBSCRIBE. Contact: <sip:user2@192.168.243.82:5062>. Accept: application/dialog-info+xml. Max-Forwards: 70. User-Agent: Tiptel IP 284 6.70.13.18 0015651b574f. Expires: 60. Event: dialog. Content-Length: 0. . # U 2014/11/12 19:46:18.449161 pub_ip_ep:5060 -> 192.168.51.168:5060 SUBSCRIBE sip:user1@192.168.51.168:5060 SIP/2.0. Via: SIP/2.0/UDP pub_ip_ep;branch=z9hG4bK7de2.a9aed4070706f93b25b4d2d3d7963a19.0. Via: SIP/2.0/UDP 192.168.243.82:5062;rport=54705;received=pub_ip_ua;branch=z9hG4bK459444805. From: "user2" <sip:user2@fakedomain.com>;tag=1902678123. To: <sip:user1@fakedomain.com>;tag=2518urgZJFet. Call-ID: 2104228355. CSeq: 3 SUBSCRIBE. Contact: <sip:user2@192.168.243.82:5062;alias=pub_ip_ua~54705~1>. Proxy-Authorization: Digest username="user2", realm="fakedomain.com", nonce="VGOr71RjqsMDoDyEqMnELO4fotFJLYhV", uri="sip:user1@192.168.51.168:5060", response="12fbfa50428b37bd55dbb4b51f8d5cba", algorithm=MD5. Accept: application/dialog-info+xml. Max-Forwards: 65. User-Agent: Tiptel IP 284 6.70.13.18 0015651b574f. Expires: 60. Event: dialog. Content-Length: 0. """

2 1

TLS/TCP sipping
by Petr Wozniak 11 Nov '14

11 Nov '14

Hello, Base on my testing OPTION pings can be sent only to UDP nated clients. So it is impossible with kamailio to send OPTION pings to TCP/TLS nated clients? I found doc for some version of nathelper module where the natping _tcp parameter can be set by modparam("nathelper", "natping_tcp", 1) Unfortunately, this parameter cannot be used in default nathelper module in kamailio 4.2.(doc is probably from OpenSIPS) I would like to send OPTION pings to TLS nated and individualy selected user agents. Does exist some possibility to do it with kamailio 4.2? If not by default does exist the possibility to compile and build kamailio with the nathelper module mentioned above (with natping_tcp parameter)? Or does exist some other solution? Thank you in advance Petr

1 0

Kamailio v4.2.1 Released
by Daniel-Constantin Mierla 11 Nov '14

11 Nov '14

Hello, Kamailio SIP Server v4.2.1 stable release is out. This is a maintenance release of the latest stable branch, 4.2, that includes fixes since release of v4.2.0. There is no change to database schema or configuration language structure that you have to do on installations of v4.2.0. Deployments running previous v4.x.x versions are strongly recommended to be upgraded to v4.2.1. For more details about version 4.2.1 (including links and guidelines to download the tarball or from GIT repository), visit: * http://www.kamailio.org/w/2014/11/kamailio-v4-2-1-released/ RPM, Debian/Ubuntu packages will be available soon as well. Cheers, Daniel -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

1 0

header manipulation in locally generated SIP OPTIONS requests
by Klaus Feichtinger 11 Nov '14

11 Nov '14

Hello, does kamailio offer any possibility for adding / replacing SIP headers in locally built SIP requests? In detail: SIP OPTIONS requests that are built by the DISPATCHER module for probing the configured targets. I have to extend these messages with "Accept" SIP header fields (which are marked with m* in RFC3261 - so they SHOULD be present), as the dispatcher target is requiring this information for answering these requests.... The event_route is principally accepting the append_hf() function and is adding the configured header fields. But the answer to that request (which is including these additional header fields) is confusing the dispatcher module. Dispatcher module is reacting with this ERROR message: DEBUG: dispatcher [dispatch.c:2406]: probing set #1, URI sip:10.10.10.10 DEBUG: dispatcher [dispatch.c:2345]: OPTIONS-Request was finished with code 500 (to , group 1) ERROR: dispatcher [dispatch.c:2358]: Setting the state failed (, group 1) When I comment the textops functions out again and use the original OPTIONS messages, dispatcher is happy and knows the states of the probed targets. Therefore, I´ll ask again: does kamailio offer any way for manipulating locally built SIP requests? kr Klaus

3 4

Releasing v4.2.1
by Daniel-Constantin Mierla 11 Nov '14

11 Nov '14

Hello, I am considering to release first minor version out of branch 4.2 as v4.2.1 next week, by Tuesday or Wednesday. If there is any comment regarding it, write to sr-dev mailing list. Cheers, Daniel -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Training, Nov 24-27, Berlin - http://www.asipto.com

1 1

ALIAS_DB replacing From and Contact fields
by Martin Schiøtz 11 Nov '14

11 Nov '14

Hi I'm using the ALIAS_DB module. username = 101 alias_username = 44444444 (fictive public phone number) 'alias_db_lookup("dbaliases")' is working fine for incoming calls from PSTN. Calling 44444444 R-URI is replaced with 101 SIP uri. But when 101 is calling to a PSTN number how do I replace the From and Contact fields with 44444444? Cheers, Martin

1 0

RTP end points
by Javier Ricke 10 Nov '14

10 Nov '14

i used asterisk, and install kamailio for traffic RTP can be send between end points, and do not have to go through RTP proxy, any work this form?, and client behind to NAT.. regards!

2 2

beginner's problem with sipping
by Petr Wozniak 10 Nov '14

10 Nov '14

Dear sr-users, I am beginner and apologize for bothering you with such a trivial problem. I would like to test sip UDP and TCP keepalive pinging. Kamailio and client are on the same network (192.168.1.44 and 192.168.1.20) that implies not behind NAT. So in kamailio.cfg I have set modparam("nathelper", "ping_nated_only", 0) My simple kamailio.cfg please you find enclosed. >From logfiles on client's side implies that neither UDP nor OPTIONS pings are sending from kamailio. If somebody would be so kind to help me I will be very glad. Thank you in advance Regards Petr

2 3

← Newer
1
...
6
7
8
9
10
11
12
13
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 November 2014