Based on the discussions about outbound and in-dialog routing it seems
like we need to use GRUU and live with the fact that the route-set
changes (in breach of RFC 3261).
Can anyone share a Kamailio registrar configuration that uses GRUU to
look-up in-dialog requests (preferably one that makes use of
t_load_contacts(), t_next_contact(), and t_next_contact_flow())?
Regards,
Peter
Hello,
Since this is a significant rewrite of an existing module, I'd like to
ask if anyone has any objections against committing the attached patch.
Functionally, it adds a second parameter to add_path() and
add_path_received(), enabling the script writer to include arbitrary
additional URI parameters in the Path header. It also adds support for
SPVE for all parameters.
Code wise, it rewrites most parts of prepend_path() to make the code
more streamlined, use fewer memory chunks and lumps and (hopefully) make
the code easier to read, shorter, and easier to extend in the future.
I'm attaching the new path.c as well for readability. I haven't included
the updates to docs.
cheers
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A new Flyspray task has been opened. Details are below.
User who did this - Hugh James (hugh.james)
Attached to Project - sip-router
Summary - force_send_socket() doesnt set the source IP address reliably when using uac_req_send()
Task Type - Bug Report
Category - Core
Status - Unconfirmed
Assigned To -
Operating System - Linux
Severity - Medium
Priority - Normal
Reported Version - 4.0
Due in Version - Undecided
Due Date - Undecided
Details - I'm having an issue with force_send_socket(). I have a server with two interfaces on separate sub-nets 192.168.60.xx and 192.168.70.xx , and running Kamailio as a proxy with SIP messaging coming in/out over both interfaces.
I have a second Kamailio running on a second IP (192.168.60.101) address and need to send a custom method between the two instances from time to time.
The custom message has to go from 192.168.60.102 to 192.168.60.101 when a 200-OK to an INVITE arrives and at other similar points in the call.
I'm using the following lines in my configuration script , but it works sometimes and not at other times. Sometimes the message is sent to 192.168.60.101 from 192.168.70.102 (which is the wrong interface) , and therefore doesn't reach the second Kamailio server. It appears as though the message is always sent out on the interface the last message was received on even though I use force_send_socket() to try and set the source IP address for the message
Have I misunderstood the purpose of this function? is there some other way of sending an internally generated message from a specific IP address/interface
I have attached an example wireshark trace showing this behavior
force_send_socket(192.168.60.102:5060);
$uac_req(method)="CUSTOMMETHOD";
$uac_req(ruri)="sip:" + "192.168.60.101" ;
$uac_req(furi)="sip:" + "192.168.60.102" ;
$uac_req(turi)="sip:" + 192.168.60.101 ;
$uac_req(ouri)="sip:" + 192.168.60.101 ;
$uac_req(hdrs)="CSeq: 22 CUSTOMMETHOD\r\n";
$uac_req(hdrs)="Content-Type: text/custom\r\n";
$var(cseqbody) = $var(MessageType)+"?" \
+$ci+"?" \
+$CCM_x1+"?" \
+$CCM_x2+"?" \
+$CCM_x3+"?" \
+$CCM_x4+"?" \
+$CCM_x5+"?" \
+$CCM_x6+"?";
$uac_req(body)= $var(cseqbody);
uac_req_send();
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=294
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 - Víctor Seva (linuxmaniac)
Attached to Project - sip-router
Summary - utils/kamctl: add contact path parameter
Task Type - Improvement
Category - utils
Status - Unconfirmed
Assigned To -
Operating System - All
Severity - Low
Priority - Normal
Reported Version - Development
Due in Version - Undecided
Due Date - Undecided
Details - This patch needs FS#292
+ ul add <user> <uri> <expires> <path> .. introduce a temporary usrloc entry
One or more files have been attached.
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=293
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 - Víctor Seva (linuxmaniac)
Attached to Project - sip-router
Summary - usrloc: use 6th param on add function to set the contact path
Task Type - Improvement
Category - Module
Status - Unconfirmed
Assigned To -
Operating System - All
Severity - Low
Priority - Normal
Reported Version - Development
Due in Version - Undecided
Due Date - Undecided
Details - This patch modifies RPC ul.add and MI ul_add functions to use the 6th (useless) param as path contact value.
One or more files have been attached.
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=292
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.