Hello,
I've made a patch to kamailio-4.0.3 which removes stale registration when kamailio looses an incoming tcp connection. Of course this patch needs more work.
Since the are no direct references between user location contacts and tcp connections callback function uses linear search through the whole location table using received field as a key.
Can anybody more experienced in kamailio internals check if I chose the right place to get information about lost tcp connections ? Another thing I wanted to ask is maybe somebody can suggest a better way to tie a tcp connection to the user location information without complicating "usrloc" module by any heavy data structures.
If anybody else except me need this It would be great to fix known problems and add it to kamailio.
27 aug 2013 kl. 00:29 skrev Vitaliy Aleksandrov vitalik.voip@gmail.com:
Hello,
I've made a patch to kamailio-4.0.3 which removes stale registration when kamailio looses an incoming tcp connection. Of course this patch needs more work.
Since the are no direct references between user location contacts and tcp connections callback function uses linear search through the whole location table using received field as a key.
Can anybody more experienced in kamailio internals check if I chose the right place to get information about lost tcp connections ? Another thing I wanted to ask is maybe somebody can suggest a better way to tie a tcp connection to the user location information without complicating "usrloc" module by any heavy data structures.
If anybody else except me need this It would be great to fix known problems and add it to kamailio. <remove_tcp_contacts.patch>_______________________________________________
This is something required for outbound too. We need to remove the registration and thus the flow if a connection dies. The problem is that we can manage the connection on another server (edge proxy) too.
/O
27 aug 2013 kl. 08:27 skrev "Olle E. Johansson" oej@edvina.net:
27 aug 2013 kl. 00:29 skrev Vitaliy Aleksandrov vitalik.voip@gmail.com:
Hello,
I've made a patch to kamailio-4.0.3 which removes stale registration when kamailio looses an incoming tcp connection. Of course this patch needs more work.
Since the are no direct references between user location contacts and tcp connections callback function uses linear search through the whole location table using received field as a key.
Can anybody more experienced in kamailio internals check if I chose the right place to get information about lost tcp connections ? Another thing I wanted to ask is maybe somebody can suggest a better way to tie a tcp connection to the user location information without complicating "usrloc" module by any heavy data structures.
If anybody else except me need this It would be great to fix known problems and add it to kamailio. <remove_tcp_contacts.patch>_______________________________________________
This is something required for outbound too. We need to remove the registration and thus the flow if a connection dies. The problem is that we can manage the connection on another server (edge proxy) too.
...which is why I earlier proposed an event-route for this use-case.
/O
I started to implement this. It is in a branch somewhere, but I couldn't get it working.
If someone who knows the TCP code better could take a look...
Regards,
Peter
On 26 August 2013 23:28, Olle E. Johansson oej@edvina.net wrote:
27 aug 2013 kl. 08:27 skrev "Olle E. Johansson" oej@edvina.net:
27 aug 2013 kl. 00:29 skrev Vitaliy Aleksandrov <vitalik.voip@gmail.com :
Hello,
I've made a patch to kamailio-4.0.3 which removes stale registration
when kamailio looses an incoming tcp connection.
Of course this patch needs more work.
Since the are no direct references between user location contacts and
tcp connections callback function uses linear search through the whole location table using received field as a key.
Can anybody more experienced in kamailio internals check if I chose the
right place to get information about lost tcp connections ?
Another thing I wanted to ask is maybe somebody can suggest a better
way to tie a tcp connection to the user location information without complicating "usrloc" module by any heavy data structures.
If anybody else except me need this It would be great to fix known
problems and add it to kamailio.
<remove_tcp_contacts.patch>_______________________________________________
This is something required for outbound too. We need to remove the
registration and thus the flow if a connection dies. The problem is that we can manage the connection on another server (edge proxy) too.
...which is why I earlier proposed an event-route for this use-case.
/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
Let's work on a description on the logic needed and see if Vitally's code is close:
1. Connection dies (tcp, tls, sctp) 2. Event-route activates 3. Check if there's a outbound flow with reg-id associated with the flow 4. If not, is there a registration associated with the flow 5. If 3 or 4 is true, do something
Do we have functions for 3 and 4? Can this be done in scripting?
/O
27 aug 2013 kl. 09:18 skrev Peter Dunkley peter.dunkley@crocodilertc.net:
I started to implement this. It is in a branch somewhere, but I couldn't get it working.
If someone who knows the TCP code better could take a look...
Regards,
Peter
On 26 August 2013 23:28, Olle E. Johansson oej@edvina.net wrote:
27 aug 2013 kl. 08:27 skrev "Olle E. Johansson" oej@edvina.net:
27 aug 2013 kl. 00:29 skrev Vitaliy Aleksandrov vitalik.voip@gmail.com:
Hello,
I've made a patch to kamailio-4.0.3 which removes stale registration when kamailio looses an incoming tcp connection. Of course this patch needs more work.
Since the are no direct references between user location contacts and tcp connections callback function uses linear search through the whole location table using received field as a key.
Can anybody more experienced in kamailio internals check if I chose the right place to get information about lost tcp connections ? Another thing I wanted to ask is maybe somebody can suggest a better way to tie a tcp connection to the user location information without complicating "usrloc" module by any heavy data structures.
If anybody else except me need this It would be great to fix known problems and add it to kamailio. <remove_tcp_contacts.patch>_______________________________________________
This is something required for outbound too. We need to remove the registration and thus the flow if a connection dies. The problem is that we can manage the connection on another server (edge proxy) too.
...which is why I earlier proposed an event-route for this use-case.
/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
-- Peter Dunkley Technical Director Crocodile RCS Ltd _______________________________________________ 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
On 08/27/2013 10:22 AM, Olle E. Johansson wrote:
Let's work on a description on the logic needed and see if Vitally's code is close:
- Connection dies (tcp, tls, sctp)
- Event-route activates
- Check if there's a outbound flow with reg-id associated with the flow
- If not, is there a registration associated with the flow
- If 3 or 4 is true, do something
Do we have functions for 3 and 4? Can this be done in scripting?
Haven't seen functions which can do 3 and 4 at the last stable usrloc module.
27 aug 2013 kl. 10:25 skrev Vitaliy Aleksandrov vitalik.voip@gmail.com:
On 08/27/2013 10:22 AM, Olle E. Johansson wrote:
Let's work on a description on the logic needed and see if Vitally's code is close:
- Connection dies (tcp, tls, sctp)
- Event-route activates
- Check if there's a outbound flow with reg-id associated with the flow
- If not, is there a registration associated with the flow
- If 3 or 4 is true, do something
Do we have functions for 3 and 4? Can this be done in scripting?
Haven't seen functions which can do 3 and 4 at the last stable usrloc module.
Ok, then the question is if they can be coded, isn't it?
/O
Hello,
thanks for the patch. Some remarks.
As you highlighted that the solution is not very efficient (due to no direct mapping between records and tcp connection), it should have a way to disable it (maybe via mod param for usrloc).
At this moment is hardcoded for 'location' table, but there can be other names used, since this value is given as parameter to save()/lookup(). It will have to iterate through all usrloc tables (called domains interanlly in the module).
Also, if I didn't get it wrong, it works only with in-memory records, if the usrloc is configured in db-only mode, it does not work with current patch, right?
I had in mind to implement such features, but using timer, to iterate through tcp connections and see if there is still an open connection for it. This will do delayed discovery, but I am not sure it will bring more benefits -- initially I thought is faster lookup done by a dedicated timer, presumly there are less tcp connections that usrloc records.
Anyhow, perhaps we should do some optimization here, we can store the connection id in usrloc structure and then match received address only if there is same conenction id. Or add received built from tcp connection close callback in a list that is used by usrloc expires timers.
Cheers, Daniel
On 8/27/13 12:29 AM, Vitaliy Aleksandrov wrote:
Hello,
I've made a patch to kamailio-4.0.3 which removes stale registration when kamailio looses an incoming tcp connection. Of course this patch needs more work.
Since the are no direct references between user location contacts and tcp connections callback function uses linear search through the whole location table using received field as a key.
Can anybody more experienced in kamailio internals check if I chose the right place to get information about lost tcp connections ? Another thing I wanted to ask is maybe somebody can suggest a better way to tie a tcp connection to the user location information without complicating "usrloc" module by any heavy data structures.
If anybody else except me need this It would be great to fix known problems and add it to kamailio.
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
On 08/27/2013 11:57 AM, Daniel-Constantin Mierla wrote:
Hello,
thanks for the patch. Some remarks.
As you highlighted that the solution is not very efficient (due to no direct mapping between records and tcp connection), it should have a way to disable it (maybe via mod param for usrloc).
At this moment is hardcoded for 'location' table, but there can be other names used, since this value is given as parameter to save()/lookup(). It will have to iterate through all usrloc tables (called domains interanlly in the module).
Ok, I'll remove hardcoded "location" domain. It will search in all domains from dlist_t. Module parameter will be added too. I understand that search through the all contacts is not for production use at all. I really need this feature and I'm sure everyone who uses tcp/tls/ws too so I wanted to start this discussion from a little peace of code to get feedback from community.
Also, if I didn't get it wrong, it works only with in-memory records, if the usrloc is configured in db-only mode, it does not work with current patch, right?
To remove old contacts i've used delete_ucontact from usrloc api. This function checks db_mode and removes contact from db in case of DB_ONLY mode and just updates expiration in case of WRITE_BACK.
I had in mind to implement such features, but using timer, to iterate through tcp connections and see if there is still an open connection for it. This will do delayed discovery, but I am not sure it will bring more benefits -- initially I thought is faster lookup done by a dedicated timer, presumly there are less tcp connections that usrloc records.
Anyhow, perhaps we should do some optimization here, we can store the connection id in usrloc structure and then match received address only if there is same conenction id. Or add received built from tcp connection close callback in a list that is used by usrloc expires timers.
Searching through a single list from a separate process sounds much better than my version. I'll try to implement this when I have free time.
The way Olle proposed looks more preferable as it can work in environment with separate registrar and outbound servers. But I have to read some theory about outbound before moving this way.
On 8/27/13 12:10 PM, Vitaliy Aleksandrov wrote:
On 08/27/2013 11:57 AM, Daniel-Constantin Mierla wrote:
Hello,
thanks for the patch. Some remarks.
As you highlighted that the solution is not very efficient (due to no direct mapping between records and tcp connection), it should have a way to disable it (maybe via mod param for usrloc).
At this moment is hardcoded for 'location' table, but there can be other names used, since this value is given as parameter to save()/lookup(). It will have to iterate through all usrloc tables (called domains interanlly in the module).
Ok, I'll remove hardcoded "location" domain. It will search in all domains from dlist_t. Module parameter will be added too. I understand that search through the all contacts is not for production use at all. I really need this feature and I'm sure everyone who uses tcp/tls/ws too so I wanted to start this discussion from a little peace of code to get feedback from community.
I understand, I just proposed a way to move further and improve a bit.
Also, if I didn't get it wrong, it works only with in-memory records, if the usrloc is configured in db-only mode, it does not work with current patch, right?
To remove old contacts i've used delete_ucontact from usrloc api. This function checks db_mode and removes contact from db in case of DB_ONLY mode and just updates expiration in case of WRITE_BACK.
But the issue would be that the hash tables will not be in memory, so you will not get in this way to call the delete_ucontact() function. This function is called via a different code path for db only mode.
I had in mind to implement such features, but using timer, to iterate through tcp connections and see if there is still an open connection for it. This will do delayed discovery, but I am not sure it will bring more benefits -- initially I thought is faster lookup done by a dedicated timer, presumly there are less tcp connections that usrloc records.
Anyhow, perhaps we should do some optimization here, we can store the connection id in usrloc structure and then match received address only if there is same conenction id. Or add received built from tcp connection close callback in a list that is used by usrloc expires timers.
Searching through a single list from a separate process sounds much better than my version. I'll try to implement this when I have free time.
OK. My thought for the moment would be to keep this list in shared memory, and then usrloc cleaning-expired-records timers would check if there is a match for each tcp connection - no matter is expired record or not, because they iterate anyhow thorugh all records. This will need a different approach for db only mode as well.
However, other solutions can be proposed and implemented.
The way Olle proposed looks more preferable as it can work in environment with separate registrar and outbound servers. But I have to read some theory about outbound before moving this way.
That would be good too, but the number of devices with SIP Outbound support is still low out there.
Cheers, Daniel
Also, if I didn't get it wrong, it works only with in-memory records, if the usrloc is configured in db-only mode, it does not work with current patch, right?
To remove old contacts i've used delete_ucontact from usrloc api. This function checks db_mode and removes contact from db in case of DB_ONLY mode and just updates expiration in case of WRITE_BACK.
But the issue would be that the hash tables will not be in memory, so you will not get in this way to call the delete_ucontact() function. This function is called via a different code path for db only mode.
Tnx, good remark. It shows that I missed how DB_ONLY mode works. Will spent some time to examine it. Just remembered that kamailio can close connection from its side due to tcp_connection_lifetime parameter. Haven't checked where how it works.
On 08/28/2013 06:45 PM, Juha Heinanen wrote:
Vitaliy Aleksandrov writes:
If anybody else except me need this It would be great to fix known problems and add it to kamailio.
i don't know if this come already up, but why not use this in branch failure route:
unregister("location", "", "$T_reply_rid");
Didn't know about $T_reply_rid variable and that unregister can remove only single contact. In my case the problem with unregister is that stale contact will be removed only if somebody tries to call to a disconnected phone.
Vitaliy Aleksandrov writes:
Didn't know about $T_reply_rid variable and that unregister can remove only single contact. In my case the problem with unregister is that stale contact will be removed only if somebody tries to call to a disconnected phone.
so you get one call to unregistered contact and after that it is not anymore in location db.
is that not acceptable to you? are you proposing to scan all contacts for broken tcp connections on some timer or what?
-- juha
On 8/28/13 10:33 PM, Juha Heinanen wrote:
Vitaliy Aleksandrov writes:
Didn't know about $T_reply_rid variable and that unregister can remove only single contact. In my case the problem with unregister is that stale contact will be removed only if somebody tries to call to a disconnected phone.
so you get one call to unregistered contact and after that it is not anymore in location db.
is that not acceptable to you? are you proposing to scan all contacts for broken tcp connections on some timer or what?
proposed solution in the patch was to scan all the location records when a tcp connection goes down. I suggested to keep the connection id + peer ip/port in a list and scan the location records from time to time, eventually via a dedicated timer process. Anyhow, the patch is not that complete yet, some cases were not approached.
Another idea I threw in (which I thought of doing), is to to something similar to nat keepalive mechanism in nathelper module (which fetches natted contacts and send nat pings), but now fetching all tcp contacts and verifying that the tcp connection is still active.
Cheers, Daniel
Daniel-Constantin Mierla writes:
proposed solution in the patch was to scan all the location records when a tcp connection goes down.
ok. for me it is enough to unregister tcp (and udp) contact when tm tries to reach it. the only problem with that currently is that branch failure route is not executed immediately, but after tm timer fires although tm learns immediately that tcp contact is not reachable.
Another idea I threw in (which I thought of doing), is to to something similar to nat keepalive mechanism in nathelper module (which fetches natted contacts and send nat pings), but now fetching all tcp contacts and verifying that the tcp connection is still active.
that sounds like a clean, good solution.
-- juha
Thanks community for all replies.
I did the second try. Result is in the attachment.
This time a did it in the way proposed by Daniel-Constantin Mierla. All job is done in timer process when it iterates through all registrations looking for expired ones.
It works for all database modes except DB_ONLY.
I'm not sure about tcpconn_get() / tcpconn_put() functions. tcpconn_get() increments ref counter, but there are several function to decrement it: tcpconn_put(), tcpconn_chld_put() and atomic_dec_and_test(). When I was looking for examples in other modules I saw that tcp_read.c uses tcpconn_chld_put(), but forward.h and msg_translator.c uses only tcpconn_get() without decrementing ref counter at all.
It would be great if somebody more experienced shed some light on this.
Hello,
I applied your patches with some changes. There is no need to store tcp connection id in other structure in the core, it is stored in msg->rcv.proto_reserved1.
You have to add the documentation for the new usrloc parameter, in xml files from modules/usrloc/doc/ - send over the patch and I will commit it as well.
Cheers, Daniel
On 8/29/13 12:47 PM, Vitaliy Aleksandrov wrote:
Thanks community for all replies.
I did the second try. Result is in the attachment.
This time a did it in the way proposed by Daniel-Constantin Mierla. All job is done in timer process when it iterates through all registrations looking for expired ones.
It works for all database modes except DB_ONLY.
I'm not sure about tcpconn_get() / tcpconn_put() functions. tcpconn_get() increments ref counter, but there are several function to decrement it: tcpconn_put(), tcpconn_chld_put() and atomic_dec_and_test(). When I was looking for examples in other modules I saw that tcp_read.c uses tcpconn_chld_put(), but forward.h and msg_translator.c uses only tcpconn_get() without decrementing ref counter at all.
It would be great if somebody more experienced shed some light on 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
This patch has a bug which leads to false contact removal.
This happens when UA reconnects to a proxy from the same src port and sends new REGISTER with the same Contact. In that case kamailio updates an existing contact and I forgot to update tcp connection id in the ucontact_t object.
I've fixed this bug in my production system (kamailio-3.2) and it works well. The patch for 4.0.3 will be ready tonight.
Hello,
I applied your patches with some changes. There is no need to store tcp connection id in other structure in the core, it is stored in msg->rcv.proto_reserved1.
You have to add the documentation for the new usrloc parameter, in xml files from modules/usrloc/doc/ - send over the patch and I will commit it as well.
Cheers, Daniel
On 8/29/13 12:47 PM, Vitaliy Aleksandrov wrote:
Thanks community for all replies.
I did the second try. Result is in the attachment.
This time a did it in the way proposed by Daniel-Constantin Mierla. All job is done in timer process when it iterates through all registrations looking for expired ones.
It works for all database modes except DB_ONLY.
I'm not sure about tcpconn_get() / tcpconn_put() functions. tcpconn_get() increments ref counter, but there are several function to decrement it: tcpconn_put(), tcpconn_chld_put() and atomic_dec_and_test(). When I was looking for examples in other modules I saw that tcp_read.c uses tcpconn_chld_put(), but forward.h and msg_translator.c uses only tcpconn_get() without decrementing ref counter at all.
It would be great if somebody more experienced shed some light on 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
-- Daniel-Constantin Mierla -http://www.asipto.com http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda Kamailio Advanced Trainings - Berlin, Oct 21-24; Miami, Nov 11-13, 2013
- more details about Kamailio trainings athttp://www.asipto.com -
Make the patch for master branch, 4.0 doesn't take any new feature and I applied the patches to master branch anyhow.
Also, do not forget the patch for xml documentation.
Cheers, Daniel
On 9/5/13 9:27 AM, Vitaliy Aleksandrov wrote:
This patch has a bug which leads to false contact removal.
This happens when UA reconnects to a proxy from the same src port and sends new REGISTER with the same Contact. In that case kamailio updates an existing contact and I forgot to update tcp connection id in the ucontact_t object.
I've fixed this bug in my production system (kamailio-3.2) and it works well. The patch for 4.0.3 will be ready tonight.
Hello,
I applied your patches with some changes. There is no need to store tcp connection id in other structure in the core, it is stored in msg->rcv.proto_reserved1.
You have to add the documentation for the new usrloc parameter, in xml files from modules/usrloc/doc/ - send over the patch and I will commit it as well.
Cheers, Daniel
On 8/29/13 12:47 PM, Vitaliy Aleksandrov wrote:
Thanks community for all replies.
I did the second try. Result is in the attachment.
This time a did it in the way proposed by Daniel-Constantin Mierla. All job is done in timer process when it iterates through all registrations looking for expired ones.
It works for all database modes except DB_ONLY.
I'm not sure about tcpconn_get() / tcpconn_put() functions. tcpconn_get() increments ref counter, but there are several function to decrement it: tcpconn_put(), tcpconn_chld_put() and atomic_dec_and_test(). When I was looking for examples in other modules I saw that tcp_read.c uses tcpconn_chld_put(), but forward.h and msg_translator.c uses only tcpconn_get() without decrementing ref counter at all.
It would be great if somebody more experienced shed some light on 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
-- Daniel-Constantin Mierla -http://www.asipto.com http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda Kamailio Advanced Trainings - Berlin, Oct 21-24; Miami, Nov 11-13, 2013
- more details about Kamailio trainings athttp://www.asipto.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
Make the patch for master branch, 4.0 doesn't take any new feature and I applied the patches to master branch anyhow.
Also, do not forget the patch for xml documentation.
Cheers, Daniel
Patch for master branch is in the attachment.
Changelog: - documentation is updated - tcpconn_id initialized to "-1" for contacts loaded from a database during startup (Write-Back & Write-Through database modes). - tcpconn_id is being updated when UA reconnects and refreshes its registration.
How did you generate the patch? Apparently the tabs in existing code were replaced by whitespaces and the patch fails to apply because it doesn't match any longer the context.
Can you resend in it raw format with 'git diff >../filename.patch'?
Cheers, Daniel
On Fri, Sep 6, 2013 at 12:46 AM, Vitaliy Aleksandrov <vitalik.voip@gmail.com
wrote:
Make the patch for master branch, 4.0 doesn't take any new feature and I applied the patches to master branch anyhow.
Also, do not forget the patch for xml documentation.
Cheers, Daniel
Patch for master branch is in the attachment.
Changelog:
- documentation is updated
- tcpconn_id initialized to "-1" for contacts loaded from a database
during startup (Write-Back & Write-Through database modes).
- tcpconn_id is being updated when UA reconnects and refreshes its
registration.
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
Maybe when I opened the previous patch by a text editor to check if it has all I wanted to add tabs were accidentally replaced by spaces. Anyway fixed version is in the attachment.
How did you generate the patch? Apparently the tabs in existing code were replaced by whitespaces and the patch fails to apply because it doesn't match any longer the context.
Can you resend in it raw format with 'git diff >../filename.patch'?
Cheers, Daniel
On Fri, Sep 6, 2013 at 12:46 AM, Vitaliy Aleksandrov <vitalik.voip@gmail.com mailto:vitalik.voip@gmail.com> wrote:
Make the patch for master branch, 4.0 doesn't take any new feature and I applied the patches to master branch anyhow. Also, do not forget the patch for xml documentation. Cheers, DanielPatch for master branch is in the attachment. Changelog: - documentation is updated - tcpconn_id initialized to "-1" for contacts loaded from a database during startup (Write-Back & Write-Through database modes). - tcpconn_id is being updated when UA reconnects and refreshes its registration. _______________________________________________ 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://twitter.com/#%21/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Trainings - Berlin, Oct 21-24; Miami, Nov 11-13, 2013
- more details about Kamailio trainings at http://www.asipto.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
Hello,
thanks, patch was commited and pushed to remote repository.
Cheers, Daniel
On 9/10/13 11:02 PM, Vitaliy Aleksandrov wrote:
Maybe when I opened the previous patch by a text editor to check if it has all I wanted to add tabs were accidentally replaced by spaces. Anyway fixed version is in the attachment.
How did you generate the patch? Apparently the tabs in existing code were replaced by whitespaces and the patch fails to apply because it doesn't match any longer the context.
Can you resend in it raw format with 'git diff >../filename.patch'?
Cheers, Daniel
On Fri, Sep 6, 2013 at 12:46 AM, Vitaliy Aleksandrov <vitalik.voip@gmail.com mailto:vitalik.voip@gmail.com> wrote:
Make the patch for master branch, 4.0 doesn't take any new feature and I applied the patches to master branch anyhow. Also, do not forget the patch for xml documentation. Cheers, DanielPatch for master branch is in the attachment. Changelog: - documentation is updated - tcpconn_id initialized to "-1" for contacts loaded from a database during startup (Write-Back & Write-Through database modes). - tcpconn_id is being updated when UA reconnects and refreshes its registration. _______________________________________________ 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://twitter.com/#%21/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Trainings - Berlin, Oct 21-24; Miami, Nov 11-13, 2013
- more details about Kamailio trainings at http://www.asipto.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
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
On 09/23/2013 11:23 PM, Andreas Granig wrote:
Hi,
On 09/13/2013 11:27 AM, Daniel-Constantin Mierla wrote:
thanks, patch was commited and pushed to remote repository.
The patch only handles the case where a tcp connection is directly made to the registrar, as no event route is fired, right?
You are right. Current version works only when registrar accepts tcp connections. Anyway it's a good idea to call event_route[] when kamailio looses a tcp connection to give user a chance to process it somehow.
On the one hand it's great when experienced user can achieve what he wants by different ways depending on the situation, but on the other it makes a mess for new kamailio users.
Hi Vitaliy,
On 09/24/2013 12:45 AM, Vitaliy Aleksandrov wrote:
The patch only handles the case where a tcp connection is directly made to the registrar, as no event route is fired, right?
You are right. Current version works only when registrar accepts tcp connections. Anyway it's a good idea to call event_route[] when kamailio looses a tcp connection to give user a chance to process it somehow.
On the one hand it's great when experienced user can achieve what he wants by different ways depending on the situation, but on the other it makes a mess for new kamailio users.
I think the implementation is fine for "normal" use cases where you just have one combined registrar/proxy, which is probably what new kamailio users are starting with.
The reason I'd love to see an event-route is to handle cases for scaled architectures, where you have load-balancers/edge-servers accepting tcp/tls connections from clients and forward them to a back-end farm of registrars/proxies e.g. via udp.
The implementation of that event-route would be completely independent of the current solution anyways, because it won't hook up with usrloc (on the edge proxies there is usually no usrloc loaded), rather than having the code somewhere in the core and just firing an event-route, where the system developer can do arbitrary actions (like creating a custom sip message to be sent to the back-end servers, which triggers an unregister there). Honestly I have no clue yet as of how to actually do that. Firing the event-route would be the rather easy part I guess, but do we have all the information needed to do an unregister on the back-end registrar? Probably the only info we have is the source ip/port/proto of the disconnected client, so we'd need some logic in the registrar/usrloc module on the back-end registrar to match a location entry with that info somehow.
I'm just throwing in some thoughs on that topic for further discussions, so no clear idea how to accomplish that from my side.
Andreas
Andreas Granig writes:
The reason I'd love to see an event-route is to handle cases for scaled architectures, where you have load-balancers/edge-servers accepting tcp/tls connections from clients and forward them to a back-end farm of registrars/proxies e.g. via udp.
another application is informing presence server that the active watcher is not anymore reachable via its record_route that points to the proxy.
-- juha
Hi,
you could use for example RFC3680 ("A Session Initiation Protocol (SIP) Event Package for Registrations") to synchronize the information about the connection status between the edge- and the core-proxy. This is the way it is done in IMS for information about the signalling status (Diameter/Rx).
Just my $0.02, Carsten
2013/9/24 Andreas Granig agranig@sipwise.com:
Hi Vitaliy,
On 09/24/2013 12:45 AM, Vitaliy Aleksandrov wrote:
The patch only handles the case where a tcp connection is directly made to the registrar, as no event route is fired, right?
You are right. Current version works only when registrar accepts tcp connections. Anyway it's a good idea to call event_route[] when kamailio looses a tcp connection to give user a chance to process it somehow.
On the one hand it's great when experienced user can achieve what he wants by different ways depending on the situation, but on the other it makes a mess for new kamailio users.
I think the implementation is fine for "normal" use cases where you just have one combined registrar/proxy, which is probably what new kamailio users are starting with.
The reason I'd love to see an event-route is to handle cases for scaled architectures, where you have load-balancers/edge-servers accepting tcp/tls connections from clients and forward them to a back-end farm of registrars/proxies e.g. via udp.
The implementation of that event-route would be completely independent of the current solution anyways, because it won't hook up with usrloc (on the edge proxies there is usually no usrloc loaded), rather than having the code somewhere in the core and just firing an event-route, where the system developer can do arbitrary actions (like creating a custom sip message to be sent to the back-end servers, which triggers an unregister there). Honestly I have no clue yet as of how to actually do that. Firing the event-route would be the rather easy part I guess, but do we have all the information needed to do an unregister on the back-end registrar? Probably the only info we have is the source ip/port/proto of the disconnected client, so we'd need some logic in the registrar/usrloc module on the back-end registrar to match a location entry with that info somehow.
I'm just throwing in some thoughs on that topic for further discussions, so no clear idea how to accomplish that from my side.
Andreas
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
-
Andreas Granig -
Carsten Bock -
Daniel-Constantin Mierla -
Juha Heinanen -
Olle E. Johansson -
Peter Dunkley -
Vitaliy Aleksandrov