Re: [SR-Users] presentce handly_subscribe() protocol/port mismatch to WS endpoint

2017-10-12 Thread Yuriy Gorlichenko
Hi. I added set_contact_alias() insead process i described previously if(is_method("SUBSCRIBE")) { xlog("L_INFO", "{$rm} . from external sources contact : $ct . proto is {$pr} "); set_contact_alias(); handle_subscribe(); t_release(); } But i got next error: presence engine

Re: [SR-Users] presentce handly_subscribe() protocol/port mismatch to WS endpoint

2017-10-12 Thread Yuriy Gorlichenko
Sorry - set_contact_alias() On Oct 12, 2017 14:05, "Yuriy Gorlichenko" wrote: > Yep got it. Looks like add_contact_alias should fix my issue > > On Oct 12, 2017 13:37, "Daniel-Constantin Mierla" > wrote: > >> You have to use set_contact_alias() instead

Re: [SR-Users] presentce handly_subscribe() protocol/port mismatch to WS endpoint

2017-10-12 Thread Yuriy Gorlichenko
Yep got it. Looks like add_contact_alias should fix my issue On Oct 12, 2017 13:37, "Daniel-Constantin Mierla" 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 >

Re: [SR-Users] presentce handly_subscribe() protocol/port mismatch to WS endpoint

2017-10-12 Thread Daniel-Constantin Mierla
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

Re: [SR-Users] presentce handly_subscribe() protocol/port mismatch to WS endpoint

2017-10-12 Thread Yuriy Gorlichenko
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" 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. > >

Re: [SR-Users] presentce handly_subscribe() protocol/port mismatch to WS endpoint

2017-10-12 Thread Yuriy Gorlichenko
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

Re: [SR-Users] presentce handly_subscribe() protocol/port mismatch to WS endpoint

2017-10-12 Thread Daniel-Constantin Mierla
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

Re: [SR-Users] presentce handly_subscribe() protocol/port mismatch to WS endpoint

2017-10-11 Thread Yuriy Gorlichenko
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 :

Re: [SR-Users] presentce handly_subscribe() protocol/port mismatch to WS endpoint

2017-10-11 Thread Yuriy Gorlichenko
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

Re: [SR-Users] presentce handly_subscribe() protocol/port mismatch to WS endpoint

2017-10-11 Thread Yuriy Gorlichenko
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

Re: [SR-Users] presentce handly_subscribe() protocol/port mismatch to WS endpoint

2017-10-04 Thread Yuriy Gorlichenko
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 : > I mean i tried to change $du and print it. It was changed but notify was > set

Re: [SR-Users] presentce handly_subscribe() protocol/port mismatch to WS endpoint

2017-10-04 Thread Yuriy Gorlichenko
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" wrote: >

Re: [SR-Users] presentce handly_subscribe() protocol/port mismatch to WS endpoint

2017-10-04 Thread Yuriy Gorlichenko
Already tried yesterday evening. Same result with $du On Oct 4, 2017 14:35, "Daniel-Constantin Mierla" 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:

Re: [SR-Users] presentce handly_subscribe() protocol/port mismatch to WS endpoint

2017-10-04 Thread Daniel-Constantin Mierla
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

Re: [SR-Users] presentce handly_subscribe() protocol/port mismatch to WS endpoint

2017-10-03 Thread Yuriy Gorlichenko
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

Re: [SR-Users] presentce handly_subscribe() protocol/port mismatch to WS endpoint

2017-10-03 Thread Yuriy Gorlichenko
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

Re: [SR-Users] presentce handly_subscribe() protocol/port mismatch to WS endpoint

2017-10-03 Thread Daniel-Constantin Mierla
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

Re: [SR-Users] presentce handly_subscribe() protocol/port mismatch to WS endpoint

2017-10-03 Thread Yuriy Gorlichenko
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 : > Hi. I

[SR-Users] presentce handly_subscribe() protocol/port mismatch to WS endpoint

2017-10-03 Thread Yuriy Gorlichenko
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():