[SR-Users] presentce handly_subscribe() protocol/port mismatch to WS endpoint
Yuriy Gorlichenko
ovoshlook at gmail.com
Wed Oct 11 21:00:39 CEST 2017
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 at 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 at 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 at d0c20d13-e5b4-4649-821e-9ab8ec94b141
DEBUG: presence [notify.c:123]: printf_subs():
watcher_user at watcher_domain:
94e51c30Bdf28de52519 at d0c20d13-e5b4-4649-821e-9ab8ec94b141
DEBUG: presence [notify.c:124]: printf_subs(): to_user at to_domain:
8dc08f881f2105dD3d75 at d0c20d13-e5b4-4649-821e-9ab8ec94b141
DEBUG: presence [notify.c:125]: printf_subs(): from_user at from_domain:
94e51c30Bdf28de52519 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at d0c20d13-e5b4-4649-821e-9ab8ec94b141 via
>>>> sip:94e51c30bdf28de52519 at 93.81.99.68:54733;gr=urn:uuid:88b30
>>>> 33f-e65d-4694-ac45-2a1d1a44501c on behalf of
>>>> sip:8dc08f881f2105dD3d75 at d0c20d13-e5b4-4649-821e-9ab8ec94b141 for
>>>> event presence : 3biad4n635ugovv7vmjv
>>>>
>>>>
>>>> 2017-10-03 21:31 GMT+03:00 Yuriy Gorlichenko <ovoshlook at 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 at 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 at 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 at d0c20d13-e5b4-4649-821e-9ab8ec94b141 via
>>>>> sip:94e51c30bdf28de52519 at 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 at 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 at 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 at 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
>>>>
>>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20171011/5662026d/attachment.html>
More information about the sr-users
mailing list