Ok. solved I moved record_route for subscribe to other part of the config file and for now if msg_apply_changes() works so if someone intrested in solution:
For me it works like this if(is_method("SUBSCRIBE")) { if ( $pr == "wss" ) { xlog("L_INFO", "$rm from WSS proto. contact : $ct "); remove_hf("Contact"); append_hf("Contact:<sip:$fU@$si:$sp;transport=ws>\r\n"); msg_apply_changes(); xlog("L_INFO", "New contact : $ct "); $fs = "tls:"+INTERNALIP+":7443"; } handle_subscribe(); t_release(); This code saves valid contact at the active_watchers table for this SUBSCRIBE request and generates NOTIFY via correct transport. 2017-10-11 22:00 GMT+03:00 Yuriy Gorlichenko <ovoshl...@gmail.com>: > Continue talking with myself... )) > > Found when presence building NOTIFY request it uses entry from > active_watchers table for sending NOTIFY > When SUBSCRIBE from webPhone receives by kamailio it stors it like this > > presentity_uri | > watcher_username | watcher_domain | to_user > | to_domain | event | event_id | > to_tag | from_tag | callid > | local_cseq | remote_cseq | contact > | > record_route | expires | status | reason | version | socket_info > | local_contact | from_user | from_domain > | updated | updated_winfo | flags | user_agent > | > sip:8dc08f881f2105dD3d75@d0c20d13-e5b4-4649-821e-9ab8ec94b141 | > 94e51c30Bdf28de52519 | d0c20d13-e5b4-4649-821e-9ab8ec94b141 | > 8dc08f881f2105dD3d75 | d0c20d13-e5b4-4649-821e-9ab8ec94b141 | presence | > | 65b96bb6fd203a89fdddc27e45e37497-709f | vbr8o327n1 | > 6qgtaasruts2tqsib3rk | 1 | 9634 | > sip:94e51c30bdf28de52519@95.29.8.36:55404;gr=urn:uuid: > 305d99ab-ddf2-46b0-9ec0-74a1eef86595 | | 1507746863 | 1 > | | 2 | tls:172.31.13.191:7443 | sip:1.2.3.4:5060 | > 94e51c30Bdf28de52519 | d0c20d13-e5b4-4649-821e-9ab8ec94b141 | -1 | > -1 | 0 | SIP.js/0.7.3 | > > so it says nothing about that watcher at the websockets > > > Then i see it builds NOTIFY request using these params: > > DEBUG: presence [notify.c:1479]: send_notify_request(): dialog info: > DEBUG: presence [notify.c:122]: printf_subs(): pres_uri: > sip:8dc08f881f2105dD3d75@d0c20d13-e5b4-4649-821e-9ab8ec94b141 > DEBUG: presence [notify.c:123]: printf_subs(): > watcher_user@watcher_domain: 94e51c30Bdf28de52519@d0c20d13- > e5b4-4649-821e-9ab8ec94b141 > DEBUG: presence [notify.c:124]: printf_subs(): to_user@to_domain: > 8dc08f881f2105dD3d75@d0c20d13-e5b4-4649-821e-9ab8ec94b141 > DEBUG: presence [notify.c:125]: printf_subs(): from_user@from_domain: > 94e51c30Bdf28de52519@d0c20d13-e5b4-4649-821e-9ab8ec94b141 > DEBUG: presence [notify.c:126]: printf_subs(): callid/from_tag/to_tag: > 11ml332armq1sdjjhr4i/adkeanjkns/65b96bb6fd203a89fdddc27e45e37497-92c7 > DEBUG: presence [notify.c:127]: printf_subs(): local_cseq/remote_cseq: > 1/9417 > DEBUG: presence [notify.c:128]: printf_subs(): local_contact/contact: > sip:1.2.3.4:5060/sip:94e51c30bdf28de52519@95.29.8. > 36:63502;gr=urn:uuid:ad169d10-dc89-48e3-9a83-28635a77f216 > DEBUG: presence [notify.c:129]: printf_subs(): record_route: > DEBUG: presence [notify.c:130]: printf_subs(): sockinfo_str: tls: > 172.31.13.191:7443 > DEBUG: presence [notify.c:132]: printf_subs(): event: presence > DEBUG: presence [notify.c:133]: printf_subs(): status: active > DEBUG: presence [notify.c:134]: printf_subs(): reason: > DEBUG: presence [notify.c:135]: printf_subs(): version: 2 > DEBUG: presence [notify.c:136]: printf_subs(): expires: 599 > > > So i suppose it sending to UPD because at the contact field at the > database stores nothing about transport (like postfix ;transport=ws) > And does not matter how I handle contact at NAT (by fix_nated_contact() or > add_contact_alias()) because it stores just a source IPaddress and port. > > fix_nated_register() will not help to fix this issue because it is just > updates location and uses avp(RECEIVED) for storing real address and real > transport which never have any entry to the "active_watchers" table. > > So the only way i found to say where to send notify is to change $ct > variable with adding postfix ";transport=ws" > Because based on it module wil build NOTIFY > > but here are 2 troubles > 1) $ct variable is readonly (remove and append contact header has no any > effect for this. msg_apply_changes says: > "cannot apply msg changes after adding record-route header - it > breaks conditional 2nd header") > 2) as i said i can not change anything at the tm:local-request for notify > as i wrote at the prevoius messages here. IT changes needed variables but > it has no effect on message > > So main question - how to save real transport at the contct field at the > active_watchers table. > > Will be happy to any suggession. > > > > > 2017-10-11 13:13 GMT+03:00 Yuriy Gorlichenko <ovoshl...@gmail.com>: > >> Hi. Got debug 3 information and found next (here is pastebin link with >> dump >> https://pastebin.com/ALHQkM9E) >> >> After NOTIFY was created i trying to handle it by tm:local-request route >> and found there one thing afnter changed $fs and $ru with $du >> >> DEBUG: tm [uac.c:329]: t_run_local_req(): apply new updates without Via >> to sip msg >> >> as i understood it applies changes but not uses it for redirect request >> throught needed socket. >> Shoud i use msg_apply_changes() or something ike that? >> >> >> >> >> >> 2017-10-04 16:13 GMT+03:00 Yuriy Gorlichenko <ovoshl...@gmail.com>: >> >>> May be debug=3 level says more? I will try to collect it. I don't think >>> it is a bug. I think somethig wrong at my side, but can not find anything >>> >>> 2017-10-04 14:58 GMT+03:00 Yuriy Gorlichenko <ovoshl...@gmail.com>: >>> >>>> I mean i tried to change $du and print it. It was changed but notify >>>> was set to original ruri. I know that it worked for register requests and >>>> invite. I built services using it. >>>> >>>> I found this trouble only with NOTIFY >>>> >>>> On Oct 4, 2017 14:35, "Daniel-Constantin Mierla" <mico...@gmail.com> >>>> wrote: >>>> >>>>> Can you print $du there and see if it set? looks like it is not routed >>>>> by r-uri, but dst uri. >>>>> >>>>> Cheers, >>>>> Daniel >>>>> >>>>> On 03.10.17 22:58, Yuriy Gorlichenko wrote: >>>>> >>>>> Found that at the tm:local-request $ru modifies but anyway - request >>>>> sent to old RURI. >>>>> INFO: NOTIFY to WS, update RURI >>>>> >>>>> -- here is making >>>>> $ru = $ru+";transport=ws"; >>>>> --- >>>>> >>>>> INFO: NOTIFY to WS, new RURI: sip:94e51c30bdf28de52519@93.81 >>>>> .99.68:54733;gr=urn:uuid:88b3033f-e65d-4694-ac45-2a1d1a44501 >>>>> c;transport=ws >>>>> >>>>> --- for now $ru is updated >>>>> >>>>> -- but here also same result: >>>>> >>>>> INFO: presence [notify.c:1619]: send_notify_request(): NOTIFY >>>>> sip:94e51c30Bdf28de52519@d0c20d13-e5b4-4649-821e-9ab8ec94b141 via >>>>> sip:94e51c30bdf28de52519@93.81.99.68:54733;gr=urn:uuid:88b30 >>>>> 33f-e65d-4694-ac45-2a1d1a44501c on behalf of >>>>> sip:8dc08f881f2105dD3d75@d0c20d13-e5b4-4649-821e-9ab8ec94b141 for >>>>> event presence : 3biad4n635ugovv7vmjv >>>>> >>>>> >>>>> 2017-10-03 21:31 GMT+03:00 Yuriy Gorlichenko <ovoshl...@gmail.com>: >>>>> >>>>>> Can not find any entry of this device at the active watchers. >>>>>> Suppose after module found sockets mistmatch and didnt got NOTIFY >>>>>> response it removes entry from active watchers... >>>>>> >>>>>> I added handling at the event route as you sugested and tried to do >>>>>> next >>>>>> >>>>>> Firs i tried fix $ru here but it does not work >>>>>> Also tried to force socket but same >>>>>> >>>>>> >>>>>> I see at the logs that first kamailio says about proto mistmatch and >>>>>> only then calling event_route[tm:local-request]... >>>>>> >>>>>> This is my log with most important variables for understanding >>>>>> >>>>>> INFO: <script>: --------------------------------------- >>>>>> INFO: <script>: #012SUBSCRIBE | source: 93.81.99.68:57031, >>>>>> INFO: <script>: #012SUBSCRIBE | proto: wss, >>>>>> INFO: <script>: #012SUBSCRIBE | RURI: sip:8dc08f881f2105dD3d75@ >>>>>> d0c20d13-e5b4-4649-821e-9ab8ec94b141, >>>>>> INFO: <script>: #012SUBSCRIBE | contact: <sip:94e51c30bdf28de52519@ >>>>>> d0c20d13-e5b4-4649-821e-9ab8ec94b141;gr=urn:uuid:14f23c6c-166f-4 >>>>>> 649-9b7e-71a66b20450f> >>>>>> INFO: <script>: #012SUBSCRIBE | from : 94e51c30Bdf28de52519 >>>>>> INFO: <script>: #012SUBSCRIBE | to : 8dc08f881f2105dD3d75 >>>>>> INFO: <script>: --------------------------------------- >>>>>> INFO: <script>: SUBSCRIBE : fixing nated contact >>>>>> INFO: <script>: SUBSCRIBE from WSS proto >>>>>> >>>>>> ----- Here is handle_subscribe happens >>>>>> >>>>>> WARNING: <core> [core/forward.c:231]: get_send_socket2(): >>>>>> protocol/port mismatch (forced tls:172.31.13.191:7443, to udp: >>>>>> 93.81.99.68:57031) >>>>>> >>>>>> ---- event_route[tm:local-request] >>>>>> >>>>>> INFO: <script>: --------------------------------------- >>>>>> INFO: <script>: #012NOTIFY | source: 172.31.13.191:5060, >>>>>> INFO: <script>: #012NOTIFY | proto: udp, >>>>>> INFO: <script>: #012NOTIFY | RURI: sip:94e51c30bdf28de52519@93.81 >>>>>> .99.68:57031;gr=urn:uuid:14f23c6c-166f-4649-9b7e-71a66b20450f, >>>>>> INFO: <script>: #012NOTIFY | contact: <sip:34.192.121.47:5060 >>>>>> ;transport=tls> >>>>>> INFO: <script>: #012NOTIFY | from : 8dc08f881f2105dD3d75 >>>>>> INFO: <script>: #012NOTIFY | to : 94e51c30Bdf28de52519 >>>>>> INFO: <script>: --------------------------------------- >>>>>> INFO: <script>: NOTIFY to WS, forsing socket to TLS >>>>>> >>>>>> ---- here is i trying to fix $ru and $fs >>>>>> >>>>>> INFO: presence [notify.c:1619]: send_notify_request(): NOTIFY >>>>>> sip:94e51c30Bdf28de52519@d0c20d13-e5b4-4649-821e-9ab8ec94b141 via >>>>>> sip:94e51c30bdf28de52519@93.81.99.68:57031;gr=urn:uuid:14f23 >>>>>> c6c-166f-4649-9b7e-71a66b20450f on behalf of >>>>>> sip:8dc08f881f2105dD3d75@d0c20d13-e5b4-4649-821e-9ab8ec94b141 for >>>>>> event presence : 8n0erm4mtff6pn9ljgdq >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 2017-10-03 18:43 GMT+03:00 Daniel-Constantin Mierla < >>>>>> mico...@gmail.com>: >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> you should use set_contact_alias() for subscribe instead of >>>>>>> fixed_nated_contact(), is a better option. >>>>>>> >>>>>>> Back to the reported topic, can you paste here the db record from >>>>>>> active_watchers table? >>>>>>> >>>>>>> Then, you should be able to update some parts of the local generated >>>>>>> requests by having an event_route[tm:local-request] block in your >>>>>>> kamailio.cfg. >>>>>>> >>>>>>> Cheers, >>>>>>> Daniel >>>>>>> >>>>>>> On 03.10.17 10:44, Yuriy Gorlichenko wrote: >>>>>>> >>>>>>> Also found at the lists some solutions like "accept >>>>>>> fix_nated_register() and fix_nated_contact() for REGISTER and SUBSCRIBE" >>>>>>> >>>>>>> Done it. But still protos mistmatch... >>>>>>> >>>>>>> kamailio founds tls:myip:myport and forces t to udp... >>>>>>> >>>>>>> 2017-10-03 10:49 GMT+03:00 Yuriy Gorlichenko <ovoshl...@gmail.com>: >>>>>>> >>>>>>>> Hi. I have presence server and it works fine for UDP/TCP/TLS >>>>>>>> endpoints. >>>>>>>> For now i have new one type of endpoints that runs via WebSockets >>>>>>>> >>>>>>>> It sends SUBSCRIBE request to the and then after handle_subscribe() >>>>>>>> NOTIFY not comes to the subscriber because of >>>>>>>> [core/forward.c:231]: get_send_socket2(): protocol/port mismatch >>>>>>>> >>>>>>>> I already had some issues regarding this for ACK for example but i >>>>>>>> resolved it cimply doing >>>>>>>> >>>>>>>> $ru = $ru+";transport=wss" >>>>>>>> >>>>>>>> but NOTIFY sending is internal process and can't be controlled by >>>>>>>> config file. So i can not change $ru for NOTIFY directly. >>>>>>>> >>>>>>>> Any ideas how to fix this? >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Kamailio (SER) - Users Mailing >>>>>>> Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Daniel-Constantin Mierlawww.twitter.com/miconda -- >>>>>>> www.linkedin.com/in/miconda >>>>>>> Kamailio Advanced Training - www.asipto.com >>>>>>> Kamailio World Conference - www.kamailioworld.com >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> Daniel-Constantin Mierlawww.twitter.com/miconda -- >>>>> www.linkedin.com/in/miconda >>>>> Kamailio Advanced Training - www.asipto.com >>>>> Kamailio World Conference - www.kamailioworld.com >>>>> >>>>> >>> >> >
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users