I will try to do also add_contact_alias that you recommend. Will look on result and describe it here
On Oct 12, 2017 13:29, "Yuriy Gorlichenko" <[email protected]> wrote: > No. I used fix_nated_contact for it because use just 2 libs for WS where > notify should be sent and both works well. > > Regarding other staff - i use fix_nated_contact() before send message to > mediaServer ( asterisk/fs) but it also works well. > > But yep i understand that in some cases it should be used as your > suggested. > > On Oct 12, 2017 13:24, "Daniel-Constantin Mierla" <[email protected]> > wrote: > >> I was traveling and no much time to follow up on mailing list ... >> >> Did you use set_contact_alias() before handling the subscribe with >> presence module? You should not change the contact in the way you do, some >> UA may reject it when receiving requests. >> >> Cheers, >> Daniel >> >> On 11.10.17 23:32, Yuriy Gorlichenko wrote: >> >> 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 <[email protected]>: >> >>> 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:[email protected]: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/adkeanjkn >>> s/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:[email protected]:63502;g >>> r=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 <[email protected]>: >>> >>>> 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 <[email protected]>: >>>> >>>>> 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 <[email protected]>: >>>>> >>>>>> 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" <[email protected]> >>>>>> 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:[email protected] >>>>>>> .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:[email protected]: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 <[email protected]>: >>>>>>> >>>>>>>> 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-9ab8ec94b1 >>>>>>>> 41;gr=urn:uuid:14f23c6c-166f-4649-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:[email protected] >>>>>>>> .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:[email protected]: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 < >>>>>>>> [email protected]>: >>>>>>>> >>>>>>>>> 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 <[email protected]> >>>>>>>>> : >>>>>>>>> >>>>>>>>>> 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 >>>>>>>>> [email protected]https://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 >>>>>>> >>>>>>> >>>>> >>>> >>> >> >> -- >> 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 [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
