On Fri, Jan 10, 2003 at 08:38:03PM +0100, Jan Janak wrote:
Sounds good, go ahead. If you need any implementation-related advice, post a message to the mailing list, I will try to reply asap, some parts haven't been well documented yet so don't hesitate to ask.
Thank you for your kind proposal!
I have one question:
Am I correct that in order to change some field in header I have to do the following:
1. Check that _m->somefield is NULL and call parse_headers() with the appropriate HDR_FOO flag. 2. Check that _m->somefield is non-NULL and return if false. 3. Modify _m->somefield according to the type of that field. 4. Using del_lump() mark original version of the header for deletion and using insert_new_lump() indicate where modified version should be placed before sending a message out.
-Maxim
regards, Jan.
On 10-01 19:27, Maxim Sobolev wrote:
On Fri, Jan 10, 2003 at 03:37:46PM +0200, Maxim Sobolev wrote:
Sounds reasonably - I'll do it that way.
I am planning add a new nathelper module, which will export the following functions:
add_rport() - insert a rport= parameter into the first Via field fix_nated_contact() - replaces host:port in Contact field with host:port we received this message from add_direction_passive() - adds direction=passive option to the SDP
Then it would be possible to do the following at the very top of config before any other REGISTER/INVITE processing:
if (method == "INVITE" || method == "REGISTER") { if (search("User-Agent: Cisco ATA.*") { add_rport(); if (method == "INVITE") { add_direction_passive(); }; if (method == "REGISTER") { fix_nated_contact(); }; }; };
Does it sound reasonably for you?
-Maxim
Thanks!
-Maxim
On Fri, Jan 10, 2003 at 02:15:11PM +0100, Jan Janak wrote:
On 10-01 14:32, Maxim Sobolev wrote:
Folks,
I need an advise on how to better implement one feature, which isn't currently present in SER. We need to allow UAs behind NAT properly register with the registrar - by "properly" I mean that host:port portion of URI in Contact field should not be used, but host:port the request came from should be used instead. By definition we know that those UAs will support symmetric SIP signalling, so that this scheme will work just fine.
In my opinion there are two ways to do it: either add new rewritecontact* family of functions similar to rewritehost ones. or add a new flag for the save() function. This is where I need your help - which implementation looks better for you (or maybe you have even some better idea), since we are really interested in inclusion of our changes into the mainline to reduce our local hacks.
This should be implemented as a standalone module for ser. I want to keep registrar clean, it should not be aware of NATs. So, create a new module for ser that will contain all the NAT traversal helper functions, the functions will be then called from the config script.
That includes modifications of contact, adding rport to Via and so on.
regards, Jan.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers