Re: [SR-Users] Kamailio - DMQ dns srv Question
Hello, I can take a look today. Cheers, Charles On 22 Sep 2016 06:20, "Daniel-Constantin Mierla" wrote: > Hello, > > I guess that the one who did the implementation of the srv query for dmq > hasn't "allocated" any service name. I haven't looked at the sources, but I > guess it should be a small patch to compose the srv dns string to be > queried -- maybe that part can be made a mod param so each can choose its > preferred service. > > Cheers, > Daniel > > On 21/09/16 19:28, José Seabra wrote: > > Hello, > I have a doubt related with DMQ dns behavior, I noticed that when kamailio > starts, it tries to resolve DMQ name configured on parameter > notification_address as the following sequence: > >1. SRV >2. A >3. > > > Isn't supposed kamailio try first resolve the NAPTR DMQ name, and then > SRV? > I'm asking this because kamailio is trying resolve the SRV record without > any transport protocol specified on query, as my dns server only accepts > queries on the format "_Service._Proto.Name" the SRV will never be resolved. > > Thank you. > BR > -- > José Seabra > > > ___ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing > listsr-us...@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > > > -- > Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - > http://www.linkedin.com/in/miconda > Kamailio Advanced Training, Berlin, Oct 24-26, 2016 - http://www.asipto.com > > > ___ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users@lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > > -- Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered office: Faraday Wharf, Innovation Birmingham Campus, Holt Street, Birmingham Science Park, Birmingham B7 4BB. ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] ndb_mongodb -Sending Query to Mongo
Hello,
Ok cool thanks Daniel will do that.
Cheers
Jon
To: sr-users@lists.sip-router.org
From: mico...@gmail.com
Date: Thu, 22 Sep 2016 07:28:19 +0200
Subject: Re: [SR-Users] ndb_mongodb -Sending Query to Mongo
Hello,
in case of ndb_mongodb, the result is the json returned by the
server. Maybe you can run with debug=3 and see if you can get more
info about what happens there.
To access part of result, you need to use a json module over
$mongodb(mgr1=>value).
Cheers,
Daniel
On 21/09/16 14:36, Jonathan Hunter
wrote:
Hi Guys,
I am using the ndb_mongodb module, and Im just trying to
return values from the dispatcher table, in particular the
setid of a particular entry depending on its attrs value.
If I query using mongodb shell command it works fine, here
I enter test.com and it returns only the setid value, or 2;
db.dispatcher.find( { attrs: "test.com" }, { setid: 1, _id:
0 } )
{ "setid" : 2 }
However I have been having issues getting this to work
using mongodb_find_one, as I would of thought the following
route return the same;
if(mongodb_find_one("ml-mongodb", "kamailiosbc",
"dispatcher", "{ \"attrs\" : \"test.com\" },{ \"setid\":
\"1\", \"_id\": \"0\" }", "mgr1"))
However it returns all the entries relating to that attrs
columm from dispatcher table, instead of just setid.
Is it possible to do this? I am stuggling to find the json
format to acheive the same thing.
Also in terms of the mgr1 response, I see its contained
within the $mongodb(key), can I drill down to get
specific fields from it or would I need to use
transformations or jansson to do this?
Many thanks
Jon
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Oct 24-26, 2016 - http://www.asipto.com
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio - DMQ dns srv Question
Hello Daniel and Charles, Thank you for your feedback. Another doubt is when we use a FQDN that only resolves as A record, would be better DMQ send only a A query or is there any reason for always try SRV? Thank you for your great job. BR José Seabra 2016-09-22 8:33 GMT+01:00 Charles Chance : > Hello, > > I can take a look today. > > Cheers, > Charles > > On 22 Sep 2016 06:20, "Daniel-Constantin Mierla" > wrote: > >> Hello, >> >> I guess that the one who did the implementation of the srv query for dmq >> hasn't "allocated" any service name. I haven't looked at the sources, but I >> guess it should be a small patch to compose the srv dns string to be >> queried -- maybe that part can be made a mod param so each can choose its >> preferred service. >> >> Cheers, >> Daniel >> >> On 21/09/16 19:28, José Seabra wrote: >> >> Hello, >> I have a doubt related with DMQ dns behavior, I noticed that when >> kamailio starts, it tries to resolve DMQ name configured on parameter >> notification_address as the following sequence: >> >>1. SRV >>2. A >>3. >> >> >> Isn't supposed kamailio try first resolve the NAPTR DMQ name, and then >> SRV? >> I'm asking this because kamailio is trying resolve the SRV record without >> any transport protocol specified on query, as my dns server only accepts >> queries on the format "_Service._Proto.Name" the SRV will never be resolved. >> >> Thank you. >> BR >> -- >> José Seabra >> >> >> ___ >> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing >> listsr-us...@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >> >> >> -- >> Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - >> http://www.linkedin.com/in/miconda >> Kamailio Advanced Training, Berlin, Oct 24-26, 2016 - http://www.asipto.com >> >> >> ___ >> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list >> sr-users@lists.sip-router.org >> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >> >> > Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered > office: Faraday Wharf, Innovation Birmingham Campus, Holt Street, > Birmingham Science Park, Birmingham B7 4BB. > > ___ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users@lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > > -- Cumprimentos José Seabra ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Killing dialog using kamcmd
Hello;
i use a event route like below for radius request. there is a acc_request
for it. you can use it
event_route[tm:local-request]{
xlog("L_ALERT","Local-Request [$ci] ");
if(is_method("BYE")){
acc_rad_request("Timeout");
}
}
--
View this message in context:
http://sip-router.1086192.n5.nabble.com/Killing-dialog-using-kamcmd-tp151976p152029.html
Sent from the Users mailing list archive at Nabble.com.
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio - DMQ dns srv Question
Hey,
On 22 September 2016 at 12:18, José Seabra wrote:
> Hello Daniel and Charles,
> Thank you for your feedback.
> Another doubt is when we use a FQDN that only resolves as A record, would
> be better DMQ send only a A query or is there any reason for always try SRV?
>
>
As far as I recall (it's been a while since I did anything with this), the
default behaviour is to query A record only. There is a mod_param to enable
multi-record/SRV lookup:
modparam("dmq", "multi_notify", 1)
But the default is off.
Is this not the behaviour you are seeing?
Cheers,
Charles
> Thank you for your great job.
>
> BR
> José Seabra
>
> 2016-09-22 8:33 GMT+01:00 Charles Chance :
>
>> Hello,
>>
>> I can take a look today.
>>
>> Cheers,
>> Charles
>>
>> On 22 Sep 2016 06:20, "Daniel-Constantin Mierla"
>> wrote:
>>
>>> Hello,
>>>
>>> I guess that the one who did the implementation of the srv query for dmq
>>> hasn't "allocated" any service name. I haven't looked at the sources, but I
>>> guess it should be a small patch to compose the srv dns string to be
>>> queried -- maybe that part can be made a mod param so each can choose its
>>> preferred service.
>>>
>>> Cheers,
>>> Daniel
>>>
>>> On 21/09/16 19:28, José Seabra wrote:
>>>
>>> Hello,
>>> I have a doubt related with DMQ dns behavior, I noticed that when
>>> kamailio starts, it tries to resolve DMQ name configured on parameter
>>> notification_address as the following sequence:
>>>
>>>1. SRV
>>>2. A
>>>3.
>>>
>>>
>>> Isn't supposed kamailio try first resolve the NAPTR DMQ name, and then
>>> SRV?
>>> I'm asking this because kamailio is trying resolve the SRV record
>>> without any transport protocol specified on query, as my dns server only
>>> accepts queries on the format "_Service._Proto.Name" the SRV will never be
>>> resolved.
>>>
>>> Thank you.
>>> BR
>>> --
>>> José Seabra
>>>
>>>
>>> ___
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
>>> listsr-us...@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>
>>> --
>>> Daniel-Constantin Mierlahttp://twitter.com/#!/miconda -
>>> http://www.linkedin.com/in/miconda
>>> Kamailio Advanced Training, Berlin, Oct 24-26, 2016 - http://www.asipto.com
>>>
>>>
>>> ___
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>> sr-users@lists.sip-router.org
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>
>> Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered
>> office: Faraday Wharf, Innovation Birmingham Campus, Holt Street,
>> Birmingham Science Park, Birmingham B7 4BB.
>>
>> ___
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users@lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>
>
> --
> Cumprimentos
> José Seabra
>
> ___
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users@lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
--
Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered
office: Faraday Wharf, Innovation Birmingham Campus, Holt Street,
Birmingham Science Park, Birmingham B7 4BB.
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio - DMQ dns srv Question
Hi Charles
I have modparam("dmq", "multi_notify", 1) because my A record resolves more
than one Kamailio addresses, and if i understood well the documentation
says that we need set it to a value different of 0 to resolve all ip
addresses associated to the Name configured on DMQ.
I'm using DMQ with 4 kamailio instances, so i think that i need have it set
to a value different than 0, or i'm wrong?.
Documentation says:
Enables the ability to resolve multiple IPv4/IPv6 addresses for a single
notification address.
A value of zero resolves to the first IP address found. A non-zero value
resolves to all IP addresses associated with the host. This includes
addresses from DNS SRV records, A and records.
*Default value is “0”.*
Thank you
Cheers
José
2016-09-22 13:28 GMT+01:00 Charles Chance :
> Hey,
>
> On 22 September 2016 at 12:18, José Seabra wrote:
>
>> Hello Daniel and Charles,
>> Thank you for your feedback.
>> Another doubt is when we use a FQDN that only resolves as A record, would
>> be better DMQ send only a A query or is there any reason for always try SRV?
>>
>>
> As far as I recall (it's been a while since I did anything with this), the
> default behaviour is to query A record only. There is a mod_param to enable
> multi-record/SRV lookup:
>
> modparam("dmq", "multi_notify", 1)
>
> But the default is off.
>
> Is this not the behaviour you are seeing?
>
> Cheers,
> Charles
>
>
>
>
>> Thank you for your great job.
>>
>> BR
>> José Seabra
>>
>> 2016-09-22 8:33 GMT+01:00 Charles Chance :
>>
>>> Hello,
>>>
>>> I can take a look today.
>>>
>>> Cheers,
>>> Charles
>>>
>>> On 22 Sep 2016 06:20, "Daniel-Constantin Mierla"
>>> wrote:
>>>
Hello,
I guess that the one who did the implementation of the srv query for
dmq hasn't "allocated" any service name. I haven't looked at the sources,
but I guess it should be a small patch to compose the srv dns string to be
queried -- maybe that part can be made a mod param so each can choose its
preferred service.
Cheers,
Daniel
On 21/09/16 19:28, José Seabra wrote:
Hello,
I have a doubt related with DMQ dns behavior, I noticed that when
kamailio starts, it tries to resolve DMQ name configured on parameter
notification_address as the following sequence:
1. SRV
2. A
3.
Isn't supposed kamailio try first resolve the NAPTR DMQ name, and
then SRV?
I'm asking this because kamailio is trying resolve the SRV record
without any transport protocol specified on query, as my dns server only
accepts queries on the format "_Service._Proto.Name" the SRV will never be
resolved.
Thank you.
BR
--
José Seabra
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
listsr-us...@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierlahttp://twitter.com/#!/miconda -
http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Oct 24-26, 2016 - http://www.asipto.com
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>> Sipcentric Ltd. Company registered in England & Wales no. 7365592.
>>> Registered
>>> office: Faraday Wharf, Innovation Birmingham Campus, Holt Street,
>>> Birmingham Science Park, Birmingham B7 4BB.
>>>
>>> ___
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>> sr-users@lists.sip-router.org
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>
>>
>>
>> --
>> Cumprimentos
>> José Seabra
>>
>> ___
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users@lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>
>
>
> Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered
> office: Faraday Wharf, Innovation Birmingham Campus, Holt Street,
> Birmingham Science Park, Birmingham B7 4BB.
>
> ___
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users@lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
--
Cumprimentos
José Seabra
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio - DMQ dns srv Question
Hi José,
In your config, you need to tell DMQ about a minimum of one other node.
This can be in the form of an IP or FQDN - however, where the FQDN resolves
to a single IP, it does not make sense to perform anything other than an A
lookup, so you should set the parameter to 0 in this case.
The number of nodes in your cluster is irrelevant - once started, DMQ will
contact the one you have told it about and learn about the others
automatically.
Optionally, you can tell DMQ about multiple nodes upfront (to account for
instances where the first one may be down or unreachable), by giving it an
FQDN which resolves to multiple IP addresses - in which case you'll need to
set the multi_notify parameter to 1.
Does that help?
Cheers,
Charles
On 22 September 2016 at 13:36, José Seabra wrote:
> Hi Charles
> I have modparam("dmq", "multi_notify", 1) because my A record resolves
> more than one Kamailio addresses, and if i understood well the
> documentation says that we need set it to a value different of 0 to resolve
> all ip addresses associated to the Name configured on DMQ.
> I'm using DMQ with 4 kamailio instances, so i think that i need have it
> set to a value different than 0, or i'm wrong?.
>
> Documentation says:
>
> Enables the ability to resolve multiple IPv4/IPv6 addresses for a single
> notification address.
>
> A value of zero resolves to the first IP address found. A non-zero value
> resolves to all IP addresses associated with the host. This includes
> addresses from DNS SRV records, A and records.
>
> *Default value is “0”.*
>
> Thank you
> Cheers
> José
>
>
>
> 2016-09-22 13:28 GMT+01:00 Charles Chance :
>
>> Hey,
>>
>> On 22 September 2016 at 12:18, José Seabra wrote:
>>
>>> Hello Daniel and Charles,
>>> Thank you for your feedback.
>>> Another doubt is when we use a FQDN that only resolves as A record,
>>> would be better DMQ send only a A query or is there any reason for always
>>> try SRV?
>>>
>>>
>> As far as I recall (it's been a while since I did anything with this),
>> the default behaviour is to query A record only. There is a mod_param to
>> enable multi-record/SRV lookup:
>>
>> modparam("dmq", "multi_notify", 1)
>>
>> But the default is off.
>>
>> Is this not the behaviour you are seeing?
>>
>> Cheers,
>> Charles
>>
>>
>>
>>
>>> Thank you for your great job.
>>>
>>> BR
>>> José Seabra
>>>
>>> 2016-09-22 8:33 GMT+01:00 Charles Chance
>>> :
>>>
Hello,
I can take a look today.
Cheers,
Charles
On 22 Sep 2016 06:20, "Daniel-Constantin Mierla"
wrote:
> Hello,
>
> I guess that the one who did the implementation of the srv query for
> dmq hasn't "allocated" any service name. I haven't looked at the sources,
> but I guess it should be a small patch to compose the srv dns string to be
> queried -- maybe that part can be made a mod param so each can choose its
> preferred service.
>
> Cheers,
> Daniel
>
> On 21/09/16 19:28, José Seabra wrote:
>
> Hello,
> I have a doubt related with DMQ dns behavior, I noticed that when
> kamailio starts, it tries to resolve DMQ name configured on parameter
> notification_address as the following sequence:
>
>1. SRV
>2. A
>3.
>
>
> Isn't supposed kamailio try first resolve the NAPTR DMQ name, and
> then SRV?
> I'm asking this because kamailio is trying resolve the SRV record
> without any transport protocol specified on query, as my dns server only
> accepts queries on the format "_Service._Proto.Name" the SRV will never be
> resolved.
>
> Thank you.
> BR
> --
> José Seabra
>
>
> ___
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
> listsr-us...@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
> --
> Daniel-Constantin Mierlahttp://twitter.com/#!/miconda -
> http://www.linkedin.com/in/miconda
> Kamailio Advanced Training, Berlin, Oct 24-26, 2016 -
> http://www.asipto.com
>
>
> ___
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users@lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
Sipcentric Ltd. Company registered in England & Wales no. 7365592.
Registered
office: Faraday Wharf, Innovation Birmingham Campus, Holt Street,
Birmingham Science Park, Birmingham B7 4BB.
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>
>>> --
>>> Cumprimentos
>>> José Seabra
>>>
>>> ___
>>> SIP Express Router (SE
Re: [SR-Users] Addressing a distinct PSI result is: 555 AS Contacting Failed - iFC terminated dialog
Hi all, No further need to investigate. I found the bug. Thanks, Christoph From: sr-users [mailto:sr-users-boun...@lists.sip-router.org] On Behalf Of Valentin Christoph Sent: Tuesday, September 20, 2016 12:13 PM To: sr-users@lists.sip-router.org Cc: Onic Roman Subject: [SR-Users] Addressing a distinct PSI result is: 555 AS Contacting Failed - iFC terminated dialog Hi all, I'm trying to send a call to an AS via a kamailio S-CSCF (release 4.4.3). I'm addressing the AS by a distinct PSI: sip:04325432...@domain.net;user=gsmr. At the first try the S-CSCF sends a SAR to HSS and receives a successful SAA (tshark traces attached), but the S-CSCF rejects the call with 555 AS Contacting Failed - iFC terminated dialog. At the second try (a few seconds later), the S-CSCF doesn't exchange SAR/SAA with the HSS, and now the call is successfully forwarded to the AS. This problem is permanent, it is not the result of a temporary loss of connectivity between S-CSCF and AS. I checked the iFCs that I had configured at the HSS and I think, they are OK. I attached -tshark traces from the node, where the S-CSCF resides: 2016_09_19_error_555_17_scscf_filtered.pcap -WITH_DEBUG logs from kamailio: 2016_09_19_error_555_17_kamailio_1st_try.log -A tarball of /usr/local/etc/kamailio: 2016_09_19_error_555_17_kamailio.tar.gz Can anybody help? Is it a bug in kamailio or is the problem on my side? Thanks, Christoph The information contained in this e-mail message is privileged and confidential and is for the exclusive use of the addressee. The person who receives this message and who is not the addressee, one of his employees or an agent entitled to hand it over to the addressee, is informed that he may not use, disclose or reproduce the contents thereof, and is kindly asked to notify the sender and delete the e-mail immediately. The information contained in this e-mail message is privileged and confidential and is for the exclusive use of the addressee. The person who receives this message and who is not the addressee, one of his employees or an agent entitled to hand it over to the addressee, is informed that he may not use, disclose or reproduce the contents thereof, and is kindly asked to notify the sender and delete the e-mail immediately. ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio - DMQ dns srv Question
Hi charles,
Inline
Thanks
2016-09-22 13:51 GMT+01:00 Charles Chance :
> Hi José,
>
> In your config, you need to tell DMQ about a minimum of one other node.
> This can be in the form of an IP or FQDN - however, where the FQDN resolves
> to a single IP, it does not make sense to perform anything other than an A
> lookup, so you should set the parameter to 0 in this case.
>
> The number of nodes in your cluster is irrelevant - once started, DMQ will
> contact the one you have told it about and learn about the others
> automatically.
>
> Optionally, you can tell DMQ about multiple nodes upfront (to account for
> instances where the first one may be down or unreachable), by giving it an
> FQDN which resolves to multiple IP addresses - in which case you'll need to
> set the multi_notify parameter to 1.
>
> >> This is the reason that I'm using multi_notify, the doubt here was why
> it is querying dns using SRV without service specification.
>
>
>
Does that help?
>
> Cheers,
> Charles
>
>
> On 22 September 2016 at 13:36, José Seabra wrote:
>
>> Hi Charles
>> I have modparam("dmq", "multi_notify", 1) because my A record resolves
>> more than one Kamailio addresses, and if i understood well the
>> documentation says that we need set it to a value different of 0 to resolve
>> all ip addresses associated to the Name configured on DMQ.
>> I'm using DMQ with 4 kamailio instances, so i think that i need have it
>> set to a value different than 0, or i'm wrong?.
>>
>> Documentation says:
>>
>> Enables the ability to resolve multiple IPv4/IPv6 addresses for a single
>> notification address.
>>
>> A value of zero resolves to the first IP address found. A non-zero value
>> resolves to all IP addresses associated with the host. This includes
>> addresses from DNS SRV records, A and records.
>>
>> *Default value is “0”.*
>>
>> Thank you
>> Cheers
>> José
>>
>>
>>
>> 2016-09-22 13:28 GMT+01:00 Charles Chance
>> :
>>
>>> Hey,
>>>
>>> On 22 September 2016 at 12:18, José Seabra
>>> wrote:
>>>
Hello Daniel and Charles,
Thank you for your feedback.
Another doubt is when we use a FQDN that only resolves as A record,
would be better DMQ send only a A query or is there any reason for always
try SRV?
>>> As far as I recall (it's been a while since I did anything with this),
>>> the default behaviour is to query A record only. There is a mod_param to
>>> enable multi-record/SRV lookup:
>>>
>>> modparam("dmq", "multi_notify", 1)
>>>
>>> But the default is off.
>>>
>>> Is this not the behaviour you are seeing?
>>>
>>> Cheers,
>>> Charles
>>>
>>>
>>>
>>>
Thank you for your great job.
BR
José Seabra
2016-09-22 8:33 GMT+01:00 Charles Chance >>> >:
> Hello,
>
> I can take a look today.
>
> Cheers,
> Charles
>
> On 22 Sep 2016 06:20, "Daniel-Constantin Mierla"
> wrote:
>
>> Hello,
>>
>> I guess that the one who did the implementation of the srv query for
>> dmq hasn't "allocated" any service name. I haven't looked at the sources,
>> but I guess it should be a small patch to compose the srv dns string to
>> be
>> queried -- maybe that part can be made a mod param so each can choose its
>> preferred service.
>>
>> Cheers,
>> Daniel
>>
>> On 21/09/16 19:28, José Seabra wrote:
>>
>> Hello,
>> I have a doubt related with DMQ dns behavior, I noticed that when
>> kamailio starts, it tries to resolve DMQ name configured on parameter
>> notification_address as the following sequence:
>>
>>1. SRV
>>2. A
>>3.
>>
>>
>> Isn't supposed kamailio try first resolve the NAPTR DMQ name, and
>> then SRV?
>> I'm asking this because kamailio is trying resolve the SRV record
>> without any transport protocol specified on query, as my dns server only
>> accepts queries on the format "_Service._Proto.Name" the SRV will never
>> be
>> resolved.
>>
>> Thank you.
>> BR
>> --
>> José Seabra
>>
>>
>> ___
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
>> listsr-us...@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>> --
>> Daniel-Constantin Mierlahttp://twitter.com/#!/miconda -
>> http://www.linkedin.com/in/miconda
>> Kamailio Advanced Training, Berlin, Oct 24-26, 2016 -
>> http://www.asipto.com
>>
>>
>> ___
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
>> list
>> sr-users@lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
> Sipcentric Ltd. Company registered in England & Wales no. 7365592.
> Registered
> office: Faraday Wharf, Innovation Birmingham Campus, Holt Street,
> Bir
Re: [SR-Users] Addressing a distinct PSI result is: 555 AS Contacting Failed - iFC terminated dialog
Hi Valentin, where was it? Greeting from Hamburg, Carsten 2016-09-22 14:58 GMT+02:00 Valentin Christoph : > Hi all, > > > > No further need to investigate. > > > > I found the bug. > > > > Thanks, > > Christoph > > > > *From:* sr-users [mailto:sr-users-boun...@lists.sip-router.org] *On > Behalf Of *Valentin Christoph > *Sent:* Tuesday, September 20, 2016 12:13 PM > *To:* sr-users@lists.sip-router.org > *Cc:* Onic Roman > *Subject:* [SR-Users] Addressing a distinct PSI result is: 555 AS > Contacting Failed - iFC terminated dialog > > > > Hi all, > > > > I’m trying to send a call to an AS via a kamailio S-CSCF (release 4.4.3). > I’m addressing the AS by a distinct PSI: sip:04325432...@domain.net; > user=gsmr. > > > > At the first try the S-CSCF sends a SAR to HSS and receives a successful > SAA (tshark traces attached), but the S-CSCF rejects the call with 555 AS > Contacting Failed - iFC terminated dialog. > > > > At the second try (a few seconds later), the S-CSCF doesn’t exchange > SAR/SAA with the HSS, and now the call is successfully forwarded to the AS. > > > > This problem is permanent, it is not the result of a temporary loss of > connectivity between S-CSCF and AS. > > > > I checked the iFCs that I had configured at the HSS and I think, they are > OK. > > > > I attached > > -tshark traces from the node, where the S-CSCF resides: > 2016_09_19_error_555_17_scscf_filtered.pcap > > -WITH_DEBUG logs from kamailio: 2016_09_19_error_555_17_ > kamailio_1st_try.log > > -A tarball of /usr/local/etc/kamailio: 2016_09_19_error_555_17_ > kamailio.tar.gz > > > > Can anybody help? Is it a bug in kamailio or is the problem on my side? > > > > Thanks, > > Christoph > > > > > The information contained in this e-mail message is privileged and > confidential and is for the exclusive use of the addressee. The person who > receives this message and who is not the addressee, one of his employees or > an agent entitled to hand it over to the addressee, is informed that he may > not use, disclose or reproduce the contents thereof, and is kindly asked to > notify the sender and delete the e-mail immediately. > > > > The information contained in this e-mail message is privileged and > confidential and is for the exclusive use of the addressee. The person who > receives this message and who is not the addressee, one of his employees or > an agent entitled to hand it over to the addressee, is informed that he may > not use, disclose or reproduce the contents thereof, and is kindly asked to > notify the sender and delete the e-mail immediately. > > > ___ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users@lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > > -- Carsten Bock CEO (Geschäftsführer) ng-voice GmbH Millerntorplatz 1 20359 Hamburg / Germany http://www.ng-voice.com mailto:cars...@ng-voice.com Office +49 40 5247593-40 Fax +49 40 5247593-99 Sitz der Gesellschaft: Hamburg Registergericht: Amtsgericht Hamburg, HRB 120189 Geschäftsführer: Carsten Bock Ust-ID: DE279344284 Hier finden Sie unsere handelsrechtlichen Pflichtangaben: http://www.ng-voice.com/imprint/ ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio - DMQ dns srv Question
Hi, On 22 September 2016 at 14:08, José Seabra wrote: > Hi charles, > Inline > Thanks > > 2016-09-22 13:51 GMT+01:00 Charles Chance : > >> Hi José, >> >> In your config, you need to tell DMQ about a minimum of one other node. >> This can be in the form of an IP or FQDN - however, where the FQDN resolves >> to a single IP, it does not make sense to perform anything other than an A >> lookup, so you should set the parameter to 0 in this case. >> >> The number of nodes in your cluster is irrelevant - once started, DMQ >> will contact the one you have told it about and learn about the others >> automatically. >> >> Optionally, you can tell DMQ about multiple nodes upfront (to account for >> instances where the first one may be down or unreachable), by giving it an >> FQDN which resolves to multiple IP addresses - in which case you'll need to >> set the multi_notify parameter to 1. >> > > >> >> This is the reason that I'm using multi_notify, the doubt here was why >> it is querying dns using SRV without service specification. >> > > Understood, thanks - I misread the following... > Another doubt is when we use a FQDN that only resolves as A record, > would be better DMQ send only a A query or is there any reason for always > try SRV? > > ...to mean a scenario in which the FQDN resolves to a single IP only. My mistake! I'll take a look into adding service specification later today. Cheers, Charles -- Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered office: Faraday Wharf, Innovation Birmingham Campus, Holt Street, Birmingham Science Park, Birmingham B7 4BB. ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Addressing a distinct PSI result is: 555 AS Contacting Failed - iFC terminated dialog
Hi Carsten,
I had to update the file modules/tm/t_suspend.c (see attachment).
I did following change and hope I did not cause any side effects:
/* which route block type were we in when we were suspended */
cb_type = FAILURE_CB_TYPE;
switch (t->async_backup.backup_route) {
case REQUEST_ROUTE:
cb_type = REQUEST_CB_TYPE;
break;
case FAILURE_ROUTE:
cb_type = FAILURE_CB_TYPE;
break;
case TM_ONREPLY_ROUTE:
cb_type = ONREPLY_CB_TYPE;
break;
case BRANCH_ROUTE:
cb_type = BRANCH_CB_TYPE;
break;
}
Currently I have a local copy of latest 4.4 branch. I’m far away from bringing
changes back to github (need to learn a lot more, before actively cooperating).
Kind regards,
Christoph
From: sr-users [mailto:sr-users-boun...@lists.sip-router.org] On Behalf Of
Carsten Bock
Sent: Thursday, September 22, 2016 3:22 PM
To: Kamailio (SER) - Users Mailing List
Cc: Onic Roman
Subject: Re: [SR-Users] Addressing a distinct PSI result is: 555 AS Contacting
Failed - iFC terminated dialog
Hi Valentin,
where was it?
Greeting from Hamburg,
Carsten
2016-09-22 14:58 GMT+02:00 Valentin Christoph
mailto:christoph.valen...@kapsch.net>>:
Hi all,
No further need to investigate.
I found the bug.
Thanks,
Christoph
From: sr-users
[mailto:sr-users-boun...@lists.sip-router.org]
On Behalf Of Valentin Christoph
Sent: Tuesday, September 20, 2016 12:13 PM
To: sr-users@lists.sip-router.org
Cc: Onic Roman
Subject: [SR-Users] Addressing a distinct PSI result is: 555 AS Contacting
Failed - iFC terminated dialog
Hi all,
I’m trying to send a call to an AS via a kamailio S-CSCF (release 4.4.3). I’m
addressing the AS by a distinct PSI: sip:04325432...@domain.net;user=gsmr.
At the first try the S-CSCF sends a SAR to HSS and receives a successful SAA
(tshark traces attached), but the S-CSCF rejects the call with 555 AS
Contacting Failed - iFC terminated dialog.
At the second try (a few seconds later), the S-CSCF doesn’t exchange SAR/SAA
with the HSS, and now the call is successfully forwarded to the AS.
This problem is permanent, it is not the result of a temporary loss of
connectivity between S-CSCF and AS.
I checked the iFCs that I had configured at the HSS and I think, they are OK.
I attached
-tshark traces from the node, where the S-CSCF resides:
2016_09_19_error_555_17_scscf_filtered.pcap
-WITH_DEBUG logs from kamailio:
2016_09_19_error_555_17_kamailio_1st_try.log
-A tarball of /usr/local/etc/kamailio:
2016_09_19_error_555_17_kamailio.tar.gz
Can anybody help? Is it a bug in kamailio or is the problem on my side?
Thanks,
Christoph
The information contained in this e-mail message is privileged and confidential
and is for the exclusive use of the addressee. The person who receives this
message and who is not the addressee, one of his employees or an agent entitled
to hand it over to the addressee, is informed that he may not use, disclose or
reproduce the contents thereof, and is kindly asked to notify the sender and
delete the e-mail immediately.
The information contained in this e-mail message is privileged and confidential
and is for the exclusive use of the addressee. The person who receives this
message and who is not the addressee, one of his employees or an agent entitled
to hand it over to the addressee, is informed that he may not use, disclose or
reproduce the contents thereof, and is kindly asked to notify the sender and
delete the e-mail immediately.
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Carsten Bock
CEO (Geschäftsführer)
ng-voice GmbH
Millerntorplatz 1
20359 Hamburg / Germany
http://www.ng-voice.com
mailto:cars...@ng-voice.com
Office +49 40 5247593-40
Fax +49 40 5247593-99
Sitz der Gesellschaft: Hamburg
Registergericht: Amtsgericht Hamburg, HRB 120189
Geschäftsführer: Carsten Bock
Ust-ID: DE279344284
Hier finden Sie unsere handelsrechtlichen Pflichtangaben:
http://www.ng-voice.com/imprint/
The information contained in this e-mail message is privileged and confidential
and is for the exclusive use of the addressee. The person who receives this
message and who is not the addressee, one of his employees or an agen
[SR-Users] Selective rport behaviour
Hi, In some scenarios, it happens that a request is received with the following characteristics: IP xxx.xxx.xxx.xxx:14000 -> server:5060 Via: SIP/2.0/xxx.xxx.xxx.xxx:5060;branch=9hG4bKblah;rport Normally, we just force_rport() on all incoming requests so that we reply to the real source port of the request, since most endpoints on this installation are NAT'd. However, occasionally we run into a scenario where an ALG or misconfigured client incorrectly inserts an rport attribute into its topmost Via, and really expects to receive a response at the address/port indicated in the Via (i.e. 5060). Does Kamailio offer a means of dealing with these on a selective basis? Would refraining from calling force_rport() be enough? Or would it be necessary to set reply_to_via=1 as well, thus breaking symmetrical behaviour for the vast majority of the NAT'd endpoints? In other words, I'm not 100% clear on the following: 1) What impact does force_rport() have if an 'rport' attribute is sent by the client? In this case, there should be nothing to "force"; I assume that if the 'rport' attribute is placed by the client, then the proxy will return replies to the source port of the request even if force_rport() is not called, because that's the RFC 3581-compatible thing to do. Right? 2) Does reply_to_via=1 override the behaviour hypothesised in #1? 3) Does reply_to_via=1 override force_rport()? Thanks! -- Alex -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 (direct) / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Kamailio - DMQ dns srv Question
Thank you Charles, Cheers José Seabra 2016-09-22 14:19 GMT+01:00 Charles Chance : > Hi, > > On 22 September 2016 at 14:08, José Seabra wrote: > >> Hi charles, >> Inline >> Thanks >> >> 2016-09-22 13:51 GMT+01:00 Charles Chance >> : >> >>> Hi José, >>> >>> In your config, you need to tell DMQ about a minimum of one other node. >>> This can be in the form of an IP or FQDN - however, where the FQDN resolves >>> to a single IP, it does not make sense to perform anything other than an A >>> lookup, so you should set the parameter to 0 in this case. >>> >>> The number of nodes in your cluster is irrelevant - once started, DMQ >>> will contact the one you have told it about and learn about the others >>> automatically. >>> >>> Optionally, you can tell DMQ about multiple nodes upfront (to account >>> for instances where the first one may be down or unreachable), by giving it >>> an FQDN which resolves to multiple IP addresses - in which case you'll need >>> to set the multi_notify parameter to 1. >>> >> >> >>> >> This is the reason that I'm using multi_notify, the doubt here was >>> why it is querying dns using SRV without service specification. >>> >> >> > > Understood, thanks - I misread the following... > > >> Another doubt is when we use a FQDN that only resolves as A record, >> would be better DMQ send only a A query or is there any reason for always >> try SRV? >> >> > ...to mean a scenario in which the FQDN resolves to a single IP only. My > mistake! > > I'll take a look into adding service specification later today. > > Cheers, > Charles > > > Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered > office: Faraday Wharf, Innovation Birmingham Campus, Holt Street, > Birmingham Science Park, Birmingham B7 4BB. > > ___ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users@lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > > -- Cumprimentos José Seabra ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Selective rport behaviour
On Thu, Sep 22, 2016 at 09:58:33AM -0400, Alex Balashov wrote: > Normally, we just force_rport() on all incoming requests so that we reply to > the real source port of the request, since most endpoints on this > installation are NAT'd. > > However, occasionally we run into a scenario where an ALG or misconfigured > client incorrectly inserts an rport attribute into its topmost Via, and > really expects to receive a response at the address/port indicated in the > Via (i.e. 5060). You can never trust "client" headers/devices IMHO. And I never had problems with force_rport, so logically force_rport overrides anything the "client" sends. > Does Kamailio offer a means of dealing with these on a selective basis? > Would refraining from calling force_rport() be enough? Or would it be > necessary to set reply_to_via=1 as well, thus breaking symmetrical behaviour > for the vast majority of the NAT'd endpoints? > > In other words, I'm not 100% clear on the following: > > 1) What impact does force_rport() have if an 'rport' attribute is sent by > the client? > > In this case, there should be nothing to "force"; I assume that if the > 'rport' attribute is placed by the client, then the proxy will return > replies to the source port of the request even if force_rport() is not > called, because that's the RFC 3581-compatible thing to do. Right? force_rport sets the flag FL_FORCE_RPORT, and the helpful comments say the following: * - if the original via contains rport / rport=something or msg->msg_flags * FL_FORCE_RPORT is set (e.g. script force_rport() cmd) rport=src_port * is added (over previous rport / as first via param or after received * if no received was present and received is added too) and /* check if rport needs to be updated: * - if FL_FORCE_RPORT is set add it (and del. any previous version) * - if via already contains an rport add it and overwrite the previous * rport value if present (if you don't want to overwrite the previous * version remove the comments) */ > 2) Does reply_to_via=1 override the behaviour hypothesised in #1? > 3) Does reply_to_via=1 override force_rport()? force_rport seems to override any rport available in via, so reply_to_via has no additional effects. ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Killing dialog using kamcmd
Hello,
I'm not sure if it is a bug of 4.3 branch..
need to test it on 4.4.. it should write down the record on DB automatically
Laura
Il 22/09/16 14:20, ycaner ha scritto:
> Hello;
> i use a event route like below for radius request. there is a acc_request
> for it. you can use it
>
> event_route[tm:local-request]{
>
> xlog("L_ALERT","Local-Request [$ci] ");
>
> if(is_method("BYE")){
> acc_rad_request("Timeout");
> }
> }
>
>
>
>
> --
> View this message in context:
> http://sip-router.1086192.n5.nabble.com/Killing-dialog-using-kamcmd-tp151976p152029.html
> Sent from the Users mailing list archive at Nabble.com.
>
> ___
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users@lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Selective rport behaviour
On 09/22/2016 10:55 AM, Daniel Tryba wrote: force_rport seems to override any rport available in via, so reply_to_via has no additional effects. Thanks, that was helpful. But so, if force_rport() is not used, do I need reply_to_via=1 in order to have replies go back to the declared port in the Via rather than the received source port (as would be mandated by the presence of client-injected rport)? As for trusting client headers, I strongly agree. Unfortunately, sometimes business requirements collide with our philosophies. -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 (direct) / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] failed to find command http_async_query - Even though module loaded
Hi guys, I am using the http_async_client module to POST some requests to a Web Interface, and on server 1 it all works well. I have done a fresh install from github, version 4.4 on Centos 6.8 on server 2, and kamailio wont start. Its the same configuration file, however it states; failed to find command http_async_query (params 3) However the module is loaded, and when installing no errors were written when creating the module, and in terms of its links they are below and look ok to me. Is there anywhere else I should be looking? Thanks Jon ldd http_async_client.solinux-vdso.so.1 => (0x7ffecedf1000) libcurl.so.4 => /usr/lib64/libcurl.so.4 (0x7fdc5bd63000) libevent-2.0.so.5 => /usr/lib64/libevent-2.0.so.5 (0x7fdc5bb1c000) libsrutils.so.1 => /usr/local/kamailio-4.4/lib64/kamailio/libsrutils.so.1 (0x7fdc5b90c000)libkcore.so.1 => /usr/local/kamailio-4.4/lib64/kamailio/libkcore.so.1 (0x7fdc5b6ff000) libc.so.6 => /lib64/libc.so.6 (0x7fdc5b36a000)libidn.so.11 => /lib64/libidn.so.11 (0x7fdc5b138000)libldap-2.4.so.2 => /lib64/libldap-2.4.so.2 (0x7fdc5aee7000)librt.so.1 => /lib64/librt.so.1 (0x7fdc5acde000)libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x7fdc5aa9a000)libkrb5.so.3 => /lib64/libkrb5.so.3 (0x7fdc5a7b3000)libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x7fdc5a586000)libcom_err.so.2 => /lib64/libcom_err.so.2 (0x7fdc5a382000)libz.so.1 => /lib64/libz.so.1 (0x7fdc5a16c000)libssl3.so => /usr/lib64/libssl3.so (0x7fdc59f28000)libsmime3.so => /usr/lib64/libsmime3.so (0x7fdc59cfb000)libnss3.so => /usr/lib64/libnss3.so (0x7fdc599bb000)libnssutil3.so => /usr/lib64/libnssutil3.so (0x7fdc5978e000)libplds4.so => /lib64/libplds4.so (0x7fdc5958a000)libplc4.so => /lib64/libplc4.so (0x7fdc59385000)libnspr4.so => /lib64/libnspr4.so (0x7fdc59146000)libpthread.so.0 => /lib64/libpthread.so.0 (0x7fdc58f29000)libdl.so.2 => /lib64/libdl.so.2 (0x7fdc58d25000)libssh2.so.1 => /usr/lib64/libssh2.so.1 (0x7fdc58afc000)libm.so.6 => /lib64/libm.so.6 (0x7fdc58878000) /lib64/ld-linux-x86-64.so.2 (0x7fdc5c1f8000)liblber-2.4.so.2 => /lib64/liblber-2.4.so.2 (0x7fdc58668000)libresolv.so.2 => /lib64/libresolv.so.2 (0x7fdc5844e000)libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x7fdc58234000)libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x7fdc58028000)libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x7fdc57e25000)libssl.so.10 => /usr/lib64/libssl.so.10 (0x7fdc57bb8000)libcrypto.so.10 => /usr/lib64/libcrypto.so.10 (0x7fdc577d4000)libcrypt.so.1 => /lib64/libcrypt.so.1 (0x7fdc5759d000)libselinux.so.1 => /lib64/libselinux.so.1 (0x7fdc5737d000)libfreebl3.so => /lib64/libfreebl3.so (0x7fdc5717a000) ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] failed to find command http_async_query - Even though module loaded
Hi, are you sure that on server 2 you are running 4.4 branch? The three params version of the query has been removed in master in this commit https://github.com/kamailio/kamailio/commit/61adc6e16c73070bd3f8a9a04efa18263793a270 . Setting the query's body is now done through the $http_req pseudovariable, for uniformity of the interface. What does kamailio -v show on that server? Cheers, Federico On Thu, Sep 22, 2016 at 11:34 PM, Jonathan Hunter wrote: > Hi guys, > > I am using the http_async_client module to POST some requests to a Web > Interface, and on server 1 it all works well. > > I have done a fresh install from github, version 4.4 on Centos 6.8 on > server 2, and kamailio wont start. > > Its the same configuration file, however it states; > > failed to find command http_async_query (params 3) > > However the module is loaded, and when installing no errors were written > when creating the module, and in terms of its links they are below and look > ok to me. > > Is there anywhere else I should be looking? > > Thanks > > Jon > > > > > ldd http_async_client.so > linux-vdso.so.1 => (0x7ffecedf1000) > libcurl.so.4 => /usr/lib64/libcurl.so.4 (0x7fdc5bd63000) > libevent-2.0.so.5 => /usr/lib64/libevent-2.0.so.5 > (0x7fdc5bb1c000) > libsrutils.so.1 => > /usr/local/kamailio-4.4/lib64/kamailio/libsrutils.so.1 > (0x7fdc5b90c000) > libkcore.so.1 => /usr/local/kamailio-4.4/lib64/kamailio/libkcore.so.1 > (0x7fdc5b6ff000) > libc.so.6 => /lib64/libc.so.6 (0x7fdc5b36a000) > libidn.so.11 => /lib64/libidn.so.11 (0x7fdc5b138000) > libldap-2.4.so.2 => /lib64/libldap-2.4.so.2 (0x7fdc5aee7000) > librt.so.1 => /lib64/librt.so.1 (0x7fdc5acde000) > libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 > (0x7fdc5aa9a000) > libkrb5.so.3 => /lib64/libkrb5.so.3 (0x7fdc5a7b3000) > libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x7fdc5a586000) > libcom_err.so.2 => /lib64/libcom_err.so.2 (0x7fdc5a382000) > libz.so.1 => /lib64/libz.so.1 (0x7fdc5a16c000) > libssl3.so => /usr/lib64/libssl3.so (0x7fdc59f28000) > libsmime3.so => /usr/lib64/libsmime3.so (0x7fdc59cfb000) > libnss3.so => /usr/lib64/libnss3.so (0x7fdc599bb000) > libnssutil3.so => /usr/lib64/libnssutil3.so (0x7fdc5978e000) > libplds4.so => /lib64/libplds4.so (0x7fdc5958a000) > libplc4.so => /lib64/libplc4.so (0x7fdc59385000) > libnspr4.so => /lib64/libnspr4.so (0x7fdc59146000) > libpthread.so.0 => /lib64/libpthread.so.0 (0x7fdc58f29000) > libdl.so.2 => /lib64/libdl.so.2 (0x7fdc58d25000) > libssh2.so.1 => /usr/lib64/libssh2.so.1 (0x7fdc58afc000) > libm.so.6 => /lib64/libm.so.6 (0x7fdc58878000) > /lib64/ld-linux-x86-64.so.2 (0x7fdc5c1f8000) > liblber-2.4.so.2 => /lib64/liblber-2.4.so.2 (0x7fdc58668000) > libresolv.so.2 => /lib64/libresolv.so.2 (0x7fdc5844e000) > libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x7fdc58234000) > libkrb5support.so.0 => /lib64/libkrb5support.so.0 > (0x7fdc58028000) > libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x7fdc57e25000) > libssl.so.10 => /usr/lib64/libssl.so.10 (0x7fdc57bb8000) > libcrypto.so.10 => /usr/lib64/libcrypto.so.10 (0x7fdc577d4000) > libcrypt.so.1 => /lib64/libcrypt.so.1 (0x7fdc5759d000) > libselinux.so.1 => /lib64/libselinux.so.1 (0x7fdc5737d000) > libfreebl3.so => /lib64/libfreebl3.so (0x7fdc5717a000) > > ___ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users@lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > > ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Selective rport behaviour
Hi Alex,
I had the same problem as you and I couldn't find a way to selectively
reply to via.
What I ended up doing is the following dirty trick...
Before a transaction is created for the processed message I do:
if (SOME CONDITION) {
remove_hf_value("Via[-1].rport");
msg_apply_changes();
}
For sure it would be better to be able to selectively set the reply_to_via
behavior.
Hope this helps.
Cheers,
Federico
On Thu, Sep 22, 2016 at 6:11 PM, Alex Balashov
wrote:
> On 09/22/2016 10:55 AM, Daniel Tryba wrote:
>
> force_rport seems to override any rport available in via, so reply_to_via
>> has no additional effects.
>>
>
> Thanks, that was helpful. But so, if force_rport() is not used, do I need
> reply_to_via=1 in order to have replies go back to the declared port in the
> Via rather than the received source port (as would be mandated by the
> presence of client-injected rport)?
>
> As for trusting client headers, I strongly agree. Unfortunately, sometimes
> business requirements collide with our philosophies.
>
> --
> Alex Balashov | Principal | Evariste Systems LLC
>
> Tel: +1-706-510-6800 (direct) / +1-800-250-5920 (toll-free)
> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
>
> ___
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users@lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
