[SR-Users] presentce handly_subscribe() protocol/port mismatch to WS endpoint
Yuriy Gorlichenko
ovoshlook at gmail.com
Wed Oct 11 23:32:25 CEST 2017
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 at 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 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@
>>>>>> d0c20d13-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
>>>>>> ;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 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 at 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/20171012/56567226/attachment.html>
More information about the sr-users
mailing list