[SR-Users] rtjson + uac + event - OK, ACK and BYE display name not updated

2016-12-06 Thread Diego Nadares
Hi Guys,

We are modifying "from" and "to" headers with rtjson module via a json
struct. It works fine in INVITE, TRYING, RINGING and OK but not in the
following messages. Kamailio It's changing ONLY "from" and "to" URI BUT NOT
the DISPLAY NAME. I think it's the tm module but I can't figure out how to
confirm this. Maybe I need to configure something else in my cfg or could
it be a bug?

My json struct that is handled by rtjson module

  response.routing = "serial";
//response.routing = "parallel";
response.routes = [];
response.routes[0] = {};
response.routes[0].uri = "sip:11@172.16.213.31:5060";
response.routes[0].headers = { // Headers to be modified
"from": {
"display": "11",
"uri": "sip:1@172.16.213.38"
},
"to": {
"display": "22",
"uri": "sip:22@172.16.213.38"
},
};
response.routes[0].headers.extra = {};//"X-Hdr-A: abc\r\nX-Hdr-B:
bcd\r\n";

This is part of my cfg


modparam("dialog","dlg_flag", FLD_START)
modparam("uac","restore_mode","auto")
modparam("uac", "restore_dlg", 1)


# account only INVITEs
if (is_method("INVITE") && !has_totag()) {
setflag(FLT_ACC); # do accounting
   * setflag(FLD_START); # do accounting*
setflag(FLT_ACCMISSED);
setflag(FLT_ACCFAILED);
}
.


>From source/Aleg:
*From: sipp http://sip:sipp@172.16.213.21:5060>>;tag=1.*
*To: sut http://sip:55@172.16.213.38:5060>>.*

To dest/Bleg:
*From: 11 >;tag=1.*
*To: 22 >.*

Incorrect display name in BYE and ACK:
*From: sipp >;tag=1.*
*To: sut >;tag=2.*


interface: any
filter: ( port 5060 ) and (ip or ip6)
#
U 2016/12/06 15:52:13.638731 172.16.213.21:5060 -> 172.16.213.38:5060
INVITE sip:55@172.16.213.38:5060 SIP/2.0.
Via: SIP/2.0/UDP 172.16.213.21:5060;branch=z9hG4bK-12775-1-0.
*From: sipp http://sip:sipp@172.16.213.21:5060>>;tag=1.*
*To: sut http://sip:55@172.16.213.38:5060>>.*
Call-ID: 1-12775@172.16.213.21.
CSeq: 1 INVITE.
Contact: "SIPP" .
Max-Forwards: 70.
Subject: Performance Test.
Content-Type: multipart/mixed;boundary=uniqueBoundary.
Remote-Party-ID: :5060;party=calling;id-type=subscriber;privacy=off;screen=no>.
Content-Length:   549.
.
--uniqueBoundary.
Content-Type: application/sdp.
.
v=0.
o=user1 53655765 2353687637 IN IP4 172.16.213.21.
s=-.
c=IN IP4 172.16.213.21.
t=0 0.
m=audio 6000 RTP/AVP 8.
a=rtpmap:8 PCMA/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-11,16.
.
--uniqueBoundary.
Content-Type: application/gtd.
Content-Disposition: signal;handling=optional.
.
IAM,.
CGN,04,y,1,y,4,1143617400.
CIC,000573.
CPC,09.
CPN,02,y,1,52381660.
FCI,n,n,n,n,y,n,n,u.
GCI,f7140cc78a611601838a002128d7e512.
NOC,0,n,1,n.
PRN,q761*,AR*,oper2,1993.
TMR,02.
.
--uniqueBoundary--.

#
U 2016/12/06 15:52:13.734159 172.16.213.38:5060 -> 172.16.213.21:5060
SIP/2.0 100 trying -- your call is important to us.
Via: SIP/2.0/UDP 172.16.213.21:5060;branch=z9hG4bK-12775-1-0.
*From: sipp http://sip:sipp@172.16.213.21:5060>>;tag=1.*
*To: sut http://sip:55@172.16.213.38:5060>>.*
Call-ID: 1-12775@172.16.213.21.
CSeq: 1 INVITE.
Server: kamailio (4.4.4 (x86_64/linux)).
Content-Length: 0.
.

#
U 2016/12/06 15:52:13.878600 172.16.213.38:5060 -> 172.16.213.31:5060
INVITE sip:11@172.16.213.31:5060 SIP/2.0.
Via: SIP/2.0/UDP
172.16.213.38;branch=z9hG4bKabaa.840cc83114975a34a37b7af020d37b65.1.
*From: 11 >;tag=1.*
*To: 22 >.*
Call-ID: 1-12775@172.16.213.21.
CSeq: 1 INVITE.
Max-Forwards: 69.
Subject: Performance Test.
Content-Type: multipart/mixed;boundary=uniqueBoundary.
Content-Length:   788.
Contact: .
.
--uniqueBoundary.
Content-Type: application/sdp.
.
v=0.
o=user1 53655765 2353687637 IN IP4 172.16.213.38.
s=-.
c=IN IP4 172.16.213.38.
t=0 0.
m=audio 40236 RTP/AVP 8.
a=rtpmap:8 PCMA/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-11,16.
a=sendrecv.
a=rtcp:40237.
a=ice-ufrag:QNCzXhUr.
a=ice-pwd:Ci90BRpdZH51Hx5BaPgGMrGCeh.
a=candidate:P1djl8LFNb5kexbG 1 UDP 2130706431 172.16.213.38 40236 typ host.
a=candidate:P1djl8LFNb5kexbG 2 UDP 2130706430 172.16.213.38 40237 typ host.
.
--uniqueBoundary.
Content-Type: application/gtd.
Content-Disposition: signal;handling=optional.
.
IAM,.
CGN,04,y,1,y,4,1143617400.
CIC,000573.
CPC,09.
CPN,02,y,1,52381660.
FCI,n,n,n,n,y,n,n,u.
GCI,f7140cc78a611601838a002128d7e512.
NOC,0,n,1,n.
PRN,q761*,AR*,oper2,1993.
TMR,02.
.
--uniqueBoundary--.

#
U 2016/12/06 15:52:13.879441 172.16.213.31:5060 -> 172.16.213.38:5060
SIP/2.0 180 Ringing.
Via: SIP/2.0/UDP
172.16.213.38;branch=z9hG4bKabaa.840cc83114975a34a37b7af020d37b65.1.
*From: 11 >;tag=1.*
*To: 22 >;tag=2.*
Call-ID: 1-12775@172.16.213.21.
CSeq: 1 INVITE.
Contact: .
Content-Type: application/

Re: [SR-Users] rtjson + uac + event - OK, ACK and BYE display name not updated

2016-12-07 Thread Diego Nadares
Hi Daniel, thanks for your reply.

I think uac it's configured with dialog module allready for storing those
values. In fact, it's changing display and uri partially. These are my uac
and dlg params:

modparam("dialog","dlg_flag", FLD_START)
modparam("uac","restore_mode","auto") modparam("uac", "restore_dlg", 1)
<--- to safe values

The dialog flag is set in request route:

request_route { .
# account only INVITEs if (is_method("INVITE") && !has_totag()) {
setflag(FLT_ACC); # do accounting setflag(FLD_START); # do accounting
setflag(FLT_ACCMISSED); setflag(FLT_ACCFAILED); }
Am I missing something in my cfg? Maybe I need to put something else
related to dialogs?

In the sip trace I see that it's doing fine with uris in all messages but
the problem is only with the display names in "ack" and "bye". Even when
"bye" comes from b leg it left display names unchanged.

What should I log to see more info? Any hint where to look in the code?

Thanks!

Diego






El El mié, 7 de dic. de 2016 a las 06:52, Daniel-Constantin Mierla <
mico...@gmail.com> escribió:

> Hello,
>
> the replacement of From and To is done via the uac module -- inside it is
> the code for doing these operations. rtjson doesn't have much to do with
> subsequent operations.
>
> But iirc, the module does the update only for URIs, being the required
> values not to be changed from RFC point of view.
>
> You can try with uac configured to use dialog for storing From/To values
> instead of relying on record route parameters -- I haven't tried myself.
> Cheers,
> Daniel
>
>
> On 06/12/2016 19:24, Diego Nadares wrote:
>
> Hi Guys,
>
> We are modifying "from" and "to" headers with rtjson module via a json
> struct. It works fine in INVITE, TRYING, RINGING and OK but not in the
> following messages. Kamailio It's changing ONLY "from" and "to" URI BUT NOT
> the DISPLAY NAME. I think it's the tm module but I can't figure out how to
> confirm this. Maybe I need to configure something else in my cfg or could
> it be a bug?
>
> My json struct that is handled by rtjson module
>
>   response.routing = "serial";
> //response.routing = "parallel";
> response.routes = [];
> response.routes[0] = {};
> response.routes[0].uri = "sip:11@172.16.213.31:5060";
> response.routes[0].headers = { // Headers to be modified
> "from": {
> "display": "11 <011%20->",
> "uri": "sip:1@172.16.213.38"
> },
> "to": {
> "display": "22",
> "uri": "sip:22@172.16.213.38"
> },
> };
> response.routes[0].headers.extra = {};//"X-Hdr-A: abc\r\nX-Hdr-B:
> bcd\r\n";
>
> This is part of my cfg
>
> 
> modparam("dialog","dlg_flag", FLD_START)
> modparam("uac","restore_mode","auto")
> modparam("uac", "restore_dlg", 1)
> 
>
> # account only INVITEs
> if (is_method("INVITE") && !has_totag()) {
> setflag(FLT_ACC); # do accounting
>* setflag(FLD_START); # do accounting*
> setflag(FLT_ACCMISSED);
> setflag(FLT_ACCFAILED);
> }
> .
>
>
> From source/Aleg:
> *From: sipp  <http://sip:sipp@172.16.213.21:5060>>;tag=1.*
> *To: sut  <http://sip:55@172.16.213.38:5060>>.*
>
> To dest/Bleg:
> *From: 11 <011%20->  >;tag=1.*
> *To: 22  >.*
>
> Incorrect display name in BYE and ACK:
> *From: sipp  >;tag=1.*
> *To: sut  >;tag=2.*
>
>
> interface: any
> filter: ( port 5060 ) and (ip or ip6)
> #
> U 2016/12/06 15:52:13.638731 172.16.213.21:5060 -> 172.16.213.38:5060
> INVITE sip:55@172.16.213.38:5060 SIP/2.0.
> Via: SIP/2.0/UDP 172.16.213.21:5060;branch=z9hG4bK-12775-1-0.
> *From: sipp  <http://sip:sipp@172.16.213.21:5060>>;tag=1.*
> *To: sut  <http://sip:55@172.16.213.38:5060>>.*
> Call-ID: 1-12775@172.16.213.21.
> CSeq: 1 INVITE.
> Contact: "SIPP" .
> Max-Forwards: 70.
> Subject: Performance Test.
> Content-Type: multipart/mixed;boundary=uniqueBoundary.
> Remote-Party-ID: :5060;party=calling;id-type=
> subscriber;privacy=off;scree

Re: [SR-Users] rtjson + uac + event - OK, ACK and BYE display name not updated

2016-12-07 Thread Diego Nadares
Hi Daniel, thanks again. I modified the code and now it's working as I
need. Do you think this could be useful for anybody else? If so I can
show/send you the code to verify it's ok and then ask for a pull request.

Thanks again!

Diego
___
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] sipp dead calls

2016-12-14 Thread Diego Nadares
Hi guys,

We are testing kamailio with sipp. We are running it with 20cps and some
calls do the following. When Kamailio is processing the 'ringing' a '200ok'
arrives in the middle. First, kamailio forwards the 200 ok and then the
ringing. 'ACK' arrives and, I suppose, the call is established. The thing
is than when the 'BYE' arrives kamailio responds with a 404.

This is the summary of the call

Id Time Source Destination Protocol Len Info

6483 2016-12-14 11:26:06.264697 SIPP-A KAMAILIO SIP/SDP 692 Request: INVITE
sip:@172.16.213.38:5060 |

6484 2016-12-14 11:26:06.264937 KAMAILIO SIPP-A SIP 367 Status: 100 trying
-- your call is important to us |
6485 2016-12-14 11:26:06.266327 KAMAILIO SIPP-B SIP/SDP 1179 Request:
INVITE sip:@172.16.213.31:5060 |
*6486 2016-12-14 11:26:06.267217 SIPP-B KAMAILIO SIP 566 Status: 180
Ringing | *
6487 2016-12-14 11:26:06.267268 SIPP-B KAMAILIO SIP/SDP 733 Status: 200 OK
|
6488 2016-12-14 11:26:06.267758 KAMAILIO  SIPP-A SIP/SDP 788 Status: 200 OK
|
*6489 2016-12-14 11:26:06.267833 *KAMAILIO SIPP-A* SIP 442 Status: 180
Ringing | *
6490 2016-12-14 11:26:06.268868 SIPP-A KAMAILIO SIP 493 Request: ACK
sip:127.0.0.8;line=sr-N6IAzBFwMJZfWJZLM.M7MlF-W.y6Mx14NEt7Nw05NhPQKjaP |
6491 2016-12-14 11:26:06.269162 KAMAILIO SIPP-B SIP 609 Request: ACK
sip:172.16.213.31:5060;transport=UDP |
6492 2016-12-14 11:26:06.269614 SIPP-A KAMAILIO SIP 404 Request: BYE
sip:@172.16.213.38:5060 |
6493 2016-12-14 11:26:06.269782 KAMAILIO SIPP-A SIP 348 Status: *404 Not
here* |

We are using modules rtjson, evapi, uac, topoh, rtpproxy for all calls. My
debug level is -1. With higher levels this behavior increase.

Kamailio is running in a virtual machine with centos7 with 8 cores and 8gb
of ram.

Do you need any further information? I can send you a pcap or ngrep file.

Best regards,

Diego.
___
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] sipp dead calls

2016-12-14 Thread Diego Nadares
Hi Mack,

The only thing I added to the basic scenarios is rrs="true"

In UAS


In UAC


I use the same scenario with the same fields for every call. In a test of
6000 calls I see ~5  dead calls.

Diego


2016-12-14 17:28 GMT-03:00 Mack Hendricks :

> Hey Diego,
>
> This smells like a sipP scenario file issue.  Did you customize the the
> scenario file being used by sipP B?
>
> -Mack
>
> On Dec 14, 2016, at 3:23 PM, Diego Nadares  wrote:
>
> Hi guys,
>
> We are testing kamailio with sipp. We are running it with 20cps and some
> calls do the following. When Kamailio is processing the 'ringing' a '200ok'
> arrives in the middle. First, kamailio forwards the 200 ok and then the
> ringing. 'ACK' arrives and, I suppose, the call is established. The thing
> is than when the 'BYE' arrives kamailio responds with a 404.
>
> This is the summary of the call
>
> Id Time Source Destination Protocol Len Info
>
> 6483 2016-12-14 11:26:06.264697 SIPP-A KAMAILIO SIP/SDP 692 Request:
> INVITE sip:@172.16.213.38:5060 |
>
> 6484 2016-12-14 11:26:06.264937 KAMAILIO SIPP-A SIP 367 Status: 100
> trying -- your call is important to us |
> 6485 2016-12-14 11:26:06.266327 KAMAILIO SIPP-B SIP/SDP 1179 Request:
> INVITE sip:@172.16.213.31:5060 |
> *6486 2016-12-14 11:26:06.267217 SIPP-B KAMAILIO SIP 566 Status: 180
> Ringing | *
> 6487 2016-12-14 11:26:06.267268 SIPP-B KAMAILIO SIP/SDP 733 Status: 200
> OK |
> 6488 2016-12-14 11:26:06.267758 KAMAILIO  SIPP-A SIP/SDP 788 Status: 200
> OK |
> *6489 2016-12-14 11:26:06.267833 *KAMAILIO SIPP-A* SIP 442 Status: 180
> Ringing | *
> 6490 2016-12-14 11:26:06.268868 SIPP-A KAMAILIO SIP 493 Request: ACK
> sip:127.0.0.8;line=sr-N6IAzBFwMJZfWJZLM.M7MlF-W.y6Mx14NEt7Nw05NhPQKjaP |
> 6491 2016-12-14 11:26:06.269162 KAMAILIO SIPP-B SIP 609 Request: ACK
> sip:172.16.213.31:5060;transport=UDP |
> 6492 2016-12-14 11:26:06.269614 SIPP-A KAMAILIO SIP 404 Request: BYE
> sip:@172.16.213.38:5060 |
> 6493 2016-12-14 11:26:06.269782 KAMAILIO SIPP-A SIP 348 Status: *404 Not
> here* |
>
> We are using modules rtjson, evapi, uac, topoh, rtpproxy for all calls. My
> debug level is -1. With higher levels this behavior increase.
>
> Kamailio is running in a virtual machine with centos7 with 8 cores and 8gb
> of ram.
>
> Do you need any further information? I can send you a pcap or ngrep file.
>
> Best regards,
>
> Diego.
> ___
> 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
>
>
___
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] ACK not routed to destination

