Hi,

Thanks for the clarification.

If I'm not mistaken, the message below, grabbed with sipgrep, is the corresponding message that the debug output relates to. Some details modifed to protect the kittens :)

U 2015/07/01 20:42:33.766671 10.6.0.173:5060 -> 10.6.0.174:5060

KDMQ sip:usrloc@10.6.0.174:5060 SIP/2.0.
Via: SIP/2.0/UDP 10.6.0.173;branch=z9hG4bKab3c.7fcad257000000000000000000000000.0.
To: <sip:usrloc@10.6.0.174:5060>.
From: <sip:usrloc@10.6.0.173:5060>;tag=390c95c339281829d3cea6f43c8512cb-8e63.
CSeq: 10 KDMQ.
Call-ID: 3c502b38465e8d95-8433@10.6.0.173.
Content-Length: 471.
User-Agent: kamailio (bfievkrl01).
Max-Forwards: 1.
Content-Type: application/json.
.
{"action":1,"aor":"subscriber_name@subscriber_domain","ruid":"uloc-55941474-20f1-1","c":"sip:subscriber_name@212.2.160.202:61270;rinstance=7b7c543d11c12134;transport=UDP","received":"sip:212.2.160.202:61270","path":"<sip:10.7.0.109;lr;received=sip:212.2.160.202:61270>","callid":"rvOjXlyhAGK1aokNbR859w..","user_agent":"Z 3.7.30891 r30851","instance":"","expires":1435779866,"cseq":7,"flags":0,"cflags":64,"q":-1,"last_modified":1435779753,"methods":5087,"reg_id":0}


On 01/07/2015 21:30, Charles Chance wrote:

Hello,

Should be no need to load any additional deserializer. The docs simply mean if you wish to send/receive your own messages from within a module or script, it's up to you to choose the best payload type and method of (de)serialization.

Can you post an example KDMQ message here to look at?

Cheers,
Charles

On 1 Jul 2015 20:49, "Asgaroth" <00asgaroth00@gmail.com> wrote:
Hi All,

I am playing with the new dmq_replicate module and am banging my head against an issue I have come accross. I can see the kamailio registrars sending the replication messages to the other node(s) in the dmq bus, and the payload looks to be of type json. However, on the recieving nodes, when I try to issue a kamctl ul show --brief, the output of the AOR's are garbled.

I had a look at the dmq/dmq_ursloc moduled, and the dmq module docs mention that we may need to load our own deserializers, is this the case when using the dmq_usrloc module as well? I am only using dmq to replicate registration messages.

Here is a sample of the dmq workers on a recieving node applying the update, and you can see that it thinks the contact to add is 'p÷#031#002', is was expecting the actual AOR of the subriber to show up here.

Am I missing something simple here or is there something more sinister at play.

Any pointers would be greatly appreciated.

Kamailio Version:

version: kamailio 4.3.0 (x86_64/linux) c6aa95
flags: STATS: Off, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, DBG_F_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: c6aa95
compiled on 16:14:27 Jun 23 2015 with gcc 4.4.7

Debug log below:

