Hi,
I'm working with a softphone project named mjSip,
now I've implemented the TLS protocol in the softphone
and I would try it with 2 iptel account setted on two pc,
on the first I have:
# MjSip UA configuration file
# ___________________________________________
#
host_port=5061
transport_protocols= tls
outbound_proxy=sip.iptel.org
from_url=<sip:alexlel@iptel.org>
username=alexlel
realm=iptel.org
passwd=2387lelloh
debug_level=8
log_path=log
max_logsize=2000
do_register=yes
keepalive_time=8000
_______________________________
the second is such as this.
However I have no response in SSL/TLS by the iptel server.
Does it work in TLS?
Thanks,
Regards.
Spam detection software, running on the system "mail.iptel.org", has
identified this incoming email as possible spam. The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: I would like to take this time to welcome you to our hiring
process and give you a brief synopsis of the position's benefits and requirements.
If you are taking a career break, are on a maternity leave, recently retired
or simply looking for some part-time job, this position is for you. [...]
Content analysis details: (12.2 points, 5.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
0.4 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL
[188.49.28.2 listed in zen.spamhaus.org]
3.3 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL
1.7 URIBL_BLACK Contains an URL listed in the URIBL blacklist
[URIs: it-jobsearch.com]
1.7 URIBL_DBL_SPAM Contains an URL listed in the DBL blocklist
[URIs: it-jobsearch.com]
0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines
1.3 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net
[Blocked - see <http://www.spamcop.net/bl.shtml?188.49.28.2>]
1.4 RCVD_IN_BRBL_LASTEXT RBL: RCVD_IN_BRBL_LASTEXT
[188.49.28.2 listed in bb.barracudacentral.org]
1.5 BAYES_60 BODY: Bayes spam probability is 60 to 80%
[score: 0.6541]
0.8 RDNS_NONE Delivered to internal network by a host with no rDNS
I have finally got to the section of the install section "10. Ready to
Rock". Unfortunately, I did get the error message "ERROR: domain
unknown: use usernames with domain or set default domain in
SIP_DOMAIN". I did the two steps that the instructions gave and cannot
find ".kamctlrc" to "add SIP_DOMAIN=mysipserver.com"
Please help. I am not quite understanding what should be done to fix this
Peter
Hello,
the place and date for Kamailio/SER Developer Seminar have been set: San
Mateo (just south of San Francisco, CA, in the nearby of international
airport), for one day and a half, Oct 24-25, 2011.
I posted more details, including about content and registration, at:
*
http://www.kamailio.org/w/2011/10/kamailio-developer-seminar-san-francisco-…
Participating fee is 250USD. Selection of attendees is done by the rule
of first come first served. The number of seats is limited, don't wait
too long if you want to attend.
Looking forward to meeting many of you there.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- http://www.asipto.com
Kamailio Advanced Training, Dec 5-8, Berlin: http://asipto.com/u/kathttp://linkedin.com/in/miconda -- http://twitter.com/miconda
Hi everyone.
I'm still facing problems with my Kamailio Dispatcher <-> FreeSWITCH setup.
Everything works when connecting directly to FreeSWITCH.
When connecting to Kamailio, which should work as a dispatcher
(load-balancer) in front of FreeSWITCH I get "Too many hops", "Timeouts"
etc.
My test setup with SIP clients is an iPhone, an Android, an iPad and a
laptops with Ubuntu.
Can someone help me out, for a small amount of money, until I can get it to
work? Hopefully it's just the kamailio.cfg which needs to do things
correctly. Currently I'm using this http://pastebin.com/mahKECAw with help
from Morten in this mailing list.
This is what I am getting:
INFO: test server charset
/usr/local/lib/kamailio//kamctl/kamdbctl.mysql: line 105: mysql: command not
found
/usr/local/lib/kamailio//kamctl/kamdbctl.mysql: line 106: mysql: command not
found
Usage: grep [OPTION]... PATTERN [FILE]...
Try `grep --help' for more information.
/usr/local/lib/kamailio//kamctl/kamdbctl.mysql: line 112: [: =: unary
operator expected
INFO: creating database openser ...
/usr/local/lib/kamailio//kamctl/kamdbctl.mysql: line 71: mysql: command not
found
ERROR: Creating core database and grant privileges failed!
I looked at the files and cannot find the problem. Please help.
Peter
I have a setup with Kamailio as dispatcher in front of a FreeSwitch server.
This is my kamailio.cfg: http://pastebin.com/8PR2GFBD
I'm currently getting "Too many hops" when calling between SIP clients. I am
able to call to FreeSwitch and listen to voicemail, hold music etc.
After a long conversation with a FreeSwitch expert, and some tests, I was
told that Kamailio delivers the wrong IP (NAT problems) to FreeSwitch.
I've also run tshark on both FreeSwitch and Kamailio and when calling
between clients they just send the packets between each other.
Can anyone help me out? I've tried to Google a lot for this problem and
asked in several IRC channels, mailing lists and forums. Without any luck.
Owki, reading RFC-3261 again ;)
Imho Kamailio does what it is supposed to do, it forwards the packet to the
first element in the Route header.
But as I received the BYE packet from <sip:their_sbc> , that one should have
stripped itself out of the Route header, making everything just work, right?
Now I can hackishly fix it with a rewritehostport in the middle. But that
will eventually not scale up that nicely. Ergo, does anyone have a good idea
on how to e.g. have Kamailio in this situation ignore the first uri in the
route header? Or am I still not getting it :) ?
thx !
BYE sip:05xxxxxx at my_kamailio
<http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users>:5060;transport=udp
SIP/2.0
Record-Route: <sip:their_sbc;lr=on;ftag=as5716fec8>
Via: SIP/2.0/UDP their_sbc;branch=z9hG4bK1ae8.269e4f67.0
Via: SIP/2.0/UDP
their_internals:5060;received=their_internals;branch=z9hG4bK4f9044a7;rport=5060
Route:
<sip:their_sbc;lr=on;ftag=as5716fec8>,<sip:36d0a5cfbaeb6b055d5bb02c32127b49_32123456789
at my_kamailio <http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users>
;lr=on;ftag=as5716fec8>
Max-Forwards: 69
From: "Some_Telecom" <sip:02xxxxxxxx at their_sbc
<http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users>>;tag=as5716fec8
To: <sip:05xxxxxx at their_sbc
<http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users>:5060>;tag=U3FrFDm5Zr0KF
Call-ID: 68fe6a470986bd087ce4ed860f603af6 at their_sbc
<http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users>
CSeq: 103 BYE
User-Agent: Integrics Enswitch
X-Asterisk-HangupCause: Normal Clearing
X-Asterisk-HangupCauseCode: 16
Content-Length: 0
X-Enswitch-RURI: sip:05xxxxxx at my_kamailio
<http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users>:5060;transport=udp
X-Enswitch-Source: their_internals:5060
Hello,
I have the following issue.
A calls B, talk for a while, then B sends a BYE, but A never receives it.
The BYE is transmited from the proxy listening interface:port to itself, but
not to the asterisk port.
U 2011/10/08 00:29:29.207335 Kamailio_IP:5060 -> Kamailio_IP:5060
BYE sip:Kamailio_IP;lr=on SIP/2.0.
The scenario is:
A (pstn subs) --> Asterisk:5080 --> Kamailio:5060 --> B (registered sip
ua)
Asterisk and Kamailio are in the same box, listening both at the same IP
(eth iface) address, but one at port 5080, and the proxy at 5060 (udp).
The configuration is based on kamailio.cfg file provided by the v3.1.5 (with
a few modules added, like dialplan and cr..etc).
If A is who send the BYE, everything goes well.
I attach the full sip capture.
Thanks for you time.
Claudio
I'm trying to integrate to an integrics enswitch, almost everything works
like a charm, except on BYE packets as Kamailio in my setup forwards these
incorrectly.
Digging somewhat I believe the culprit sits in the Route header which comes
from the enswitch:
Route:
<sip:their_sbc;lr=on;ftag=as5716fec8>,<sip:36d0a5cfbaeb6b055d5bb02c32127b49_32123456789@my_kamailio
;lr=on;ftag=as5716fec8>
Kamailio takes into account the first argument (the thing sip:their_sbc...)
on which it cannot find the correct transaction. And forwards it back to the
sender, instead of forwarding it correctly to my freeswitch. which gives a
storm of traffic ;)
If I compare that with an ACK packet in the same transaction , having this
as a Route header :
Route: <sip:36d0a5cfbaeb6b055d5bb02c32127b49_32123456789@my_kamailio
;lr=on;ftag=as5716fec8>
Kamailio sends it along correctly.
IMHO if I could convince Kamailio to always take the last part of the Route
header into account and ignore the first one it would correctly work. What
would be a good approach? Rewriting the route header looks abit harsch.
disclaimer : I'm not sure which component is disrespecting the RFC, if any,
or if I just fully not get something :)
Short overview + packet detail (with some obfuscation):
My setup:
their_sbc --- my_kamailio --- freeswitch --- my_kamailio --- enduser
BYE sip:05xxxxxx@my_kamailio:5060;transport=udp SIP/2.0
Record-Route: <sip:their_sbc;lr=on;ftag=as5716fec8>
Via: SIP/2.0/UDP their_sbc;branch=z9hG4bK1ae8.269e4f67.0
Via: SIP/2.0/UDP
their_internals:5060;received=their_internals;branch=z9hG4bK4f9044a7;rport=5060
Route:
<sip:their_sbc;lr=on;ftag=as5716fec8>,<sip:36d0a5cfbaeb6b055d5bb02c32127b49_32123456789@my_kamailio
;lr=on;ftag=as5716fec8>
Max-Forwards: 69
From: "Some_Telecom" <sip:02xxxxxxxx@their_sbc>;tag=as5716fec8
To: <sip:05xxxxxx@their_sbc:5060>;tag=U3FrFDm5Zr0KF
Call-ID: 68fe6a470986bd087ce4ed860f603af6@their_sbc
CSeq: 103 BYE
User-Agent: Integrics Enswitch
X-Asterisk-HangupCause: Normal Clearing
X-Asterisk-HangupCauseCode: 16
Content-Length: 0
X-Enswitch-RURI: sip:05xxxxxx@my_kamailio:5060;transport=udp
X-Enswitch-Source: their_internals:5060
BYE sip:36d0a5cfbaeb6b055d5bb02c32127b49_32123456789@my_kamailio;lr=on;ftag=as5716fec8
SIP/2.0
Record-Route: <sip:05xxxxxx@my_kamailio;lr=on;ftag=as5716fec8>
Record-Route: <sip:their_sbc;lr=on;ftag=as5716fec8>
Via: SIP/2.0/UDP my_kamailio;branch=z9hG4bK1ae8.b4f95af2.0
Via: SIP/2.0/UDP my_kamailio;rport=5060;branch=z9hG4bK1ae8.a4f95af2.0
Via: SIP/2.0/UDP their_sbc;rport=5060;branch=z9hG4bK1ae8.269e4f67.0
Via: SIP/2.0/UDP
their_internals:5060;received=their_internals;branch=z9hG4bK4f9044a7;rport=5060
Route: <sip:their_sbc;lr=on;ftag=as5716fec8>
Max-Forwards: 67
From: "Some_Telecom" <sip:02xxxxxxxx@their_sbc>;tag=as5716fec8
To: <sip:05xxxxxx@their_sbc:5060>;tag=U3FrFDm5Zr0KF
Call-ID: 68fe6a470986bd087ce4ed860f603af6@their_sbc
CSeq: 103 BYE
User-Agent: Integrics Enswitch
X-Asterisk-HangupCause: Normal Clearing
X-Asterisk-HangupCauseCode: 16
Content-Length: 0
X-Enswitch-RURI: sip:05xxxxxx@my_kamailio:5060;transport=udp
X-Enswitch-Source: their_internals:5060