2016-12-15 Thread Diego Nadares
Hi Wim,

Check this:

Dec 15 15:12:02 DNS-enum-8Gb-3 kamailio[6864]: 1(6883) DEBUG: tm
[t_lookup.c:485]: matching_3261(): DEBUG: *RFC3261 transaction matching
failed*

Maybe is related rrs. Add it to your sipp scenarios.

 
  
  
  


Diego

2016-12-15 11:13 GMT-03:00 Wim Van Cauwenbergh :

> Hi, I have setup kamailio with the dispatcher module and have a problem
> with the ACK in response to 200OK not being forwarded by kamailio:
>
> Scenario is very simple:
> sipp(.219) --> kamailio (.220) --> sipp(.239)
>
> SIP trace:
>
> root@DNS-enum-8Gb-3:/var/log# ngrep -W byline -d eth0 port 5060
> interface: eth0 (10.57.26.0/255.255.255.0)
> filter: (ip or ip6) and ( port 5060 )
> #
> U 10.57.26.219:5060 -> 10.57.26.220:5060
> INVITE sip:service@10.57.26.220:5060 SIP/2.0.
> Via: SIP/2.0/UDP 10.57.26.219:5060;branch=z9hG4bK-15698-1-0.
> From: sipp ;tag=15698SIPpTag021.
> To: sut .
> Call-ID: 1-15698@10.57.26.219.
> CSeq: 1 INVITE.
> Contact: sip:sipp@10.57.26.219:5060.
> Max-Forwards: 70.
> Subject: Performance Test.
> Content-Type: application/sdp.
> Content-Length:   135.
> .
> v=0.
> o=user1 53655765 2353687637 <02353%2068-7637> IN IP4 10.57.26.219.
> s=-.
> c=IN IP4 10.57.26.219.
> t=0 0.
> m=audio 6000 RTP/AVP 0.
> a=rtpmap:0 PCMU/8000.
>
> #
> U 10.57.26.220:5060 -> 10.57.26.219:5060
> SIP/2.0 100 trying -- your call is important to us.
> Via: SIP/2.0/UDP 10.57.26.219:5060;branch=z9hG4bK-15698-1-0.
> From: sipp ;tag=15698SIPpTag021.
> To: sut .
> Call-ID: 1-15698@10.57.26.219.
> CSeq: 1 INVITE.
> Server: kamailio (4.2.0 (x86_64/linux)).
> Content-Length: 0.
> .
>
> #
> U 10.57.26.220:5060 -> 10.57.26.239:5060
> INVITE sip:service@10.57.26.220:5060 SIP/2.0.
> Record-Route: .
> Via: SIP/2.0/UDP 10.57.26.220;branch=z9hG4bKf92d.
> 33550a94aa52aef3978cb507902d8aaa.0.
> Via: SIP/2.0/UDP 10.57.26.219:5060;branch=z9hG4bK-15698-1-0.
> From: sipp ;tag=15698SIPpTag021.
> To: sut .
> Call-ID: 1-15698@10.57.26.219.
> CSeq: 1 INVITE.
> Contact: sip:sipp@10.57.26.219:5060.
> Max-Forwards: 69.
> Subject: Performance Test.
> Content-Type: application/sdp.
> Content-Length:   135.
> .
> v=0.
> o=user1 53655765 2353687637 <02353%2068-7637> IN IP4 10.57.26.219.
> s=-.
> c=IN IP4 10.57.26.219.
> t=0 0.
> m=audio 6000 RTP/AVP 0.
> a=rtpmap:0 PCMU/8000.
>
> #
> U 10.57.26.239:5060 -> 10.57.26.220:5060
> SIP/2.0 180 Ringing.
> Via: SIP/2.0/UDP 10.57.26.220;branch=z9hG4bKf92d.
> 33550a94aa52aef3978cb507902d8aaa.0, SIP/2.0/UDP 10.57.26.219:5060;branch=
> z9hG4bK-15698-1-0.
> From: sipp ;tag=15698SIPpTag021.
> To: sut ;tag=14783SIPpTag018.
> Call-ID: 1-15698@10.57.26.219.
> CSeq: 1 INVITE.
> Contact: .
> Content-Length: 0.
> .
>
> #
> U 10.57.26.239:5060 -> 10.57.26.220:5060
> SIP/2.0 200 OK.
> Via: SIP/2.0/UDP 10.57.26.220;branch=z9hG4bKf92d.
> 33550a94aa52aef3978cb507902d8aaa.0, SIP/2.0/UDP 10.57.26.219:5060;branch=
> z9hG4bK-15698-1-0.
> From: sipp ;tag=15698SIPpTag021.
> To: sut ;tag=14783SIPpTag018.
> Call-ID: 1-15698@10.57.26.219.
> CSeq: 1 INVITE.
> Contact: .
> Content-Type: application/sdp.
> Content-Length:   135.
> .
> v=0.
> o=user1 53655765 2353687637 <02353%2068-7637> IN IP4 10.57.26.239.
> s=-.
> c=IN IP4 10.57.26.239.
> t=0 0.
> m=audio 6000 RTP/AVP 0.
> a=rtpmap:0 PCMU/8000.
>
> #
> U 10.57.26.220:5060 -> 10.57.26.219:5060
> SIP/2.0 180 Ringing.
> Via: SIP/2.0/UDP 10.57.26.219:5060;branch=z9hG4bK-15698-1-0.
> From: sipp ;tag=15698SIPpTag021.
> To: sut ;tag=14783SIPpTag018.
> Call-ID: 1-15698@10.57.26.219.
> CSeq: 1 INVITE.
> Contact: .
> Content-Length: 0.
> .
>
> #
> U 10.57.26.220:5060 -> 10.57.26.219:5060
> SIP/2.0 200 OK.
> Via: SIP/2.0/UDP 10.57.26.219:5060;branch=z9hG4bK-15698-1-0.
> From: sipp ;tag=15698SIPpTag021.
> To: sut ;tag=14783SIPpTag018.
> Call-ID: 1-15698@10.57.26.219.
> CSeq: 1 INVITE.
> Contact: .
> Content-Type: application/sdp.
> Content-Length:   135.
> .
> v=0.
> o=user1 53655765 2353687637 <02353%2068-7637> IN IP4 10.57.26.239.
> s=-.
> c=IN IP4 10.57.26.239.
> t=0 0.
> m=audio 6000 RTP/AVP 0.
> a=rtpmap:0 PCMU/8000.
>
> #
> U 10.57.26.219:5060 -> 10.57.26.220:5060
> ACK sip:10.57.26.239:5060;transport=UDP SIP/2.0.
> Via: SIP/2.0/UDP 10.57.26.219:5060;branch=z9hG4bK-15698-1-5.
> From: sipp ;tag=15698SIPpTag021.
> To: sut ;tag=14783SIPpTag018.
> Call-ID: 1-15698@10.57.26.219.
> CSeq: 1 ACK.
> Contact: sip:sipp@10.57.26.219:5060.
> Max-Forwards: 70.
> Subject: Performance Test.
> XContactinOK: .
> Content-Length: 0.
> .
>
> #
> U 10.57.26.239:5060 -> 10.57.26.220:5060
> SIP/2.0 200 OK.
> Via: SIP/2.0/UDP 10.57.26.220;branch=z9hG4bKf92d.
> 33550a94aa52aef3978cb507902d8aaa.0, SIP/2.0/UDP 10.57.26.219:5060;branch=
> z9hG4bK-15698-1-0.
> From: sipp ;tag=15698SIPpTag021.
> To: sut ;tag=14783SIPpTag018.
> Call-ID: 1-15698@10.57.26.219.
> CSeq: 1 INVITE.
> Contact: .
> Content-Type: application/sdp.
> Content-Length:   135.
> .
> v=0.
> o=user1 53655765 2353687637 <02353%2068-7637> IN IP4 10.57.26.239.
> s=-.
> c=IN IP4 10.57.26.239.
> t=0 0.
> m=audio 6000 RTP/AVP 0.
> a=rtpmap:0 PCMU/8000.
>
> #
> U 10

Re: [SR-Users] sipp dead calls

2016-12-16 Thread Diego Nadares
Hi Guys, me again,

I increased the pause in uas after RINGING to 1000 milliseconds. With this
value, works fine if I send 15 cps BUT if I send 25 I have to increase the
pause to 2000 milliseconds.




  

  



If you see the first trace is kamailio who answers the BYE with a 404. Is
it like the call wasn't established?

Any help we'll be appreciated.

Thanks in advance.

Diego!


El El mié, 14 de dic. de 2016 a las 18:22, Diego Nadares 
escribió:

> Hi Mack,
>
> The only thing I added to the basic scenarios is rrs="true"
>
> In UAS
> 
>
> In UAC
> 
>
> I use the same scenario with the same fields for every call. In a test of
> 6000 calls I see ~5  dead calls.
>
> Diego
>
>
> 2016-12-14 17:28 GMT-03:00 Mack Hendricks :
>
> Hey Diego,
>
> This smells like a sipP scenario file issue.  Did you customize the the
> scenario file being used by sipP B?
>
> -Mack
>
> On Dec 14, 2016, at 3:23 PM, Diego Nadares  wrote:
>
> Hi guys,
>
> We are testing kamailio with sipp. We are running it with 20cps and some
> calls do the following. When Kamailio is processing the 'ringing' a '200ok'
> arrives in the middle. First, kamailio forwards the 200 ok and then the
> ringing. 'ACK' arrives and, I suppose, the call is established. The thing
> is than when the 'BYE' arrives kamailio responds with a 404.
>
> This is the summary of the call
>
> Id Time Source Destination Protocol Len Info
>
> 6483 2016-12-14 11:26:06.264697 SIPP-A KAMAILIO SIP/SDP 692 Request:
> INVITE sip:@172.16.213.38:5060 |
>
> 6484 2016-12-14 11:26:06.264937 KAMAILIO SIPP-A SIP 367 Status: 100
> trying -- your call is important to us |
> 6485 2016-12-14 11:26:06.266327 KAMAILIO SIPP-B SIP/SDP 1179 Request:
> INVITE sip:@172.16.213.31:5060 |
> *6486 2016-12-14 11:26:06.267217 SIPP-B KAMAILIO SIP 566 Status: 180
> Ringing | *
> 6487 2016-12-14 11:26:06.267268 SIPP-B KAMAILIO SIP/SDP 733 Status: 200
> OK |
> 6488 2016-12-14 11:26:06.267758 KAMAILIO  SIPP-A SIP/SDP 788 Status: 200
> OK |
> *6489 2016-12-14 11:26:06.267833 *KAMAILIO SIPP-A* SIP 442 Status: 180
> Ringing | *
> 6490 2016-12-14 11:26:06.268868 SIPP-A KAMAILIO SIP 493 Request: ACK
> sip:127.0.0.8;line=sr-N6IAzBFwMJZfWJZLM.M7MlF-W.y6Mx14NEt7Nw05NhPQKjaP |
> 6491 2016-12-14 11:26:06.269162 KAMAILIO SIPP-B SIP 609 Request: ACK
> sip:172.16.213.31:5060;transport=UDP |
> 6492 2016-12-14 11:26:06.269614 SIPP-A KAMAILIO SIP 404 Request: BYE
> sip:@172.16.213.38:5060 |
> 6493 2016-12-14 11:26:06.269782 KAMAILIO SIPP-A SIP 348 Status: *404 Not
> here* |
>
> We are using modules rtjson, evapi, uac, topoh, rtpproxy for all calls. My
> debug level is -1. With higher levels this behavior increase.
>
> Kamailio is running in a virtual machine with centos7 with 8 cores and 8gb
> of ram.
>
> Do you need any further information? I can send you a pcap or ngrep file.
>
> Best regards,
>
> Diego.
>
>
> ___
> 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
>
>
>
>
>
>
>
___
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] Socket in rtjson module

2016-12-21 Thread Diego Nadares
Hi Guys,

Anybody knows if each 'socket' specified in routes struct should be use to
send the messages?

The socket is configured in kamailio.

In kamailio.cfg
listen=udp:172.16.213.38:5060

json struct

