Hello everybody!
i am trying a setup of kamailio like sbc for ms teams,
I currently have the following scenario:
TLS Connection OK
Out Call ok (except BYE 481 on reply)
my problem is in incoming calls
microsoft only supports srtp
and my pbx (freeswitch based) only works with rtp,
now i was reading that you need to use rtpengine to manage srtp to rtp,
unfortunately it seems that rtpengine has become very difficult to build
especially with recent os,
I was wondering if it is possible to …
[View More]have an alternative to rtpengine for
managing the srtp (rtpproxy does not seem to work)
has anyone managed to get a working setup?
in case it is possible to send a configuration template?
Thanks You !!!
Davide
[View Less]
Hello all,
I’m trying to figure out if I can set. Timeout for specific provisional
responses.
I know I can set timeouts for INV, and restart the timer every time a
provisional response is received.
But this not what I actually need. What I need is to set a timeout from the
100 Trying to the next 180/183 (or a final response) and set back a 480 if
not received.
I’m not sure TM would allow me to do that, so maybe using a hash table to
store transactions and calculate the time since the INV to …
[View More]the received
180/183. But there’s gotta be a simpler way.
Many thanks!
David
--
Regards,
David Villasmil
email: david.villasmil.work(a)gmail.com
phone: +34669448337
[View Less]
Hello,
I'm currently developing a service on Kamailio where it's possible to
configure redirections for a subscriber using a code.
In order to implement that client should send an INVITE with a specific
code on the Request URI and the redirection is configured.
What should be the best way to answer this INVITE?
A 200 OK will make the call answered and doesn't seem the best way.
A negative reply (4/5/6xx) would work, but it seems strange to have the
operation concluded with success …
[View More]and answering with a negative reply.
I found "199 - Early Dialog Terminated" to be suitable, but the
documentation suggests it should be used upstream.
Thanks in advance for any suggestion.
Cheers
[View Less]
Hi!
Don't know if this is a Kamailio Question, maybe someone had deal with it
in the past.
I use Kamailio with dispatcher to send the request (registration, invites,
all) to my asterisk (inbound) and then the asterisk has the outbound
trunks, everything works, but
this is little thing in asterisk when entering the "sip show peers" it
shows me that all the peers are registered with the kamailio IP, if I set
the nat option to no, it will show me the correct IP but breaks other
clients.
Any …
[View More]idea what to do ?
[View Less]
Hello!
In the configuration below Kamailio Proxy creates a transaction for the SIP
PUBLISH to get info from the HTTP server in async mode.
But before creating a transaction, a synthetic 200 OK is sent, so that I
need somehow to drop the real 200 OK from the upstream Presence Server.
If drop 200 OK in *reply_route*, tm module starts to retransmit.
Those it is necessary that the 200 OK be consumed by the tm module, but
does not go further.
*if ( !is_method("PUBLISH") ) {*
* …
[View More]sl_send_reply("200", "Ok"); t_newtran();*
* $http_req(suspend) = 1; http_async_query("$var(url)",
"CALLBACK");*
*}*
*route[CALLBACK] {*
* <some header manipulation>*
* t_on_reply("PUBLISH_REPLY"); route(RELAY); exit;*
*}*
*onreply_route[PUBLISH_REPLY] { if ( t_check_status("200") ) {
drop; # Does not work!!! }}*
Any advice is appreciated
--
BR,
Denys Pozniak
[View Less]
Hello,
I had some questions regarding the Kamailio config file.
I am trying to make Kamailio just behave as a sip proxy between two sip trunks. Could you send me an example for this possibly?
Hi,
If topos is activated and kamailio responds with a 407 "proxy
authentication required" to an initial INVITE, INVITE received after with
credentials (MD5 response in Proxy-Authorization header) is badly managed.
Credentials are never validated and Kamailio responds 407 again. If topoh
is used instead topos all works fine and credentials are validated.
call flow is:
Phone sends INVITE to kamailio SBC
kamailio respond 407 "proxy authentication required" because SBC wants to
authenticate …
[View More]caller
Phone resends INVITE with Proxy-Authorization header with all valid
information
kamailio responds 407 again instead forwarding INVITE.
My code:
if (!pv_auth_check("$fd", "$sht(auth_cache=>$var(key))", "0", "1")) {
auth_challenge("$fd", “1”);
exit;
}
# user authenticated - remove auth header
consume_credentials();
So if topos is used, pv_auth_check always returns false even if the phone
sets valid information.
If topoh is activated, pv_auth_check always returns true (same phone and
same kamailio SBC versioning)
I made my tests with kamailio 5.4.3 on centos 7.
Regards,
Frédéric Gaisnon
[View Less]
Hi
I m using kamailio 5.3
OS Ubuntu 18
I wan to Register on sip server and then send traffic to to it form
kamailio.
Like :
Client ---(sip peer)-->kamailio------(sip peer)---->gateway
Please help me
Thank you
Regards
Gaurav Kumar
Hi List,
I have some weird multipart/mixed;boundary issues.
I use kamailio 5.3.6 with rtpengine 7.x.x (same with 8.x.x).
If i try to remove a multipart/mixed and leave only the sdp with
filter_body() that works except one thing.
The sender used IMHO an non RFC compliant version of rfc5621 and wrote the
Content-Length Header twice (one in the header, one in the sdp).
After manipulating the SDP filter_body() lets Content-Length in the sdp (i
guess).
And rtpengine is not happy with the sdp …
[View More]after that.
rtpengine [rtpengine.c:2588]: rtpp_function_call(): proxy replied with
error: Failed to parse SDP
Any ideas how to solve this?
Kind regards
Karsten Horsmann
https://tools.ietf.org/html/rfc5621#section-3.1
route[REMOVE_MULTIPART] {
if (has_body("multipart/mixed")) {
if ($sel(cfg_get.remove.multipart) == 1) {
if (filter_body("application/sdp")) {
remove_hf("Content-Type");
append_hf("Content-Type:
application/sdp\r\n");
msg_apply_changes();
xlog("L_WARN", "[$cfg(route)] Body part
multipart/mixed with application/sdp found\n");
} else {
xlog("L_ERROR", "[$cfg(route)] Body part
multipart/mixed without application/sdp found\n");
}
} else {
xlog("L_INFO", "[$cfg(route)] Body part
multipart/mixed found - manipulation disabled\n");
}
}
}
-------------------
INVITE sip:+49XXXXXXXX@172.20.120.57:5060 SIP/2.0
Via: SIP/2.0/UDP 172.20.120.51:5061;branch=z9hG4bK-6589-1-0
From: sipp <sip:sipp@172.20.120.51:5061>;tag=6589SIPpTag001
To: sut <sip:+49XXXXXXXXX@172.20.120.57:5060>
Call-ID: 1-6589(a)172.20.120.51
CSeq: 1 INVITE
Contact: sip:sipp@172.20.120.51:5061
Max-Forwards: 70
Subject: Performance Test
Content-Type: multipart/mixed;boundary=sonus-content-delim
Content-Length: 1185
--sonus-content-delim
Content-Type: application/sdp
Content-Length: 305
v=0
o=Sonus_UAC 895311 862130 IN IP4 8.8.8.8
s=SIP Media Capabilities
c=IN IP4 8.8.8.8
t=0 0
m=audio 26088 RTP/AVP 8 0 18 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:18 annexb=no
a=fmtp:101 0-15
a=sendrecv
a=rtcp:26089
a=ptime:20
--sonus-content-delim
Content-Type: application/pidf+xml
<?xml version="1.0" encoding="UTF-8"?><presence
xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicLoc"
mlns:btd="http://btd.orange-business.com" entity="
pres:geotarget@btip.orange-business.com"><tuple
id="XXXX"><status><gp:geopriv><gp:location-info><cl:civicAddress><cl:country>DE</cl:countr
<cl:A1>Some
State</cl:A1><cl:A3>Somewhere</cl:A3><cl:A4>Somewhere</cl:A4><cl:A6>Somestreet</cl:A6><cl:YYY>1</cl:YYY><cl:PC>9999</cl:PC><cl:EMERGENCYZONE>XXXXXXX</cl:EMERG
CYZONE></cl:civicAddress></gp:location-info><gp:usage-rules></gp:usage-rules></gp:geopriv></status></tuple></presence>
--sonus-content-delim--
---------------------
INVITE sip:+49XXXXXXXX@foo SIP/2.0
Via: SIP/2.0/TCP
212.XX.XX.XX;branch=z9hG4bKc228.6b8fdf20d79998d1d355feb2dcf5ba63.0
From: sipp <sip:sipp@foo>;tag=6589SIPpTag001
To: sut <sip:+49XXXXXXXX@foo>
Call-ID: 1-6589(a)172.20.120.51
CSeq: 1 INVITE
Max-Forwards: 69
Content-Length: 347
Content-Type: application/sdp
P-Asserted-Identity: <sip:+49XXXXXXXX@212.XX.XX.XX>
Contact: <sip:btpsh-60211bbe-674b-1@212.XX.XX.XX;transport=tcp>
Content-Length: 305
v=0
o=Sonus_UAC 895311 862130 IN IP4 8.8.8.8
s=SIP Media Capabilities
c=IN IP4 8.8.8.8
t=0 0
m=audio 26088 RTP/AVP 8 0 18 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:18 annexb=no
a=fmtp:101 0-15
a=sendrecv
a=rtcp:26089
a=ptime:20
--
Mit freundlichen Grüßen
*Karsten Horsmann*
[View Less]