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(a)gmail.com
<mailto: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(a)gmail.com <mailto: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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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>