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 <ovoshlook@gmail.com mailto:ovoshlook@gmail.com>:

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 sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

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 ;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:94e51c30bdf28de52519@93.81.99.68: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 ovoshlook@gmail.com:

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-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, 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:94e51c30bdf28de52519@93.81.99.68: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 miconda@gmail.com:

...

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 ovoshlook@gmail.com:

...

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 Listsr-users@lists.kamailio.orghttps://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

Already tried yesterday evening. Same result with $du

On Oct 4, 2017 14:35, "Daniel-Constantin Mierla" miconda@gmail.com 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:94e51c30bdf28de52519@93. 81.99.68: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:94e51c30bdf28de52519@93.81.99.68: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 ovoshlook@gmail.com:

...

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@d0c20 d13-e5b4-4649-821e-9ab8ec94b141, INFO: <script>: #012SUBSCRIBE | contact: sip:94e51c30bdf28de52519@d0c2 0d13-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, 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;transp ort=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:94e51c30bdf28de52519@93.81.99.68: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 miconda@gmail.com:

...

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 ovoshlook@gmail.com:

...

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 Listsr-users@lists.kamailio.orghttps://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

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 ovoshlook@gmail.com:

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" miconda@gmail.com 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:94e51c30bdf28de52519@93.81 .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:94e51c30bdf28de52519@93.81.99.68: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 ovoshlook@gmail.com:

...

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@d0c20 d13-e5b4-4649-821e-9ab8ec94b141, INFO: <script>: #012SUBSCRIBE | contact: sip:94e51c30bdf28de52519@ d0c20d13-e5b4-4649-821e-9ab8ec94b141;gr=urn:uuid:14f23c6c-166f-4 649-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;transp ort=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:94e51c30bdf28de52519@93.81.99.68: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 miconda@gmail.com:

...

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 ovoshlook@gmail.com:

...

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 Listsr-users@lists.kamailio.orghttps://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

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:94e51c30bdf28de52519@95.29.8.36: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:94e51c30bdf28de52519@95.29.8.36: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 ovoshlook@gmail.com:

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 ovoshlook@gmail.com:

...

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 ovoshlook@gmail.com:

...

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" miconda@gmail.com 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:94e51c30bdf28de52519@93.81 .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:94e51c30bdf28de52519@93.81.99.68: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 ovoshlook@gmail.com:

...

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@d0c20 d13-e5b4-4649-821e-9ab8ec94b141, INFO: <script>: #012SUBSCRIBE | contact: sip:94e51c30bdf28de52519@ d0c20d13-e5b4-4649-821e-9ab8ec94b141;gr=urn:uuid:14f23c6c-166f-4 649-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;transp ort=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:94e51c30bdf28de52519@93.81.99.68: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 <miconda@gmail.com

...

:

...

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 ovoshlook@gmail.com:

> 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 Listsr-users@lists.kamailio.orghttps://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

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 <ovoshlook@gmail.com mailto:ovoshlook@gmail.com>:

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:94e51c30bdf28de52519@95.29.8.36: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:94e51c30bdf28de52519@95.29.8.36:63502;gr=urn:uuid:ad169d10-dc89-48e3-9a83-28635a77f216
<http://1.2.3.4:5060/sip:94e51c30bdf28de52519@95.29.8.36: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 <ovoshlook@gmail.com
<mailto:ovoshlook@gmail.com>>:

    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
    <ovoshlook@gmail.com <mailto:ovoshlook@gmail.com>>:

        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
        <ovoshlook@gmail.com <mailto:ovoshlook@gmail.com>>:

            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"
            <miconda@gmail.com <mailto:miconda@gmail.com>> 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:94e51c30bdf28de52519@93.81.99.68: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:94e51c30bdf28de52519@93.81.99.68: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
                <ovoshlook@gmail.com <mailto:ovoshlook@gmail.com>>:

                    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:94e51c30bdf28de52519@93.81.99.68: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:94e51c30bdf28de52519@93.81.99.68: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 <miconda@gmail.com
                    <mailto:miconda@gmail.com>>:

                        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 <ovoshlook@gmail.com
                        <mailto:ovoshlook@gmail.com>>:

                            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
                        sr-users@lists.kamailio.org
                        <mailto:sr-users@lists.kamailio.org>
                        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>

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" ovoshlook@gmail.com 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" miconda@gmail.com 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 ovoshlook@gmail.com:

...

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:94e51c30bdf28de52519@95.29.8.36: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:94e51c30bdf28de52519@95.29.8.36: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 ovoshlook@gmail.com:

...

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 ovoshlook@gmail.com:

...

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 ovoshlook@gmail.com:

