THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A new Flyspray task has been opened. Details are below.
User who did this - Pascal Maugeri (pmaugeri)
Attached to Project - sip-router
Summary - SDP parsing when dealing with multi-part bodies
Task Type - Bug Report
Category - Core
Status - Assigned
Assigned To - Andrei Pelinescu-Onciul
Operating System - All
Severity - Low
Priority - Normal
Reported Version - Development
Due in Version - Undecided
Due Date - Undecided
Details - I got the following error when dealing with SIP INVITE with multi-part when the client is behind NAT:
May 12 15:27:04 test /usr/sbin/kamailio[1792]: ERROR: nathelper [nathelper.c:2954]: can't extract body from the message
The SIP INVITE message looks like:
INVITE sip:toto@test.net SIP/2.0
[...]
Content-Type: multipart/mixed;boundary=gnkr
Content-Length: 659
--gnkr
Content-Type: application/sdp
Content-Length: 330
v=0
o=pascal 1273565967736 1273565967737 IN IP4 10.1.1.226
[...]
It looks the Content-length within the multi-part is not accepted.
I fixed it changing the source code of parser/sdp/sdp_helpr_funcs.c, in get_sdp_hdr_field() function:
switch(hdr->type){
case HDR_CONTENTTYPE_T:
case HDR_CONTENTDISPOSITION_T:
replaced with:
switch(hdr->type){
case HDR_CONTENTTYPE_T:
case HDR_CONTENTDISPOSITION_T:
case HDR_CONTENTLENGTH_T:
(I'm using kamailio 3.0.1)
Cheers
Pascal
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=73
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A user has added themself to the list of users assigned to this task.
FS#73 - SDP parsing when dealing with multi-part bodies
User who did this - Pascal Maugeri (pmaugeri)
http://sip-router.org/tracker/index.php?do=details&task_id=73
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A user has added themself to the list of users assigned to this task.
FS#72 - allow rewriting request uri also in failure route
User who did this - Juha Heinanen (jh)
http://sip-router.org/tracker/index.php?do=details&task_id=72
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A new Flyspray task has been opened. Details are below.
User who did this - Juha Heinanen (jh)
Attached to Project - sip-router
Summary - allow rewriting request uri also in failure route
Task Type - Improvement
Category - Core
Status - Assigned
Assigned To - Andrei Pelinescu-Onciul
Operating System - All
Severity - Medium
Priority - Normal
Reported Version - Development
Due in Version - Undecided
Due Date - Undecided
Details - in order to make life of module and script writer easier, allow rewriting of request uri also in failure route similar to what has been done in opensips 1.5:
There is no need to call "append_branch()" function in failure_route in order to use the RURI - you still need to use it only if you want to do parallel forking.
Ex:
# in 1.4.x
failure_route[2]
if (t_check_status("408")) {
# set new RURI
rewritehostport("my_voicemail.com:5060");
append_branch();
t_relay();
}
}
->
# in 1.5.x
failure_route[2]
if (t_check_status("408")) {
# set new RURI
rewritehostport("my_voicemail.com:5060");
t_relay();
}
}
-- juha
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=72
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
Module: sip-router
Branch: master
Commit: 53bb79cef5eb70e98472903ef84b5585cc798e65
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=53bb79c…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Committer: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: Thu May 13 11:41:06 2010 +0200
registrar(k): reset dst uri in lookup
- upon lookup, dst uri is reset if no new dst uri is set from received
or path, otherwise the coordinates of selected contact are not
effective
- reported by Andreas Granig
---
modules_k/registrar/lookup.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/modules_k/registrar/lookup.c b/modules_k/registrar/lookup.c
index c758c84..4a573d1 100644
--- a/modules_k/registrar/lookup.c
+++ b/modules_k/registrar/lookup.c
@@ -105,6 +105,9 @@ int lookup(struct sip_msg* _m, char* _t, char* _s)
goto done;
}
+ /* reset next hop address */
+ reset_dst_uri(_m);
+
/* If a Path is present, use first path-uri in favour of
* received-uri because in that case the last hop towards the uac
* has to handle NAT. - agranig */