Re: [SR-Users] change_reply_status() 415 - 200 change
On 2/13/15 11:36 AM, Juha Heinanen wrote: i tried to use change_reply_status() to change 415 to 200, but got: ERROR: textopsx [textopsx.c:283]: change_reply_status_f(): ERROR: textops: the class of provisional or positive final replies cannot be changed textopsx/README does not mention anything about what can or cannot be changed. why is it that the above change cannot be made? just guessing -- because the transaction state machine would be different? jiri ___ 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] SIP client TCP behaviour
On 4/7/14 5:53 PM, Alex Balashov wrote: Hello, I don't know a lot about SIP with TCP, so I thought I'd ask for some opinions here. I've been testing Kamailio with TCP against the Android SIP client (4.4.2) and have found, to my annoyance, that it sends a RURI with a transport attribute in its INVITEs: INVITE sip:14045551...@sip.evaristesys.com;transport=tcp My upstream gateways are all UDP, so this causes Kamailio to attempt to contact them all via TCP (and fail). I know how to bend the transport with Kamailio, and I can strip this attribute. My question is more methodological: is this correct for a client to do? Think of it as a hop-by-hop attribute expressing its next-hop (i.e. proxy) transport preference for outbound request, K is free to rewrite it to its liking. In my opinion, the answer is no. The client should not be so presumptuous. It should specify the transport in its Contact, to indicate how it wants to be reached, and leave other decisions about transport to the UAS. But is there something I am perhaps missing? You are right for inbound. If a reasonably behaving application has choice of transport, I would be perfectly fine with indicating it explicitely both in outbound request-URIs and Contacts that attract inbound requests. -jiri ___ 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] SIP client TCP behaviour
On 4/7/14 7:31 PM, Alex Balashov wrote: On 04/07/2014 01:29 PM, Jiri Kuthan wrote: Think of it as a hop-by-hop attribute expressing its next-hop (i.e. proxy) transport preference for outbound request, K is free to rewrite it to its liking. Yeah, but my Kamailio already defaults to UDP. It means I have to do extra work to override this preference. Since the next hop is opaque to the client, why should it have a say in choosing the transport used to reach it? Why should it care? my point is it is entirely SIP proxy business todo anything about the incomig URI. throw away the upstream hop preferences or keep them. If it wants to have a clear result, it must basically whitelist/blacklist some URI parameters. jiri ___ 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] 500 I'm terribly sorry error
Warning header field in the answer could reveal the content of the URI which
may be what's causing troubles
jiri
On 12/10/13 5:09 PM, Helena Garcia-Nieto wrote:
Hi Daniel,
Thanks for the answer but…
I already tested if the problem is there and even commenting the prefix out the
error is exactly the same.
That is why I test it using:
pstn.gw_ip = 10.XX.XX.XX
pstn.gw_port = 5060
And route(PSTN)
Without changing original PSTN routing.
I’m getting the same problem.
Could you think on something else that can be affecting that?
Helena
*From:*sr-users-boun...@lists.sip-router.org
[mailto:sr-users-boun...@lists.sip-router.org] *On Behalf Of *Daniel-Constantin
Mierla
*Sent:* martes, 10 de diciembre de 2013 16:54
*To:* Kamailio (SER) - Users Mailing List
*Subject:* Re: [SR-Users] 500 I'm terribly sorry error
Hello,
I guess the r-uri is not correct after your changes. you can try to print $ru
with xlog(...) just before the route(RELAY).
You should use string operation to add the prefix instead of using a regular
expression substitution, like:
prefix(A99901);
or
$rU = A99901 + $rU;
Cheers,
Daniel
On 10/12/13 16:19, Helena Garcia-Nieto wrote:
Hello,
Thanks in advanced for the help. I am almost new with kamailio and still
struggling through silly problems so please forgive me if the solution is so
obvious.
I have a network like
Xlitle -- Kamailio -- GW
The GW is more or less out of my reach for changing the behaivour.
As devices I have xlitle
Kamailio is on version 4.0.2
I’ve changed only few things from the default config file. Add mysql
support, auth, userlocdb, pstngw.
For this part, gw routing , I’ve defined gw ip and port inside the PSTN
definition like:
#!ifdef WITH_PSTN
# PSTN GW Routing
#
# - pstn.gw_ip: valid IP or hostname as string value, example:
# pstn.gw_ip = 10.0.0.101 desc My PSTN GW Address
#
# - by default is empty to avoid misrouting
pstn.gw_ip = desc PSTN GW Address
pstn.gw_port = desc PSTN GW Port
iskratel.gw_ip = 10.XX.XX.XX
iskratel.gw_port = 5060
#!endif
I route the calls with:
route(ISKRATEL);
And defined a routing function
route[ISKRATEL] {
#!ifdef WITH_PSTN
# check if ISKRATEL GW IP is defined
if (strempty($sel(cfg_get.iskratel.gw_ip))) {
xlog(SCRIPT: PSTN rotuing enabled but iskratel.gw_ip not
defined\n);
return;
}
# only local users allowed to call
if(from_uri!=myself) {
sl_send_reply(403, Not Allowed);
exit;
}
if (strempty($sel(cfg_get.iskratel.gw_port))) {
$ru = sip: + $rU + @ + $sel(cfg_get.iskratel.gw_ip);
} else {
$ru = sip: + $rU + @ + $sel(cfg_get.iskratel.gw_ip) +
:
+ $sel(cfg_get.iskratel.gw_port);
}
# Add profix to ISKRATEL: A99901
subst_uri('/^sip:(.*)/sip:A99901\1/i'); # add A99901
route(RELAY);
exit;
#!endif
return;
}
I can see that the code goes all the way to the route(relay) but all I can
see is the 500 I’m terribly sorry, server error occurred (7/SL) and a second
response 500 I’m terribly sorry, server error occurred (7/TM)
I’ve tried defining the IP as the given pstn.gw_ip and route(pstn) without
changing anything on the pst default routing but the response of the server is
the same.
I cannot see any special error on the logs.
I have the exact same config for this part, in another test server and the
calls go to the gw without reporting any error.
I’ll appreciate any help from you! Thanks in advanced for your time
Helena
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org mailto:sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -http://www.asipto.com
http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda
___
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] Handling of CANCEL in case of no matching INVITE
Hi Bill,
plain-kamailio cannot send BYEs (not sure if some module can). The point is the
proxy is
sort of passive element and doesn't initiate transactions on its own.
Why isn't it enough to have the BYEs sent by UAC? I mean sometimes there can be
some
confusing situations (say forking downstream) and it is eventually the UAC
that's in
the best position to know what to BYE or CANCEL.
The point is this all seems a UAS business to me, for which a proxy can only do
some
approximiations risking it will be wrong. Like in the case 2, you may not even
notice
the ACK is already on its way (because you didn't record-route)... Getting
control
of this would really mean using the dialog module and running in B2BUA mode
rather
than proxy.
-jiri
On 5/3/13 11:59 AM, Vassilis Radis wrote:
Thank you jiri,
I totally agree, but I have a question that occured to me now and I cant find
answer:
If Kamailio receives a CANCEL from a UAC after kamailio has responded with a
200 to the corresponding INVITE, what does t_relay_cancel() do in the following
2
cases:
1. CANCEL received before the ACK from UAC. This is legal from the side of the
UAC, since the UAC may have sent the CANCEL before it receives the 200 to the
INVITE that kamailio sent.
2. CANCEL received after the ACK . This is illegal, but anyway, kamailio must
do something. I can't find in the RFC if it should respond 200 to the CANCEL
and
drop it, or 481(Call/Transaction Does Not Exist). Although 481 seems more resonable,
16.10 section of RFC says: ... If a matching response context is found,
the element MUST immediately return a 200 (OK) response to the CANCEL
request.. It does not discriminate if the corresponding INVITE has been 200ed
or not. Any
insights?
In the spirit of what you wrote in your reply, could I configure it somehow, to
take initiative and translate the CANCEL to a BYE downstream, no matter whether
CANCEL is received before or after the ACK?
Bill
On Fri, May 3, 2013 at 12:26 PM, Jiri Kuthan j...@iptel.org
mailto:j...@iptel.org wrote:
On 5/3/13 11:04 AM, Vassilis Radis wrote:
Hello all,
In the documentation of the t_relay_cancel() (TM module) there is an
example that reads:
if (method == CANCEL) {
if (!t_relay_cancel()) { # implicit drop if relaying was successful,
# nothing to do
# corresponding INVITE transaction found but error occurred
sl_reply(500, Internal Server Error);
drop;
}
# bad luck, corresponding INVITE transaction is missing,
# do the same as for INVITEs
}
What bothers me is the phrase#do the same as or INVITEs, because in
RFC(http://tools.ietf.org/__html/rfc3261#section-16.10
http://tools.ietf.org/html/rfc3261#section-16.10 ) it says:
If a response context is not found, the element does not have any
knowledge of the request to apply the CANCEL to. It MUST*statelessly*
forward the CANCEL request (it may have statelessly forwarded the
associated request previously).
So aren't we supposed to immediately statelessly forward the CANCEL if
t_relay_cancel() did not find the INVITE transaction, instead of doing the same
as INVITEs, which could be t_relay() (not stateless)?. Like below:
if (method == CANCEL) {
if (!t_relay_cancel()) { # implicit drop if relaying was successful,
# nothing to do
# corresponding INVITE transaction found but error occurred
sl_reply(500, Internal Server Error);
drop;
}
# bad luck, corresponding INVITE transaction is missing,
forward();
}
Am I correct or am i missing something?
It could be even more standardized this way indeed. Aparts
from standards, measured by common sense I cannot realize
that either way would break something. The CANCEL should
not be appearing there at all. Perhaps it would make a difference
when SER is restarted and one after it went alive again,
UAC sent a CANCEL. Then what you suggest would perform better.
If you want to make sure you have captured this case, also make
sure that branch ids are configured to be produced statelessly.
Otherwise SER-proxied CANCEL won't match the previous INVITE anyhow.
other than that, SER is much better than RFC3261. Its
registrar is stateless (in departure from the RFC, otherwise
it would be more vulnerable to DoS attacks), INVITE transaction
is hold after a 200 passes through (otherwise it would not
absorb retransmissions, create another transaction and
cause interop issues), and probably more.
I just wanted to say it is really important to look first
at what interop issues one may have or not, as SER the
way it is is likely to produce better interop than
consequent standard compliance. In most cases you
Re: [SR-Users] Handling of CANCEL in case of no matching INVITE
On 5/3/13 2:59 PM, Vassilis Radis wrote: Yes, I used the term proxy to include statefullness and dialog awareness, which makes me think: What is the point of being transaction-aware without being dialog-aware? I am trying to find a use for it, but I cant. Things are simpler: restartig transaction-stateful causes less harm than restarting dialog-stateful, unless you care of replication/failover/etc You will also achieve better performance with transactions than with dialogs transactions. That's a non-academic aspect especially for public services like iptel.org -- unsolicited traffic hits as first memory limitations and therefore you better use memory conservatively. -jiri ___ 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] path uri problem
On 4/10/13 1:25 PM, Iñaki Baz Castillo wrote: Please, RFC 5626 is the solution for NAT. I thought Olle was about to agree, except the RFC number being in fact 2460 :) jiri ___ 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] Tag maximum size/length
On 3/28/13 11:21 AM, Grant Bagdasarian wrote: Hello, Is there a maximum length/size defined for the From and To Tag? The RFC states: “it MUST be globally unique and cryptographically random with at least 32 bits of randomness”. Though I can’t find anything in the RFC about the maximum. The sip_capture table stores the to_tag and from_tag in a varchar(64). Does this mean the max is 64? Source: https://code.google.com/p/homer/source/browse/sql/create_sipcapture.sql Yes, that's an implementation's limitation. -jiri ___ 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] Tag maximum size/length
On 3/28/13 12:41 PM, Grant Bagdasarian wrote: Do you mean implementation in the context of Kamailio's implementation of SIP? yes If so, what if certain SIP clients implement it in a different way and their Tag values exceed this limitation? that depends on the application how a loss of bits affects it. With the required level of entropy, the impact is probably not big within a module: good enough for say correlation. it would be more problematic if the sip_capture module tried to work with some other module and match the tags between them -- that would obviously fail. if you wanted to be more deterministic with the sip_capture module and mysql data model, you would probably have to change data types to TEXT (256 bytes) or BLOB (64k). While these sizes are not prohibited by the spec, MTU constraints and fragmentation would anihilate INVITEs with such Tags anyhow. Also these types have some performance penalties associated with them. so in summary -- it appears that while somehow esthetically suboptimal, the 64 bytes limit is mostly good enough. jiri -Original Message- From: Jiri Kuthan [mailto:j...@iptel.org] Sent: Thursday, March 28, 2013 11:42 AM To: Kamailio (SER) - Users Mailing List Cc: Grant Bagdasarian Subject: Re: [SR-Users] Tag maximum size/length On 3/28/13 11:21 AM, Grant Bagdasarian wrote: Hello, Is there a maximum length/size defined for the From and To Tag? The RFC states: “it MUST be globally unique and cryptographically random with at least 32 bits of randomness”. Though I can’t find anything in the RFC about the maximum. The sip_capture table stores the to_tag and from_tag in a varchar(64). Does this mean the max is 64? Source: https://code.google.com/p/homer/source/browse/sql/create_sipcapture.sql Yes, that's an implementation's limitation. -jiri ___ 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] Wrong ACK packet sent from Cisco gw
apparently the cisco device is a pre-3261 implementation, i.e.
it behaves correctly in the historical RFC2543 terms.
normal SER configuration should actually handle it in code
like this...
if (loose_route()) {
route(RECORD_ROUTE);
route(FORWARD); // t_relay
jiri
this is a message digest:
INVITE sip:91500@sip_server:5060
Contact: sip:911873699@cisco_gw:5060
200
Record-Route: sip:sip_server;lr=on;did=015.864b8107.
Contact: sip:91500@asterisk_server.
ACK sip:sip_server:5060;lr=on;did=015.864b8107
Route: sip:91500@asterisk_server:5060.
On 1/17/11 5:33 PM, Nawfel Oujdi wrote:
Hello!
I m facing the same strange behaviour with my AS5300 voice gateway. When
the gw is connected directly to PBX everythings works well but when i put a sip
proxy forwarding calls between gw and PBX all the calls hangs up after 5 sec
(+or -). Looking into the trace sip i realize that gw send a wrong ACK in reply
of INVITE , then sip proxy discard it and PBX hangs the call cause he never
receive the ACK.
ACK sip:79.125.120.12:5060;lr=on;did=ce.3716ea02 SIP/2.0
Via: SIP/2.0/UDP cisco_gw:5060;x-route-tag=cid:Orange@cisco_gw
From: sip:911873699@cisco_gw;tag=65FB8-B18
Route: sip:91500@PBX:5060
To: sip:91500@sip_proxy;tag=as7f388e3f
Date: Mon, 17 Jan 2011 09:26:36 GMT
Call-ID: B6F61A2E-215211E0-802BD462-C4432B89@cisco_gw
To work fine , the content of Route header should be in ACK header and
viceversa.
I tried to compare between the sip trace of a wrong call and a good one
(using other cisco gw AS5350 who works well with sip proxy in the same
escenario) and
i realize that the only difference is the INVITE of wrong case doesn' t send
branch number in the via header.
INVITE sip:91500@sip_proxy:5060 SIP/2.0
Via: SIP/2.0/UDP cisco_gw:5060;x-route-tag=cid:Orange@cisco_gw
From: sip:911873699@cisco_gw;tag=65FB8-B18
To: sip:91500@sip_proxy
i m using c5300-is-mz.123-26.bin ios version.
Anybody understand what is happening in there?? is there any solution?? i ll
send more information if it s requested.
Thanks in advance.
Nawfel Oujdi
here is the result of ngrep:
U 2011/01/13 15:14:43.791514 cisco_gw:51703 - sip_server:5060
INVITE sip:91500@sip_server:5060 SIP/2.0.
Via: SIP/2.0/UDP cisco_gw:5060;x-route-tag=cid:Orange@cisco_gw.
From: sip:911873699@cisco_gw;tag=4F226C8-2DC.
To: sip:91500@sip_server.
Date: Thu, 13 Jan 2011 14:14:43 GMT.
Call-ID: 4D776A24-1E5611E0-9B81F289-1B94787@cisco_gw.
Supported: timer,100rel.
Min-SE: 1800.
Cisco-Guid: 1295951687-508957152-2608788105-28919687.
User-Agent: Cisco-SIPGateway/IOS-12.x.
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE,
NOTIFY, INFO.
CSeq: 101 INVITE.
Max-Forwards: 6.
Remote-Party-ID: sip:911873699@cisco_gw;party=calling;screen=yes;privacy=off.
Timestamp: 1294928083.
Contact: sip:911873699@cisco_gw:5060.
Expires: 180.
Allow-Events: telephone-event.
Content-Type: application/sdp.
Content-Length: 270.
.
v=0.
o=CiscoSystemsSIP-GW-UserAgent 8894 2421 IN IP4 cisco_gw.
s=SIP Call.
c=IN IP4 cisco_gw.
t=0 0.
m=audio 16924 RTP/AVP 18 101.
c=IN IP4 cisco_gw.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:20.
U 2011/01/13 15:14:43.791893 sip_server:5060 - cisco_gw:5060
SIP/2.0 100 Giving a try.
Via: SIP/2.0/UDP cisco_gw:5060;x-route-tag=cid:Orange@cisco_gw.
From: sip:911873699@cisco_gw;tag=4F226C8-2DC.
To: sip:91500@sip_server.
Call-ID: 4D776A24-1E5611E0-9B81F289-1B94787@cisco_gw.
CSeq: 101 INVITE.
Server: OpenSIPS (1.6.3-notls (i386/linux)).
Content-Length: 0.
.
U 2011/01/13 15:14:43.791957 sip_server:5060 - asterisk_server:5060
INVITE sip:91500@sip_server:5060 SIP/2.0.
Record-Route: sip:sip_server;lr=on;did=015.864b8107.
Via: SIP/2.0/UDP sip_server;branch=z9hG4bK3e35.3ed9b366.0.
Via: SIP/2.0/UDP cisco_gw:5060;x-route-tag=cid:Orange@cisco_gw.
From: sip:911873699@cisco_gw;tag=4F226C8-2DC.
To: sip:91500@sip_server.
Date: Thu, 13 Jan 2011 14:14:43 GMT.
Call-ID: 4D776A24-1E5611E0-9B81F289-1B94787@cisco_gw.
Supported: timer,100rel.
Min-SE: 1800.
Cisco-Guid: 1295951687-508957152-2608788105-28919687.
User-Agent: Cisco-SIPGateway/IOS-12.x.
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE,
NOTIFY, INFO.
CSeq: 101 INVITE.
Max-Forwards: 5.
Remote-Party-ID: sip:911873699@cisco_gw;party=calling;screen=yes;privacy=off.
Timestamp: 1294928083.
Contact: sip:911873699@cisco_gw:5060.
Expires: 180.
Allow-Events: telephone-event.
Content-Type: application/sdp.
Content-Length: 270.
.
v=0.
o=CiscoSystemsSIP-GW-UserAgent 8894 2421 IN IP4 cisco_gw.
s=SIP Call.
c=IN IP4 cisco_gw.
t=0 0.
m=audio 16924 RTP/AVP 18 101.
c=IN IP4 cisco_gw.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=ptime:20.
U 2011/01/13 15:14:43.792775 asterisk_server:5060 - sip_server:5060
SIP/2.0 100 Trying.
Via: SIP/2.0/UDP
Re: [SR-Users] scheduling inside SER
not sure if there is a point in doing that, at least for incoming traffic since it already happens in kernel, unless you want to do it in kernel. jiri On 3/7/13 2:25 PM, irma zujovic wrote: Thank you for your answer. So is there any way to produce some kind of algorithm for prioritization of SIP messages inisde FOKUS IMS Core platform by configuring SER? That was my first goal, when asking the previous question. I tought that scheduling and buffering of messages inside FOKUS IMS is done inside SER, and tought about priorituzation inside SER. If you can help me in any way i would be very greatful. Thank you in advance Irma On Tue, Mar 5, 2013 at 4:13 PM, Jiri Kuthan j...@iptel.org mailto:j...@iptel.org wrote: On 3/5/13 2:36 PM, irma zujovic wrote: Hello, I am using FOKUS IMS Core open source platform, and trying to investigate scheduling and queuing inside IMS. FOKUS IMS uses SER. My question is : where inside SER configuration scripts, the *scheduling * and *queueing *of SIP messages is done? I am interested in a special function or part of the written program. this is not done in SER, it is done in kernel. kernel dispatches incoming traffic to one of multiple processes listening on sockets. Same for outgoing traffic -- SER leaves it to kernel's decision. jiri I hope that engineers that worked on developing of SER could help me with this issue. Thank you in advance Irma _ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org mailto:sr-users@lists.sip-router.org http://lists.sip-router.org/__cgi-bin/mailman/listinfo/sr-__users 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] INVITE messages not authenticated (default configuration)?
well, it is really a matter of policy (and not software) what to
authenticate and opinions on it can differ. I like the pre-configured
options in oob, but that may be very well just because I wrote
them :)
https://github.com/flowroute/kamailio/blob/master/etc/sip-router-oob.cfg
(note it is for sip-router flavor and I'm not sure how far the
kamailio merging process has digged into config files -- the logic
should be apparent though)
I think a simple and reasonable policy is to authenticate *ALL* INVITEs
without To-tag (i.e. those that really initiate a call) and ALL REGISTERs
that have a served domain in From.
It is also worthwhile checking if the digest username corresponds
(equals in the simplest caste) the From URI. Otherwise the proxy
server could accept an INVITE authenticated by f...@bar.com in
digest header field and still permit j...@bar.com in From.
Going more relaxed is certainly unsafe. Challenging more can break
interoperability. (some phones are silly not to support authentication
for BYE, call-forwarding schemes may lead to unexpected domains in
URIs, CANCEL/ACK just don't have it, etc.)
jiri
On 3/7/13 11:20 PM, Paul Belanger wrote:
Greeting,
Hopefully, I'm understanding the following default kamailio.cfg[1]
file. Over the weekend, I was attached by SipVicious. Following
along with the example Daniel[2] create with kamailio and asterisk, I
have almost the same setup. Rather then storing my SIP profiles in
Asterisk database, I have then in Kamailio.
To my point, the attacker was actually able to by pass any sort of
authentication, but simply sending an INIVTE message:
./svmap.py -e 18885551234 kamailio.example.org -m INVITE
Which kamailio, forwarded to Asterisk and because there is no
additional auth within asterisk, was able to hit the asterisk context
for getting processed (they did not get out to the real world).
However, my question is why do we not authenticate INVITE
messages? If my understanding is correct, if would require something
like the following:
if (is_method(INVITE)) {
if (!proxy_authorize($fd, subscriber)) {
proxy_challenge($fd, 0);
exit;
}
}
If so, why not also do it in the default configuration file?
[1]
http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=blob_plain;f=etc/kamailio.cfg;hb=HEAD
[2] http://kb.asipto.com/asterisk:realtime:kamailio-3.3.x-asterisk-10.7.0-astdb
___
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] Remote Party ID
I think the most straight-forward way is to load the RPID in user preferences as AVP, and print the associated AVP from SER script. I guess there is an example of such in the OOB script -- have you tried to look there? -jiri On 12/6/11 2:50 PM, Pavel Segeč wrote: Hi, I'm looking for some recommendations or guidlines. My leading IT department which is providing PSTN connectivity requires to include Remote Party ID in SIP Messages in a case where From URI is not in telco format (I prefer email like style of addressing). How to simply assign to an user its Remote Party ID which will be used when PSTN calling will occure? On what should I focus on? To use user preferences with AVP pairs? or something another? thank palo73 ___ 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] issue tracking system
We use it and keep it rebooting every now and when. -1 -jiri On 7/19/11 8:18 PM, Jason Penton wrote: +1 for Jira. If you have the resources to setup and manage JIRA then I would suggest this too. We use and it is really very good On Tue, Jul 19, 2011 at 8:05 PM, Alex Balashov abalas...@evaristesys.com mailto:abalas...@evaristesys.com wrote: We have been extremely happy with Mantis as a self-hosted approach. It is easy to use, yet has the sophistication and flexibility for a needed to manage a project of non-trivial size. On the other hand, Digium recently moved away from it in favour of JIRA for issues.asterisk.org http://issues.asterisk.org. For fairly large projects like this one[1], I have always favoured internal hosting of such systems in order to maintain maximum control, use optional plugins, make customisations, etc. I think that would make the most sense for the SR/Kamailio community. -- Alex [1] It's not nearly as large as say, the Linux kernel, but it's bigger than 99% of open-source which, after all, consists largely of projects done by one person or a few people at most. -- Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 tel:%2B1-678-954-0670 Fax: +1-404-961-1892 tel:%2B1-404-961-1892 Web: http://www.evaristesys.com/ _ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org mailto:sr-users@lists.sip-router.org http://lists.sip-router.org/__cgi-bin/mailman/listinfo/sr-__users 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] off-topic: jobs projects - figuring out the best solution
I beg to differ -- digging through archives seems a bit impractical to me. I think doing it over web would be a great help. -jiri On 4/6/11 7:38 PM, Klaus Darilion wrote: I think a website does not give any benefit over the business mailing list. regards klaus Daniel-Constantin Mierla wrote: Hello, recently the demand in jobs and projects related to kamailio seemed to increase. I can just say that I am very happy with that. While announcing on the mailing lists is ok, I think we should try to make the process better and more productive, i.e., easier to advertise by publishers and easier to read for those interesting. For that, imo, we need a web page where someone can post such announcements and the others can read it. Since I had this idea in mind for some while, I searched for a dokuwiki plugin that could help, so we can reuse our wiki system. I found bureaucracy plugin, but does not seem to be ready for latest dokuwiki version according to its page: http://www.dokuwiki.org/plugin:bureaucracy But maybe it just works, I should try it instead of waiting, anyhow spare time is not my friend these days... Alternatives would be: - a wordpress plugin - haven't searched for one yet, but there are tons of plugins for WP, maybe one will fit the needs - another web application designed for such purposes My question to you is whether you can recommend a solution which we can evaluate. Ideally (or better said, as many characteristics to be met as possible), the system should be able to: - allow people to post announcements for jobs and projects (with or without prior registration, but with spam prevention - e.g., captcha) - allow to publish details about the job/projects, contact addresses, validity period - allow to invalidate an announcement when the position/project is taken - send an email notification when the announcement is done first time, with a link to the web page of the announcement, so we can send it one to a particular mailing list Cheers, Daniel ___ 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] uri unescape transformation?
On 3/26/11 2:06 AM, Juha Heinanen wrote: i could not find a transformation or function to unescape an uri, such as this: sip%3Atest%40test.fi did i miss it or is there a need to write one? we have never introduced escaping indeed. -jiri -- juha ___ 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] uri unescape transformation?
well shame on me and thanks for catching it :-) -jiri On 3/26/11 7:38 PM, Daniel-Constantin Mierla wrote: On 3/26/11 7:30 PM, Jiri Kuthan wrote: On 3/26/11 2:06 AM, Juha Heinanen wrote: i could not find a transformation or function to unescape an uri, such as this: sip%3Atest%40test.fi did i miss it or is there a need to write one? we have never introduced escaping indeed. Starting with 3.x, by loading pv module you get access to some particular functions called 'transformations' which can be used to escape/unescape string values stored in config file variables. See more at: http://sip-router.org/wiki/cookbooks/transformations/devel Cheers, Daniel ___ 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] about syn_branch
On 3/7/11 9:50 AM, Juha Heinanen wrote: we noticed that if sr 3.1 config does not contain syn_branch=0 then acks to 200 oks that are t_relayed by sr, contain branch=0 param in topmost via. in kamailio 1.5, via branch param has proper value even when tm param syn_branch is not set. What is proper value? (Some frequently think that downstream entities must be able to rely on branch(Via)==branch(ACK), which is not granted since without RR-ing the ACK can take a shorter path resulting in a very different ACK.) a couple of questions: 1) according to core cookbook, syn_branch core param only affects stateless forwarding. in my config, all acks are t_relayed, i.e., syn_branch param should not have any effect, but is does. how is that possible? is there a bug in core cookbook? In fact, ACK is forwarded statelessly even when INVITE is processed using TM. A loose definition of stateful is message you hold for future retransmissions. You don't retransmit ACKs and therefore you don't store them in SR. All of this confusion comes from ACK being a very special kind of request -- like INVITE it has same Cseq, unlike INVITE it may have a different forwarding path, Via stack, topmost branch, to-tags... it is a confusing protocol design. It should have been better a cleanly separated SUB-NOT-like transaction pair, than a merged INV-180-200-ACK hack. 2) should t_relaying of acks to 200 oks use proper (i.e.. non 0) Not sure what proper would be, as the branch parameter doesn't play any role for matching messages neither downstream nor at SR. We can make it look better but I'm wondering if it would improve something. via branch param even when syn_branch is not set to any value in config? if not why? if yes, will branch=0 be used only when ack to 200 ok does not match any invite transaction? Is there something which doesn't work as is? -jiri ___ 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] about syn_branch
On 3/7/11 10:40 AM, Juha Heinanen wrote: see above. we have seen rfc3261 sip user agents that don't understand branch=0 value That's probably good enough argument, as some newer implementations may give up on RFC2543 backwards compatibility and complaing about lack of branch. and matching of ack fails. so instead of doing full md5 calculation, it would make sense to use rfc3261 compliant constant rather than 0. Agreed, that would probably serve the purpose well. -jiri ___ 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] SIP Recorder
the SIP proxy server does not see media indeed, you better look at a media server such as SEMS. (iptel.org/sems) jiri On 1/26/11 2:41 PM, Danny Dias wrote: Hello my friends, I have a requeriment, which indicates that i have to record every SIP conversation between peers (also for callings to the PSTN); the recording server will be built for our company following this requeriments (also requested for the client): My doubt is: How can i handle sip conversations recording when all the calls are passing through a Proxy Server? I do understand that the media is always peer to peer and the signaling goes through the Proxy, but in this case the media not only has to pass between the peers because it must be recorded. How should i handle this? ___ 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] SIP Recorder
As said, SER is not the best vehicle for that as it in its SIP proxy definition does not process media. SEMS does this (recording, mixing, storing) quite decently. I'm just wondering what is the reason that Asterisk can't be used -- perhaps SEMS would fail that criteria as well. -jiri On 1/26/11 6:43 PM, Danny Dias wrote: Many thanks Jaremya, The main problem is that both terminals, SHALL (required and must not be changed, because of standards of EUROCAE ED-137 Part3) initiate a session with the recorder server (a commercial one, can't use Asterisk for my disgrace) sending INVITE and receiving the subsequent responses from sip recording server to stablish the session with it...after this, when the media starts to go directly peer to peer (the normal call), the terminals (specials ones) must summarize the IN+OUT audio to the recording server and through rtsp the media should be recorded...it's weird, but thats the requirement :S i mean signaling: APROXYB (the normal procedure) At the same time, this must be done: (I'm not sure how to do this...the proxy could be out of this or not, not sure :() A ---INVITE--- SIP_PROXY ---INVITE--- SIP_RECORDER B ---INVITE--- SIP_RECORDER --INVITE-- SIP_RECORDER Then, The audio will go directly from A to B (because of the normal procedures), and also, A and B, will summarize IN+OUT on each site and send this result through RTSP to the recording server (this is not important to the proxy righ not)...My real doubt is how to stablish the session between the peers A and B to the recording server through the Proxy and also (at the same time) continue with the normal flow of the call (invite from a to b, 200 ok viceversa etc etc...) Should i use some function like t_replicate to send 2 invites like this: A --INVITE-- PROXY --INVITE-- B . . INVITE . RECORDER SERVER But the problem here is that the session between A and PROXY would be OK, but i can't see the way how B should send INVITE to the recorder server.. I hope to be clear on my problem :( and i know it looks very weird, but it's the requirement of the document mentioned above Thanks in advance!!! 2011/1/26 r...@dimension-virtual.com mailto:r...@dimension-virtual.com Danny Dias ing.diasda...@gmail.com mailto:ing.diasda...@gmail.com escribió: Thanks Jeremya, but it's a requeriment from the client to record the calls through an external server and not with rtpproxys, my question is how the media should be handled in order to record the conversations if the server is external? Signaling: Phone_A --- Proxy --- Phone_B Media: Phone_A --- SIP RECORDER --- Phone_B (Changing the SDP headers to send RTP to the IP of the SIP RECORDER). The main problem is that the recording must be made in ACTIVE way, it means, we should record (IN+OUT) in Phone A, and the same in B, 2 recording for each call...the customer says that it's working now in his arquitecture (its analog), and we made the same with the IP technology...resuming: with a sip recorder in the middle of the media should work right? 2 ways of doing that: a) Signaling: A - Proxy - B2BUA (recorder) - B Media: A - B2BUA - B b) Prefered way Signaling: A - Proxy - B Media: A- RTPPROXY - B At the end, both solutions are THE SAME, what you do is to tell A to send media to the B2BUA or the RTPPRoxy. As a matters of scale ... b) solution is the best one. Also, another things to take into account are: 1- Transcoding issues (RTPPRoxy does not do transconding, not easly) 2- Secured RTP (ZRTP, SRTP, etc.) 3- LAG in audio. This message was sent using IMP, the Internet Messaging Program. ___ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org mailto: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] multidomain: running multiple kamailio on one host
You can also serve multiple domain with a single instance. -jiri On 11/5/10 9:15 AM, Jon Bonilla (Manwe) wrote: El Fri, 05 Nov 2010 09:10:15 +0100 MÉSZÁROS Mihálym...@alma.ki.niif.hu escribió: Hello all! Is there any known problem to run multiple kamailio/sip-router instance in one host. No problem at all. ___ 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] Stateful vs. stateless replies from script
On 10/7/10 12:16 PM, Andrei Pelinescu-Onciul wrote: On Oct 07, 2010 at 10:57, Jiri Kuthanj...@iptel.org wrote: There's a bit of a misunderstanding here. ... Now consider an authenticated message that is retransmitted: the first message will pass authentication, but it's retransmission will fail = I admit I haven't thought it through but would it really fail? in both cases (retransmission and replay attack) it will resend initial answer (100 if forwarded, challenge if failed to authenticate) and do nothing downstream -- attacker won't gain an unfair advantage, won't it? the retransmission will be challenged. why if the original request passed authentication? I see the point TM can't differentiate between retransmissions and replay attacks easily (unless we do more of nonce-based protection). But does it really matter? -jiri ___ 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] Stateful vs. stateless replies from script
inline
On 10/7/10 11:11 AM, Alex Balashov wrote:
On 10/07/2010 04:57 AM, Jiri Kuthan wrote:
The problem is that somewhat increased can be A LOT. transaction
context is in order of kilobytes and creating transaction context
on every single request can exhaust memory very very quickly.
It is not just about evil attacks but also about resilience against
different sorts of misconfigurations which flood the server with
traffic. Which happens.
Thanks to you and Marius for taking the time to formulate thorough replies. I
read them with interest!
Is the problem you mention above not mitigated to some extent by the fact that
a transaction is not created until either t_newtran() or t_relay() is called?
For
example:
route {
...
if(is_method(INVITE)) {
...
if(!check_from()) {
xlog(L_ERR, [...] From URI user part does not
match authorisation username!\n);
send_reply(403, Forbidden);
exit;
}
...
if(!t_relay())
sl_reply_error();
}
As far as I know, the 403 Forbidden above would go out statelessly, right?
yes
So, I assume that the misconfigurations and memory exhaust vulnerabilities
under discussion are -- if it is INVITEs we are talking about -- ones in which
the
request is relayed and the negative replies come end-to-end from upstream,
right?
I was refering to all other checks you may want to do before you establish
transaction context and forward. Particularly if you do authenticate. Generally
the default way of scripting was based on the assumption don't establish
transaction/forward until it is clear you want to forward.
But in that case, by virtue of having called t_relay(), the reply is already
processed statefully.
Yes, but I was making a point to a different case. Again -- I think the question
is when does the script writer choose that a request is good enough to be
processed.
Before all sort of tests the writer chooses to deploy are positive, stateless
reply seems safer to me.
Now, of course, there are other types of request handling where a transaction
is implicitly created, but am I correct in my interpretation of INVITE handling
vis-a-vis transaction creation above?
Yes. Until you do some t_command, there is no transaction contet. Once you do,
there is. The point is really in the script that incorporates some request
filtering policy -- what is good enough to spend memory on...
-jiri
Thanks,
___
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] Stateful vs. stateless replies from script
On 10/7/10 10:42 AM, Alex Balashov wrote: Now that K v3.1.0 provides send_reply(), what is the preferred ideology about whether to send stateful or stateless negative error replies? I mean in general, not in specific cases like digest authentication in the new 'auth' module, where, according to the docs, a transaction and stateful replies are required in order for enhanced nonce replay protection. That's a fair point -- transaction processing could be used as nonce memory to mitigate replay attacks. For that however transaction processing would have to be in script earlier before anything else (sending a positive reply, doing anything that's subject to authentication), and the nonce verification would have to be bound to transaction id. Otherwise a replay attack could occur just with a different transaction id, so that TM would not filter it out. One could see it as a trade-off between a bit better replay-attack resilience and a bit higher vulnerability to memory exhaustion. Both kind attacks are possibly either way, so it is not a really either-or type of choice. The traditional wisdom in past bodies of scripts and knowledge in the public realm has been, in my interpretation, that stateless replies are acceptable for final negative responses from script[1]. After all, a reply like 404 Not Found from the proxy is basically fire-and-forget; why devote additional transactional memory to it while the transaction hold-down timer expires? We do not care if we receive an ACK, nor want anything further to do with this branch. Yes, that has been the purpose. On the other hand, there is a point of view out there that mixing stateless and stateful replies is not good, despite the somewhat increased overhead and resource usage associated with making all replies stateful. The problem is that somewhat increased can be A LOT. transaction context is in order of kilobytes and creating transaction context on every single request can exhaust memory very very quickly. It is not just about evil attacks but also about resilience against different sorts of misconfigurations which flood the server with traffic. Which happens. This perspective emphasises that if the proxy is fundamentally operating in a stateful manner, it should do so with respect to all messages, rather than allowing a large category of replies to slip under the radar of TM and have possibly inconsistent results. For now, I have changed my code to use send_reply() in all cases where sl_send_reply() was used in the past; it seems easier to let Kamailio/SR make the decision. However, in practice, most requests will result in the creation of a transaction, so it is like replacing sl_send_reply() with t_reply() in the majority of cases. Am I missing anything? Any salient considerations I missed? I think the argumentation is perfectly right, it is just the operational trade-offs to be made. I am curious as to the consensus about the best practice here from the vantage point of the developers. I'm personally most worried about memory exhaustion, but that's really my choice which I would not advertise as generally applicable/best/whatsoever. Eventually that's why we haven't cemented one way or other. -jiri Thanks, -- Alex [1] Except in FAILURE-ROUTEs, from which only stateful replies may be issued. ___ 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] Wrong handling CANCEL message
Iñaki Baz Castillo wrote: 2010/4/30 Klaus Darilion klaus.mailingli...@pernau.at: 200 OK seems correct as long as the transaction is still in memory. http://tools.ietf.org/html/rfc3261#section-9.2 I don't agree. As per RFC 3261 when a proxy receives a 200 for an INVITE the transaction is terminated so a CANCEL after the 200 should not match such transaction. That's a bug in the RFC and we shall not better projects RFC bugs in implementations :) A well behaving proxy shall keep the context for some period of time. Then the proxy should reply 481 to the CANCEL rather than a 200. well, once the transaction is gone, forwarding the CANCEL statelessly would seem a legitimiate behaviour, as long as the proxy is in position to produce branch ID consistently with that for INVITE. -jiri ___ 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
