Re: [SR-Users] Branching GIT repository for 5.2.x release series

2018-11-02 Thread Iman Mohammadi
Very good Dear Daniel but The sooner the better.thank you very much for
support

Best Regards
Iman Mohammadi

On Fri, Nov 2, 2018, 15:05 Daniel-Constantin Mierla  Hello,
>
> if there is no other opinion, I am considering to create git branch 5.2
> at the beginning of next week (likely on Monday evening), to be used for
> 5.2.x release series.
>
> From that moment, the master branch can get new features and the
> appropriate bug fixes have to be backported to branch 5.2 as well.
>
> With this step, the first release in 5.2.x series, respectively v5.2.0,
> should be out in about 2-3 weeks.
>
> Cheers,
> Daniel
>
> --
> Daniel-Constantin Mierla -- www.asipto.com
> www.twitter.com/miconda -- www.linkedin.com/in/miconda
> Kamailio World Conference -- www.kamailioworld.com
> Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com
>
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] Crash ims_diameter_server

2018-11-02 Thread Iman Mohammadi
That's Great,Thank you very much Dear Carsten

Best Regards
Iman Mohammadi

On Fri, Nov 2, 2018, 10:31 Carsten Bock  Hi,
>
> my colleague implemented a fix for this some months ago, but we haven't
> pushed it upstream. I will talk to him to fix this in the official Repo
> also.
>
> Thanks,
> Carsten
> --
>
> 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/
>
>
> Am Do., 1. Nov. 2018 um 06:55 Uhr schrieb Iman Mohammadi <
> iman.mohammadi.tele...@gmail.com>:
>
>> Hi
>> I tried it before,it must be list for our purpose,int or string doesnt
>> meet our purpose
>>
>> thanks
>>
>> On Thu, Nov 1, 2018 at 9:00 AM Mojtaba  wrote:
>>
>>> Hi.
>>> There are some reason for this issue.
>>> The three nested json is not reason for crash ims_diameter.
>>> Let try this senario.
>>> Chenge type of the last indoor level of json from List to other
>>> type(like int or ...).
>>> Then check the lamailio is crashed or not?
>>> With Regards.Mojtaba
>>>
>>>
>>> On Wed, 31 Oct 2018 21:56 Iman Mohammadi, <
>>> iman.mohammadi.tele...@gmail.com> wrote:
>>>
 When the below format is sent from rest , kamailio crashes

 List[{
 List[{
 List[{
  ]}
  ]}
  ]}
 (Json with 3 nested lists),
 With 2 lists it works properly,
 When diameter is translated to json with 3 lists by this module it also
 works properly,
 Json format is correct too.

 gdb:

 gdb) bt full
 #0  0x7f5e23c4a11e in diameterserver_add_avp (m=0x0, d=0x7f5e1b5c2240 
 "", len=12, avp_code=431, flags=64, vendorid=0, data_do=2,
 func=0x7f5e23c51d6c <__FUNCTION__.20148> "parselist") at 
 avp_helper.c:208
 avp = 0x7f5e1b5c3bd0
 __FUNCTION__ = "diameterserver_add_avp"
 #1  0x7f5e23c4d0c8 in parselist (response=0x0, list=0x7fff9f21a8d0, 
 item=0x11b67d0, level=2) at avp_helper.c:309
 i = 1
 flags = 64
 x = "p\250!\237"
 avp_list = {head = 0x0, tail = 0x0}
 avp_list_s = {s = 0x7f5e1b5c2240 "", len = 12}
 __FUNCTION__ = "parselist"
 #2  0x7f5e23c4cffc in parselist (response=0x7f5e1b5c3ab8, list=0x0, 
 item=0x11b6550, level=1) at avp_helper.c:304
 subitem = 0x11b67d0
 i = 0
 flags = 64
 x = "\000\000\000"
 avp_list = {head = 0x0, tail = 0x0}
 avp_list_s = {s = 0x7fff9f21a8f0 "@\251!\237\377\177", len = 
 600070897}
 __FUNCTION__ = "parselist"
 #3  0x7f5e23c4db3a in addAVPsfromJSON (response=0x7f5e1b5c3ab8, 
 json=0x7f5e23e53950 ) at avp_helper.c:349
 subitem = 0x11b6550
 i = 4
 __FUNCTION__ = "addAVPsfromJSON"
 root = 0x11b4210
 #4  0x7f5e23c3fbdb in callback_cdp_request (request_in=0x7f5e1b5c19b0, 
 param=0x0) at ims_diameter_server.c:193
 fmsg = 0xab7840 <_faked_msg>
 backup_rt = 1
 ctx = {rec_lev = 0, run_flags = 0, last_retcode = 1, jmp_env = 
 {{__jmpbuf = {1, -5713032302318786866, 7971288, 7971288,
 140042162528420, 0, -5713032302339758386, 
 5712822384154044110}, __mask_was_saved = 0, __saved_mask = {__val = {
   140735863172072, 127, 0, 140042162532340, 
 140042389578761, 4222451713, 140042162532340, 140042162532340, 
 140042162532340,
   140042162532340, 140042162532358, 140042162532467, 
 140042162532340, 140042162532467, 0, 0}
 response = 0x7f5e1b5c3ab8
 __FUNCTION__ = "callback_cdp_request"
 #5  0x7f5e24a705c0 in api_callback (p=0x7f5e1b598f50, 
 msg=0x7f5e1b5c19b0, ptr=0x0) at api_process.c:83
 t = 0x7f5e1b598f50
 auto_drop = 32767
 h = 0x7f5e1b5b3358
 ---Type  to continue, or q  to quit---
 x = {type = (unknown: 2669784000), handler = {requestHandler = 
 0x7f5e23c3eed1 ,
 responseHandler = 0x7f5e23c3eed1 }, 
 param = 0x3ee9f21ac10, next = 0x7f5e1b5988b8, prev = 0x19f210069}
 type = REQUEST_HANDLER
 rsp = 0x7f5e1b5c19b0
 __FUNCTION__ = "api_callback"
 #6  0x7f5e24a857d7 in worker_process (id=5) at worker.c:346
 t = {p = 0x7f5e1b598f50, msg = 0x7f5e1b5c19b0}
 cb = 0x7f5e1b59df30
 r = 128
 __FUNCTION__ = "worker_process"
 #7  0x7f5e24a62a8e in diameter_peer_start (blocking=0) at 
 diameter_peer.c:242
 pid = 0
 k = 5
 

[SR-Users] Branching GIT repository for 5.2.x release series

2018-11-02 Thread Daniel-Constantin Mierla
Hello,

if there is no other opinion, I am considering to create git branch 5.2
at the beginning of next week (likely on Monday evening), to be used for
5.2.x release series.

From that moment, the master branch can get new features and the
appropriate bug fixes have to be backported to branch 5.2 as well.

With this step, the first release in 5.2.x series, respectively v5.2.0,
should be out in about 2-3 weeks.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference -- www.kamailioworld.com
Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] Store TLS handshake date from Kamailio to an external DB

2018-11-02 Thread Toffi Bossol
Hello ,
Thanks for you answer.
I re-formulate my questions:
   
   - How can I tell Kamailio to store the TLS Data in an external DB?
   - How can I configure Kamailio to read (without re-use) data from DB and 
verify if there was a TLS session established before?
Many Thanks in advance.

Best regards,
Toffi 

Am Donnerstag, 1. November 2018, 12:10:57 MEZ hat Daniel Tryba 
 Folgendes geschrieben:  
 
 On Thu, Nov 01, 2018 at 09:20:46AM +, Toffi Bossol wrote:
> my use case will be:
>    
>    - We use two Kamailio instances (A and B)  
> 
>    - A Client registers to a Kamailio A using TLS (SIP over TLS). The TLS 
>session data shall be stored into an external DB.
>    - Kamailio A is now unreachable.
>    - The client sends a register to Kamailio B over TLS.
>    - Kamailio B shall look into the external DB and checks that there is 
>already a TLS session data and can reuse it.  

In order to make a SIP over TLS handshake, there has to be a new
handshake. So the old data is stale and unusable.


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
  ___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] Diversion headers access and message too long error

2018-11-02 Thread Joan Salvatella
Thanks for your help Henning. The error was on Asterisk, now everything is
working like a charm.

On Thu, Nov 1, 2018 at 11:29 AM Henning Westerholt  wrote:

> Am Donnerstag, 1. November 2018, 11:18:37 CET schrieb Joan Salvatella:
> > Thanks for your quick response. Kamailio is complaining about a too long
> > SIP message so migrating to TCP makes sense (I hadn't thought about it).
> >
> > I have enabled TCP in kamailio.cfg:
> > disable_tcp=no
> >
> > I am using the dispatchers module to identify the gateway endpoints and I
> > have updated it accordingly:
> >
> > 1 sip:10.0.1.69:5080;transport=tcp
> >
> > and in my invite resolver I am forcing the sending socket to be tcp as
> > well.
> > [..]
> >$fs = "tcp:PRIVATE_IP:5080";
> > [..]
> > Are there any resources that I can check to make sure that I am not
> missing
> > anything? Since this is not working, I am suspecting it is related with
> the
> > Asterisk side of things but that should be handled in another mail list.
> > > [..]
>
> Hello Joan,
>
> on a first sight it looks fine. Do you get an error from the asterisk
> side?
> Then indeed it would be good to ask on the asterisk user list about that.
>
> If you get also errors in the Kamailio log, we would need more details
> about
> this to continue here.
>
> Best regards,
>
> Henning
>
> --
> Henning Westerholt - https://skalatan.de/blog/
> Kamailio services - https://skalatan.de/services
> Kamailio security assessment - https://skalatan.de/de/assessment
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] Diversion headers access and message too long error

2018-11-02 Thread Joan Salvatella
Hello Henning,

Thanks for your quick response. Kamailio is complaining about a too long
SIP message so migrating to TCP makes sense (I hadn't thought about it).

I have enabled TCP in kamailio.cfg:
disable_tcp=no

I am using the dispatchers module to identify the gateway endpoints and I
have updated it accordingly:

1 sip:10.0.1.69:5080;transport=tcp

and in my invite resolver I am forcing the sending socket to be tcp as
well.

route[INVITE_RESOLVER] {
xlog("L_DBG", "[R-INVITE-RESOLVER:$ci] Entering INVITE resolver\n");

   route(CHECK_DID);

   # Use main asterisk dispatcher set
   $var(disp_set) = 1;

   # Store diversion reason
   redis_cmd("abn", "SET $fd-div $dir", "r");

   # Trim SIP messages of useless headers
   remove_hf_re("^X-");

   $fs = "tcp:PRIVATE_IP:5080";

   xlog("L_INFO", "[R-INVITE-RESOLVER:$ci] Processing dispatcher set
$var(disp_set)\n");

   if(!ds_select_domain("$var(disp_set)", "4")) {
  # This should only happen if the route set is empty.
  sl_send_reply("503", "Out of Gateways");
  xlog("L_ERR", "[R-INVITE-RESOLVER:$ci] !> "
   "No gateways available!\n");
  exit;
   }

   xlog("L_INFO", "[R-INVITE-RESOLVER:$ci] -> "
 "Selected gateway: $rd:$rp\n");

   t_on_failure("DISPATCHER_ROLLOVER");
   route(INVITE_POSTROUTE);
}

Are there any resources that I can check to make sure that I am not missing
anything? Since this is not working, I am suspecting it is related with the
Asterisk side of things but that should be handled in another mail list.

Thanks for your support,


On Tue, Oct 30, 2018 at 9:29 PM Henning Westerholt  wrote:

> Am Montag, 29. Oktober 2018, 17:27:27 CET schrieb Joan Salvatella:
> > [..]
> >- *Message Too Long Error:* Since Twilio uses long URIs to define its
> >resources, the SIP messages being handled by Kamailio are sometimes
> too
> > big and generate a "Message Too Long error". I have been able to
> > temporarily patch this removing unused headers using remove_hf_re and
> > remove_hf but it still fails from time to time. Is there a way to split
> the
> > UDP packet to mitigate this issue? or what other options could be
> > considered?
>
> Hello Joan,
>
> I don't understand the error description completely. Does Kamailio
> complain
> about a to long header field or a too long SIP message?
>
> About the question regarding the options - have you thought about using
> TCP?
>
> Best regards, Henning
>
> --
> Henning Westerholt - https://skalatan.de/blog/
> Kamailio security assessment - https://skalatan.de/de/assessment
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users


[SR-Users] Fwd: Fw: kamailio5.0.0 support presence

2018-11-02 Thread chaos wu
Hi Kamailio expert,

i want to use kamailio to simulate presence server, after receive
subscribe, i need kamailio reply 200 OK, and then  send out Notify, but
now, it just forward the subscribe, don't reply, could you help check my
cfg? thanks in advance.

BRs


kamailio.cfg
Description: Binary data
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] Installing rtpengine from RPM on CentOS

2018-11-02 Thread Alexey Vasilyev
Hello.
Rtpengine has spec file here
https://github.com/sipwise/rtpengine/tree/master/el/rtpengine.spec

It is perfectly builds with this spec on Centos 7.
In spec file I added variable
%global with_transcoding 1
If you don't need transcoding change it to 0. So you don't need any special
dependencies to build it.
If you need transcoding, leave it 1. Then you'll need to find or to build
some ffmpeg libs.
-- 
Best regards
Alexey Vasilyev

чт, 1 нояб. 2018 г. в 15:01, Pan Christensen :

> That’s the kamailio module to control rtpengine, not the rtpengine itself.
>
>
>
>
>
> *Pan B. Christensen *
> Developer
>
> Phonect AS
>
> Mail: pan.christen...@phonect.no
> + 47 41 88 88 00
>
>  [image: mail_footer]
>
>
>
> *From:* sr-users  * On Behalf Of *Sergey
> Safarov
> *Sent:* torsdag 1. november 2018 13:37
> *To:* Kamailio (SER) - Users Mailing List 
> *Subject:* Re: [SR-Users] Installing rtpengine from RPM on CentOS
>
>
>
> This is packaged in main kamailio rpm package
>
> https://github.com/kamailio/kamailio/blob/master/pkg/kamailio/obs/kamailio.spec#L1453-L1454
>
>
>
> чт, 1 нояб. 2018 г. в 14:33, Pan Christensen :
>
> Hello!
>
>
>
> According to
> https://github.com/sipwise/rtpengine/blob/master/el/README.el.md , we
> should be able to install rtpengine from a CentOS repository using yum.
> We’re unable to find the packages. Any suggestions?
>
>
>
>
>
> *Pan B. Christensen *
> Developer
>
> Phonect AS
>
> Mail: pan.christen...@phonect.no
> + 47 41 88 88 00
>
>  [image: mail_footer]
>
>
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] Crash ims_diameter_server

2018-11-02 Thread Carsten Bock
Hi,

my colleague implemented a fix for this some months ago, but we haven't
pushed it upstream. I will talk to him to fix this in the official Repo
also.

Thanks,
Carsten
--

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/


Am Do., 1. Nov. 2018 um 06:55 Uhr schrieb Iman Mohammadi <
iman.mohammadi.tele...@gmail.com>:

> Hi
> I tried it before,it must be list for our purpose,int or string doesnt
> meet our purpose
>
> thanks
>
> On Thu, Nov 1, 2018 at 9:00 AM Mojtaba  wrote:
>
>> Hi.
>> There are some reason for this issue.
>> The three nested json is not reason for crash ims_diameter.
>> Let try this senario.
>> Chenge type of the last indoor level of json from List to other type(like
>> int or ...).
>> Then check the lamailio is crashed or not?
>> With Regards.Mojtaba
>>
>>
>> On Wed, 31 Oct 2018 21:56 Iman Mohammadi, <
>> iman.mohammadi.tele...@gmail.com> wrote:
>>
>>> When the below format is sent from rest , kamailio crashes
>>>
>>> List[{
>>> List[{
>>> List[{
>>>  ]}
>>>  ]}
>>>  ]}
>>> (Json with 3 nested lists),
>>> With 2 lists it works properly,
>>> When diameter is translated to json with 3 lists by this module it also
>>> works properly,
>>> Json format is correct too.
>>>
>>> gdb:
>>>
>>> gdb) bt full
>>> #0  0x7f5e23c4a11e in diameterserver_add_avp (m=0x0, d=0x7f5e1b5c2240 
>>> "", len=12, avp_code=431, flags=64, vendorid=0, data_do=2,
>>> func=0x7f5e23c51d6c <__FUNCTION__.20148> "parselist") at 
>>> avp_helper.c:208
>>> avp = 0x7f5e1b5c3bd0
>>> __FUNCTION__ = "diameterserver_add_avp"
>>> #1  0x7f5e23c4d0c8 in parselist (response=0x0, list=0x7fff9f21a8d0, 
>>> item=0x11b67d0, level=2) at avp_helper.c:309
>>> i = 1
>>> flags = 64
>>> x = "p\250!\237"
>>> avp_list = {head = 0x0, tail = 0x0}
>>> avp_list_s = {s = 0x7f5e1b5c2240 "", len = 12}
>>> __FUNCTION__ = "parselist"
>>> #2  0x7f5e23c4cffc in parselist (response=0x7f5e1b5c3ab8, list=0x0, 
>>> item=0x11b6550, level=1) at avp_helper.c:304
>>> subitem = 0x11b67d0
>>> i = 0
>>> flags = 64
>>> x = "\000\000\000"
>>> avp_list = {head = 0x0, tail = 0x0}
>>> avp_list_s = {s = 0x7fff9f21a8f0 "@\251!\237\377\177", len = 
>>> 600070897}
>>> __FUNCTION__ = "parselist"
>>> #3  0x7f5e23c4db3a in addAVPsfromJSON (response=0x7f5e1b5c3ab8, 
>>> json=0x7f5e23e53950 ) at avp_helper.c:349
>>> subitem = 0x11b6550
>>> i = 4
>>> __FUNCTION__ = "addAVPsfromJSON"
>>> root = 0x11b4210
>>> #4  0x7f5e23c3fbdb in callback_cdp_request (request_in=0x7f5e1b5c19b0, 
>>> param=0x0) at ims_diameter_server.c:193
>>> fmsg = 0xab7840 <_faked_msg>
>>> backup_rt = 1
>>> ctx = {rec_lev = 0, run_flags = 0, last_retcode = 1, jmp_env = 
>>> {{__jmpbuf = {1, -5713032302318786866, 7971288, 7971288,
>>> 140042162528420, 0, -5713032302339758386, 
>>> 5712822384154044110}, __mask_was_saved = 0, __saved_mask = {__val = {
>>>   140735863172072, 127, 0, 140042162532340, 
>>> 140042389578761, 4222451713, 140042162532340, 140042162532340, 
>>> 140042162532340,
>>>   140042162532340, 140042162532358, 140042162532467, 
>>> 140042162532340, 140042162532467, 0, 0}
>>> response = 0x7f5e1b5c3ab8
>>> __FUNCTION__ = "callback_cdp_request"
>>> #5  0x7f5e24a705c0 in api_callback (p=0x7f5e1b598f50, 
>>> msg=0x7f5e1b5c19b0, ptr=0x0) at api_process.c:83
>>> t = 0x7f5e1b598f50
>>> auto_drop = 32767
>>> h = 0x7f5e1b5b3358
>>> ---Type  to continue, or q  to quit---
>>> x = {type = (unknown: 2669784000), handler = {requestHandler = 
>>> 0x7f5e23c3eed1 ,
>>> responseHandler = 0x7f5e23c3eed1 }, param 
>>> = 0x3ee9f21ac10, next = 0x7f5e1b5988b8, prev = 0x19f210069}
>>> type = REQUEST_HANDLER
>>> rsp = 0x7f5e1b5c19b0
>>> __FUNCTION__ = "api_callback"
>>> #6  0x7f5e24a857d7 in worker_process (id=5) at worker.c:346
>>> t = {p = 0x7f5e1b598f50, msg = 0x7f5e1b5c19b0}
>>> cb = 0x7f5e1b59df30
>>> r = 128
>>> __FUNCTION__ = "worker_process"
>>> #7  0x7f5e24a62a8e in diameter_peer_start (blocking=0) at 
>>> diameter_peer.c:242
>>> pid = 0
>>> k = 5
>>> p = 0x36
>>> __FUNCTION__ = "diameter_peer_start"
>>> #8  0x7f5e24a559bc in cdp_child_init (rank=0) at cdp_mod.c:243
>>> __FUNCTION__ = "cdp_child_init"
>>> #9  0x00547e54 in init_mod_child (m=0x7f5e28656fb8, rank=0) at 
>>> core/sr_module.c:943
>>>

Re: [SR-Users] Parse Header error when send Register to P-CSCF using ims-pcscf

2018-11-02 Thread Mojtaba
Hello,
Would you paste the register flow SIP message in wireshark or tcpdump?
And Please paste the XML senario that you used to generate SIP
message.
Thank With Regards.Mojtaba
On Sun, Oct 28, 2018 at 10:20 PM Hưng Nguyễn Tiến
 wrote:
>
> Hi, i'm newbie in kamailio,
> I tried installed ims kamailio from ng-repository packages,
>
> Then when I tried to send register to SIP server using SIPp,
> I received this log
>  [Proxy-CSCF][28505]: ERROR:  [core/parser/msg_parser.c:331]: 
> parse_headers(): bad header field [(null)]
> [Proxy-CSCF][28500]: ERROR:  [core/parser/msg_parser.c:331]: 
> parse_headers(): bad header field [(null)]
>  [Proxy-CSCF][28496]: WARNING:  [core/receive.c:192]: receive_msg(): 
> parsing relevant headers failed
>  [Proxy-CSCF][28505]: message repeated 2 times: [ WARNING:  
> [core/receive.c:192]: receive_msg(): parsing relevant headers failed]
>  [Proxy-CSCF][28492]: ERROR:  [core/parser/msg_parser.c:675]: 
> parse_msg(): ERROR: parse_msg: 
> message=<#002#020#002#021#023�#023���z'��z'#006��[%�#007>
>
> Thank you
> --
> Nguyễn Tiến Hưng
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users



-- 
--Mojtaba Esfandiari.S

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] Installing rtpengine from RPM on CentOS

2018-11-02 Thread Mojtaba
Hello,
The installation of rtpengine is straightforward, But the installation
of dependencies may be different.
Please check this post:
https://lists.kamailio.org/pipermail/sr-users/2018-July/102114.html
I have write this for Debian.
With regards. Mojtaba
On Fri, Nov 2, 2018 at 12:27 AM Henning Westerholt  wrote:
>
> Am Donnerstag, 1. November 2018, 15:00:18 CET schrieb Pan Christensen:
> > That’s the kamailio module to control rtpengine, not the rtpengine itself.
> > [..]
>
> Hello Pan,
>
> in case you did not get an answer on this list I would suggest to contact the
> rtpengine authors directly.
>
> The page https://github.com/sipwise/rtpengine/blob/master/el/README.el.md
> indeed does not contain any informations about a Cent.OS repository.
>
> There was a discussion a few month ago (about manual installation on Cent.OS):
> https://lists.kamailio.org/pipermail/sr-users/2018-June/101952.html
>
> Installing from source or building your own RPMs is described as well on the
> docs quoted above, as you probably already read.
>
> Best regards,
>
> Henning
>
> --
> Henning Westerholt - https://skalatan.de/blog/
> Kamailio services - https://skalatan.de/services
> Kamailio security assessment - https://skalatan.de/de/assessment
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users



-- 
--Mojtaba Esfandiari.S

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users