[SR-Users] New developer: Alexandr Dubovikov
Hello, a new person has now developer access to GIT repository - Alexandr Dubovikov, contributor in the past with patches, is going to work now on extensions related to Homer project - turning the SIP server in a SIP capturing server. His developer id is adubovikov. You can read more about Homer project at: * http://code.google.com/p/homer/ * http://www.kamailio.org/events/2011-Cluecon/AD-Homerv2.pdf Cheers, Daniel -- Daniel-Constantin Mierla -- http://www.asipto.com Kamailio Advanced Training, Oct 10-13, Berlin: http://asipto.com/u/kat http://linkedin.com/in/miconda -- http://twitter.com/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
Re: [SR-Users] The not so simple Kamailio Load Balancing of Asterisk
On 8/18/11 12:24 AM, Stefan Sayer wrote: Wouldn't it make more sense to add current load information to some headers of all messages coming from asterisk? most probably, the app/media server/gateway is sending messages to the proxy very often anyway, and if not, some options pinging can be done if there's no traffic for a while (probably proprietary format - at least I don't know about a standard defined for that). The dispatcher module can send OPTIONS requests to see if the peers are still available. The reply to them can include such headers. This can be a way of communication, indeed. Cheers, Daniel Stefan o Edson - Lists on 08/17/2011 03:36 PM: Couldn't this be already doable through Lua or other external way? Something like ask all asterisk box about their load and return the next to receive the call? Edson. Em 17/08/2011 07:17, Daniel-Constantin Mierla escreveu: On 8/17/11 12:07 PM, Olle E. Johansson wrote: At some point I would love integrating Asterisk AMI feedback into the scheme. If we do that, we can get proper load balancing for Asterisk, based on current usage and capacity of each server, not just calls sent to them from Kamailio. That would be indeed useful -- if you hurry up, you can make it to upcoming v3.2.0 :-) 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 -- Daniel-Constantin Mierla -- http://www.asipto.com Kamailio Advanced Training, Oct 10-13, Berlin: http://asipto.com/u/kat http://linkedin.com/in/miconda -- http://twitter.com/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
Re: [SR-Users] The not so simple Kamailio Load Balancing of Asterisk
On 8/17/11 3:36 PM, Edson - Lists wrote: Couldn't this be already doable through Lua or other external way? Something like ask all asterisk box about their load and return the next to receive the call? This is doable, indeed, but Lua or C or ... will require some some coding ... hope to see such implementations in public space soon :-) Cheers, Daniel Edson. Em 17/08/2011 07:17, Daniel-Constantin Mierla escreveu: On 8/17/11 12:07 PM, Olle E. Johansson wrote: At some point I would love integrating Asterisk AMI feedback into the scheme. If we do that, we can get proper load balancing for Asterisk, based on current usage and capacity of each server, not just calls sent to them from Kamailio. That would be indeed useful -- if you hurry up, you can make it to upcoming v3.2.0 :-) 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 -- Daniel-Constantin Mierla -- http://www.asipto.com Kamailio Advanced Training, Oct 10-13, Berlin: http://asipto.com/u/kat http://linkedin.com/in/miconda -- http://twitter.com/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
Re: [SR-Users] decode_mime_type error
Hello, On 8/19/11 2:09 AM, Bucur Marius wrote: Hi Jijo, In my opinion, decode_mime_type is broken, and parse_accept_body does not work as expected. For example, this is a valid accept header: accept: text/plain;param=,some value. but the parse_accept_body will return -1 because the first return value of decode_mime_type is ,some value\. The second invocation will think some value\ is a mime type, which obviously isn't. I must say I never saw such an accept header, but the standard permits it. Indeed, a quick fix would be to ignore the return code when comma is found. This must be done for other functions that call decode_mime_type like has_body(mime) in textops. This is just my opinion, but I think this solution is a bit hackish since the convention, the promise that decode_mime_type should respect is to return a non-NULL, non-end pointer ONLY when there are more mime types in the body. And it doesn't. A lot of functions that call it rely on this. I think it is easier/more elegant to fix the bug in the decode_mime_type then to change the function convention in all callers. Also, this might work for most callers, but parse_accept_body will still be buggy, as I explained in the example above. this has to be fixed, the safest way not to forget about this is to open an issue on bug tracker. Cheers, Daniel Cheers, Marius From: Jijorealj...@gmail.com To: Bucur Mariusbucur_marius_ovi...@yahoo.com Sent: Thursday, August 18, 2011 10:48 AM Subject: Re: [SR-Users] decode_mime_type error Hi Marius, Right, the same function is used for Accept and Content-Type. I don't think there is any change required for parsing Accept. In case of Accept the function decode_mime_type is called in a loop until it find all the media types. On the returning from decode_mime_type(), the main function parse_accept_xxx() checks the pointer is 'comma' or not. if its comma, then the function decode_mime_type called again and find the remaining media types. So i think the existing implementation for Parsing Accept is fine. The only change required here is not return error for comma while parsing the Content-Type. Thanks Jijo On Thu, Aug 18, 2011 at 12:32 PM, Bucur Mariusbucur_marius_ovi...@yahoo.com wrote: Hello Jijo, You are right, multiple mime-types are not allowed. But it seems like decode_mime_type had the purpose of also parsing the Accept header: Accept: text/html, image/jpeg, multipart hence the search for commas :). The only function that uses this feature and calls decode_mime_type in a loop is parse_accept_body. The other functions that call decode_mime_type just fail when returning ret != end, and since multiple mime types in content-type are not allowed the behavior is fine. The bad thing is the Accept header can have mime parameters too (which can contain comma). Accept= Accept HCOLON [ accept-range *(COMMA accept-range) ] accept-range = media-range *(SEMI accept-param) media-range= ( */* / ( m-type SLASH * ) / ( m-type SLASH m-subtype ) ) *( SEMI m-parameter ) So I think the best thing would be to change decode_mime_type so that it does a more thorough parsing (e.g. check for parameter) hence a parameter value can contain commas (only if quoted). Cheers, Marius From: Jijorealj...@gmail.com To: Bucur Mariusbucur_marius_ovi...@yahoo.com; SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing Listsr-users@lists.sip-router.org Sent: Thursday, August 18, 2011 8:04 AM Subject: Re: [SR-Users] decode_mime_type error Hi Marius, Thanks for the response.. I checked the other functions, but they don't have the check for ret !=end, but they check the pointer and if it is comma then loop through again until it find all the media types. As per the RFC3261 multiple media-types are not supoorted in the Content-Type. So I'm not sure why the author used comma to determine multiple media types . Probably just followed like Route or Record-Route headers..?? Content-Type = ( Content-Type / c ) HCOLON media-type media-type = m-type SLASH m-subtype *(SEMI m-parameter) m-type = discrete-type / composite-type discrete-type= text / image / audio / video / application / extension-token composite-type = message / multipart / extension-token Record-Route = Record-Route HCOLON rec-route *(COMMA rec-route) Thanks Jijo On Thu, Aug 18, 2011 at 2:23 AM, Bucur Mariusbucur_marius_ovi...@yahoo.com wrote: Hello Jijo, It seems like the decode_mime_type is a somehow broken. The comma is very well allowed in boundary, as you said. The BNF specified in RFC2046 permits it. But, the decode_mime_type function ignores everything coming after comma. More than that, it notifies the function caller that this content type has multiple mime types. I think the author of the function thought of something like: Content-Type: text/html, image/jpeg // very weird, though
Re: [SR-Users] LCR Modules Comparison
Hello, some comments inline... On 8/18/11 12:59 PM, Henning Westerholt wrote: On Wednesday 17 August 2011, Spencer Thomason wrote: Can anyone shed some light into the differences between the available LCR modules? We have migrated our config from OpenSIPS where we used the drouting module to Kamailio where we are using the lcr module. Our ruleset is not crazy huge, about 100k entries. Are there compelling reasons to choose one module over the other? Is there one that has the most active development behind it and is a standard for the platform or is there one that will be deprecated in the foreseeable future? Hi Spencer, the carrierroute module is also actively maintained, mtree as well. The drouting is available but probably the one with the least usage here. Its initial import has been done from Raul Alexis and I guess they use it in production, but don't know details. There were also some patches from other people in the last year, but recently it has seen not that much activity. The modules differ mostly in their provided configuration interface, their capabilities and the internal used datastructures IMHO. lcr * introduced in 0.9.x times, reworked several times * provided initially support for a limited number of routes, today it supports large route sets as well * provides easy failover functionaly to try sequentially several gateways * uses internally a hash table cr * introduced in 1.3, reworked for 1.5 * support larger route sets * provides flexible failure routing capabilities with a dedicated table, but is more complicated to setup and use * uses a trie (tree) internally mtree * introduced in 3.1 * support larger route sets * provides generic tree matching functionality, but without that much additional functionality * uses a tree internally mtree is indeed more like a generic tool to store some data in memory, indexed in a tree, based on prefix-like keys. The you have to do your logic in config file. For example, this module together with dispatcher are used extensively by us to build all kinds of least cost routing systems. drouting * ported from opensips for 3.0 * support larger route sets * provides failover capabilities and some special matching as time or date * uses a trie (tree) internally This modules was actually around since 2005 (see history remarks in modules_k/drouting/drouting.c) and I am very familiar with its code. I'm not using it lately, but if someone reports issues they are going to be fixed. I know many people using it, therefore I guess it just works fine. Cheers, Daniel -- Daniel-Constantin Mierla -- http://www.asipto.com Kamailio Advanced Training, Oct 10-13, Berlin: http://asipto.com/u/kat http://linkedin.com/in/miconda -- http://twitter.com/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
Re: [SR-Users] min expires question
Hello, On 8/18/11 6:20 PM, Fabian Borot wrote: Hello This is how my registrar module is configured, hoping that min-expires set to 30 wont allow registration attempts more often than 30 seconds, but if I configure a UAC to register every 15 seconds I see that kamailio allows it. Shouldn't it reply with 422 Session Interval Too Small or 423 Interval Too Brief? it will not allow a REGISTER with Expires value less than 30sec. But even the phone sends a REGISTER with Expires 3600 (for example), it can send again in 10 sec another REGISTER with Expires 3600. In order to see if there is something incorrect, send us full REGISTER requests and the replies. Cheers, Daniel # - registrar params - modparam(registrar, default_expires, 120) modparam(registrar, min_expires, 30) modparam(registrar, method_filtering, 1) /* uncomment the next line to disable parallel forking via location */ # modparam(registrar, append_branches, 0) /* uncomment the next line not to allow more than 10 contacts per AOR */ #modparam(registrar, max_contacts, 10) 131.380336 192.168.1.6 - 192.168.1.194 SIP Request: REGISTER sip:192.168.1.194 131.381174 192.168.1.194 - 192.168.1.6 SIP Status: 200 OK(1 bindings) 144.386014 192.168.1.6 - 192.168.1.194 SIP Request: REGISTER sip:192.168.1.194 144.387110 192.168.1.194 - 192.168.1.6 SIP Status: 200 OK(1 bindings) 157.395358 192.168.1.6 - 192.168.1.194 SIP Request: REGISTER sip:192.168.1.194 157.396340 192.168.1.194 - 192.168.1.6 SIP Status: 200 OK(1 bindings) 170.404905 192.168.1.6 - 192.168.1.194 SIP Request: REGISTER sip:192.168.1.194 170.405771 192.168.1.194 - 192.168.1.6 SIP Status: 200 OK(1 bindings) 183.414375 192.168.1.6 - 192.168.1.194 SIP Request: REGISTER sip:192.168.1.194 183.415217 192.168.1.194 - 192.168.1.6 SIP Status: 200 OK(1 bindings) txs fborot ___ 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 -- Daniel-Constantin Mierla -- http://www.asipto.com Kamailio Advanced Training, Oct 10-13, Berlin: http://asipto.com/u/kat http://linkedin.com/in/miconda -- http://twitter.com/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
Re: [SR-Users] new functionality: CDR-based accounting
Hello, On 17.08.2011 11:46, Daniel-Constantin Mierla wrote: On 8/11/11 10:12 AM, Timo Reimann wrote: Hey Graham, On 10.08.2011 14:27, Graham Wooden wrote: I would be interested in the 1.5 backported module. Is that available for the masses? I personally wouldn't mind publishing the backport code. One interesting question, however, is in what form to do that. Several approaches come to my mind: - A separate branch with just the patch. - A separate Kamailio 1.5 branch with the modified code. - Distribution via the mailing list. - Distribution in private. Naturally, I'd favor something centralized to allow more people access to the code. @Daniel: What's your thought on this? Do you have a preferred way? Maybe uploading it (a tarball if big or just the patch file) on the tracker is another quite easy possibility. Either on the one from sip-router.org, or, since it is 1.5, can be even on the sourceforge.net. This will allow to upload new versions of the files if changes are needed in the future. Then provide the link to the tracker item on the mailing list. I would prefer no commit on the mainstream SVN branches, so we do not open past releases, that will create lot of confusion. As Daniel suggested, I put the patch on the Sourceforge tracker: http://sourceforge.net/tracker/?func=detailaid=3394470group_id=139143atid=743022 If something's not working as expected, please let me know. Note, however, that support for the 1.5 branch cannot be guaranteed and will discontinue very soon from my side. Cheers, --Timo Note, however, that the time frame we (as in my company) are going to use, support, and maintain the 1.5 backport code is already now foreseeable. Cheers, --Timo On 8/4/11 1:08 AM, Timo Reimanntimo.reim...@1und1.de wrote: Hi all, as announced quite a while ago, I finally checked in code that allows to produce CDRs (Call Data Records) directly from SIP-Router and generate logs accordingly. The main code portion resides in modules_k/acc and provides a switch to enable basic CDR generation including start time, end time, and duration. Analogous to the existing logging approach, you may define an extra parameter covering to-be-included dialog pseudo-variables that must be assigned in the configuration script. The new code will take care of transforming the basic and custom CDR fields into CDR logs at the end of a dialog. Speaking of dialogs: The implementation relies heavily on the dialog module. It takes advantage of dialog variables introduces by Carsten Bock and adds a few more features. Most notably, we had to change the dialog callback signature to provide both request and response messages. Having only one of them proved to be insufficient in certain cases; for instance, a locally generated 408 returned a FAKED_REPLY, thus rendering it impossible to access dialog variables through the PV framework. Other modules using dialog callbacks have been updated along the commit, third-party modules outside the repository will need to do so too (and think about whether using the request or response is the Right Thing to do). Due to the changes brought to the dialog module, I pushed the new acc and dialog code into a separate branch called treimann/acc-cdr. Feel free to give it a try by consulting the updated documentation and suggesting (or, if it's good enough, implementing :) ) improvements. A Kamailio 1.5 backport of the code has been in usage for quite some time with us, so generally there shouldn't be any major logical flaws. SIP-Router certainly needs more testing, however, so I'd be glad for any feedback. My plan is to merge the code into master branch prior to the 3.2 feature freeze, unless significant objections arise. Finally, big-time credits go to my co-worker Sven Knoblich who is the main contributor of the code. He's been working on this stuff for the past few months and dreams in CDRs by now. ___ 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 -- Daniel-Constantin Mierla -- http://www.asipto.com Kamailio Advanced Training, Oct 10-13, Berlin: http://asipto.com/u/kat http://linkedin.com/in/miconda -- http://twitter.com/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
Re: [SR-Users] [sr-dev] New developer: Alexandr Dubovikov
On 19.08.2011 10:44, Olle E. Johansson wrote: 19 aug 2011 kl. 10:23 skrev Daniel-Constantin Mierla: Hello, a new person has now developer access to GIT repository - Alexandr Dubovikov, contributor in the past with patches, is going to work now on extensions related to Homer project - turning the SIP server in a SIP capturing server. His developer id is adubovikov. You can read more about Homer project at: * http://code.google.com/p/homer/ * http://www.kamailio.org/events/2011-Cluecon/AD-Homerv2.pdf Welcome Alexandr! Thank you! /O ___ 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 Wbr, Alexandr ___ 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] Question about encryption with Kamailio
Hello all,
Thanks Klaus for your answer, it helps me a lot !!
For my configuration, do I need to install a database ?
After doing some research, I think for routing purposes a database is not
needed...
Thanks you very much for your input,
Regards
Message du 13/08/11 08:38
De : Klaus Darilion
A : sr-users@lists.sip-router.org
Copie à :
Objet : Re: [SR-Users] Question about encryption with Kamailio
On 12.08.2011 14:56, margot.basa wrote:
Hello all,
I would like to use Kamailio to encrypt contents of SIP messages (using
SIP TLS) between 2 endpoints, i.e.:
- To use 5061 port instead of 5060 port,
- To use sips uri instead of sip uri...
For example, T1 and T2 communicates with Server A like that:
1) T1 and T2 send REGISTER to Server A
2) T1 and T2 received 200 OK from Server A
...
3) Server A sends an INVITE message to T1 and T2
...
4) RTP flow between T1 and T2 (this should not be encrypted)
...
5) Server A sends a BYE request to T1 and T2
...
All those exchanges are made on Transport layer TCP or UDP on port 5060.
T1 and T2 are not able to support TLS but Server A needs to
receive/send messages in SIP TLS.
I would like to insert Kamailio between T1 and Server A, T2 and
Server B in order to encrypt contents of SIP messages.
I have some questions about that:
- I think Kamailio can do that but I am not sure, can you confirm that
to me please?
Yes, you can do that with Kamailio
- Can I use Kamailio as it is to do that?
Almost yes. You only have to load the TLS module and tell Kamailio to
listen on port 5061 for TLS.
Probably some modifications to the default configuration are needed.
- Do I have to add a Route header in requests in order that requests
between T1 and Server A go through Kamailio
Yes. When record-routing is activated (it is activated in the default
config), all in-dialog requests (ACK, reINVITE, BYE) will be routed
automatically via Kamailio.
The more complicated part will be the initial requests (REGISTER,
INVITE). Requests from the clients to the server are quite easy to handle:
if (src_ip != ip.address.of.server) {
$du = sip:ip.address.of.server;transport=tls;
t_relay();
Complicated are INVITEs from the server to the client. Usually during
registration the server stores the contact information of the client, to
send incoming calls to this address. This is either the information in
the Contact header, or the IP address:port from which the REGISTER was
received (if the server performs NAT traversal).
Both cases are bad - as the server should send the request to Kamailio,
but Kamailio needs to know where to forward the request.
The proper solution is using Path - see documentation of the Path
module. If your servers supports Path, then you are finished.
If your server does not support Path, there are 2 approaches:
A) The server stores the Contact, but sends the INVITE requests always
to Kamailio. Therefore, the server needs some kond of outbound proxy
functionality.
B) Kamailio stores the contact of the client, and forwards the REGISTER
with a contact pointing to itself. Thus, server will lookup the client,
finds the IP address of Kamailio and forwards the request. Then Kamailio
again looks up the client in the location table and then forwards the
request. This only works, if Kamailio puts an unique identifier of the
client into the username part of the Contact header.
- Does Kamailio is able to intercept SIP packets automatically (with a
certain configuration)?
No. Other nodes have to send SIP messages to Kamailio. This is why
record-routing is needed to tell the other clients to route in-dialog
requests via Kamailio too.
- Do you know difference between Freeswitch and Kamailio? (because I
have seen that Freeswitch can do what I need:
see Figure4: http://wiki.freeswitch.org/wiki/SIP_TLS)
No.
Klaus
Thank you very much for your input.
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
Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ?
Je crée ma boîte mail www.laposte.net
___
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] E2E ACK is not logged with siptrace modul kamailio
Hello,
On 8/18/11 4:12 PM, MÉSZÁROS Mihály wrote:
Hi Daniel!
Thank You very much!
I tested it, and it seems to be working for me!
ok.
Only one typo what i corrected.
You have missed out the beginning from your example.
if(method==ACK) sip_trace();
Thank you again!
By the way two problems with git HEAD.
I checked out the current git HEAD, and I have experienced these two
problems:
1.
modul purple is not compiled for me.
hal:/usr/local/src/sip-router/modules_k/purple# make
CC (gcc) [M purple.so] clientpipe.o
In file included from purple.h:23,
from clientpipe.c:28:
/usr/include/libpurple/status.h:93: error: expected
specifier-qualifier-list before 'gpointer'
make: *** [clientpipe.o] Error 1
There was a change in the libpurple API and the module was not updated
for latest version of libpurple -- it has no active maintainer. However,
this module is not compiled by default, if you need it either update it
to latest purple library or use an older version of that library.
2.
htable-create.sql
MYSQL table create is giving back error. The problem is VARCHAR
without length.
diff --git a/utils/kamctl/mysql/htable-create.sql
b/utils/kamctl/mysql/htable-create.sql
index 6adfa48..79eb43b 100644
--- a/utils/kamctl/mysql/htable-create.sql
+++ b/utils/kamctl/mysql/htable-create.sql
@@ -5,6 +5,6 @@ CREATE TABLE htable (
key_type INT DEFAULT 0 NOT NULL,
value_type INT DEFAULT 0 NOT NULL,
key_value VARCHAR(128) DEFAULT '' NOT NULL,
-expires VARCHAR DEFAULT 0 NOT NULL
+expires VARCHAR(128) DEFAULT 0 NOT NULL
) ENGINE=MyISAM;
This is fixed now, thanks,
Cheers,
Daniel
Cheers,
Misi
2011-08-17 12:09 keltezéssel, Daniel-Constantin Mierla írta:
Hello,
I have committed the feature to be able to use sip_trace() from
onsend_route, therefore you can catch forwarded ACKs:
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=9d8df2527d13878cee23af5b14f142a0cc4cd878
An example of usage would be:
onsend_route {
}
Let me know if it works.
Cheers,
Daniel
On 8/13/11 9:46 PM, Mészáros Mihály wrote:
Hi Daniel,
Thank you for looking after the issue.
Am I understand you correctly:
You mean that it couldn't be corrected (or it is not the right
solution) in TM to have a callback to messages what are sent out
stateless way, and correct the issue in this way.
So you mean I will have to add siptrace to call logic in config
file to route block onsend_route?
I am looking forward to hear about the fix, after you will be ready
with it.
Many Thanks,
Misi
On 2011-08-12 15:25, Daniel-Constantin Mierla wrote:
Hello,
ok, seems that there is no actual callback for outgoing ACK -- the
same seems to be in 1.x, based on a quick look there -- the
callback for TM outgoing requests is useless since the ACK is
forwarded in stateless mode.
The great thing with 3.x is that we have onsend_route where the
outgoing message content is available, so I just need to code a bit
in siptrace module and have it working properly to store the
outgoing ACKs. I will try to do it asap.
Cheers,
Daniel
On 8/11/11 9:23 PM, MÉSZÁROS Mihály wrote:
Hello Daniel,
I appreciate highly your help!
Cheers,
Misi
2011-08-11 20:41 keltezéssel, Daniel-Constantin Mierla írta:
Hello,
I will look to see what happens with the outgoing ACK, probably
tomorrow or so. Btw, there is no need to apologize, here are open
discussions, reporting issues, throwing ideas, bad or good, the
conclusion comes after some analysis and help from the others.
It's hard to know everything and who does not care does not
participate.
Cheers,
Daniel
On 8/11/11 4:32 PM, MÉSZÁROS Mihály wrote:
Hi Daniel,
I put on setflag before WITHINDLG,
so AFAIK the ACK as a new transaction is executing this step.
The root of my problem is that I can see the incoming E2E ACK,
but i couldn't see the outgoing!
route {
#pike flood detection
if (!pike_check_req()) { exit; };
# per request initial checks
route(REQINIT);
#siptrace
setflag(22);
sip_trace();
xdbg(SIP Request: \n $mb \n);
# NAT detection
route(NAT);
# handle requests within SIP dialogs
route(WITHINDLG);
And in debug i can't find where want kamailio log/trace the
_outgoing_ message.
I can see only that it will be forwarded in stateless way.
This is why i started to dig in sl modul. But thank You, now i
see it was a mistake. soy.
Sorry for the early case opening, you are right not sl causing
that. I thought i find something. sorry again.
But i can see only incoming E2E ACK and I can't see the outgoing
pair in siptrace.
In TM modul i can't see where it is calling back siptrace in
case of E2E ack.
Aug 11 11:42:06 hal /usr/sbin/kamailio[24381]: DEBUG: core
[socket_info.c:501]: grep_sock_info - checking if host==us:
14==14 [195.11
[SR-Users] masking carriers
Hi, Background: Kamailio 1.5.x + rtpproxy I am not too crazy about telling our customers where we send our calls. But if they take a look at the sip dialog as it is right now, they can see our suppliers/carriers IP addresses. What can we do to mask this, so that the last piece of information stops at our IPs? We are running rtpproxy for the media - if that makes any difference. Someone told me I cannot mask anything without moving to Kamailio 3.x - is that the case? Thanks!! //Anders ___ 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] masking carriers
On 08/19/2011 07:18 PM, Anders wrote: Hi, Background: Kamailio 1.5.x + rtpproxy I am not too crazy about telling our customers where we send our calls. But if they take a look at the sip dialog as it is right now, they can see our suppliers/carriers IP addresses. What can we do to mask this, so that the last piece of information stops at our IPs? We are running rtpproxy for the media - if that makes any difference. Someone told me I cannot mask anything without moving to Kamailio 3.x - is that the case? That is the case. However, if you do move to 3.x, you should look into the 'topoh' (topology hiding) module: http://www.kamailio.org/docs/modules/3.1.x/modules/topoh.html -- Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-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 http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] masking carriers
Someone told me I cannot mask anything without moving to Kamailio 3.x - is that the case? That is the case. However, if you do move to 3.x, you should look into the 'topoh' (topology hiding) module: http://www.kamailio.org/docs/modules/3.1.x/modules/topoh.html Ok, thanks a lot / upgrading time! //Anders ___ 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] decode_mime_type error
Hello Jijo, About the example I pointed, the parse_accept_body will fail and let me explain why. For the second invocation, 'some value' is not a valid mime type (a mime type is of form 'type/subtype'). When decode_mime_type will not find the '/' separator (see parse_content.c:310) it will fail, making parse_accept_body to fail too. If you want to test, just call parse_accept_body with the example I pointed, and you will see it returns -1 for my example (a valid accept header). This is, of course, bad behavior. Best regards, Marius From: Jijo realj...@gmail.com To: Bucur Marius bucur_marius_ovi...@yahoo.com; sr-users@lists.sip-router.org Sent: Friday, August 19, 2011 11:17 AM Subject: Re: [SR-Users] decode_mime_type error Hi Marius, The existing implementation is done considering the limitation of decode_mime_type but somehow missed the change in parse_content_type_hdr. I agree with you that its better to do the change in decode_mime_type as it is common for lot of other callers.. Regarding the example you pointed, According to my understanding from the code, I believe that existing implementation for parse_accept_body shall work as the mime types are predefined. So in the example you pointed for second invocation 'some value' is not a defined mime type as it not matching with predefined types. The decode_mime_type returns end pointer and parse_accept_body shall process only with the valid mime type text/plain. another example with multiple mime types.., Accept: text/html, multipart/mixed In this case parse_accept_body returns 2 mime types as both are predefined in the list. Thanks Jijo On Thu, Aug 18, 2011 at 5:58 PM, Bucur Marius bucur_marius_ovi...@yahoo.com wrote: Hi Jijo, In my opinion, decode_mime_type is broken, and parse_accept_body does not work as expected. For example, this is a valid accept header: accept: text/plain;param=,some value. but the parse_accept_body will return -1 because the first return value of decode_mime_type is ,some value\. The second invocation will think some value\ is a mime type, which obviously isn't. I must say I never saw such an accept header, but the standard permits it. Indeed, a quick fix would be to ignore the return code when comma is found. This must be done for other functions that call decode_mime_type like has_body(mime) in textops. This is just my opinion, but I think this solution is a bit hackish since the convention, the promise that decode_mime_type should respect is to return a non-NULL, non-end pointer ONLY when there are more mime types in the body. And it doesn't. A lot of functions that call it rely on this. I think it is easier/more elegant to fix the bug in the decode_mime_type then to change the function convention in all callers. Also, this might work for most callers, but parse_accept_body will still be buggy, as I explained in the example above. Cheers, Marius From: Jijo realj...@gmail.com To: Bucur Marius bucur_marius_ovi...@yahoo.com Sent: Thursday, August 18, 2011 10:48 AM Subject: Re: [SR-Users] decode_mime_type error Hi Marius, Right, the same function is used for Accept and Content-Type. I don't think there is any change required for parsing Accept. In case of Accept the function decode_mime_type is called in a loop until it find all the media types. On the returning from decode_mime_type(), the main function parse_accept_xxx() checks the pointer is 'comma' or not. if its comma, then the function decode_mime_type called again and find the remaining media types. So i think the existing implementation for Parsing Accept is fine. The only change required here is not return error for comma while parsing the Content-Type. Thanks Jijo On Thu, Aug 18, 2011 at 12:32 PM, Bucur Marius bucur_marius_ovi...@yahoo.com wrote: Hello Jijo, You are right, multiple mime-types are not allowed. But it seems like decode_mime_type had the purpose of also parsing the Accept header: Accept: text/html, image/jpeg, multipart hence the search for commas :). The only function that uses this feature and calls decode_mime_type in a loop is parse_accept_body. The other functions that call decode_mime_type just fail when returning ret != end, and since multiple mime types in content-type are not allowed the behavior is fine. The bad thing is the Accept header can have mime parameters too (which can contain comma). Accept = Accept HCOLON [ accept-range *(COMMA accept-range) ] accept-range = media-range *(SEMI accept-param) media-range= ( */* / ( m-type SLASH * ) / ( m-type SLASH m-subtype ) ) *( SEMI m-parameter ) So I think the best thing would be to change decode_mime_type so that it does a more thorough parsing (e.g. check for parameter) hence a parameter value can contain commas (only if quoted). Cheers, Marius From: Jijo realj...@gmail.com To: Bucur Marius
