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/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:[email protected]: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 <[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
