[SR-Users] presentce handly_subscribe() protocol/port mismatch to WS endpoint
Yuriy Gorlichenko
ovoshlook at gmail.com
Thu Oct 12 22:32:04 CEST 2017
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 at d0c20d13-e5b4-4649-821e-9ab8ec94b141;gr=urn:uuid:e117b73f-c43e-42cc-a136-3c36fe65b5fb>
. proto is {wss}
INFO: <script>: {SUBSCRIBE} . contact :
<sip:94e51c30bdf28de52519 at 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 at gmail.com>:
> Sorry - set_contact_alias()
>
> On Oct 12, 2017 14:05, "Yuriy Gorlichenko" <ovoshlook at 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 at 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 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>
>>>> 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>:
>>>>>
>>>>>> 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/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 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 d0c20d13-e5b4-4649-821e-9ab8ec94b141,
>>>>>>>>>>> INFO: <script>: #012SUBSCRIBE | contact: <
>>>>>>>>>>> sip:94e51c30bdf28de52519 at 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 at 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 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> 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/35176400/attachment.html>
More information about the sr-users
mailing list