Yep got it. Looks like add_contact_alias should fix my issue On Oct 12, 2017 13:37, "Daniel-Constantin Mierla" <[email protected]> wrote:
> You have to use set_contact_alias() instead of add_contact_alias() -- see > the readme of nathelper module, there is a different behaviour between the > two, which is relevant in this case. > > Cheers, > Daniel > > On 12.10.17 12:31, Yuriy Gorlichenko wrote: > > 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:94e51c30b >>>> [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: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:[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 >>> >>> > -- > 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