Jul  1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: <core> [parser/msg_parser.c:606]: parse_msg(): SIP Request:
Jul  1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: <core> [parser/msg_parser.c:608]: parse_msg():  method: <KDMQ>
Jul  1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: <core> [parser/msg_parser.c:610]: parse_msg():  uri: <sip:usrloc@10.6.0.174:5060>
Jul  1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: <core> [parser/msg_parser.c:612]: parse_msg():  version: <SIP/2.0>
Jul  1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: <core> [parser/parse_via.c:1254]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK9b3c.fe993716000000000000000000000000.0>; state=16
Jul  1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: <core> [parser/parse_via.c:2642]: parse_via(): end of header reached, state=5
Jul  1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: <core> [parser/msg_parser.c:496]: parse_headers(): parse_headers: Via found, flags=2
Jul  1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: <core> [parser/msg_parser.c:498]: parse_headers(): parse_headers: this is the first via
Jul  1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: <core> [receive.c:134]: receive_msg(): After parse_msg...
Jul  1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: <core> [receive.c:177]: receive_msg(): preparing to run routing scripts...
Jul  1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: tm [t_lookup.c:1011]: t_check_msg(): DEBUG: t_check_msg: msg id=450 global id=449 T start=0xffffffffffffffff
Jul  1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: <core> [parser/parse_addr_spec.c:894]: parse_addr_spec(): end of header reached, state=10
Jul  1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: <core> [parser/msg_parser.c:173]: get_hdr_field(): DEBUG: get_hdr_field: <To> [30]; uri=[sip:usrloc@10.6.0.174:5060]
Jul  1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: <core> [parser/msg_parser.c:175]: get_hdr_field(): DEBUG: to body [<sip:usrloc@10.6.0.174:5060>#015#012]
Jul  1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: <core> [parser/msg_parser.c:153]: get_hdr_field(): get_hdr_field: cseq <CSeq>: <10> <KDMQ>
Jul  1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: <core> [parser/msg_parser.c:187]: get_hdr_field(): DEBUG: get_hdr_body : content_length=471
Jul  1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: <core> [parser/msg_parser.c:89]: get_hdr_field(): found end of header
Jul  1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: tm [t_lookup.c:466]: t_lookup_request(): t_lookup_request: start searching: hash=50105, isACK=0
Jul  1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: tm [t_lookup.c:424]: matching_3261(): DEBUG: RFC3261 transaction matching failed
Jul  1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: tm [t_lookup.c:648]: t_lookup_request(): DEBUG: t_lookup_request: no transaction found
Jul  1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: tm [t_lookup.c:1080]: t_check_msg(): DEBUG: t_check_msg: msg id=450 global id=450 T end=(nil)
Jul  1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: dmq [message.c:53]: dmq_handle_message(): dmq_handle_message [KDMQ sip:usrloc@10.6.0.174:5060] [ ]
Jul  1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: dmq [message.c:65]: dmq_handle_message(): dmq_handle_message peer found: usrloc
Jul  1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil)
Jul  1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil)
Jul  1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23014]: DEBUG: dmq [worker.c:84]: worker_loop(): dmq_worker [0 23014] lock acquired
Jul  1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil)
Jul  1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23014]: DEBUG: <core> [parser/parse_addr_spec.c:172]: parse_to_param(): DEBUG: add_param: tag=390c95c339281829d3cea6f43c8512cb-7e62
Jul  1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23014]: DEBUG: <core> [parser/parse_addr_spec.c:894]: parse_addr_spec(): end of header reached, state=29
Jul  1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23014]: DEBUG: dmq_usrloc [usrloc_sync.c:250]: usrloc_dmq_handle_msg(): dmq message received from sip:usrloc@10.6.0.173:5060
Jul  1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23014]: DEBUG: dmq_usrloc [usrloc_sync.c:353]: usrloc_dmq_handle_msg(): Received DMQ_UPDATE. Update contact info...
Jul  1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23014]: DEBUG: dmq_usrloc [usrloc_sync.c:60]: add_contact(): 'p÷#031#002' found in usrloc
Jul  1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23014]: DEBUG: dmq_usrloc [usrloc_sync.c:62]: add_contact(): get_ucontact = 0
Jul  1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23014]: DEBUG: dmq_usrloc [usrloc_sync.c:72]: add_contact(): Found contact
Jul  1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23014]: DEBUG: usrloc [ucontact.c:1688]: update_ucontact(): exists callback for type= UL_CONTACT_UPDATE
Jul  1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23014]: DEBUG: usrloc [ul_callback.h:84]: run_ul_callbacks(): contact=0x7ffe86eabad8, callback type 2/15, id 0 entered
Jul  1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23014]: DEBUG: dmq_usrloc [usrloc_sync.c:494]: dmq_ul_cb_contact(): Callback from usrloc with type=2
Jul  1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23014]: DEBUG: dmq_usrloc [usrloc_sync.c:517]: dmq_ul_cb_contact(): Contact recieved from DMQ... skip
Jul  1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23014]: DEBUG: dmq_usrloc [usrloc_sync.c:85]: add_contact(): Release record
Jul  1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23014]: DEBUG: dmq_usrloc [usrloc_sync.c:87]: add_contact(): Unlock udomain
Jul  1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23014]: DEBUG: sl [sl.c:280]: send_reply(): reply in stateless mode (sl)
Jul  1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil)
Jul  1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23014]: DEBUG: <core> [msg_translator.c:158]: check_via_address(): (10.6.0.173, 10.6.0.173, 0)
Jul  1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil)
Jul  1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil)
Jul  1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: <core> [xavp.c:446]: xavp_destroy_list(): destroying xavp list (nil)
Jul  1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23007]: DEBUG: <core> [receive.c:278]: receive_msg(): cleaning up
Jul  1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23014]: DEBUG: dmq [worker.c:134]: worker_loop(): sent reply
Jul  1 20:40:52 bfievkrl02 /usr/sbin/kamailio[23014]: DEBUG: dmq [worker.c:82]: worker_loop(): dmq_worker [0 23014] getting lock



_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

www.sipcentric.com

Follow us on twitter @sipcentric

Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered office: Faraday Wharf, Innovation Birmingham Campus, Holt Street, Birmingham Science Park, Birmingham B7 4BB.


_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users