Re: [SR-Users] Send SIP Info within a dialog using $uac_req(method)="INFO"

Hello Daniel, Sorry to bother you again, last time! So the mi command line is; kamctl mi t_uac_dlg INFO sip:3003@193.144.1.112 . . \"From:sip:1234@8.8.8.8"\r\nTo:sip:3003@193.144.1.112\r\nContact:sip:daemon@8.8.8.8\r\n\"" Which works fine, however I add to exec module and it doesnt like the syntax; exec_avp("kamctl mi t_uac_dlg INFO sip:3003@193.144.1.112 . . \"From:sip:1234@8.8.8.8"\r\nTo:sip:3003@193.144.1.112\r\nContact:sip:daemon@8.8.8.8\r\n\""", "$avp(test)"); I presume its due to the \" and \r\n characters. What should I modify them or surround them with to please the exec command, as I can see in documentation for variables its '' quotes, but not sure around characters. Thanks Jon ________________________________ From: Daniel-Constantin Mierla &lt;miconda(a)gmail.com&gt; Sent: 16 November 2016 09:45 To: Jonathan Hunter; Kamailio SER - Users Mailing List Subject: Re: [SR-Users] Send SIP Info within a dialog using $uac_req(method)="INFO" Hello, as I can see in the logs, the rpc command fails to execute because it requires async processing which is not implemented by jsonrpc-s module. Then it is an INVITE received: ct 7 13:45:36 POC_ProxyA /usr/sbin/kamailio[6572]: INFO: <script>: Try and issue command via RPC Oct 7 13:45:36 POC_ProxyA /usr/sbin/kamailio[6572]: INFO: <script>: getting here 500 Oct 7 13:45:36 POC_ProxyA /usr/sbin/kamailio[6572]: INFO: <script>: getting here this rpc transport does not support async mode Oct 7 13:45:36 POC_ProxyA /usr/sbin/kamailio[6572]: INFO: <script>: getting here {"jsonrpc":"2.0","error":{"code":-32000,"message":"Execution Error"}} Oct 7 13:45:36 POC_ProxyA /usr/sbin/kamailio[6572]: INFO: <script>: route EXTENIN-We have an Invite here from 209-thirdlane check Hash table trans to see if there A solution for now would be to run the mi command via exec module. Cheers, Daniel On 15/11/16 12:30, Jonathan Hunter wrote: Hello, Please see debug output for when I try and send the SIP INFO when I am initiating a new call. I am just testing out the command currently, in practice I will look to inject the SIP INFO into an already formed dialog, so is the way I am trying to test cause me an issue? I can see; Oct 7 13:45:36 POC_ProxyA /usr/sbin/kamailio[6572]: DEBUG: tm [uac.c:249]: t_uac_prepare(): DEBUG:tm:t_uac: next_hop=<sip:kamailio.org><sip:kamailio.org> Which will be why its sending the sip info to sip:kamailio.org I presume. See some output from the relevant process below; Thanks Jon ct 7 13:45:36 POC_ProxyA /usr/sbin/kamailio[6572]: INFO: <script>: Try and issue command via RPC Oct 7 13:45:36 POC_ProxyA /usr/sbin/kamailio[6572]: INFO: <script>: getting here 500 Oct 7 13:45:36 POC_ProxyA /usr/sbin/kamailio[6572]: INFO: <script>: getting here this rpc transport does not support async mode Oct 7 13:45:36 POC_ProxyA /usr/sbin/kamailio[6572]: INFO: <script>: getting here {"jsonrpc":"2.0","error":{"code":-32000,"message":"Execution Error"}} Oct 7 13:45:36 POC_ProxyA /usr/sbin/kamailio[6572]: INFO: <script>: route EXTENIN-We have an Invite here from 209-thirdlane check Hash table trans to see if there Oct 7 13:45:36 POC_ProxyA /usr/sbin/kamailio[6572]: INFO: <script>: We can populate here with sip:209-thirdlane@192.33.132.215,sip:07917190438@192.33.132.215,MmU2NDI0MGNmZTVmZjE4ZWM0NzI5ZjcxYmExMzdkNGQ Oct 7 13:45:36 POC_ProxyA /usr/sbin/kamailio[6572]: DEBUG: tm [uac.c:249]: t_uac_prepare(): DEBUG:tm:t_uac: next_hop=<sip:kamailio.org><sip:kamailio.org> Oct 7 13:45:36 POC_ProxyA /usr/sbin/kamailio[6572]: DEBUG: <core> [dns_cache.c:537]: _dns_hash_find(): (_sip._udp.kamailio.org(22), 33), h=392 Oct 7 13:45:36 POC_ProxyA /usr/sbin/kamailio[6572]: DEBUG: <core> [resolve.c:741]: get_record(): lookup(_sip._udp.kamailio.org, 33) failed Oct 7 13:45:36 POC_ProxyA /usr/sbin/kamailio[6572]: DEBUG: <core> [dns_cache.c:864]: dns_cache_mk_bad_entry(): (_sip._udp.kamailio.org, 33, 60, 1) Oct 7 13:45:36 POC_ProxyA /usr/sbin/kamailio[6572]: DEBUG: <core> [dns_cache.c:798]: dns_cache_add(): adding _sip._udp.kamailio.org(22) 33 (flags=1) at 392 Oct 7 13:45:36 POC_ProxyA /usr/sbin/kamailio[6572]: DEBUG: <core> [dns_cache.c:537]: _dns_hash_find(): (kamailio.org(12), 1), h=235 Oct 7 13:45:36 POC_ProxyA /usr/sbin/kamailio[6572]: DEBUG: <core> [resolve.c:937]: get_record(): skipping 0 NS (p=0x9ed4ae, end=0x9ed4ae) Oct 7 13:45:36 POC_ProxyA /usr/sbin/kamailio[6572]: DEBUG: <core> [resolve.c:952]: get_record(): parsing 0 ARs (p=0x9ed4ae, end=0x9ed4ae) Oct 7 13:45:36 POC_ProxyA /usr/sbin/kamailio[6572]: DEBUG: <core> [dns_cache.c:1741]: dns_get_related(): (0x7fb9632c04c8 (kamailio.org, 1), 1, *(nil)) (0) Oct 7 13:45:36 POC_ProxyA /usr/sbin/kamailio[6572]: DEBUG: <core> [dns_cache.c:840]: dns_cache_add_unsafe(): adding kamailio.org(12) 1 (flags=0) at 235 Oct 7 13:45:36 POC_ProxyA /usr/sbin/kamailio[6572]: DEBUG: <core> [forward.c:174]: get_out_socket(): socket determined: 0x7fb96c730fc8 Oct 7 13:45:36 POC_ProxyA /usr/sbin/kamailio[6572]: DEBUG: tm [uac.c:150]: dlg2hash(): DEBUG: dlg2hash: 18155 Oct 7 13:45:36 POC_ProxyA /usr/sbin/kamailio[6572]: INFO: <script>: We appear to have an entry for 209-thirdlane and its 10.70.1.129so modify Accordingly Oct 7 13:45:36 POC_ProxyA /usr/sbin/kamailio[6572]: DEBUG: tm [t_lookup.c:1312]: t_newtran(): DEBUG: t_newtran: msg id=4 , global msg id=4 , T on entrance=(nil) Oct 7 13:45:36 POC_ProxyA /usr/sbin/kamailio[6572]: DEBUG: tm [t_lookup.c:466]: t_lookup_request(): t_lookup_request: start searching: hash=4096, isACK=0 Oct 7 13:45:36 POC_ProxyA /usr/sbin/kamailio[6572]: DEBUG: tm [t_lookup.c:424]: matching_3261(): DEBUG: RFC3261 transaction matching failed Oct 7 13:45:36 POC_ProxyA /usr/sbin/kamailio[6572]: DEBUG: tm [t_lookup.c:648]: t_lookup_request(): DEBUG: t_lookup_request: no transaction found Oct 7 13:45:36 POC_ProxyA /usr/sbin/kamailio[6572]: DEBUG: tm [t_hooks.c:358]: run_reqin_callbacks_internal(): DBG: trans=0x7fb9632c6558, callback type 1, id 0 entered Oct 7 13:45:36 POC_ProxyA /usr/sbin/kamailio[6572]: DEBUG: tm [t_hooks.c:358]: run_reqin_callbacks_internal(): DBG: trans=0x7fb9632c6558, callback type 1, id 0 entered Oct 7 13:45:36 POC_ProxyA /usr/sbin/kamailio[6572]: DEBUG: <core> [md5utils.c:67]: MD5StringArray(): MD5 calculated: ede2024c259a7db0dd7350b8d0d986f8 Oct 7 13:45:36 POC_ProxyA /usr/sbin/kamailio[6572]: DEBUG: tm [t_funcs.c:321]: t_relay_to(): SER: new INVITE Oct 7 13:45:36 POC_ProxyA /usr/sbin/kamailio[6572]: DEBUG: <core> [mem/shm_mem.c:101]: _shm_resize(): WARNING:vqm_resize: resize(0) called Oct 7 13:45:36 POC_ProxyA /usr/sbin/kamailio[6572]: DEBUG: tm [t_reply.c:647]: _reply_light(): DEBUG: reply sent out. buf=0x7fb96c9e0340: SIP/2.0 100 Trying Oct 7 13:45:36 POC_ProxyA /usr/sbin/kamailio[6572]: DEBUG: tm [t_reply.c:657]: _reply_light(): DEBUG: _reply_light: finished Oct 7 13:45:36 POC_ProxyA /usr/sbin/kamailio[6572]: DEBUG: <script>: new branch [0] to sip:07917190438@10.70.1.129 Oct 7 13:45:36 POC_ProxyA /usr/sbin/kamailio[6572]: DEBUG: siputils [checks.c:97]: has_totag(): no totag Oct 7 13:45:36 POC_ProxyA /usr/sbin/kamailio[6572]: DEBUG: <core> [forward.c:174]: get_out_socket(): socket determined: 0x7fb96c731808 Oct 7 13:45:36 POC_ProxyA /usr/sbin/kamailio[6572]: DEBUG: tm [t_funcs.c:368]: t_relay_to(): SER: new transaction fwd'ed Oct 7 13:45:36 POC_ProxyA /usr/sbin/kamailio[6572]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Oct 7 13:45:36 POC_ProxyA /usr/sbin/kamailio[6572]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Oct 7 13:45:36 POC_ProxyA /usr/sbin/kamailio[6572]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Oct 7 13:45:36 POC_ProxyA /usr/sbin/kamailio[6572]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Oct 7 13:45:36 POC_ProxyA /usr/sbin/kamailio[6572]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Oct 7 13:45:36 POC_ProxyA /usr/sbin/kamailio[6572]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Oct 7 13:45:36 POC_ProxyA /usr/sbin/kamailio[6572]: DEBUG: <core> [xavp.c:446]: xavp_destroy_list(): destroying xavp list (nil) Oct 7 13:45:36 POC_ProxyA /usr/sbin/kamailio[6572]: DEBUG: <core> [receive.c:278]: receive_msg(): cleaning up ________________________________ From: Daniel-Constantin Mierla <miconda@gmail.com><mailto:miconda@gmail.com> Sent: 15 November 2016 10:59 To: Jonathan Hunter; Kamailio SER - Users Mailing List Subject: Re: [SR-Users] Send SIP Info within a dialog using $uac_req(method)="INFO" Hello, I looked quickly at the code and the mi command should take the values from the parameters. Can you run with debug=3 and get all the logs messages to see if we can spot something threre. Cheers, Daniel On 15/11/16 11:27, Jonathan Hunter wrote: Hi, Sorry Daniel, let me be clear. Correct the To/From are not taken from the rpc command, the INFO is triggered/sent but with the To/From of the new request coming in; Below I dial 07917190438 from ext 209 and this INFO is sent; INFO sip:kamailio.org SIP/2.0 Via: SIP/2.0/UDP 8.8.8.8;branch=z9hG4bK63d7.374d4573000000000000000000000000.0 To: <sip:07917190438@8.8.8.8> From: <sip:209@8.8.8.8>;tag=c32652d8e50f480c90e2f8379a0698aa-ea50 CSeq: 10 INFO Call-ID: YWFhMmVmMzUxM2Q2YzUwMzZhOTFjNDc4OGZlYmM2N2I Max-Forwards: 70 Content-Length: 0 User-Agent: HA PBX However this command is triggered to send the INFO and the To/From/Contact are not changed/added; jsonrpc_exec('{"jsonrpc":"2.0","method":"mi","params": ["t_uac_dlg", "INFO", "sip:3003@8.8.8.8"<sip:3003@8.8.8.8>,".",".","From:sip:1234@2.2.2.2","To:sip:3003@8.8.8.8","Contact:sip:1234@2.2.2.2"<https://outlook.live.com/owa/?path=/mail/AQMkADAwATE0YzUwLWUxMjQtMzE3Yy0wMAItMDAKAC4AAAN%2F3kvE%2FPvCRZG1c9k9YgOnAQChqxR4ZvI4ToC2kdUvgxopAAACP%2FMAAAA%3D/rp>]}'); I assumed (possibly incorrectly) you can get the command to overwrite the current contents of the headers, so as above the RURI would change to sip:3003@8.8.8.8 and the From to sip:1234@2.2.2.2 etc, however they remain unchanged. Does that make sense? Thanks Jon ________________________________ From: Daniel-Constantin Mierla <miconda@gmail.com><mailto:miconda@gmail.com> Sent: 15 November 2016 10:12 To: Jonathan Hunter; Kamailio SER - Users Mailing List Subject: Re: [SR-Users] Send SIP Info within a dialog using $uac_req(method)="INFO" Hello, what do you mean by "with default parameters" in your last remark? Are the To/From not taken from the rpc command? Cheers, Daniel On 15/11/16 11:06, Jonathan Hunter wrote: Hi Daniel, That works in terms of clearing the error, however I just see kamailio send a SIP info message to kamailio.org, as apposed to the RURI I provide, I presume again this will just be putting the t_uac_dlg parameters in the correct order? Parameters: * method - request method * RURI - request SIP URI * NEXT HOP - next hop SIP URI (OBP); use “.” if no value. * socket - local socket to be used for sending the request; use “.” if no value. * headers - set of additional headers to be added to the request; at least “From” and “To” headers must be specify) * body - (optional, may not be present) request body (if present, requires the “Content-Type” and “Content-length” headers) As looks like I am defining things correctly now but its not picking them up, again if I run manually it works in command line; jsonrpc_exec('{"jsonrpc":"2.0","method":"mi","params": ["t_uac_dlg", "INFO", "sip:3003@8.8.8.8"<sip:3003@8.8.8.8>,".",".","From:sip:1234@2.2.2.2","To:sip:3003@8.8.8.8","Contact:sip:1234@2.2.2.2"]}'); All I see it fire is an INFO message to Request-Line: INFO sip:kamailio.org SIP/2.0, with default parameters. Thanks Jon -- Daniel-Constantin Mierla http://twitter.com/#!/miconda<http://twitter.com/#%21/miconda> - http://www.linkedin.com/in/miconda Kamailio Advanced Training, Berlin, Nov 28-30, 2016 - http://www.asipto.com -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Training, Berlin, Nov 28-30, 2016 - http://www.asipto.com