[SR-Users] presentce handly_subscribe() protocol/port mismatch to WS endpoint
Daniel-Constantin Mierla
miconda at gmail.com
Thu Oct 12 12:37:00 CEST 2017
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 at gmail.com
> <mailto:ovoshlook at 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 at gmail.com <mailto:miconda at 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 at gmail.com <mailto: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 <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 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
>> <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 at gmail.com <mailto: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 <mailto: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 <mailto: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
>> <mailto: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-2a1d1a44501c;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:88b3033f-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
>>> <mailto: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
>>> <http://93.81.99.68:57031>,
>>> INFO: <script>: #012SUBSCRIBE |
>>> proto: wss,
>>> INFO: <script>: #012SUBSCRIBE |
>>> RURI:
>>> sip:8dc08f881f2105dD3d75 at d0c20d13-e5b4-4649-821e-9ab8ec94b141,
>>> INFO: <script>: #012SUBSCRIBE |
>>> contact:
>>> <sip:94e51c30bdf28de52519 at 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 at 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 at d0c20d13-e5b4-4649-821e-9ab8ec94b141
>>> via
>>> sip:94e51c30bdf28de52519 at 93.81.99.68:57031;gr=urn:uuid:14f23c6c-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
>>> <mailto: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
>>>> <mailto: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 List
>>>> sr-users at lists.kamailio.org
>>>> <mailto:sr-users at 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>
>>
>>
>>
>>
>>
>
> --
> 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 -- 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/737f858e/attachment.html>
More information about the sr-users
mailing list