Hey
Is there any variable that retrieves me the destination of a reply?
I've used the To header for the domain, but i can't seem to get the
destination port.
Any help ?
Thanks
Hi All,
can anyone share me the installtion steps for kamailio 5.1.2 with debian
packages on ubuntu.
i have used kamailio 4.3.6 with polaris configuration.
I want to upgrade latest version of kamailio. And i have installed latest
debian packages and i have used polaris scripts to bringup kamailio and its
failing with
status kamailio service with Result resources.
if i use latest debian packages , are polaris configurations are compatible
with latest packages??
Please help me out.
Thanks in advance.
Regards,
vinay
Dear all,
What's the meaning of ims_dialog default_timeout parameter ?
*Default value is 「43200 (12 hours)」*
When modparam("ims_dialog", "default_timeout", 600) was set,
the situation of Kamailio S-CSCF out of memory was solved and is running
smoothly.
Debian 8 with Kamailio 4.4.7
Hi
I have a setup with three kamailio's in the same host but on different
ports. client ->5069 -> 5070 -> 5071 -> SIP provider
Now I get this error from the 5069 Kamailio when it is routing a 200 Ok
to the client:
Apr 9 21:54:10 kfcpbx /usr/sbin/kamailio[9688]: ERROR: <core>
[forward.c:181]: get_out_socket(): no socket found
Apr 9 21:54:10 kfcpbx /usr/sbin/kamailio[9688]: ERROR: <core>
[forward.c:183]: get_out_socket(): no corresponding socket found
for(udp:192.168.2.101:10120)
Apr 9 21:54:10 kfcpbx /usr/sbin/kamailio[9688]: ERROR: <core>
[forward.c:808]: do_forward_reply(): cannot forward reply
By manipulating the database I can skip the 5070 Kamailio, and then it
works.
I captured these two 200 Ok packets to the 5069 kamailio
*Failing:*
No. Time Source Destination Protocol Length Info
4713 21:54:12.814245 127.0.0.1 127.0.0.1 SIP/SDP
2297 Status: 200 OK |
Frame 4713: 2297 bytes on wire (18376 bits), 2297 bytes captured (18376
bits)
Linux cooked capture
Internet Protocol Version 4, Src: 127.0.0.1, Dst: 127.0.0.1
User Datagram Protocol, Src Port: 5070, Dst Port: 5069
Session Initiation Protocol (200)
Status-Line: SIP/2.0 200 OK
Message Header
Via: SIP/2.0/UDP
127.0.0.1:5069;rport=5069;branch=z9hG4bK6ef1.0c009dcf5b4965c5d1a13d508e0b31c5.0
Via: SIP/2.0/UDP
192.168.2.101:10120;received=192.168.2.101;rport=10120;branch=z9hG4bKPjIq.uY6jYbHkIqCo03bYLsTzccb7oy9jw
Record-Route:
<sip:127.0.0.8;line=sr-z-yMngm271wI73zx7gmx0CmHdDZWd-w*>
Record-Route:
<sip:127.0.0.8;line=sr-z-yMngm271wI73zx7gmx0Cq.7Cc-039Sz4Rxz5kezbQWOtUMn-9yTjcWODXoTC9BzK**>
Record-Route:
<sip:127.0.0.8;line=sr-z-yMngmS0-R4LCz2LtZ-Lg02L-JoLNQGn3057t0SntZ5LNL2QD7Vz12-sjkSTtMxTiB.7Cc-0399LtUqzgSGnCQx0gQ56gLG6g0wn5UILt2NziWIO3ooTDcHdDZ*>
Record-Route:
<sip:127.0.0.8;line=sr-z-yMngm271wI73zx7gmx0Nm.7Cc5039Sz4Rxz5kezbQWOtUMn-9yTjcWODXoTC9BzK**>
Record-Route:
<sip:127.0.0.8;line=sr-z-yMngm271wI7CJx0gZx73Q.7Cc50C9I0goedg9Bzgoedg94OiRbvEynTR7EFm0wFSOZQCOsOiGQs3EIzyUMTi7jnD7qzmWjn-UVT3SwTiJx7NLo0Q**>
Record-Route:
<sip:127.0.0.1:5071;r2=on;lr=on;ftag=YNdSUHC8KGHA7ZtlPh5rrTpdcW8sdpOW;did=8de.7651>
Record-Route:
<sip:127.0.0.1:5070;lr=on;ftag=YNdSUHC8KGHA7ZtlPh5rrTpdcW8sdpOW;did=8de.01b2>
Record-Route:
<sip:127.0.0.1:5069;r2=on;lr=on;ftag=YNdSUHC8KGHA7ZtlPh5rrTpdcW8sdpOW;vsf=AAAAAAABAAAAAAAAAAAAAAAIMDE-;did=8de.d821>
Record-Route:
<sip:192.168.2.9:5069;r2=on;lr=on;ftag=YNdSUHC8KGHA7ZtlPh5rrTpdcW8sdpOW;vsf=AAAAAAABAAAAAAAAAAAAAAAIMDE-;did=8de.d821>
From: "Door"
<sip:u1@192.168.2.101>;tag=YNdSUHC8KGHA7ZtlPh5rrTpdcW8sdpOW
To: <sip:004540294149@scantron.viptel.dk:5070>;tag=1865008112
Call-ID: ou8V0cLHn.P7Oca-pgsnMmrWO43kIQX8
CSeq: 5778 INVITE
Contact:
<sip:127.0.0.8;line=sr-z-yMnrBS7CQM0gqS0CQ2Q3m27FwI73qx0CQo6gJSngJM7gcHODXPdb7Md5XSvjEqzc**>
Allow:
INVITE,ACK,PRACK,SUBSCRIBE,BYE,CANCEL,NOTIFY,INFO,REFER,UPDATE
P-AS-Response: 40294149
Content-Type: application/sdp
Content-Length: 499
Message Body
*OK (Without 5070)*
No. Time Source Destination Protocol Length Info
373 21:44:42.955075 127.0.0.1 127.0.0.1 SIP/SDP
2199 Status: 200 OK |
Frame 373: 2199 bytes on wire (17592 bits), 2199 bytes captured (17592 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 127.0.0.1, Dst: 127.0.0.1
User Datagram Protocol, Src Port: 5071, Dst Port: 5069
Session Initiation Protocol (200)
Status-Line: SIP/2.0 200 OK
Message Header
Via: SIP/2.0/UDP
127.0.0.1:5069;rport=5069;branch=z9hG4bKeea.431611add9dee6ae89135983a85d3021.0
Via: SIP/2.0/UDP
192.168.2.101:10120;received=192.168.2.101;rport=10120;branch=z9hG4bKPjXjzYAzDU-AJ9ug6mWhSQVI4gwRomuejk
Record-Route:
<sip:127.0.0.8;line=sr-z-yMngm271wI73zx7gmx0CmHdDZWd-w*>
Record-Route:
<sip:127.0.0.8;line=sr-z-yMngm271wI73zx7gmx0Cq.7Cc-039Sz4Rxz5kezbQWOtUMn-9yTjcWODXoTC9BzK**>
Record-Route:
<sip:127.0.0.8;line=sr-z-yMn4LSntRr0NzI7NQ574XqnC0M7gQ50NJNL4EgTCQ-7imIQD7Vz12-sjkSTtMxTiB.7Cc-0399LtUqzgSGnCQx0gQ56gLG6g0wn5UILt2NziWIO3ooTDcHdDZ*>
Record-Route:
<sip:127.0.0.8;line=sr-z-yMngm271wI73zx7gmx0Nm.7Cc5039Sz4Rxz5kezbQWOtUMn-9yTjcWODXoTC9BzK**>
Record-Route:
<sip:127.0.0.8;line=sr-z-yMngm271wI7CJx0gZx73Q.7Cc50C9I0goedg9Bzgoedg94OiRbvj7pJJTBsJyFttWTd-XVsSuS75k3EqOEsCOZF3k6YiyQn-UVT3oyLCQx73Z->
Record-Route:
<sip:127.0.0.1:5071;r2=on;lr=on;ftag=sJQFliIRYoYobikO47pCVGUi7HH0KxiP;did=ea4.426>
Record-Route:
<sip:127.0.0.1:5069;r2=on;lr=on;ftag=sJQFliIRYoYobikO47pCVGUi7HH0KxiP;vsf=AAAAAAABAAAAAAAAAAAAAAAIMDE-;did=ea4.7dd2>
Record-Route:
<sip:192.168.2.9:5069;r2=on;lr=on;ftag=sJQFliIRYoYobikO47pCVGUi7HH0KxiP;vsf=AAAAAAABAAAAAAAAAAAAAAAIMDE-;did=ea4.7dd2>
From: "Door"
<sip:u1@192.168.2.101>;tag=sJQFliIRYoYobikO47pCVGUi7HH0KxiP
To: <sip:004540294149@scantron.viptel.dk:5070>;tag=1402236088
Call-ID: 31a27HAVA7aFhLaX9uZkBxHu31OEZqOz
CSeq: 9542 INVITE
Contact:
<sip:127.0.0.8;line=sr-z-yMnrBS7CQM0gqS0CQ2Q3m27FwI73qx0CQo6gJSngJM7gcHODXPdb7Md5XSvjEqzc**>
Allow:
INVITE,ACK,PRACK,SUBSCRIBE,BYE,CANCEL,NOTIFY,INFO,REFER,UPDATE
P-AS-Response: 40294149
Content-Type: application/sdp
Content-Length: 500
Message Body
Somehow it must be the contents in the 200 Ok package, but I really cant
se any significant difference.
Anybody knows what that message is caused by?
--
-------------------- Med Liberalistiske Hilsner ----------------------
Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk
Greetings list,
I am trying to make two endpoints talking on DTLS-SRTP. But I hear on
audio.
Things work perfectly fine if I use RTP or SRTP with TLS.
Endpoints are pjsip based application not webrtc based clients.
Below are logs from rtpengine. I hope someone could point out amiss.
Apr 9 20:02:43 centos-1024mb-nyc-02 rtpengine[58438]: INFO:
[66d2da58-21fe-48bd-9999-a1f3a22afa6d]: --------- Port 209.182.216.71:8176
<> 72.214.35.171:63577, SSRC 1234c6eb, 641 p, 110252 b, 0 e, 60 ts
Apr 9 20:02:43 centos-1024mb-nyc-02 rtpengine[58438]: INFO:
[66d2da58-21fe-48bd-9999-a1f3a22afa6d]: --------- Port 209.182.216.71:8177
<> 72.214.35.171:63056 (RTCP), SSRC 1234c6eb, 4 p, 372 b, 0 e, 60 ts
Apr 9 20:12:24 centos-1024mb-nyc-02 rtpengine[58438]: INFO: Version
git-master-3ef300b shutting down
Apr 9 20:12:37 centos-1024mb-nyc-02 rtpengine[58958]: INFO: Generating new
DTLS certificate
Apr 9 20:12:37 centos-1024mb-nyc-02 rtpengine[58959]: INFO: Startup
complete, version git-master-3ef300b
Apr 9 20:13:43 centos-1024mb-nyc-02 rtpengine[58959]: INFO:
[a5ca8335-84d2-4daf-a0e2-6465e72b6d08]: Received command 'offer' from
127.0.0.1:57645
Apr 9 20:13:43 centos-1024mb-nyc-02 rtpengine[58959]: NOTICE:
[a5ca8335-84d2-4daf-a0e2-6465e72b6d08]: Creating new call
Apr 9 20:13:43 centos-1024mb-nyc-02 rtpengine[58959]: INFO:
[a5ca8335-84d2-4daf-a0e2-6465e72b6d08]: offer time = 0.002612 sec
Apr 9 20:13:43 centos-1024mb-nyc-02 rtpengine[58959]: INFO:
[a5ca8335-84d2-4daf-a0e2-6465e72b6d08]: Replying to 'offer' from
127.0.0.1:57645
Apr 9 20:13:56 centos-1024mb-nyc-02 rtpengine[58959]: INFO:
[a5ca8335-84d2-4daf-a0e2-6465e72b6d08]: Received command 'answer' from
127.0.0.1:42309
Apr 9 20:13:56 centos-1024mb-nyc-02 rtpengine[58959]: INFO:
[a5ca8335-84d2-4daf-a0e2-6465e72b6d08]: answer time = 0.000220 sec
Apr 9 20:13:56 centos-1024mb-nyc-02 rtpengine[58959]: INFO:
[a5ca8335-84d2-4daf-a0e2-6465e72b6d08]: Replying to 'answer' from
127.0.0.1:42309
Apr 9 20:13:56 centos-1024mb-nyc-02 rtpengine[58959]: INFO:
[a5ca8335-84d2-4daf-a0e2-6465e72b6d08 port 8000]: DTLS: Peer certificate
accepted
Apr 9 20:13:56 centos-1024mb-nyc-02 rtpengine[58959]: INFO:
[a5ca8335-84d2-4daf-a0e2-6465e72b6d08 port 8000]: DTLS-SRTP successfully
negotiated
Apr 9 20:13:57 centos-1024mb-nyc-02 rtpengine[58959]: ERR:
[a5ca8335-84d2-4daf-a0e2-6465e72b6d08 port 8000]: SRTP output wanted, but
no crypto suite was negotiated
Apr 9 20:14:00 centos-1024mb-nyc-02 rtpengine[58959]: INFO:
[a5ca8335-84d2-4daf-a0e2-6465e72b6d08 port 8000]: Confirmed peer address
as 72.214.35.171:58634
Apr 9 20:14:07 centos-1024mb-nyc-02 rtpengine[58959]: ERR:
[a5ca8335-84d2-4daf-a0e2-6465e72b6d08 port 8001]: SRTCP output wanted, but
no crypto suite was negotiated
Apr 9 20:14:07 centos-1024mb-nyc-02 rtpengine[58959]:
[a5ca8335-84d2-4daf-a0e2-6465e72b6d08] version=2, padding=0, count=1,
payloadtype=200, length=12, ssrc=2045607967, ntp_sec=1379282714,
ntp_fractions=439054259, rtp_ts=1838072137, sender_packets=3366262813,
sender_bytes=2383498210, ssrc=815258372, fraction_lost=96,
packet_loss=13713522, last_seq=3314313929, jitter=2878956247,
last_sr=2456273253, delay_since_last_sr=3351655681
Apr 9 20:14:07 centos-1024mb-nyc-02 rtpengine[58959]: INFO:
[a5ca8335-84d2-4daf-a0e2-6465e72b6d08 port 8001]: Confirmed peer address
as 72.214.35.171:57732
Apr 9 20:14:12 centos-1024mb-nyc-02 rtpengine[58959]: ERR:
[a5ca8335-84d2-4daf-a0e2-6465e72b6d08 port 8000]: SRTP output wanted, but
no crypto suite was negotiated
Apr 9 20:14:17 centos-1024mb-nyc-02 rtpengine[58959]:
[a5ca8335-84d2-4daf-a0e2-6465e72b6d08] version=2, padding=0, count=1,
payloadtype=200, length=12, ssrc=2045607967, ntp_sec=2811881700,
ntp_fractions=4080266212, rtp_ts=371429680, sender_packets=958830616,
sender_bytes=2579186043, ssrc=1909756377, fraction_lost=174,
packet_loss=11416637, last_seq=3106722675, jitter=758758394,
last_sr=2663618457, delay_since_last_sr=1399181077
Apr 9 20:14:27 centos-1024mb-nyc-02 rtpengine[58959]: ERR:
[a5ca8335-84d2-4daf-a0e2-6465e72b6d08 port 8000]: SRTP output wanted, but
no crypto suite was negotiated
Apr 9 20:14:27 centos-1024mb-nyc-02 rtpengine[58959]: ERR:
[a5ca8335-84d2-4daf-a0e2-6465e72b6d08 port 8001]: SRTCP output wanted, but
no crypto suite was negotiated
Apr 9 20:14:27 centos-1024mb-nyc-02 rtpengine[58959]:
[a5ca8335-84d2-4daf-a0e2-6465e72b6d08] version=2, padding=0, cou
It is how I have programmed it in my Kamailio configuration.
ON INVITE
rtpengine_offer("replace-origin replace-session-connection ICE=remove
UDP/TLS/RTP/SAVP");
ON 200-ok
rtpengine_answer("replace-origin replace-session-connection ICE=remove
UDP/TLS/RTP/SAVP");
Best Regards,
Aqs Younas
Hi,
Quick (and simple) question:
Can someone provide a working RTPengine request, to enable Transcoding?
I know, this is possible, but I thought before looking into deep, how this
should be configured for the rtpengine_offer() command, could someone
provide an example?
Thanks,
Carsten
Greetings,
How can i identify the first Invite received by Kamailio in a dialog. I'm
checking for the To-Tag in order to identify the first one. However, if the
UA retries the same INVITE (because of a timeout for example), it won't
have To Tag and it won't be the first INVITE that i'm receiving in that
dialog.
Is there any flag or variable that i can use to identify the first Invite
received?
Thanks in advance
Hi All,
I am using Kamailio
**
*v4.4.x* to load balanced traffic to FreeSWITCH servers. I have query
regarding ds_ping_interval and ds_probing_threshold. We have very high
traffic (around 200-400
(CPS)
calls per sec) hitting on Kamailio which then distribute it to 2-3
FreeSWITCH servers.
What is the optimal value should I set to ds_ping_interval and
ds_probing_threshold?
If I set
ds_ping_interval=2 and
ds_probing_threshold=1 then in every 2 sec, I would come to know if my
FreeSWITCH server is down/up. But by setting such low values, I afraid
there would
be
lot of SIP traffic on network.
If I set high (say
ds_probing_threshold=5) then I may loose high number of calls (200 CPS, I
will loose 1000 calls) in case
FreeSWITCH server is down.
As I said earlier we have very high traffic hitting on Kamailio, can't
kamailio use INVITE itself to probe FreeSWITCH server is down/up? In case
of low traffic can't it switch over to OPTION mechanism?
--
Thanks in Advance
,
Atul