"routes": [
{
"uri": "sip:127.0.0.1:5080",
"dst_uri": "sip:127.0.0.1:5082",
"path": ", ",
> "socket": "udp:172.16.213.38:5060",<
"headers": {
"from": {
"display": "Alice",
"uri": "sip:alice@127..

In our kamailio has two eth and I want to select which one to use but I
can't make it work through rtjson.

In the code of the module I can't find where is being assigned the socket.

Thanks in advance!

Diego
___
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] Socket in rtjson module

2016-12-22 Thread Diego Nadares
Thanks Daniel, I will try it today!

Cheers,

Diego

2016-12-22 5:17 GMT-03:00 Daniel-Constantin Mierla :

> Hello,
>
> indeed, enforcing the socket was missing. Can you try with latest git from
> master or 4.4 branches? I pushed a patch for it.
>
> Cheers,
> Daniel
>
> On 21/12/2016 15:50, Diego Nadares wrote:
>
> Hi Guys,
>
> Anybody knows if each 'socket' specified in routes struct should be use to
> send the messages?
>
> The socket is configured in kamailio.
>
> In kamailio.cfg
> listen=udp:172.16.213.38:5060
>
> json struct
>
> "routes": [
> {
> "uri": "sip:127.0.0.1:5080",
> "dst_uri": "sip:127.0.0.1:5082",
> "path": ", ",
> > "socket": "udp:172.16.213.38:5060",<
> "headers": {
> "from": {
> "display": "Alice",
> "uri": "sip:alice@127..
>
> In our kamailio has two eth and I want to select which one to use but I
> can't make it work through rtjson.
>
> In the code of the module I can't find where is being assigned the socket.
>
>
> Thanks in advance!
>
> Diego
>
>
> ___
> 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 Mierlawww.twitter.com/miconda -- www.linkedin.com/in/miconda
> Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.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] Socket in rtjson module

2016-12-22 Thread Diego Nadares
Daniel,

It works like a charm!

Thanks again!

Diego.

2016-12-22 10:17 GMT-03:00 Diego Nadares :

> Thanks Daniel, I will try it today!
>
> Cheers,
>
> Diego
>
> 2016-12-22 5:17 GMT-03:00 Daniel-Constantin Mierla :
>
>> Hello,
>>
>> indeed, enforcing the socket was missing. Can you try with latest git
>> from master or 4.4 branches? I pushed a patch for it.
>>
>> Cheers,
>> Daniel
>>
>> On 21/12/2016 15:50, Diego Nadares wrote:
>>
>> Hi Guys,
>>
>> Anybody knows if each 'socket' specified in routes struct should be use
>> to send the messages?
>>
>> The socket is configured in kamailio.
>>
>> In kamailio.cfg
>> listen=udp:172.16.213.38:5060
>>
>> json struct
>>
>> "routes": [
>> {
>> "uri": "sip:127.0.0.1:5080",
>> "dst_uri": "sip:127.0.0.1:5082",
>> "path": ", ",
>> > "socket": "udp:172.16.213.38:5060",<
>> "headers": {
>> "from": {
>> "display": "Alice",
>> "uri": "sip:alice@127..
>>
>> In our kamailio has two eth and I want to select which one to use but I
>> can't make it work through rtjson.
>>
>> In the code of the module I can't find where is being assigned the
>> socket.
>>
>> Thanks in advance!
>>
>> Diego
>>
>>
>> ___
>> 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 Mierlawww.twitter.com/miconda -- 
>> www.linkedin.com/in/miconda
>> Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.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


[SR-Users] rtjson + mhomed and record route

2016-12-22 Thread Diego Nadares
Hi list,

We have two eth,  one with a private ip and the other with a public ip. We
have MHOMED configured. The call comes from private network and then is
routed to a public network via rtjson routing. The is routed but the thing
is that the record route is being set with the private one (It's the same
when calls come from public and is routed to a private network, record
route has the public and not the private).

With mhomed configured shouldn't Record Route be updated as VIA header

" When activated, sip-router will select a socket that can reach the
destination (to be able to connect to the remote address). (sip-router
opens a UDP socket to the destination, then it retrieves the local IP which
was assigned by the operating system to the new UDP socket. Then this
socket will be closed and the retrieved IP address will be used as IP
address in the Via/Record-Route headers)..."

This is part of ngrep

U 2016/12/22 11:24:15.019643 172.16.213.21:5060 -> 172.16.213.38:5060
INVITE sip:111@172.16.213.38:5060 SIP/2.0.
Via: SIP/2.0/UDP 172.16.213.21:5060;branch=z9hG4bK-13024-1-0.
From: "Test" ;tag=1.
To: .
Call-ID: 1-13024@172.16.213.21.
CSeq: 1 INVITE.
Contact: "22 .


U 2016/12/22 11:24:15.023923 172.16.213.38:5060 -> 172.16.213.21:5060
SIP/2.0 100 trying -- your call is important to us.
Via: SIP/2.0/UDP 172.16.213.21:5060;branch=z9hG4bK-13024-1-0.


U 2016/12/22 11:24:15.038695 XXX.XXX.XXX.01:5060 -> XXX.XXX.XXX.02:5060
INVITE sip:111...@xxx.xxx.xxx.02:5060 SIP/2.0.
*-> Record-Route: . <*
Via: SIP/2.0/UDP XXX.XXX.XXX.01;branch=z9hG4bKc09f
Via: SIP/2.0/UDP 127.0.0.8;branch=z9hG4bKsr-j4IPOlV7MGQKatycM.NLOBF6

This is my cfg

mhomed=1

request_route {


# per request initial checks
route(REQINIT);

# NAT detection
#route(NATDETECT);

# CANCEL processing
if (is_method("CANCEL")) {
if (t_check_trans()) {
route(RELAY);
}
exit;
}

# handle requests within SIP dialogs
route(WITHINDLG);

### only initial requests (no To tag)

# handle retransmissions
if(t_precheck_trans()) {
t_check_trans();
exit;
}
t_check_trans();

# authentication
route(AUTH);

# record routing for dialog forming requests (in case they are
routed)
# - remove preloaded route headers
remove_hf("Route");
if (is_method("INVITE|SUBSCRIBE")) {
record_route();
}


Thanks in advance.

Diego.
___
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] rtjson + mhomed and record route (corrected)

2016-12-22 Thread Diego Nadares
Hi list,

We have two eth,  one with a private ip and the other with a public ip. We
have MHOMED configured. The call comes from private network and then is
routed to a public network via rtjson routing. The call is routed but the
thing is that the record route is being set with the private one (It's the
same when calls come from public and is routed to a private network, record
route has the public and not the private).

With mhomed configured shouldn't Record Route be updated as VIA header?

" When activated, sip-router will select a socket that can reach the
destination (to be able to connect to the remote address). (sip-router
opens a UDP socket to the destination, then it retrieves the local IP which
was assigned by the operating system to the new UDP socket. Then this
socket will be closed and the retrieved IP address will be used as IP
address in the Via/Record-Route headers)..."

This is part of ngrep

U 2016/12/22 11:24:15.019643 172.16.213.21:5060 -> 172.16.213.38:5060
INVITE sip:111@172.16.213.38:5060 SIP/2.0.
Via: SIP/2.0/UDP 172.16.213.21:5060;branch=z9hG4bK-13024-1-0.
From: "Test" ;tag=1.
To: .
Call-ID: 1-13024@172.16.213.21.
CSeq: 1 INVITE.
Contact: "22 .


U 2016/12/22 11:24:15.023923 172.16.213.38:5060 -> 172.16.213.21:5060
SIP/2.0 100 trying -- your call is important to us.
Via: SIP/2.0/UDP 172.16.213.21:5060;branch=z9hG4bK-13024-1-0.


U 2016/12/22 11:24:15.038695 XXX.XXX.XXX.01:5060 -> XXX.XXX.XXX.02:5060
INVITE sip:11 <011%20->@XXX.XXX.XXX.02:5060 SIP/2.0.
*-> Record-Route: . <*
Via: SIP/2.0/UDP XXX.XXX.XXX.01;branch=z9hG4bKc09f
Via: SIP/2.0/UDP 127.0.0.8;branch=z9hG4bKsr-j4IPOlV7MGQKatycM.NLOBF6

This is my cfg

mhomed=1

request_route {


# per request initial checks
route(REQINIT);

# NAT detection
#route(NATDETECT);

# CANCEL processing
if (is_method("CANCEL")) {
if (t_check_trans()) {
route(RELAY);
}
exit;
}

# handle requests within SIP dialogs
route(WITHINDLG);

### only initial requests (no To tag)

# handle retransmissions
if(t_precheck_trans()) {
t_check_trans();
exit;
}
t_check_trans();

# authentication
route(AUTH);

# record routing for dialog forming requests (in case they are
routed)
# - remove preloaded route headers
remove_hf("Route");
if (is_method("INVITE|SUBSCRIBE")) {
record_route();
}


Thanks in advance.

Diego

2016-12-22 12:08 GMT-03:00 Diego Nadares :

> Hi list,
>
> We have two eth,  one with a private ip and the other with a public ip. We
> have MHOMED configured. The call comes from private network and then is
> routed to a public network via rtjson routing. The is routed but the thing
> is that the record route is being set with the private one (It's the same
> when calls come from public and is routed to a private network, record
> route has the public and not the private).
>
> With mhomed configured shouldn't Record Route be updated as VIA header
>
> " When activated, sip-router will select a socket that can reach the
> destination (to be able to connect to the remote address). (sip-router
> opens a UDP socket to the destination, then it retrieves the local IP which
> was assigned by the operating system to the new UDP socket. Then this
> socket will be closed and the retrieved IP address will be used as IP
> address in the Via/Record-Route headers)..."
>
> This is part of ngrep
>
> U 2016/12/22 11:24:15.019643 172.16.213.21:5060 -> 172.16.213.38:5060
> INVITE sip:111@172.16.213.38:5060 SIP/2.0.
> Via: SIP/2.0/UDP 172.16.213.21:5060;branch=z9hG4bK-13024-1-0.
> From: "Test" ;tag=1.
> To: .
> Call-ID: 1-13024@172.16.213.21.
> CSeq: 1 INVITE.
> Contact: "22 .
> 
>
> U 2016/12/22 11:24:15.023923 172.16.213.38:5060 -> 172.16.213.21:5060
> SIP/2.0 100 trying -- your call is important to us.
> Via: SIP/2.0/UDP 172.16.213.21:5060;branch=z9hG4bK-13024-1-0.
> 
>
> U 2016/12/22 11:24:15.038695 XXX.XXX.XXX.01:5060 -> XXX.XXX.XXX.02:5060
> INVITE sip:11 <011%20->@XXX.XXX.XXX.02:5060 SIP/2.0.
> *-> Record-Route: . <*
> Via: SIP/2.0/UDP XXX.XXX.XXX.01;branch=z9hG4bKc09f
> Via: SIP/2.0/UDP 127.0.0.8;branch=z9hG4bKsr-j4IPOlV7MGQKatycM.NLOBF6
>
> This is my cfg
>
> mhomed=1
>
> request_route {
>
>
> # per request initial checks
> route(REQINIT);
>
> # NAT detection
> #route(NATDETECT);
>
> # CANCEL processing
> if (is_method(&qu

Re: [SR-Users] rtjson + mhomed and record route (corrected)

2016-12-23 Thread Diego Nadares
I don't know if it's the right  way but with modparam("rr",
"enable_double_rr", 1)  adds both rr and topoh shows the correct one.


U 2016/12/23 09:58:23.818391 xxx.xxx.xxx.01:5060 -> xxx.xxx.xxx.02:5060
INVITE sip:...@xxx.xxx.xxx.02 SIP/2.0.
Via: SIP/2.0/UDP xxx.xxx.xxx.01:5060;branch=z9hG4bK637b1bca.
Max-Forwards: 70.

U 2016/12/23 09:58:24.031593 172.16.213.38:5060 -> 172.16.208.11:5060
INVITE sip:1153526112@172.16.208.11:5060;user=phone SIP/2.0.
---> Record-Route:
.<---
Record-Route: .

So, it;s working now!

Cheers,

Diego


2016-12-22 12:20 GMT-03:00 Diego Nadares :

> Hi list,
>
> We have two eth,  one with a private ip and the other with a public ip. We
> have MHOMED configured. The call comes from private network and then is
> routed to a public network via rtjson routing. The call is routed but the
> thing is that the record route is being set with the private one (It's the
> same when calls come from public and is routed to a private network, record
> route has the public and not the private).
>
> With mhomed configured shouldn't Record Route be updated as VIA header?
>
> " When activated, sip-router will select a socket that can reach the
> destination (to be able to connect to the remote address). (sip-router
> opens a UDP socket to the destination, then it retrieves the local IP which
> was assigned by the operating system to the new UDP socket. Then this
> socket will be closed and the retrieved IP address will be used as IP
> address in the Via/Record-Route headers)..."
>
> This is part of ngrep
>
> U 2016/12/22 11:24:15.019643 172.16.213.21:5060 -> 172.16.213.38:5060
> INVITE sip:111@172.16.213.38:5060 SIP/2.0.
> Via: SIP/2.0/UDP 172.16.213.21:5060;branch=z9hG4bK-13024-1-0.
> From: "Test" ;tag=1.
> To: .
> Call-ID: 1-13024@172.16.213.21.
> CSeq: 1 INVITE.
> Contact: "22 .
> 
>
> U 2016/12/22 11:24:15.023923 172.16.213.38:5060 -> 172.16.213.21:5060
> SIP/2.0 100 trying -- your call is important to us.
> Via: SIP/2.0/UDP 172.16.213.21:5060;branch=z9hG4bK-13024-1-0.
> 
>
> U 2016/12/22 11:24:15.038695 XXX.XXX.XXX.01:5060 -> XXX.XXX.XXX.02:5060
> INVITE sip:11 <011%20->@XXX.XXX.XXX.02:5060 SIP/2.0.
> *-> Record-Route: . <*
> Via: SIP/2.0/UDP XXX.XXX.XXX.01;branch=z9hG4bKc09f
> Via: SIP/2.0/UDP 127.0.0.8;branch=z9hG4bKsr-j4IPOlV7MGQKatycM.NLOBF6
>
> This is my cfg
>
> mhomed=1
>
> request_route {
>
>
> # per request initial checks
> route(REQINIT);
>
> # NAT detection
> #route(NATDETECT);
>
> # CANCEL processing
> if (is_method("CANCEL")) {
> if (t_check_trans()) {
> route(RELAY);
> }
> exit;
> }
>
> # handle requests within SIP dialogs
> route(WITHINDLG);
>
> ### only initial requests (no To tag)
>
> # handle retransmissions
> if(t_precheck_trans()) {
> t_check_trans();
> exit;
> }
> t_check_trans();
>
> # authentication
> route(AUTH);
>
> # record routing for dialog forming requests (in case they are
> routed)
> # - remove preloaded route headers
> remove_hf("Route");
> if (is_method("INVITE|SUBSCRIBE")) {
> record_route();
> }
> 
>
> Thanks in advance.
>
> Diego
>
> 2016-12-22 12:08 GMT-03:00 Diego Nadares :
>
>> Hi list,
>>
>> We have two eth,  one with a private ip and the other with a public ip.
>> We have MHOMED configured. The call comes from private network and then is
>> routed to a public network via rtjson routing. The is routed but the thing
>> is that the record route is being set with the private one (It's the same
>> when calls come from public and is routed to a private network, record
>> route has the public and not the private).
>>
>> With mhomed configured shouldn't Record Route be updated as VIA header
>>
>> " When activated, sip-router will select a socket that can reach the
>> destination (to be able to connect to the remote address). (sip-router
>> opens a UDP socket to the destination, then it retrieves the local IP which
>> was assigned by the operating system to the new UDP socket. Then this
>> socket will be closed and the retrieved IP address will be used as IP
>> address in the Via/Record-Route headers)..."
>>
>> This is part of ngrep
>>
>> U 2016/12/22 11:24:15.019643 172.

[SR-Users] set_body_multipart and append_body_part

2016-12-26 Thread Diego Nadares
Hi guys,

I'm trying to append a content type to a message that has only one content
type. I tried using just set_body_multipart and now I'm using set_body
multipart and append_body_part with no success too.

The result is a message with multipart but has "two" sdp and no gtd. It has
the old sdp with no ip changed for rtpproxy and the new sdp with ip changed
BUT with no content type.  And the message has not the end boundary
(--unique-boundary-1.)

Kamailio log has an info and a warning

Dec 26 11:36:22 dwrfsd01 ./kamailio[8847]: INFO: 
[msg_translator.c:1693]: get_boundary(): Content-Type hdr has no params

Dec 26 11:36:22 dwrfsd01 ./kamailio[8847]: WARNING: 
[msg_translator.c:1959]: build_req_buf_from_sip_req(): check_boundaries
error


kamailio.cfg

..

route[RELAY]{
$avp(ch) = 1

if ($avp(ch)){
 set_body_multipart();
 msg_apply_changes();
 $var(gtd) ="IAM,\r\nGCI,asdafsdfasd\r\n\r\n";
 append_body_part("$var(gtd)", "application/gtd",
"signal;handling=optional");
}

}

Ngrep

U 2016/12/26 11:36:22.496634 172.16.213.21:5060 -> 172.16.213.38:5060
...
Content-Type: application/sdp.
Content-Length:   137.
.
v=0.
o=user1 53655765 2353687637 IN IP4 172.16.213.21.
s=-.
c=IN IP4 172.16.213.21.
t=0 0.
m=audio 6000 RTP/AVP 8.
a=rtpmap:8 PCMA/8000.

U 2016/12/26 11:36:22.688458 172.16.213.38:5060 -> 172.16.208.11:5060

Content-Type: multipart/mixed;boundary="unique-boundary-1".
Mime-Version: 1.0.
Remote-Party-ID: ;party=calling;privacy=off;screen=no.
.
--unique-boundary-1.
Content-Type: application/sdp.
.
v=0.
o=user1 53655765 2353687637 IN IP4 172.16.213.21.
s=-.
c=IN IP4 172.16.213.21.
t=0 0.
m=audio 6000 RTP/AVP 8.
a=rtpmap:8 PCMA/8000.
.
--unique-boundary-1.
v=0.
o=user1 53655765 2353687637 IN IP4 172.16.213.38.
s=-.
c=IN IP4 172.16.213.38.
t=0 0.
m=audio 58724 RTP/AVP 8.
a=rtpmap:8 PCMA/8000.
a=sendrecv.
a=rtcp:58725.
a=ice-ufrag:hhXDwrco.
a=ice-pwd:5temIXP8veOGuD8Dsllm5HXkWU.

Any help will be very very appreciated!

Thanks in advance.

Diego
___
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] set_body_multipart and append_body_part

2016-12-26 Thread Diego Nadares
Sorry, I forgot to paste two log lines.

.
Dec 26 11:36:22 dwrfsd01 ./kamailio[8847]: ERROR: textopsx
[textopsx.c:159]: msg_apply_changes_f(): invalid usage - not in request
route
Dec 26 11:36:22 dwrfsd01 ./kamailio[8847]: ERROR: textops [textops.c:1879]:
append_multibody_helper(): Cannot get boundary. Is body multipart?
Dec 26 11:36:22 dwrfsd01 ./kamailio[8847]: INFO: 

Re: [SR-Users] set_body_multipart and append_body_part

2016-12-26 Thread Diego Nadares
Hi Sergey,

Thanks for your reply. You are right.

I added a test with results in the second email  calling only
set_body_multipart.

Do you have any idea what is happening?

Thanks again!

Diego

El El lun, 26 de dic. de 2016 a las 13:10, Sergey Basov <
sergey.v.ba...@gmail.com> escribió:

> Hi.
>
> As from textopsx module doc: "This function can be used from REQUEST_ROUTE
> or ONREPLY_ROUTE."
>
> And you have error in your log: "Dec 26 11:36:22 dwrfsd01
> ./kamailio[8847]: ERROR: textopsx [textopsx.c:159]: msg_apply_changes_f():
> invalid usage - not in request route"
>
> --
> Sergey Basov
>
>
> 26 дек. 2016 г. 5:05 PM пользователь "Diego Nadares" 
> написал:
>
> Sorry, I forgot to paste two log lines.
>
> .
> Dec 26 11:36:22 dwrfsd01 ./kamailio[8847]: ERROR: textopsx
> [textopsx.c:159]: msg_apply_changes_f(): invalid usage - not in request
> route
> Dec 26 11:36:22 dwrfsd01 ./kamailio[8847]: ERROR: textops
> [textops.c:1879]: append_multibody_helper(): Cannot get boundary. Is body
> multipart?
> Dec 26 11:36:22 dwrfsd01 ./kamailio[8847]: INFO: 

Re: [SR-Users] set_body_multipart and append_body_part

2016-12-26 Thread Diego Nadares
I made it work but I have to set multipart always in request route  (as the
manual says) to apply the changes. Just a comment. If I don't apply changes
after append_body_part, kamailio crashes.

if (is_method("INVITE") && !has_totag()) {
set_body_multipart();
msg_apply_changes();
$var(gtd) =
"IAM,\r\nCPC,"+$avp("ch")+"\r\nGCI,asdfasd\r\n\r\n";
append_body_part("$var(gtd)", "application/gtd",
"signal;handling=optional");
msg_apply_changes();
}


I know that this is the way as it works (just apply changes in request
route) but with rtjson and the evapi module I decide if it has to have or
not multipart later and not in the first invite.
Is It possible to add in new versions of kamailio to apply the changes in
branch route too? (this would be a new request)

Cheers.

Diego.






2016-12-26 13:21 GMT-03:00 Diego Nadares :

> Hi Sergey,
>
> Thanks for your reply. You are right.
>
> I added a test with results in the second email  calling only
> set_body_multipart.
>
> Do you have any idea what is happening?
>
> Thanks again!
>
> Diego
>
> El El lun, 26 de dic. de 2016 a las 13:10, Sergey Basov <
> sergey.v.ba...@gmail.com> escribió:
>
>> Hi.
>>
>> As from textopsx module doc: "This function can be used from
>> REQUEST_ROUTE or ONREPLY_ROUTE."
>>
>> And you have error in your log: "Dec 26 11:36:22 dwrfsd01
>> ./kamailio[8847]: ERROR: textopsx [textopsx.c:159]: msg_apply_changes_f():
>> invalid usage - not in request route"
>>
>> --
>> Sergey Basov
>>
>>
>> 26 дек. 2016 г. 5:05 PM пользователь "Diego Nadares" 
>> написал:
>>
>> Sorry, I forgot to paste two log lines.
>>
>> .
>> Dec 26 11:36:22 dwrfsd01 ./kamailio[8847]: ERROR: textopsx
>> [textopsx.c:159]: msg_apply_changes_f(): invalid usage - not in request
>> route
>> Dec 26 11:36:22 dwrfsd01 ./kamailio[8847]: ERROR: textops
>> [textops.c:1879]: append_multibody_helper(): Cannot get boundary. Is body
>> multipart?
>> Dec 26 11:36:22 dwrfsd01 ./kamailio[8847]: INFO: 

Re: [SR-Users] CDR - acc_cdrs

2017-01-05 Thread Diego Nadares
Hi Annus,

Did you set the flags for those calls you want to account?

I have something like this in my request route

if (is_method("INVITE") && !has_totag()) {
setflag(FLT_ACC); # do accounting
dlg_manage();
setflag(FLT_ACCMISSED);
setflag(FLT_ACCFAILED);
 }

Logs?

Cheers,

Diego



2017-01-05 11:13 GMT-03:00 Annus Fictus :

> Hello,
>
> I'm trying to save Kamailio CDR on acc_cdrs table without success. My
> relevant configuration look like:
>
> -
>
> #!define FLT_ACC 1
> #!define FLT_ACCMISSED 2
> #!define FLT_ACCFAILED 3
>
> -
>
> #!define WITH_ACCDB
>
> 
>
> loadmodule "dialog.so"
> loadmodule "acc.so"
> modparam("dialog", "dlg_flag", 0)
>
> 
>
> # - acc params -
> modparam("acc", "early_media", 0)
> modparam("acc", "report_ack", 0)
> modparam("acc", "report_cancels", 0)
> modparam("acc", "detect_direction", 0)
> modparam("acc", "log_flag", FLT_ACC)
> modparam("acc", "log_missed_flag", FLT_ACCMISSED)
> modparam("acc", "log_extra",
> "src_user=$fU;src_domain=$fd;src_ip=$si;"
> "dst_ouser=$tU;dst_user=$rU;dst_domain=$rd")
> modparam("acc", "failed_transaction_flag", FLT_ACCFAILED)
> #!ifdef WITH_ACCDB
> modparam("acc", "db_flag", FLT_ACC)
> modparam("acc", "db_missed_flag", FLT_ACCMISSED)
> modparam("acc", "db_url", DBURL)
> modparam("acc", "cdr_enable", 1)
> modparam("acc", "cdr_log_enable", 1)
> modparam("acc", "cdr_on_failed", 1)
> modparam("acc", "cdrs_table", "acc_cdrs")
> modparam("acc", "cdr_start_on_confirmed", 1)
> modparam("acc", "db_extra",
> "src_user=$fU;src_domain=$fd;src_ip=$si;"
> "dst_ouser=$tU;dst_user=$rU;dst_domain=$td")
> #!endif
>
> Any hint is really appreciate.
>
> Regards
>
>
>
> ___
> 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] CDR - acc_cdrs

2017-01-05 Thread Diego Nadares
Sorry. I thought that after sending the email.

Kamailio It's not saving even in acc table? Are you starting a dialog?

*dialog* -- Dialog, if “cdr_enable” module parameter is enabled

In my cfg

if (is_method("INVITE") && !has_totag()) {
setflag(FLT_ACC); # do accounting
dlg_manage(); <- Starting dialog
setflag(FLT_ACCMISSED);
setflag(FLT_ACCFAILED);
 }

2017-01-05 11:58 GMT-03:00 Annus Fictus :

> Hi Diego,
>
> I'm using default script:
>
> # account only INVITEs
> if (is_method("INVITE")) {
> setflag(FLT_ACC); # do accounting
> }
>
>
> if (is_method("BYE")) {
> setflag(FLT_ACC); # do accounting ...
> setflag(FLT_ACCFAILED); # ... even if the
> transaction fails
> }
>
> Regards
>
> El 05/01/2017 a las 09:54, Diego Nadares escribió:
>
> Hi Annus,
>
> Did you set the flags for those calls you want to account?
>
> I have something like this in my request route
>
> if (is_method("INVITE") && !has_totag()) {
> setflag(FLT_ACC); # do accounting
> dlg_manage();
> setflag(FLT_ACCMISSED);
> setflag(FLT_ACCFAILED);
>  }
>
> Logs?
>
> Cheers,
>
> Diego
>
>
>
> 2017-01-05 11:13 GMT-03:00 Annus Fictus :
>
>> Hello,
>>
>> I'm trying to save Kamailio CDR on acc_cdrs table without success. My
>> relevant configuration look like:
>>
>> -
>>
>> #!define FLT_ACC 1
>> #!define FLT_ACCMISSED 2
>> #!define FLT_ACCFAILED 3
>>
>> -
>>
>> #!define WITH_ACCDB
>>
>> 
>>
>> loadmodule "dialog.so"
>> loadmodule "acc.so"
>> modparam("dialog", "dlg_flag", 0)
>>
>> 
>>
>> # - acc params -
>> modparam("acc", "early_media", 0)
>> modparam("acc", "report_ack", 0)
>> modparam("acc", "report_cancels", 0)
>> modparam("acc", "detect_direction", 0)
>> modparam("acc", "log_flag", FLT_ACC)
>> modparam("acc", "log_missed_flag", FLT_ACCMISSED)
>> modparam("acc", "log_extra",
>> "src_user=$fU;src_domain=$fd;src_ip=$si;"
>> "dst_ouser=$tU;dst_user=$rU;dst_domain=$rd")
>> modparam("acc", "failed_transaction_flag", FLT_ACCFAILED)
>> #!ifdef WITH_ACCDB
>> modparam("acc", "db_flag", FLT_ACC)
>> modparam("acc", "db_missed_flag", FLT_ACCMISSED)
>> modparam("acc", "db_url", DBURL)
>> modparam("acc", "cdr_enable", 1)
>> modparam("acc", "cdr_log_enable", 1)
>> modparam("acc", "cdr_on_failed", 1)
>> modparam("acc", "cdrs_table", "acc_cdrs")
>> modparam("acc", "cdr_start_on_confirmed", 1)
>> modparam("acc", "db_extra",
>> "src_user=$fU;src_domain=$fd;src_ip=$si;"
>> "dst_ouser=$tU;dst_user=$rU;dst_domain=$td")
>> #!endif
>>
>> Any hint is really appreciate.
>>
>> Regards
>>
>>
>>
>> ___
>> 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 
> listsr-us...@lists.sip-router.orghttp://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
>
>
___
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] [Error] Install Kamailio 4.4 in Mac 10.12

2017-01-09 Thread Diego Nadares
Hi Luis,

Do you have mysql installed? Because it's not finding those headers.

El El lun, 9 de ene. de 2017 a las 05:21, Luis De Marchi <
l...@snowmanlabs.com> escribió:

> Hi,
>
> Sorry, my english, I'm using the translator.
> I'm having trouble installing Kamailio for Mac 10.12
>
> Terminal:
> Luis:kamailio luisdemarchi$ sudo make all
>
> CC (gcc) [M db_mysql.so] km_db_mysql.o
> *km_db_mysql.c:41:10: **fatal error: **'mysql.h' file not found*
> #include 
> * ^*
> 1 error generated.
> make[1]: *** [km_db_mysql.o] Error 1
> make: *** [modules] Error 1
>
>
> *Luís De Marchi*
> Diretor Administrativo
>
> +55 (41) 99815-6800
> +55 (41) 3027-7669
> www.snowmanlabs.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] [Error] Install Kamailio 4.4 in Mac 10.12

2017-01-09 Thread Diego Nadares
In my mac:

I think that mysql dmg installed comes with dev headers too.

dnadaress-MacBook-Air:~ dnadares$ locate mysql.h
/usr/local/mysql-5.6.19-osx10.7-x86_64/include/mysql.h

cheers.

Diego.


2017-01-09 9:27 GMT-03:00 Diego Nadares :

> Hi Luis,
>
> Do you have mysql installed? Because it's not finding those headers.
>
> El El lun, 9 de ene. de 2017 a las 05:21, Luis De Marchi <
> l...@snowmanlabs.com> escribió:
>
>> Hi,
>>
>> Sorry, my english, I'm using the translator.
>> I'm having trouble installing Kamailio for Mac 10.12
>>
>> Terminal:
>> Luis:kamailio luisdemarchi$ sudo make all
>>
>> CC (gcc) [M db_mysql.so] km_db_mysql.o
>> *km_db_mysql.c:41:10: **fatal error: **'mysql.h' file not found*
>> #include 
>> * ^*
>> 1 error generated.
>> make[1]: *** [km_db_mysql.o] Error 1
>> make: *** [modules] Error 1
>>
>>
>> *Luís De Marchi*
>> Diretor Administrativo
>>
>> +55 (41) 99815-6800 <+55%2041%2099815-6800>
>> +55 (41) 3027-7669 <+55%2041%203027-7669>
>> www.snowmanlabs.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


[SR-Users] Remove/Append headers in 200 canceling and 200 ok to BYE

2017-01-12 Thread Diego Nadares
Hi List,

I'm trying to add and remove some headers in 200 canceling and 200 ok to
BYEs with no success.

I don't know in which route to add my remove_hf and append_hf. It seems
that I can't catch it on reply either on request route.

I tried adding it in

event_route[tm:local-response] {
xlog("L_ERR", "TM LOCAL REPONSE!");
route(MANAGE_HEADERS);
}

This is my route to manage hdrs:

route[MANAGE_HEADERS]{

xlog("L_ERR", "MANAGE HDRS !");

keep_hf("TH"); # for topoh

append("AHDR1:asdf\r\n");

return;
}

I suppose SERVER HDR should be removed but:

U 2017/01/12 12:45:41.566733 172.16.213.38:5060 -> 172.16.50.41:5060
SIP/2.0 200 canceling.
Via: SIP/2.0/UDP 172.16.50.41:5060;branch=z9hG4bKgg8ekd3080braugkm700.1.
CSeq: 102 CANCEL.
From: ;tag=SD7b10b01-as5ba5e269.
To: ;tag=4a86e96addfb27a943bc86e1872032b6-0a8b.
Call-ID: SD7b10b01-6a7d1089793bda79481f25cf88c023ed-c540dl1.
Server: kamailio (4.4.4 (x86_64/linux)).
Content-Length: 0.


Any help will be very appreciated.

Thanks in advance!

Diego
___
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] Remove/Append headers in 200 canceling and 200 ok to BYE

2017-01-12 Thread Diego Nadares
Hi Daniel!

Thanks for your answer.  The idea is to show only a few headers. In BYE
works great. I'm removing and adding the following hdrs:

*User-Agent: Kamailio. <---I will try what you said*
*Supported:.*
*Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, NOTIFY, INFO.*
*Accept: application/sdp, application/gtd.*

For example in following messages ( Kamailio is 172.16.213.38)

#
U 2017/01/12 14:51:10.593782 172.16.200.159:57270 -> 172.16.213.38:5060
BYE sip:127.0.0.8:5060;line=sr-9879879879798** SIP/2.0.
Via: SIP/2.0/UDP  172.16.200.159:5060;branch=z9hG4bK12B9605ED.
From: xx ;tag=95E7E4A4-23F2.
To: xxx ;tag=SDmmb7201-as0518eb07.
Date: Thu, 12 Jan 2017 17:51:05 GMT.
Call-ID: SDmmb7201-f5ded6cf4cd5d84736b088e39277e8db-c540dl1.
User-Agent: Cisco-SIPGateway/IOS-12.x.
Max-Forwards: 15.
Route: .
Timestamp: 1484243470.
CSeq: 101 BYE.
Reason: Q.850;cause=16.
Content-Disposition: signal;handling=optional.
Content-Type: application/gtd.
Content-Length: 26.
.
.
.

#
U 2017/01/12 14:51:10.647164 172.16.213.38:5060 -> 172.16.50.41:5060
BYE sip:xxx@172.16.50.41:5060;transport=udp SIP/2.0.
Via: SIP/2.0/UDP
172.16.213.38;branch=z9hG4bKdcf6.f898feef02d601e36a22d26bf3ae5e4a.0.
Via: SIP/2.0/UDP 127.0.0.8;branch=z9hG4bKsr-asdfasdfF.
From: xx ;tag=95E7E4A4-23F2.
To: xxx ;tag=SDmmb7201-as0518eb07.
Call-ID: SDmmb7201-f5ded6cf4cd5d84736b088e39277e8db-c540dl1.
Max-Forwards: 14.
CSeq: 101 BYE.
Content-Type: application/gtd.
Content-Length: 26.
*User-Agent: Kamailio.*
*Supported:.*
*Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, NOTIFY, INFO.*
*Accept: application/sdp, application/gtd.*
.
..

But in ok I can't

#
U 2017/01/12 14:51:10.653701 172.16.50.41:5060 -> 172.16.213.38:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP
172.16.213.38;branch=z9hG4bKdcf6.f898feef02d601e36a22d26bf3ae5e4a.0.
Via: SIP/2.0/UDP 127.0.0.8;branch=z9hG4bKsr-sadfasdf.
From: xx ;tag=95E7E4A4-23F2.
To: xxx ;tag=SDmmb7201-as0518eb07.
Call-ID: SDmmb7201-f5ded6cf4cd5d84736b088e39277e8db-c540dl1.
CSeq: 101 BYE.
Server: Asterisk PBX 11.17.0.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH, MESSAGE.
Supported: replaces, timer.
Content-Length: 0.
.
FY, INFO.
Accept
#
U 2017/01/12 14:51:10.669460 172.16.213.38:5060 -> 172.16.200.159:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP  172.16.200.159:5060;branch=z9hG4bK12B9605ED.
From: xx ;tag=95E7E4A4-23F2.
To: xxx ;tag=SDmmb7201-as0518eb07.
Call-ID: SDmmb7201-f5ded6cf4cd5d84736b088e39277e8db-c540dl1.
CSeq: 101 BYE.
*Server: Asterisk PBX 11.17.0.*
*Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH, MESSAGE.*
*Supported: replaces, timer.*
Content-Length: 0.
.



2017-01-12 13:23 GMT-03:00 Daniel-Constantin Mierla :

> Hello,
>
> if you are looking to remove the server header (server signature), that
> can be controlled via global parameters:
>
>   - https://www.kamailio.org/wiki/cookbooks/4.4.x/core#server_header
>
> Note that there is another header, User-Agent, that may be added by
> Kamailio in local generate request. There is a global parameter to control
> it as well.
> If you want more than that, can you add a bit more details, because CANCEL
> and BYE are processed differently. With which one you get issues?
>
> Cheers,
> Daniel
>
>
> On 12/01/2017 17:00, Diego Nadares wrote:
>
> Hi List,
>
> I'm trying to add and remove some headers in 200 canceling and 200 ok to
> BYEs with no success.
>
> I don't know in which route to add my remove_hf and append_hf. It seems
> that I can't catch it on reply either on request route.
>
> I tried adding it in
>
> event_route[tm:local-response] {
> xlog("L_ERR", "TM LOCAL REPONSE!");
> route(MANAGE_HEADERS);
> }
>
> This is my route to manage hdrs:
>
> route[MANAGE_HEADERS]{
>
> xlog("L_ERR", "MANAGE HDRS !");
>
> keep_hf("TH"); # for topoh
>
> append("AHDR1:asdf\r\n");
>
> return;
> }
>
> I suppose SERVER HDR should be removed but:
>
> U 2017/01/12 12:45:41.566733 172.16.213.38:5060 -> 172.16.50.41:5060
> SIP/2.0 200 canceling.
> Via: SIP/2.0/UDP 172.16.50.41:5060;branch=z9hG4bKgg8ekd3080braugkm700.1.
> CSeq: 102 CANCEL.
> From: ;tag=SD7b10b01-as5ba5e269.
> To: ;tag=4a86e96addfb27a943bc86e1872032b6-0a8b.
> Call-ID: SD7b10b01-6a7d1089793bda79481f25cf88c023ed-c540dl1.
> Server: kamailio (4.4.4 (x86_64/linux)).
> Content-Length: 0.
>
>
> Any help will be very appreciated.
>
> Thanks in advance!
>
> Diego
>
>
> ___
> 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 Mierlawww.twitter.com/

Re: [SR-Users] Remove/Append headers in 200 canceling and 200 ok to BYE

2017-01-13 Thread Diego Nadares
If you need any additional data please let me know.

Cheers,

Diego

2017-01-12 15:04 GMT-03:00 Diego Nadares :

> Hi Daniel!
>
> Thanks for your answer.  The idea is to show only a few headers. In BYE
> works great. I'm removing and adding the following hdrs:
>
> *User-Agent: Kamailio. <---I will try what you said*
> *Supported:.*
> *Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, NOTIFY, INFO.*
> *Accept: application/sdp, application/gtd.*
>
> For example in following messages ( Kamailio is 172.16.213.38)
>
> #
> U 2017/01/12 14:51:10.593782 172.16.200.159:57270 -> 172.16.213.38:5060
> BYE sip:127.0.0.8:5060;line=sr-9879879879798** SIP/2.0.
> Via: SIP/2.0/UDP  172.16.200.159:5060;branch=z9hG4bK12B9605ED.
> From: xx ;tag=95E7E4A4-23F2.
> To: xxx ;tag=SDmmb7201-as0518eb07.
> Date: Thu, 12 Jan 2017 17:51:05 GMT.
> Call-ID: SDmmb7201-f5ded6cf4cd5d84736b088e39277e8db-c540dl1.
> User-Agent: Cisco-SIPGateway/IOS-12.x.
> Max-Forwards: 15.
> Route: .
> Timestamp: 1484243470.
> CSeq: 101 BYE.
> Reason: Q.850;cause=16.
> Content-Disposition: signal;handling=optional.
> Content-Type: application/gtd.
> Content-Length: 26.
> .
> .
> .
>
> #
> U 2017/01/12 14:51:10.647164 172.16.213.38:5060 -> 172.16.50.41:5060
> BYE sip:xxx@172.16.50.41:5060;transport=udp SIP/2.0.
> Via: SIP/2.0/UDP 172.16.213.38;branch=z9hG4bKdcf6.
> f898feef02d601e36a22d26bf3ae5e4a.0.
> Via: SIP/2.0/UDP 127.0.0.8;branch=z9hG4bKsr-asdfasdfF.
> From: xx ;tag=95E7E4A4-23F2.
> To: xxx ;tag=SDmmb7201-as0518eb07.
> Call-ID: SDmmb7201-f5ded6cf4cd5d84736b088e39277e8db-c540dl1.
> Max-Forwards: 14.
> CSeq: 101 BYE.
> Content-Type: application/gtd.
> Content-Length: 26.
> *User-Agent: Kamailio.*
> *Supported:.*
> *Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, NOTIFY, INFO.*
> *Accept: application/sdp, application/gtd.*
> .
> ..
>
> But in ok I can't
>
> #
> U 2017/01/12 14:51:10.653701 172.16.50.41:5060 -> 172.16.213.38:5060
> SIP/2.0 200 OK.
> Via: SIP/2.0/UDP 172.16.213.38;branch=z9hG4bKdcf6.
> f898feef02d601e36a22d26bf3ae5e4a.0.
> Via: SIP/2.0/UDP 127.0.0.8;branch=z9hG4bKsr-sadfasdf.
> From: xx ;tag=95E7E4A4-23F2.
> To: xxx ;tag=SDmmb7201-as0518eb07.
> Call-ID: SDmmb7201-f5ded6cf4cd5d84736b088e39277e8db-c540dl1.
> CSeq: 101 BYE.
> Server: Asterisk PBX 11.17.0.
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
> PUBLISH, MESSAGE.
> Supported: replaces, timer.
> Content-Length: 0.
> .
> FY, INFO.
> Accept
> #
> U 2017/01/12 14:51:10.669460 172.16.213.38:5060 -> 172.16.200.159:5060
> SIP/2.0 200 OK.
> Via: SIP/2.0/UDP  172.16.200.159:5060;branch=z9hG4bK12B9605ED.
> From: xx ;tag=95E7E4A4-23F2.
> To: xxx ;tag=SDmmb7201-as0518eb07.
> Call-ID: SDmmb7201-f5ded6cf4cd5d84736b088e39277e8db-c540dl1.
> CSeq: 101 BYE.
> *Server: Asterisk PBX 11.17.0.*
> *Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
> PUBLISH, MESSAGE.*
> *Supported: replaces, timer.*
> Content-Length: 0.
> .
>
>
>
> 2017-01-12 13:23 GMT-03:00 Daniel-Constantin Mierla :
>
>> Hello,
>>
>> if you are looking to remove the server header (server signature), that
>> can be controlled via global parameters:
>>
>>   - https://www.kamailio.org/wiki/cookbooks/4.4.x/core#server_header
>>
>> Note that there is another header, User-Agent, that may be added by
>> Kamailio in local generate request. There is a global parameter to control
>> it as well.
>> If you want more than that, can you add a bit more details, because
>> CANCEL and BYE are processed differently. With which one you get issues?
>>
>> Cheers,
>> Daniel
>>
>>
>> On 12/01/2017 17:00, Diego Nadares wrote:
>>
>> Hi List,
>>
>> I'm trying to add and remove some headers in 200 canceling and 200 ok to
>> BYEs with no success.
>>
>> I don't know in which route to add my remove_hf and append_hf. It seems
>> that I can't catch it on reply either on request route.
>>
>> I tried adding it in
>>
>> event_route[tm:local-response] {
>> xlog("L_ERR", "TM LOCAL REPONSE!");
>> route(MANAGE_HEADERS);
>> }
>>
>> This is my route to manage hdrs:
>>
>> route[MANAGE_HEADERS]{
>>
>> xlog("L_ERR", "MANAGE HDRS !");
>>
>> keep_hf("TH"); # for topoh
>>
>> append("AHDR1:asdf\r\n");
>>
>> return;
>> }
>>
>> I suppose SERVER HDR should be removed but:
>>
>> U 2017/01/12 12:45:41.566733 172.16.213

Re: [SR-Users] Remove/Append headers in 200 canceling and 200 ok to BYE

2017-01-13 Thread Diego Nadares
Thanks Sergey! It works like a charm for BYEs.

Is it working for you on 200cancelling generated by Kamailio?

I tried the same work around with no success.

 if (is_method("CANCEL")) {
if (t_check_trans()) {
if(!t_is_set("onreply_route"))

t_on_reply("MANAGE_REPLY_ON_CANCEL");
route(RELAY);
}
exit;
}


Thanks again,

Diego



2017-01-13 13:27 GMT-03:00 Sergey Basov :

> Hi All.
>
> I have similar task. But i have to remove server and user-agent headers
> from all request an replyes.
>
> You can try:
>
>
> I have added route:
> # Fix user-agent and server
> route[RemoveHeader] {
> remove_hf("server");
> remove_hf("user-agent");
> return;
> }
>
>
> I use it form
> request_route {
> 
> route(RemoveHeader);
> .
> }
>
> failure_route[--- all what i have ---] {
> 
> route(RemoveHeader);
> .
> }
>
> branch_route[MANAGE_BRANCH]{
> 
> route(RemoveHeader);
> .
> }
>
> onreply_route[MANAGE_REPLY] {
> 
> route(RemoveHeader);
> .
> }
>
> failure_route[MANAGE_FAILURE] {
> 
> route(RemoveHeader);
> .
> }
>
> Seems all is fine It removes headers in all packets except 200 OK on
> BYE
> After debugging script I does not seen in which route this 200 Ok goes..
> But if I adding next to
> route[RELAY] {
> 
> if (is_method("BYE")) {
> xlog("L_INFO","route RELAY method BYE \n");
> if(!t_is_set("onreply_route"))
> t_on_reply("MANAGE_REPLY_ON_BYE");
> }
> ...
> }
>
> and adding route
> onreply_route[MANAGE_REPLY_ON_BYE] {
> route(RemoveHeader);
> xlog("L_INFO","route MANAGE_REPLY_ON_BYE entered \n");
> }
>
> this 200 Ok successfully goes to MANAGE_REPLY_ON_BYE route and headers
> are removed.
>
>
>
> 13 янв. 2017 г. 4:59 PM пользователь "Diego Nadares" 
> написал:
>
> If you need any additional data please let me know.
>
> Cheers,
>
> Diego
>
> 2017-01-12 15:04 GMT-03:00 Diego Nadares :
>
>> Hi Daniel!
>>
>> Thanks for your answer.  The idea is to show only a few headers. In BYE
>> works great. I'm removing and adding the following hdrs:
>>
>> *User-Agent: Kamailio. <---I will try what you said*
>> *Supported:.*
>> *Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, NOTIFY, INFO.*
>> *Accept: application/sdp, application/gtd.*
>>
>> For example in following messages ( Kamailio is 172.16.213.38)
>>
>> #
>> U 2017/01/12 14:51:10.593782 172.16.200.159:57270 -> 172.16.213.38:5060
>> BYE sip:127.0.0.8:5060;line=sr-9879879879798** SIP/2.0.
>> Via: SIP/2.0/UDP  172.16.200.159:5060;branch=z9hG4bK12B9605ED.
>> From: xx ;tag=95E7E4A4-23F2.
>> To: xxx ;tag=SDmmb7201-as0518eb07.
>> Date: Thu, 12 Jan 2017 17:51:05 GMT.
>> Call-ID: SDmmb7201-f5ded6cf4cd5d84736b088e39277e8db-c540dl1.
>> User-Agent: Cisco-SIPGateway/IOS-12.x.
>> Max-Forwards: 15.
>> Route: .
>> Timestamp: 1484243470.
>> CSeq: 101 BYE.
>> Reason: Q.850;cause=16.
>> Content-Disposition: signal;handling=optional.
>> Content-Type: application/gtd.
>> Content-Length: 26.
>> .
>> .
>> .
>>
>> #
>> U 2017/01/12 14:51:10.647164 172.16.213.38:5060 -> 172.16.50.41:5060
>> BYE sip:xxx@172.16.50.41:5060;transport=udp SIP/2.0.
>> Via: SIP/2.0/UDP 172.16.213.38;branch=z9hG4bKdc
>> f6.f898feef02d601e36a22d26bf3ae5e4a.0.
>> Via: SIP/2.0/UDP 127.0.0.8;branch=z9hG4bKsr-asdfasdfF.
>> From: xx ;tag=95E7E4A4-23F2.
>> To: xxx ;tag=SDmmb7201-as0518eb07.
>> Call-ID: SDmmb7201-f5ded6cf4cd5d84736b088e39277e8db-c540dl1.
>> Max-Forwards: 14.
>> CSeq: 101 BYE.
>> Content-Type: application/gtd.
>> Content-Length: 26.
>> *User-Agent: Kamailio.*
>> *Supported:.*
>> *Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, NOTIFY, INFO.*
>> *Accept: application/sdp, application/gtd.*
>> .
>> ..
>>
>> But in ok I can't
>>
>> #
>> U 2017/01/12 14:51:10.653701 172.16.50.41:5060 -> 172.16.213.38:5060
>> SIP/2.0 200 OK.
>> Via: SIP/2.0/UDP 172.16.213.38;branch=z9hG4bKdc
>> f6.f898feef02d601e36a22d26bf3ae5e4a.0.
>> Via: SIP/2.0/UDP 127.0.0.8;branch=z9hG4bKsr-sadfasdf.
>> From: xx ;tag=95E7E4A4-23F2.
>> To: xxx ;tag=SDmmb7201-as0518eb07.
>> Call-ID: SDmmb7201-f5ded6cf4cd5d84736b088e39277e8db-c540dl1.
>> CSeq: 1

Re: [SR-Users] Remove/Append headers in 200 canceling and 200 ok to BYE

2017-01-16 Thread Diego Nadares
Hi Daniel,

With the minimal it's great. The headers are the ones that we can show. Now
we are using the server_header and with this it's complete.

Thanks!

Diego.

2017-01-16 5:31 GMT-03:00 Daniel-Constantin Mierla :

> The 200ok for CANCEL generated by Kamailio doesn't get inside the
> onreply_route -- this block is only for SIP replies received by kamailio.
>
> However, the 200ok for CANCEL should have limited (minimal) number of
> headers. Which ones besides the Server do you want to remove?
>
> Cheers,
> Daniel
> On 13/01/2017 19:00, Diego Nadares wrote:
>
> Thanks Sergey! It works like a charm for BYEs.
>
> Is it working for you on 200cancelling generated by Kamailio?
>
> I tried the same work around with no success.
>
>  if (is_method("CANCEL")) {
> if (t_check_trans()) {
> if(!t_is_set("onreply_route"))
> t_on_reply("MANAGE_REPLY_ON_
> CANCEL");
> route(RELAY);
> }
> exit;
> }
>
>
> Thanks again,
>
> Diego
>
>
>
> 2017-01-13 13:27 GMT-03:00 Sergey Basov :
>
>> Hi All.
>>
>> I have similar task. But i have to remove server and user-agent headers
>> from all request an replyes.
>>
>> You can try:
>>
>>
>> I have added route:
>> # Fix user-agent and server
>> route[RemoveHeader] {
>> remove_hf("server");
>> remove_hf("user-agent");
>> return;
>> }
>>
>>
>> I use it form
>> request_route {
>> 
>> route(RemoveHeader);
>> .
>> }
>>
>> failure_route[--- all what i have ---] {
>> 
>> route(RemoveHeader);
>> .
>> }
>>
>> branch_route[MANAGE_BRANCH]{
>> 
>> route(RemoveHeader);
>> .
>> }
>>
>> onreply_route[MANAGE_REPLY] {
>> 
>> route(RemoveHeader);
>> .
>> }
>>
>> failure_route[MANAGE_FAILURE] {
>> 
>> route(RemoveHeader);
>> .
>> }
>>
>> Seems all is fine It removes headers in all packets except 200 OK on
>> BYE
>> After debugging script I does not seen in which route this 200 Ok goes..
>> But if I adding next to
>> route[RELAY] {
>> 
>> if (is_method("BYE")) {
>> xlog("L_INFO","route RELAY method BYE \n");
>> if(!t_is_set("onreply_route"))
>> t_on_reply("MANAGE_REPLY_ON_BYE");
>> }
>> ...
>> }
>>
>> and adding route
>> onreply_route[MANAGE_REPLY_ON_BYE] {
>> route(RemoveHeader);
>> xlog("L_INFO","route MANAGE_REPLY_ON_BYE entered \n");
>> }
>>
>> this 200 Ok successfully goes to MANAGE_REPLY_ON_BYE route and headers
>> are removed.
>>
>>
>>
>> 13 янв. 2017 г. 4:59 PM пользователь "Diego Nadares" 
>> написал:
>>
>> If you need any additional data please let me know.
>>
>> Cheers,
>>
>> Diego
>>
>> 2017-01-12 15:04 GMT-03:00 Diego Nadares :
>>
>>> Hi Daniel!
>>>
>>> Thanks for your answer.  The idea is to show only a few headers. In BYE
>>> works great. I'm removing and adding the following hdrs:
>>>
>>> *User-Agent: Kamailio. <---I will try what you said*
>>> *Supported:.*
>>> *Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, NOTIFY, INFO.*
>>> *Accept: application/sdp, application/gtd.*
>>>
>>> For example in following messages ( Kamailio is 172.16.213.38)
>>>
>>> #
>>> U 2017/01/12 14:51:10.593782 172.16.200.159:57270 -> 172.16.213.38:5060
>>> BYE sip:127.0.0.8:5060;line=sr-9879879879798** SIP/2.0.
>>> Via: SIP/2.0/UDP  172.16.200.159:5060;branch=z9hG4bK12B9605ED.
>>> From: xx ;tag=95E7E4A4-23F2.
>>> To: xxx ;tag=SDmmb7201-as0518eb07.
>>> Date: Thu, 12 Jan 2017 17:51:05 GMT.
>>> Call-ID: SDmmb7201-f5ded6cf4cd5d84736b088e39277e8db-c540dl1.
>>> User-Agent: Cisco-SIPGateway/IOS-12.x.
>>> Max-Forwards: 15.
>>> Route: .
>>> Timestamp: 1484243470.
>>> CSeq: 101 BYE.
>>> Reason: Q.850;cause=16.
>>> Content-Disposition: signal;handling=optional.
>>> Content-Type: application/gtd.
>>> Content-Length: 26.
>>> .
>>> .
>>> .
>>>
>>> #
>>> U 2017/01/12 14:51:10.64716

[SR-Users] Get ip from contact on redirect

2017-01-20 Thread Diego Nadares
Hi Guys,

Anybody knows how to get the ip of the new contact of the redirect? I need
it to update one xavp variable that contains the INVITE destination.

6 2017-01-20 12:44:55.138473 172.16.213.38 *172.16.208.121* SIP/SDP 85 Request:
INVITE sip:01152780776@172.16.208.121:5060 |
9 2017-01-20 12:44:55.142296 172.16.208.121 172.16.213.38 SIP 661 Status:
302 Moved temporarily |
10 2017-01-20 12:44:55.156268 172.16.213.38 172.16.208.121 SIP 423 Request:
ACK sip:01152780776@172.16.208.121:5060 |
16 2017-01-20 12:44:55.293349 172.16.213.38 *172.16.208.111* SIP/SDP
95 Request:
INVITE sip:1152780776@172.16.208.111:5060;user=phone |

My cfg:

# Manage failure routing cases
failure_route[MANAGE_FAILURE] {


if (t_check_status("302")) {
 xlog("Got a 302 - redirecting");
 get_redirects("*:1");
* $xavp(ip_b[$avp(current_route)]=>name) =
"172.16.208.111";#Hardcoded for testing*
 xlog("Got a 302 - redirecting $hdr(Contact)");
 route(RELAY);
 #t_relay();
 }

Thanks in advance.

Diego.
___
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] Get ip from contact on redirect

2017-01-20 Thread Diego Nadares
Thanks Daniel. It was very useful but I had to do the transformation in two
parts maybe because I'm very new with this.

Is correct like this?

if (t_check_status("302")) {
 #New contact is ;q=0.5,;q=0.25;
 $var(redirect_uri) = $(T_rpl($ct){nameaddr.uri});
 xlog("Got a 302 - redirecting to
$(var(redirect_uri){uri.host})" );
 get_redirects("*:1");
 $xavp(ip_b[$avp(current_route)]=>name)
=  $(var(redirect_uri){uri.host});
 xlog("Got a 302 - redirecting $hdr(Contact)");
 route(RELAY);
 #t_relay();
 }

 Is there a way to do it in one line?

Thanks again!

Diego

2017-01-20 13:16 GMT-03:00 Daniel Tryba :

> On Fri, Jan 20, 2017 at 05:11:32PM +0100, Daniel Tryba wrote:
> > The host part of this contact is: $(T_rpl($ct){nameaddr.uri});
>
> Which is not correct, {uri.host} should to the job (according to
> https://www.kamailio.org/wiki/cookbooks/4.1.x/transformations#urihost
> )
>
> ___
> 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


[SR-Users] mhomed opened sockets

2017-01-25 Thread Diego Nadares
Hi Guys,

We have two network interfaces. One public and one private. We had enabled
mhomed and works great BUT if we do a netstat -naup | grep 5060 we see that
some sockets keeps opened also when the call is finished. The source port
in netstat it's not 5060 so I suppose that kamailio use another one for
something else.

Is this the right behavior? How long does this sockets remain opened? Are
we missing something in our cfg?

6 2017-01-25 15:52:04.986651 172.16.213.38 172.16.200.159 SIP/SDP 146 Request:
INVITE sip:xxx@172.16.200.159:5060
34 2017-01-25 15:52:19.636895 172.16.213.38 172.16.200.159 SIP 716 Request:
ACK sip:xxx@172.16.200.159:5060 |
37 2017-01-25 15:54:38.947831 172.16.208.111 172.16.213.38 SIP 736 Request:
BYE sip:127.0.0.8:5060;line=sr-987jhlk* |
40 2017-01-25 15:54:38.950899 172.16.213.38 172.16.200.159 SIP 660 Request:
BYE sip:172.16.208.111:5060 |

[root@dwrfsd01 kamailio]# netstat -naup | grep 5060
udp0  0 172.16.213.38:*56086* 
172.16.200.159:5060 ESTABLISHED 17015/kamailio
udp0  0 172.16.213.38:5060  0.0.0.0:*
17006/kamailio
udp0  0 172.16.213.38:*41971* 
172.16.200.159:5060 ESTABLISHED 17051/kamailio
udp0  0 172.16.213.38:*54651* 
172.16.200.159:5060 ESTABLISHED 17008/kamailio

Thanks in advance!

Diego.
___
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] mhomed opened sockets

2017-01-26 Thread Diego Nadares
Hi list,

Any help on this?

Cheers.

Diego.



2017-01-25 16:29 GMT-03:00 Diego Nadares :

> Hi Guys,
>
> We have two network interfaces. One public and one private. We had enabled
> mhomed and works great BUT if we do a netstat -naup | grep 5060 we see that
> some sockets keeps opened also when the call is finished. The source port
> in netstat it's not 5060 so I suppose that kamailio use another one for
> something else.
>
> Is this the right behavior? How long does this sockets remain opened? Are
> we missing something in our cfg?
>
> 6 2017-01-25 15:52:04.986651 172.16.213.38 172.16.200.159 SIP/SDP 146 Request:
> INVITE sip:xxx@172.16.200.159:5060
> 34 2017-01-25 15:52:19.636895 172.16.213.38 172.16.200.159 SIP 716 Request:
> ACK sip:xxx@172.16.200.159:5060 |
> 37 2017-01-25 15:54:38.947831 172.16.208.111 172.16.213.38 SIP 736 Request:
> BYE sip:127.0.0.8:5060;line=sr-987jhlk* |
> 40 2017-01-25 15:54:38.950899 172.16.213.38 172.16.200.159 SIP 660 Request:
> BYE sip:172.16.208.111:5060 |
>
> [root@dwrfsd01 kamailio]# netstat -naup | grep 5060
> udp0  0 172.16.213.38:*56086* <http://172.16.213.38:56086>
>   172.16.200.159:5060 ESTABLISHED 17015/kamailio
> udp0  0 172.16.213.38:5060  0.0.0.0:*
>   17006/kamailio
> udp0  0 172.16.213.38:*41971* <http://172.16.213.38:41971>
>   172.16.200.159:5060 ESTABLISHED 17051/kamailio
> udp0  0 172.16.213.38:*54651* <http://172.16.213.38:54651>
>   172.16.200.159:5060 ESTABLISHED 17008/kamailio
>
> Thanks in advance!
>
> Diego.
>
___
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] mhomed opened sockets

2017-01-29 Thread Diego Nadares
Hi Daniel,

Thanks for your answer. My question was more related to why kamailio opens
those extra sockets also when it's not sending any data. Is that the normal
behavior?

You are right, i will read netstat's manual for how long and why keeps
those sockets opened.

Thanks again!

Diego

El vie, 27 de ene. de 2017 a las 05:14, Daniel-Constantin Mierla <
mico...@gmail.com> escribió:

> Hello,
>
> I am not sure what ESTABLISHED is meant by netstat for UDP sockets,
> because there is no connection defined for UDP (datagram socket is kind of
> shoot and forget) -- maybe it track that there was some traffic and
> remembers that for a while. Perhaps reading the manual of netstat will help
> to understand better.
>
> Cheers,
> Daniel
>
> On 26/01/2017 22:03, Diego Nadares wrote:
>
> Hi list,
>
> Any help on this?
>
> Cheers.
>
> Diego.
>
>
>
> 2017-01-25 16:29 GMT-03:00 Diego Nadares :
>
> Hi Guys,
>
> We have two network interfaces. One public and one private. We had enabled
> mhomed and works great BUT if we do a netstat -naup | grep 5060 we see that
> some sockets keeps opened also when the call is finished. The source port
> in netstat it's not 5060 so I suppose that kamailio use another one for
> something else.
>
> Is this the right behavior? How long does this sockets remain opened? Are
> we missing something in our cfg?
>
> 6 2017-01-25 15:52:04.986651 172.16.213.38 172.16.200.159 SIP/SDP 146 Request:
> INVITE sip:xxx@172.16.200.159:5060
> 34 2017-01-25 15:52:19.636895 172.16.213.38 172.16.200.159 SIP 716 Request:
> ACK sip:xxx@172.16.200.159:5060 |
> 37 2017-01-25 15:54:38.947831 172.16.208.111 172.16.213.38 SIP 736 Request:
> BYE sip:127.0.0.8:5060;line=sr-987jhlk* |
> 40 2017-01-25 15:54:38.950899 172.16.213.38 172.16.200.159 SIP 660 Request:
> BYE sip:172.16.208.111:5060 |
>
> [root@dwrfsd01 kamailio]# netstat -naup | grep 5060
> udp0  0 172.16.213.38:*56086* <http://172.16.213.38:56086>
>   172.16.200.159:5060 ESTABLISHED 17015/kamailio
> udp0  0 172.16.213.38:5060  0.0.0.0:*
>   17006/kamailio
> udp0  0 172.16.213.38:*41971* <http://172.16.213.38:41971>
>   172.16.200.159:5060 ESTABLISHED 17051/kamailio
> udp0  0 172.16.213.38:*54651* <http://172.16.213.38:54651>
>   172.16.200.159:5060 ESTABLISHED 17008/kamailio
>
> Thanks in advance!
>
> Diego.
>
>
>
>
> ___
> 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 Mierlawww.twitter.com/miconda -- www.linkedin.com/in/miconda
> Kamailio Advanced Training - Mar 6-8 (Europe) and Mar 20-22 (USA) - 
> www.asipto.com
> Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.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


[SR-Users] Os on virtual machine

2017-02-01 Thread Diego Nadares
Hi guys,

We are using vmware to run kamailio. The thing is that they give us support
only if we install Red Hat.

Did you test kamailio on RH? Any issues or things to have in mind?

What linux dist do you recommend?

Thanks!

Diego.
___
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] Os on virtual machine

2017-02-04 Thread Diego Nadares
Thank you all, guys!

Diego.

El El jue, 2 de feb. de 2017 a las 06:42, Daniel-Constantin Mierla <
mico...@gmail.com> escribió:

> Hello,
>
>
> On 01/02/2017 23:05, Diego Nadares wrote:
> > Hi guys,
> >
> > We are using vmware to run kamailio. The thing is that they give us
> > support only if we install Red Hat.
> >
> > Did you test kamailio on RH? Any issues or things to have in mind?
> >
> > What linux dist do you recommend?
> >
> >
> there should be no problem running kamailio on RH/CentOS. One thing to
> be careful about is selinux, it sets some os limits/restrictions that
> can get you in trouble if you have lot of traffic or kamailio workers
> (e.g., kimits regarding the number of connection allowed to be opened in
> very short time).
>
> Cheers,
> Daniel
>
> --
> Daniel-Constantin Mierla
> www.twitter.com/miconda -- www.linkedin.com/in/miconda
> Kamailio Advanced Training - Mar 6-8 (Europe) and Mar 20-22 (USA) -
> www.asipto.com
> Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.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


[SR-Users] Cdr on shutdown

2017-03-07 Thread Diego Nadares
Hi Guys,


Is it possible to generate cdrs or to save dialogs to db when kamailio
receives a kill signal from terminal?

Thanks in advance.

Diego
___
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] Cdr on shutdown

2017-03-07 Thread Diego Nadares
Hi Daniel! Thanks for your answer.

Sorry, i didn't provide enough data for what I need. I'm using kamailio as
a statefull proxy and  I all ready have dialog module working too but with
no database.

Today I started testing dialog with db_mode = 3 (shutdown). The thing is
that when I kill kamailio from terminal, the dialog module does not save
any data. It only works when I execute kamctl stop.


Cheers,

Diego.



2017-03-07 10:49 GMT-03:00 Daniel Tryba :

> On Tue, Mar 07, 2017 at 10:34:05AM -0300, Diego Nadares wrote:
> > Is it possible to generate cdrs or to save dialogs to db when kamailio
> > receives a kill signal from terminal?
>
> Killing kamailio doesn't end running calls. So if you restart kamailio
> before a BYE, accounting will be correct on teardown of the calls.
>
> The dialog module can store state in a database, but if your are
> specifically looking for something that only happens when kamailio is
> killed without a database backend, you'd have to do some dumping of
> state before the kill is processed and I don't know if that is possible.
>
>
> ___
> 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] Cdr on shutdown

2017-03-16 Thread Diego Nadares
Thanks guys. I'm using db_mode = 1 now. It works great with mysql with
myisam tables.

Cheers.

Diego

2017-03-08 6:30 GMT-03:00 Daniel Tryba :

> On Tue, Mar 07, 2017 at 11:06:20AM -0300, Diego Nadares wrote:
> > Today I started testing dialog with db_mode = 3 (shutdown). The thing is
> > that when I kill kamailio from terminal, the dialog module does not save
> > any data. It only works when I execute kamctl stop.
>
> You could ofcourse look at dbmode 1 (2 is kind of nonsenseical for your
> purpose (either you miss calls started in the update interval and
> shutdown or the interval is so short that you have small bursts)).
>
> Or write start and end of dialogs to a log via the event_routes.
>
>
> ___
> 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


[SR-Users] f_malloc WARNINGS in syslog

2017-03-16 Thread Diego Nadares
Hi Guys,

I'm seeing a lot of warnings in my syslog. Is this normal? Or maybe I am
doing something wrong in my cfg?


Mar 16 17:11:47 dwsipm03 ./kamailio[26226]: WARNING: 
[mem/f_malloc.c:444]: fm_malloc(): fm_malloc(0x7f68e5199010, 8) called from
nathelper: nathelper.c: nh_timer(2078)
Mar 16 17:11:47 dwsipm03 ./kamailio[26226]: WARNING: 
[mem/f_malloc.c:527]: fm_malloc(): fm_malloc(0x7f68e5199010, 8) returns
address 0x7f68e52a2d50
Mar 16 17:11:47 dwsipm03 ./kamailio[26226]: WARNING: 
[mem/f_malloc.c:588]: fm_free(): fm_free(0x7f68e5199010, 0x7f68e52a2d50),
called from nathelper: nathelper.c: nh_timer()
Mar 16 17:11:47 dwsipm03 ./kamailio[26226]: WARNING: 
[mem/f_malloc.c:607]: fm_free(): fm_free: freeing block alloc'ed from
nathelper: nathelper.c: nh_timer(2078)
.
Mar 16 17:15:44 dwsipm03 ./kamailio[26210]: WARNING: 
[mem/f_malloc.c:607]: fm_free(): fm_free: freeing block alloc'ed from core:
xavp.c: xavp_new_value(94)
Mar 16 17:15:44 dwsipm03 ./kamailio[26210]: WARNING: 
[mem/f_malloc.c:588]: fm_free(): fm_free(0x7f68d9d51000, 0x7f68da069ca8),
called from tm: h_table.c: free_cell_helper(246)
Mar 16 17:15:44 dwsipm03 ./kamailio[26210]: WARNING: 
[mem/f_malloc.c:607]: fm_free(): fm_free: freeing block alloc'ed from tm:
h_table.c: build_cell(317)
Mar 16 17:15:44 dwsipm03 ./kamailio[26210]: WARNING: 
[mem/f_malloc.c:588]: fm_free(): fm_free(0x7f68d9d51000, 0x7f68da031f00),
called from tm: h_table.c: free_cell_helper(150)



Thanks in advance.

Diego
___
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] f_malloc WARNINGS in syslog

2017-03-17 Thread Diego Nadares
Thanks Daniel!

2017-03-17 4:22 GMT-03:00 Daniel-Constantin Mierla :

> Hello,
>
> set memdbg and memlog parameters to a higher value than debug parameter.
> The messages are useful only if you troubleshoot memory operations.
>
> Cheers,
> Daniel
>
> On 16/03/2017 21:16, Diego Nadares wrote:
>
> Hi Guys,
>
> I'm seeing a lot of warnings in my syslog. Is this normal? Or maybe I am
> doing something wrong in my cfg?
>
> 
> Mar 16 17:11:47 dwsipm03 ./kamailio[26226]: WARNING: 
> [mem/f_malloc.c:444]: fm_malloc(): fm_malloc(0x7f68e5199010, 8) called from
> nathelper: nathelper.c: nh_timer(2078)
> Mar 16 17:11:47 dwsipm03 ./kamailio[26226]: WARNING: 
> [mem/f_malloc.c:527]: fm_malloc(): fm_malloc(0x7f68e5199010, 8) returns
> address 0x7f68e52a2d50
> Mar 16 17:11:47 dwsipm03 ./kamailio[26226]: WARNING: 
> [mem/f_malloc.c:588]: fm_free(): fm_free(0x7f68e5199010, 0x7f68e52a2d50),
> called from nathelper: nathelper.c: nh_timer()
> Mar 16 17:11:47 dwsipm03 ./kamailio[26226]: WARNING: 
> [mem/f_malloc.c:607]: fm_free(): fm_free: freeing block alloc'ed from
> nathelper: nathelper.c: nh_timer(2078)
> .
> Mar 16 17:15:44 dwsipm03 ./kamailio[26210]: WARNING: 
> [mem/f_malloc.c:607]: fm_free(): fm_free: freeing block alloc'ed from core:
> xavp.c: xavp_new_value(94)
> Mar 16 17:15:44 dwsipm03 ./kamailio[26210]: WARNING: 
> [mem/f_malloc.c:588]: fm_free(): fm_free(0x7f68d9d51000, 0x7f68da069ca8),
> called from tm: h_table.c: free_cell_helper(246)
> Mar 16 17:15:44 dwsipm03 ./kamailio[26210]: WARNING: 
> [mem/f_malloc.c:607]: fm_free(): fm_free: freeing block alloc'ed from tm:
> h_table.c: build_cell(317)
> Mar 16 17:15:44 dwsipm03 ./kamailio[26210]: WARNING: 
> [mem/f_malloc.c:588]: fm_free(): fm_free(0x7f68d9d51000, 0x7f68da031f00),
> called from tm: h_table.c: free_cell_helper(150)
> 
>
>
> Thanks in advance.
>
> Diego
>
>
> ___
> 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 Mierlawww.twitter.com/miconda -- www.linkedin.com/in/miconda
> Kamailio Advanced Training - Mar 6-8 (Europe) and Mar 20-22 (USA) - 
> www.asipto.com
> Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.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


[SR-Users] Generate extra cdr per dialog

2017-03-17 Thread Diego Nadares
Hi Guys,

I'm using acc module for accounting with the following conf:


modparam("acc", "cdr_enable", 1)
modparam("acc", "cdr_expired_dlg_enable", 1)
modparam("acc", "cdr_start_on_confirmed", 1)
modparam("acc", "cdr_facility", "LOG_LOCAL1")
modparam("acc", "cdr_end_id", "end_time_dt")
modparam("acc", "cdr_extra",
"sip_code=$rs;sip_reason=$rr;"
"hangup_src=$dlg_var(hangup_disposition);"

"prefix=$dlg_var(prefix);gos=$dlg_var(gos);endpoint_type=$dlg_var(endpoint_type);"
"ip_a=$dlg_var(ip_a);ip_b=$dlg_var(ip_b);"


It works fine. At the end of the call the cdr is generated ok.

BUT In MANAGE_FAILURE,  If the first call failed and if there are more
dests, we are generating a new call in the same dialog (Some of the dialog
vars like ip_a, ip_b can change for the new dest )

I would like to generate both cdrs, the one that failed and the new one
(with some dlg vars with new data).

if(rtjson_next_route() && t_check_status("503")) {
$avp(current_route) = $avp(current_route)+1;
t_on_branch("MANAGE_BRANCH");
t_on_failure("MANAGE_FAILURE");
route(RELAY);
exit;
}


Right now just the last call cdr is saved.

I all ready made this work with db_acc (transaction oriented) but I think
in my case it will be more reliable with cdr (dialog oriented).

Thanks in advance!

Diego.
___
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] Generate extra cdr per dialog

2017-03-18 Thread Diego Nadares
Sorry, Im reading that acc supports Multi Call-Legs accounting. That's
exactly what I need. I'll try with this first.

Thanks!

Diego.



2017-03-17 16:21 GMT-03:00 Diego Nadares :

> Hi Guys,
>
> I'm using acc module for accounting with the following conf:
>
> 
> modparam("acc", "cdr_enable", 1)
> modparam("acc", "cdr_expired_dlg_enable", 1)
> modparam("acc", "cdr_start_on_confirmed", 1)
> modparam("acc", "cdr_facility", "LOG_LOCAL1")
> modparam("acc", "cdr_end_id", "end_time_dt")
> modparam("acc", "cdr_extra",
> "sip_code=$rs;sip_reason=$rr;"
> "hangup_src=$dlg_var(hangup_disposition);"
>   "prefix=$dlg_var(prefix);gos=$dlg_var(gos);endpoint_type=$
> dlg_var(endpoint_type);"
> "ip_a=$dlg_var(ip_a);ip_b=$dlg_var(ip_b);"
> 
>
> It works fine. At the end of the call the cdr is generated ok.
>
> BUT In MANAGE_FAILURE,  If the first call failed and if there are more
> dests, we are generating a new call in the same dialog (Some of the dialog
> vars like ip_a, ip_b can change for the new dest )
>
> I would like to generate both cdrs, the one that failed and the new one
> (with some dlg vars with new data).
>
> if(rtjson_next_route() && t_check_status("503")) {
> $avp(current_route) = $avp(current_route)+1;
> t_on_branch("MANAGE_BRANCH");
> t_on_failure("MANAGE_FAILURE");
> route(RELAY);
> exit;
> }
>
>
> Right now just the last call cdr is saved.
>
> I all ready made this work with db_acc (transaction oriented) but I think
> in my case it will be more reliable with cdr (dialog oriented).
>
> Thanks in advance!
>
> Diego.
>
>
>
___
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] ACC - Cdr enabled

2017-03-20 Thread Diego Nadares
Hi guys,

I have configured to use cdr with extra fields

modparam("acc", "cdr_extra",
*"sip_code=$rs;sip_reason=$rr;"*
"hangup_src=$dlg_var(hangup_disposition);"
  "prefix=$dlg_var(prefix);gos=$dlg_var(gos);endpoint_type=$
dlg_var(endpoint_type);"
"ip_a=$dlg_var(ip_a);ip_b=$dlg_var(ip_b);"

Is this the right way to always save the hangup cause? Or is another better
way? Because, when call is finished with a bye both fields are empty.

The other thing is that I need to save, start_time and end_time with
seconds.microseconds (1490013250.601707). Is this possible?

Thanks!

Diego
___
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] ACC - Cdr enabled

2017-03-20 Thread Diego Nadares
I figured out that I can get start_time and end_time from dlg_vars.

The only thing left is hangup cause. Any help with this?

Thanks!

2017-03-20 9:46 GMT-03:00 Diego Nadares :

> Hi guys,
>
> I have configured to use cdr with extra fields
>
> modparam("acc", "cdr_extra",
> *"sip_code=$rs;sip_reason=$rr;"*
> "hangup_src=$dlg_var(hangup_disposition);"
>   "prefix=$dlg_var(prefix);gos=$dlg_var(gos);endpoint_type=$dl
> g_var(endpoint_type);"
> "ip_a=$dlg_var(ip_a);ip_b=$dlg_var(ip_b);"
>
> Is this the right way to always save the hangup cause? Or is another
> better way? Because, when call is finished with a bye both fields are empty.
>
> The other thing is that I need to save, start_time and end_time with
> seconds.microseconds (1490013250.601707). Is this possible?
>
> Thanks!
>
> Diego
>
>
___
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] ACC - Cdr enabled

2017-03-20 Thread Diego Nadares
Hi,

Sorry, . I meant the sip_code/sip_reason of the message that hangup the
call.

For example:

*** 1. row ***
   id: 160
   method: BYE
 from_tag: 1
   to_tag: 56
   callid: 1-2397@172.16.213.21
 sip_code: 200
   sip_reason: OK

*** 1. row ***
   id: 61975
   method: INVITE
 from_tag: 40511
   to_tag:
   callid: 40511-2397@172.16.213.21
 sip_code: 503
   sip_reason: Service Unavailable

thanks,

Diego

2017-03-20 10:23 GMT-03:00 Kordován Szabolcs :

> Hi,
>
> How do you mean 'hangup cause'? ISUP cause call?
> If the server supports isup cause it can insert an additional header (eg.
> X-Asterisk-HangupCauseCode) but it is not mandatory. I think you have to
> know the name of the header which contains the cause code and you can read
> it.
>
> if (is_present_hf("X-Asterisk-HangupCauseCode")) xlogl("LOG_LOCAL0",
> "L_ALERT", $hdr(X-Asterisk-HangupCauseCode));
>
> Regards,
> Szabolcs
>
> 2017-03-20 14:03 GMT+01:00 Diego Nadares :
>
>> I figured out that I can get start_time and end_time from dlg_vars.
>>
>> The only thing left is hangup cause. Any help with this?
>>
>> Thanks!
>>
>> 2017-03-20 9:46 GMT-03:00 Diego Nadares :
>>
>>> Hi guys,
>>>
>>> I have configured to use cdr with extra fields
>>>
>>> modparam("acc", "cdr_extra",
>>> *"sip_code=$rs;sip_reason=$rr;"*
>>> "hangup_src=$dlg_var(hangup_disposition);"
>>>   "prefix=$dlg_var(prefix);gos=$dlg_var(gos);endpoint_type=$dl
>>> g_var(endpoint_type);"
>>> "ip_a=$dlg_var(ip_a);ip_b=$dlg_var(ip_b);"
>>>
>>> Is this the right way to always save the hangup cause? Or is another
>>> better way? Because, when call is finished with a bye both fields are empty.
>>>
>>> The other thing is that I need to save, start_time and end_time with
>>> seconds.microseconds (1490013250.601707). Is this possible?
>>>
>>> Thanks!
>>>
>>> Diego
>>>
>>>
>>
>>
>> ___
>> 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
>
>
___
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] ACC - Cdr enabled

2017-03-20 Thread Diego Nadares
Hi, I'm trying to avoid that. I would like to save all what I need just in
acc_cdr table. Is that posible?

2017-03-20 11:39 GMT-03:00 Kordován Szabolcs :

> Hi,
>
> In the table acc you can see what you need. You can use callid to connect
> the rows.
>
> Regards,
> Szabolcs
>
> 2017-03-20 14:45 GMT+01:00 Diego Nadares :
>
>> Hi,
>>
>> Sorry, . I meant the sip_code/sip_reason of the message that hangup the
>> call.
>>
>> For example:
>>
>> *** 1. row ***
>>id: 160
>>method: BYE
>>  from_tag: 1
>>to_tag: 56
>>callid: 1-2397@172.16.213.21
>>  sip_code: 200
>>sip_reason: OK
>>
>> *** 1. row ***
>>id: 61975
>>method: INVITE
>>  from_tag: 40511
>>to_tag:
>>callid: 40511-2397@172.16.213.21
>>  sip_code: 503
>>sip_reason: Service Unavailable
>>
>> thanks,
>>
>> Diego
>>
>> 2017-03-20 10:23 GMT-03:00 Kordován Szabolcs :
>>
>>> Hi,
>>>
>>> How do you mean 'hangup cause'? ISUP cause call?
>>> If the server supports isup cause it can insert an additional header
>>> (eg. X-Asterisk-HangupCauseCode) but it is not mandatory. I think you
>>> have to know the name of the header which contains the cause code and you
>>> can read it.
>>>
>>> if (is_present_hf("X-Asterisk-HangupCauseCode")) xlogl("LOG_LOCAL0",
>>> "L_ALERT", $hdr(X-Asterisk-HangupCauseCode));
>>>
>>> Regards,
>>> Szabolcs
>>>
>>> 2017-03-20 14:03 GMT+01:00 Diego Nadares :
>>>
>>>> I figured out that I can get start_time and end_time from dlg_vars.
>>>>
>>>> The only thing left is hangup cause. Any help with this?
>>>>
>>>> Thanks!
>>>>
>>>> 2017-03-20 9:46 GMT-03:00 Diego Nadares :
>>>>
>>>>> Hi guys,
>>>>>
>>>>> I have configured to use cdr with extra fields
>>>>>
>>>>> modparam("acc", "cdr_extra",
>>>>> *"sip_code=$rs;sip_reason=$rr;"*
>>>>> "hangup_src=$dlg_var(hangup_disposition);"
>>>>>   "prefix=$dlg_var(prefix);gos=$dlg_var(gos);endpoint_type=$dl
>>>>> g_var(endpoint_type);"
>>>>> "ip_a=$dlg_var(ip_a);ip_b=$dlg_var(ip_b);"
>>>>>
>>>>> Is this the right way to always save the hangup cause? Or is another
>>>>> better way? Because, when call is finished with a bye both fields are 
>>>>> empty.
>>>>>
>>>>> The other thing is that I need to save, start_time and end_time with
>>>>> seconds.microseconds (1490013250.601707). Is this possible?
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Diego
>>>>>
>>>>>
>>>>
>>>>
>>>> ___
>>>> 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
>>>
>>>
>>
>> ___
>> 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
>
>
___
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] No cdr after Kamailio 5.0 restart

2017-03-20 Thread Diego Nadares
Hi Lucian,

I made a few changes like you and I think it's working. Loads dialogs and
generate cdr. It needs more testing. The function  cdr_on_load it's copy
and paste to avoid touching those params in on_create. A lot of improve is
needed.

diff --git a/modules/dialog/dialog.c b/modules/dialog/*dialog.c*
index ceaf08a..59210e8 100644
--- a/modules/dialog/dialog.c
+++ b/modules/dialog/dialog.c
@@ -692,7 +692,7 @@ static int mod_init(void)
LM_ERR("failed to initialize the DB support\n");
return -1;
}
-   run_load_callbacks();
+   //run_load_callbacks();
}

destroy_dlg_callbacks( DLGCB_LOADED );



diff --git a/modules/dialog/dlg_db_handler.c b/modules/dialog/
*dlg_db_handler.c*
index e27f8b2..22d0f04 100644
--- a/modules/dialog/dlg_db_handler.c
+++ b/modules/dialog/dlg_db_handler.c
@@ -173,6 +173,7 @@ int init_dlg_db(const str *db_url, int dlg_hash_size ,
int db_update_period, int
LM_ERR("unable to load the dialog data\n");
return -1;
}
+   run_load_callbacks();
}
dialog_dbf.close(dialog_db_handle);
dialog_db_handle = 0;




diff --git a/modules/acc/acc_cdr.c b/modules/acc/*acc_cdr.c*
index 73bdd45..81ad640 100644
--- a/modules/acc/acc_cdr.c
+++ b/modules/acc/acc_cdr.c
@@ -733,11 +733,79 @@ static void cdr_on_destroy( struct dlg_cell* dialog,
 LM_DBG("dialog '%p' destroyed!\n", dialog);
 }

+/* callback for loading a dialog from db. */
+static void cdr_on_load( struct dlg_cell* dialog,
+   int type,
+   struct dlg_cb_params* params)
+{
+
+LM_ERR("ON LOAD\n");
+if( !dialog)
+{
+LM_ERR( "invalid dialog\n!");
+return;
+}
+
+if( cdr_enable == 0)
+{
+return;
+}
+
+if( dlgb.register_dlgcb( dialog, DLGCB_CONFIRMED, cdr_on_start, 0, 0)
!= 0)
+{
+LM_ERR("can't register create dialog CONFIRM callback\n");
+   return;
+}
+
+if(_acc_cdr_on_failed==1) {
+   if( dlgb.register_dlgcb( dialog, DLGCB_FAILED, cdr_on_failed,
0, 0) != 0)
+   {
+   LM_ERR("can't register create dialog FAILED
callback\n");
+   return;
+   }
+}
+
+if( dlgb.register_dlgcb( dialog, DLGCB_TERMINATED, cdr_on_end, 0, 0)
!= 0)
+{
+LM_ERR("can't register create dialog TERMINATED callback\n");
+return;
+}
+
+if( dlgb.register_dlgcb( dialog, DLGCB_TERMINATED_CONFIRMED,
cdr_on_end_confirmed, 0, 0) != 0)
+{
+LM_ERR("can't register create dialog TERMINATED CONFIRMED
callback\n");
+return;
+}
+
+if( dlgb.register_dlgcb( dialog, DLGCB_EXPIRED, cdr_on_expired, 0, 0)
!= 0)
+{
+LM_ERR("can't register create dialog EXPIRED callback\n");
+return;
+}
+
+if( dlgb.register_dlgcb( dialog, DLGCB_DESTROY, cdr_on_destroy, 0, 0)
!= 0)
+{
+LM_ERR("can't register create dialog DESTROY callback\n");
+return;
+}
+
+LM_DBG("dialog '%p' created!", dialog);
+
+if( set_start_time( dialog) != 0)
+{
+LM_ERR( "failed to set start time");
+return;
+}
+}
+
+
 /* callback for the creation of a dialog. */
 static void cdr_on_create( struct dlg_cell* dialog,
int type,
struct dlg_cb_params* params)
 {
+
+LM_ERR("ON CREATE\n");
 if( !dialog || !params || !params->req)
 {
 LM_ERR( "invalid values\n!");
@@ -852,13 +920,19 @@ int init_cdr_generation( void)
 LM_ERR("can't load dialog API\n");
 return -1;
 }
-
-if( dlgb.register_dlgcb( 0, DLGCB_CREATED, cdr_on_create, 0, 0) != 0)
+//Loaded from db
+if( dlgb.register_dlgcb( 0, DLGCB_LOADED, cdr_on_load, 0, 0) != 0)
 {
 LM_ERR("can't register create callback\n");
 return -1;
 }

+if( dlgb.register_dlgcb( 0, DLGCB_CREATED, cdr_on_create, 0, 0) != 0)
+{
+   LM_ERR("can't register create callback\n");
+   return -1;
+}
+
 return 0;
 }



if( cdr_enable == 0)
{
return;
}

if( dlgb.register_dlgcb( dialog, DLGCB_CONFIRMED, cdr_on_start, 0, 0)
!= 0)
{
LM_ERR("can't register create dialog CONFIRM callback\n");
return;
}



Diego.



2017-03-20 10:06 GMT-03:00 Kordován Szabolcs :

> Hi All,
>
> I have tired your patch but it dosen't work. No any changes. :(
>
> Regards,
> Szabolcs
>
> 2017-03-16 15:36 GMT+01:00 Lucian Balaceanu :
>
>> Hello all,
>>
>> Just created the pull request: https://github.com/kamailio/ka
>> mailio/pull/1036 in relation to this problem with the sketch of a
>> solution.
>>
>> Any input is appreciated,
>> Lucian
>>
>>
>> On 15.03.2017 15:17, Daniel-Constantin Mierla wrote:
>>
>> Hello,
>>
>> ok, good to know is someone tackling it.
>>
>> Thanks,
>> Daniel
>>
>> On 15/03/2017 12:14, Pawel K

Re: [SR-Users] No cdr after Kamailio 5.0 restart

2017-03-20 Thread Diego Nadares
I didn't mention that I did this on kamailio 4.4.

Cheers,

Diego

2017-03-20 16:38 GMT-03:00 Diego Nadares :

> Hi Lucian,
>
> I made a few changes like you and I think it's working. Loads dialogs and
> generate cdr. It needs more testing. The function  cdr_on_load it's copy
> and paste to avoid touching those params in on_create. A lot of improve is
> needed.
>
> diff --git a/modules/dialog/dialog.c b/modules/dialog/*dialog.c*
> index ceaf08a..59210e8 100644
> --- a/modules/dialog/dialog.c
> +++ b/modules/dialog/dialog.c
> @@ -692,7 +692,7 @@ static int mod_init(void)
> LM_ERR("failed to initialize the DB support\n");
> return -1;
> }
> -   run_load_callbacks();
> +   //run_load_callbacks();
> }
>
> destroy_dlg_callbacks( DLGCB_LOADED );
>
> 
>
> diff --git a/modules/dialog/dlg_db_handler.c b/modules/dialog/
> *dlg_db_handler.c*
> index e27f8b2..22d0f04 100644
> --- a/modules/dialog/dlg_db_handler.c
> +++ b/modules/dialog/dlg_db_handler.c
> @@ -173,6 +173,7 @@ int init_dlg_db(const str *db_url, int dlg_hash_size ,
> int db_update_period, int
> LM_ERR("unable to load the dialog data\n");
> return -1;
> }
> +   run_load_callbacks();
> }
> dialog_dbf.close(dialog_db_handle);
> dialog_db_handle = 0;
>
>
> 
>
> diff --git a/modules/acc/acc_cdr.c b/modules/acc/*acc_cdr.c*
> index 73bdd45..81ad640 100644
> --- a/modules/acc/acc_cdr.c
> +++ b/modules/acc/acc_cdr.c
> @@ -733,11 +733,79 @@ static void cdr_on_destroy( struct dlg_cell* dialog,
>  LM_DBG("dialog '%p' destroyed!\n", dialog);
>  }
>
> +/* callback for loading a dialog from db. */
> +static void cdr_on_load( struct dlg_cell* dialog,
> +   int type,
> +   struct dlg_cb_params* params)
> +{
> +
> +LM_ERR("ON LOAD\n");
> +if( !dialog)
> +{
> +LM_ERR( "invalid dialog\n!");
> +return;
> +}
> +
> +if( cdr_enable == 0)
> +{
> +return;
> +}
> +
> +if( dlgb.register_dlgcb( dialog, DLGCB_CONFIRMED, cdr_on_start, 0, 0)
> != 0)
> +{
> +LM_ERR("can't register create dialog CONFIRM callback\n");
> +   return;
> +}
> +
> +if(_acc_cdr_on_failed==1) {
> +   if( dlgb.register_dlgcb( dialog, DLGCB_FAILED, cdr_on_failed,
> 0, 0) != 0)
> +   {
> +   LM_ERR("can't register create dialog FAILED
> callback\n");
> +   return;
> +   }
> +}
> +
> +if( dlgb.register_dlgcb( dialog, DLGCB_TERMINATED, cdr_on_end, 0, 0)
> != 0)
> +{
> +LM_ERR("can't register create dialog TERMINATED callback\n");
> +return;
> +}
> +
> +if( dlgb.register_dlgcb( dialog, DLGCB_TERMINATED_CONFIRMED,
> cdr_on_end_confirmed, 0, 0) != 0)
> +{
> +LM_ERR("can't register create dialog TERMINATED CONFIRMED
> callback\n");
> +return;
> +}
> +
> +if( dlgb.register_dlgcb( dialog, DLGCB_EXPIRED, cdr_on_expired, 0, 0)
> != 0)
> +{
> +LM_ERR("can't register create dialog EXPIRED callback\n");
> +return;
> +}
> +
> +if( dlgb.register_dlgcb( dialog, DLGCB_DESTROY, cdr_on_destroy, 0, 0)
> != 0)
> +{
> +LM_ERR("can't register create dialog DESTROY callback\n");
> +return;
> +}
> +
> +LM_DBG("dialog '%p' created!", dialog);
> +
> +if( set_start_time( dialog) != 0)
> +{
> +LM_ERR( "failed to set start time");
> +return;
> +}
> +}
> +
> +
>  /* callback for the creation of a dialog. */
>  static void cdr_on_create( struct dlg_cell* dialog,
> int type,
> struct dlg_cb_params* params)
>  {
> +
> +LM_ERR("ON CREATE\n");
>  if( !dialog || !params || !params->req)
>  {
>  LM_ERR( "invalid values\n!");
> @@ -852,13 +920,19 @@ int init_cdr_generation( void)
>  LM_ERR("can't load dialog API\n");
>  return -1;
>  }
> -
> -if( dlgb.register_dlgcb( 0, DLGCB_CREATED, cdr_on_create, 0, 0) != 0)
> +//Loaded from db
> +if( dlgb.register_dlgcb( 0, DLGCB_LOADED, cdr_on_load, 0, 0) != 0)
>  {
>  LM_ERR("can't register 

Re: [SR-Users] No cdr after Kamailio 5.0 restart

2017-03-21 Thread Diego Nadares
Hi Daniel,

I'm sorry. I don't know how to make a pull request. I can google a howto
but maybe anyone here has one.

Thanks.

Diego

2017-03-21 9:32 GMT-03:00 Daniel-Constantin Mierla :

> If you want to propose a patch to be merged into Kamailio, do a pull
> request via github.com/kamailio/kamailio -- it makes it easier to review
> as well as have the patch compiled by Travic CI before merging, so we can
> spot the basic conflicts if any. The patch has to be for master branch, to
> be merged directly.
>
> On Mon, Mar 20, 2017 at 8:40 PM, Diego Nadares  wrote:
>
>> I didn't mention that I did this on kamailio 4.4.
>>
>> Cheers,
>>
>> Diego
>>
>> 2017-03-20 16:38 GMT-03:00 Diego Nadares :
>>
>>> Hi Lucian,
>>>
>>> I made a few changes like you and I think it's working. Loads dialogs
>>> and generate cdr. It needs more testing. The function  cdr_on_load it's
>>> copy and paste to avoid touching those params in on_create. A lot of
>>> improve is needed.
>>>
>>> diff --git a/modules/dialog/dialog.c b/modules/dialog/*dialog.c*
>>> index ceaf08a..59210e8 100644
>>> --- a/modules/dialog/dialog.c
>>> +++ b/modules/dialog/dialog.c
>>> @@ -692,7 +692,7 @@ static int mod_init(void)
>>> LM_ERR("failed to initialize the DB support\n");
>>> return -1;
>>> }
>>> -   run_load_callbacks();
>>> +   //run_load_callbacks();
>>> }
>>>
>>> destroy_dlg_callbacks( DLGCB_LOADED );
>>>
>>> 
>>>
>>> diff --git a/modules/dialog/dlg_db_handler.c b/modules/dialog/
>>> *dlg_db_handler.c*
>>> index e27f8b2..22d0f04 100644
>>> --- a/modules/dialog/dlg_db_handler.c
>>> +++ b/modules/dialog/dlg_db_handler.c
>>> @@ -173,6 +173,7 @@ int init_dlg_db(const str *db_url, int dlg_hash_size
>>> , int db_update_period, int
>>> LM_ERR("unable to load the dialog data\n");
>>> return -1;
>>> }
>>> +   run_load_callbacks();
>>> }
>>> dialog_dbf.close(dialog_db_handle);
>>> dialog_db_handle = 0;
>>>
>>>
>>> 
>>>
>>> diff --git a/modules/acc/acc_cdr.c b/modules/acc/*acc_cdr.c*
>>> index 73bdd45..81ad640 100644
>>> --- a/modules/acc/acc_cdr.c
>>> +++ b/modules/acc/acc_cdr.c
>>> @@ -733,11 +733,79 @@ static void cdr_on_destroy( struct dlg_cell*
>>> dialog,
>>>  LM_DBG("dialog '%p' destroyed!\n", dialog);
>>>  }
>>>
>>> +/* callback for loading a dialog from db. */
>>> +static void cdr_on_load( struct dlg_cell* dialog,
>>> +   int type,
>>> +   struct dlg_cb_params* params)
>>> +{
>>> +
>>> +LM_ERR("ON LOAD\n");
>>> +if( !dialog)
>>> +{
>>> +LM_ERR( "invalid dialog\n!");
>>> +return;
>>> +}
>>> +
>>> +if( cdr_enable == 0)
>>> +{
>>> +return;
>>> +}
>>> +
>>> +if( dlgb.register_dlgcb( dialog, DLGCB_CONFIRMED, cdr_on_start, 0,
>>> 0) != 0)
>>> +{
>>> +LM_ERR("can't register create dialog CONFIRM callback\n");
>>> +   return;
>>> +}
>>> +
>>> +if(_acc_cdr_on_failed==1) {
>>> +   if( dlgb.register_dlgcb( dialog, DLGCB_FAILED,
>>> cdr_on_failed, 0, 0) != 0)
>>> +   {
>>> +   LM_ERR("can't register create dialog FAILED
>>> callback\n");
>>> +   return;
>>> +   }
>>> +}
>>> +
>>> +if( dlgb.register_dlgcb( dialog, DLGCB_TERMINATED, cdr_on_end, 0,
>>> 0) != 0)
>>> +{
>>> +LM_ERR("can't register create dialog TERMINATED callback\n");
>>> +return;
>>> +}
>>> +
>>> +if( dlgb.register_dlgcb( dialog, DLGCB_TERMINATED_CONFIRMED,
>>> cdr_on_end_confirmed, 0, 0) != 0)
>>> +{
>>> +LM_ERR("can't register create dialog TERMINATED CONFIRMED
>>> callback\n");
>>> +return;
>>> +}
>>> +
>>> +if( dlgb.re

[SR-Users] Disable DNS

2017-04-08 Thread Diego Nadares
Hi Guys,

Is it possible to disable using of dns in kamailio?

The thing is that not all INVITES that arrives to the proxy comes with ip
172.16.205.25/PUB_IP in the ruri. Some gateways sends a string in ruri ->
@myproxysip and others sends @other.domain.com

Request-Line: INVITE sip:111@myproxysip:5060;user=phone SIP/2.0
Request-Line: INVITE sip:...@other.domain.com:5060;user=phone SIP/2.0

Sometimes, myproxysip is from a public ip and sometimes is from a private
ip. So, it's difficult to know to which of kamailio's interfaces (pub or
priv) is.

ERROR:  [resolve.c:1694]: sip_hostport2su(): could not resolve hostn
ame.

Reconfigure those gw it's not possible. There are a lot of them and a lot
of people that won't like that idea.

Is possible to disable it? or What do you recommend me to do? Maybe using
/etc/hosts?

Any suggestion will be very appreciated.

Diego.
___
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] Disable DNS

2017-04-10 Thread Diego Nadares
Hi Daniel,

Thanks for your response. Your suggestion helped me a lot. We don't use
domains so instead a domain I set the ip address ($Ri).

I added this to my cfg. I don't know if is the right place. Whay do you
think?

request_route {

   .
   remove_hf("Route");
if (is_method("INVITE|SUBSCRIBE")) {
*$rd = $Ri; *
record_route();
}


Cheers,

Diego


2017-04-10 5:28 GMT-03:00 Daniel Tryba :

> On Sat, Apr 08, 2017 at 09:24:29PM -0300, Diego Nadares wrote:
> > ERROR:  [resolve.c:1694]: sip_hostport2su(): could not resolve
> hostn
> > ame.
> >
> > Reconfigure those gw it's not possible. There are a lot of them and a lot
> > of people that won't like that idea.
> >
> > Is possible to disable it? or What do you recommend me to do? Maybe using
> > /etc/hosts?
>
> Wouldn't the easiest solution be to set $rd to your domain?
>
>
> ___
> 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] Disable DNS

2017-04-10 Thread Diego Nadares
Thanks again Daniel.

Cheers,

Diego

2017-04-10 13:14 GMT-03:00 Daniel Tryba :

> On Mon, Apr 10, 2017 at 12:34:51PM -0300, Diego Nadares wrote:
> > Thanks for your response. Your suggestion helped me a lot. We don't use
> > domains so instead a domain I set the ip address ($Ri).
>
> Just took a look at the dns options, strangely enough there is no way to
> disable it apparently.
>
> > I added this to my cfg. I don't know if is the right place. Whay do you
> > think?
> >
> > request_route {
> >
> >.
> >remove_hf("Route");
> > if (is_method("INVITE|SUBSCRIBE")) {
> > *$rd = $Ri; *
> > record_route();
> > }
>
> Any place is fine, unless you forward/proxy for some specific domains.
> In my default setups I set $rd to a known value just before location()
> stuff.
>
> ___
> 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