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)
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 applicatio
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 t
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?
Y
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?
Andreas
_
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 i
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 fai
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, Vit
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 initialize
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.
T
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
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 a
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 n
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
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.
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 unregistere
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
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");
-- juha
_
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
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 t
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).
A
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 ther
27 aug 2013 kl. 10:25 skrev Vitaliy Aleksandrov :
> 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:
>>
>> 1. Connection dies (tcp, tls, sctp)
>> 2. Event-route activates
>> 3. Check if there's a outbound
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:
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 regist
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 tru
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 wrote:
>
> 27 aug 2013 kl. 08:27 skrev "Olle E. Johansson" :
>
> >
> > 27 aug 2013
27 aug 2013 kl. 08:27 skrev "Olle E. Johansson" :
>
> 27 aug 2013 kl. 00:29 skrev Vitaliy Aleksandrov :
>
>> 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.
>>
>> Si
27 aug 2013 kl. 00:29 skrev Vitaliy Aleksandrov :
> 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 a
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
29 matches
Mail list logo