...

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" miconda@gmail.com 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:94e51c30bdf28de52519@93.81 > .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:94e51c30bdf28de52519@93.81.99.68: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 ovoshlook@gmail.com: > >> 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:94e51c30bdf28de52519@93.81.99.68: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 < >> miconda@gmail.com>: >> >>> 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 ovoshlook@gmail.com >>> : >>> >>>> 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 Listsr-users@lists.kamailio.orghttps://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

Yep got it. Looks like add_contact_alias should fix my issue

On Oct 12, 2017 13:37, "Daniel-Constantin Mierla" miconda@gmail.com 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" ovoshlook@gmail.com 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" miconda@gmail.com 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 ovoshlook@gmail.com:

...

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:94e51c30bdf28de52519@95.29.8.36: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 df28de52519@95.29.8.36: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 ovoshlook@gmail.com:

...

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 ovoshlook@gmail.com:

...

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 ovoshlook@gmail.com:

> 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" miconda@gmail.com > 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:94e51c30bdf28de52519@93.81 >> .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:94e51c30bdf28de52519@93.81.99.68: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 ovoshlook@gmail.com: >> >>> 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:94e51c30bdf28de52519@93.81.99.68: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 < >>> miconda@gmail.com>: >>> >>>> 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 <ovoshlook@gmail.com >>>> >: >>>> >>>>> 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 Listsr-users@lists.kamailio.orghttps://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

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 tries to check domain of contact via DNS. Offcource it can not because it is lust an ID So set_contact_alias() works but not in this case (works well for all SUBSCRIBES where domain of contact is an IP address:port pair or real domain name)

INFO: <script>:{SUBSCRIBE} . from external sources contact : sip:94e51c30bdf28de52519@d0c20d13-e5b4-4649-821e-9ab8ec94b141;gr=urn:uuid:e117b73f-c43e-42cc-a136-3c36fe65b5fb . proto is {wss} INFO: <script>: {SUBSCRIBE} . contact : sip:94e51c30bdf28de52519@d0c20d13-e5b4-4649-821e-9ab8ec94b141;gr=urn:uuid:e117b73f-c43e-42cc-a136-3c36fe65b5fb . proto is {wss} ERROR: tm [ut.h:296]: uri2dst2(): ERROR: uri2dst: failed to resolve "d0c20d13-e5b4-4649-821e-9ab8ec94b141" :unresolvable A or AAAA request (-7) ERROR: tm [uac.c:443]: t_uac_prepare(): no socket found ERROR: presence [notify.c:1607]: send_notify_request(): in function tmb.t_request_within ERROR: presence [notify.c:1704]: notify(): sending Notify not successful ERROR: presence [notify.c:2763]: notifier_notify(): could not send notify ERROR: presence [notify.c:3040]: process_dialogs(): sending NOTIFY request

So in my case i fixed it with mixed scenario (anyway should rewrite contact domain but can not to do it with fix_nated_contact() because nathelper module says that i trying to change contact twice). But think it is better solution that ws previously:

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\r\n"); msg_apply_changes(); xlog("L_INFO", "New contact : $ct "); }

set_contact_alias(); handle_subscribe(); t_release(); }

so if you have any other suggestions let me knwo plz but anyway that you for response you really hepled. I didn't know about set_contact_alias() (suppose not read nathepler module documetation since 4.0.x version).

2017-10-12 14:06 GMT+03:00 Yuriy Gorlichenko ovoshlook@gmail.com:

Sorry - set_contact_alias()

On Oct 12, 2017 14:05, "Yuriy Gorlichenko" ovoshlook@gmail.com wrote:

...

Yep got it. Looks like add_contact_alias should fix my issue

On Oct 12, 2017 13:37, "Daniel-Constantin Mierla" miconda@gmail.com 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" ovoshlook@gmail.com 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" miconda@gmail.com 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 ovoshlook@gmail.com:

...

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:94e51c30bdf28de52519@95.29.8.36: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 df28de52519@95.29.8.36: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 ovoshlook@gmail.com:

> 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 ovoshlook@gmail.com: > >> 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 ovoshlook@gmail.com: >> >>> 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" < >>> miconda@gmail.com> 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:94e51c30bdf28de52519@93.81 >>>> .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:94e51c30bdf28de52519@93.81.99.68: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 <ovoshlook@gmail.com >>>> >: >>>> >>>>> 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-71a66b20450 >>>>> f, >>>>> 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:94e51c30bdf28de52519@93.81.99.68: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 < >>>>> miconda@gmail.com>: >>>>> >>>>>> 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 < >>>>>> ovoshlook@gmail.com>: >>>>>> >>>>>>> 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 Listsr-users@lists.kamailio.orghttps://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