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] > <mailto:[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] <mailto:[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] <mailto:[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 <http://172.31.13.191:7443> | >> sip:1.2.3.4:5060 <http://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 >> >> <http://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 >> <http://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] <mailto:[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] <mailto:[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] <mailto:[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] >> <mailto:[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]:54733;gr=urn:uuid:88b3033f-e65d-4694-ac45-2a1d1a44501c;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:88b3033f-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] >>> <mailto:[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 >>> <http://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-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 >>> <http://172.31.13.191:7443>, to >>> udp:93.81.99.68:57031 >>> <http://93.81.99.68:57031>) >>> >>> ---- event_route[tm:local-request] >>> >>> INFO: <script>: >>> --------------------------------------- >>> INFO: <script>: #012NOTIFY | >>> source: 172.31.13.191:5060 >>> <http://172.31.13.191:5060>, >>> INFO: <script>: #012NOTIFY | >>> proto: udp, >>> INFO: <script>: #012NOTIFY | RURI: >>> >>> sip:[email protected]:57031;gr=urn:uuid:14f23c6c-166f-4649-9b7e-71a66b20450f, >>> INFO: <script>: #012NOTIFY | >>> contact: <sip:34.192.121.47:5060 >>> <http://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:14f23c6c-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] >>> <mailto:[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] >>>> <mailto:[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 List >>>> [email protected] >>>> <mailto:[email protected]> >>>> >>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>>> >>>> <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users> >>> >>> -- >>> Daniel-Constantin Mierla >>> www.twitter.com/miconda >>> <http://www.twitter.com/miconda> -- >>> www.linkedin.com/in/miconda >>> <http://www.linkedin.com/in/miconda> >>> Kamailio Advanced Training - >>> www.asipto.com >>> <http://www.asipto.com> >>> Kamailio World Conference - >>> www.kamailioworld.com >>> <http://www.kamailioworld.com> >>> >>> >>> >> >> -- >> Daniel-Constantin Mierla >> www.twitter.com/miconda >> <http://www.twitter.com/miconda> -- >> www.linkedin.com/in/miconda >> <http://www.linkedin.com/in/miconda> >> Kamailio Advanced Training - www.asipto.com >> <http://www.asipto.com> >> Kamailio World Conference - www.kamailioworld.com >> <http://www.kamailioworld.com> >> >> >> >> >> > > -- > Daniel-Constantin Mierla > www.twitter.com/miconda <http://www.twitter.com/miconda> -- > www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda> > Kamailio Advanced Training - www.asipto.com <http://www.asipto.com> > Kamailio World Conference - www.kamailioworld.com > <http://www.kamailioworld.com> > -- Daniel-Constantin Mierla www.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
