hello, guys:i follow the linkhttp://kb.asipto.com/asterisk:realtime:kamailio-3.3.x-asterisk-10.7.0-astdbi can registered users, kamctl online shows those status. but i can not make calls. this is debug message when i make a call from 102 to SIP 103--------------------------------------------------------------- 8(1286) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/kamailio.cfg] l=486 a=6 n=route 8(1286) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/kamailio.cfg] l=801 a=3 n=return 8(1286) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/kamailio.cfg] l=489 a=6 n=route 8(1286) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/kamailio.cfg] l=636 a=17 n=if 8(1286) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/kamailio.cfg] l=601 a=25 n=has_totag 8(1286) DEBUG: siputils [checks.c:103]: no totag 8(1286) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/kamailio.cfg] l=501 a=17 n=if 8(1286) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/kamailio.cfg] l=494 a=26 n=is_method 8(1286) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/kamailio.cfg] l=498 a=17 n=if 8(1286) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/kamailio.cfg] l=496 a=25 n=t_check_trans 8(1286) DEBUG: tm [t_lookup.c:762]: DEBUG: t_lookupOriginalT: searching on hash entry 60763 8(1286) DEBUG: tm [t_lookup.c:470]: DEBUG: RFC3261 transaction matched, tid=-d87543-e16321701f723866-1--d87543- 8(1286) DEBUG: tm [t_lookup.c:859]: DEBUG: t_lookupOriginalT: canceled transaction found (0xb4d36320)! 8(1286) DEBUG: tm [t_lookup.c:862]: DEBUG: t_lookupOriginalT completed 8(1286) DEBUG: tm [tm.c:1015]: lookup_original: t_lookupOriginalT returned: 0xb4d36320 8(1286) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/kamailio.cfg] l=497 a=25 n=t_relay 8(1286) DEBUG: tm [t_lookup.c:1379]: DEBUG: t_newtran: msg id=29 , global msg id=28 , T on entrance=(nil) 8(1286) DEBUG: tm [t_lookup.c:527]: t_lookup_request: start searching: hash=60763, isACK=0 8(1286) DEBUG: tm [t_lookup.c:485]: DEBUG: RFC3261 transaction matching failed 8(1286) DEBUG: tm [t_lookup.c:709]: DEBUG: t_lookup_request: no transaction found 8(1286) DEBUG: tm [t_hooks.c:374]: DBG: trans=0xb4d3a698, callback type 1, id 0 entered 8(1286) DEBUG: tm [t_lookup.c:762]: DEBUG: t_lookupOriginalT: searching on hash entry 60763 8(1286) DEBUG: tm [t_lookup.c:470]: DEBUG: RFC3261 transaction matched, tid=-d87543-e16321701f723866-1--d87543- 8(1286) DEBUG: tm [t_lookup.c:859]: DEBUG: t_lookupOriginalT: canceled transaction found (0xb4d36320)! 8(1286) DEBUG: tm [t_lookup.c:862]: DEBUG: t_lookupOriginalT completed 8(1286) DEBUG: tm [t_fwd.c:1243]: DEBUG: e2e_cancel: e2e cancel proceeding 8(1286) DEBUG: <core> [msg_translator.c:206]: check_via_address(192.168.1.103, 192.168.1.103, 0) 8(1286) DEBUG: <core> [mem/shm_mem.c:111]: WARNING:vqm_resize: resize(0) called 8(1286) DEBUG: tm [t_reply.c:1543]: DEBUG: cleanup_uac_timers: RETR/FR timers reset 8(1286) DEBUG: tm [t_reply.c:703]: DEBUG: reply sent out. buf=0xb721ee38: SIP/2.0 200 cancelin..., shmem=0xb4d38c08: SIP/2.0 200 cancelin 8(1286) DEBUG: tm [t_reply.c:713]: DEBUG: _reply_light: finished 8(1286) DEBUG: tm [t_funcs.c:388]: SER: new transaction fwd'ed 8(1286) ERROR: *** cfgtrace: c=[/usr/local/etc/kamailio/kamailio.cfg] l=498 a=3 n=exit 8(1286) DEBUG: <core> [usr_avp.c:644]: DEBUG:destroy_avp_list: destroying list (nil) 8(1286) DEBUG: <core> [usr_avp.c:644]: DEBUG:destroy_avp_list: destroying list (nil) 8(1286) DEBUG: <core> [usr_avp.c:644]: DEBUG:destroy_avp_list=================================anyone can give a hint for that? thanks!
Best regards, James.zhu Doing asterisk/PRI/ss7/dahdi, linux, asterisk/sangoma cards, recording device, VOIP gateway. website: www.hiastar.com
From: sr-users-request@lists.sip-router.org Subject: sr-users Digest, Vol 90, Issue 72 To: sr-users@lists.sip-router.org Date: Wed, 21 Nov 2012 08:58:40 +0100
Send sr-users mailing list submissions to sr-users@lists.sip-router.org
To subscribe or unsubscribe via the World Wide Web, visit http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users or, via email, send a message with subject or body 'help' to sr-users-request@lists.sip-router.org
You can reach the person managing the list at sr-users-owner@lists.sip-router.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of sr-users digest..."
Today's Topics:
- Re: Shared Call Appearances module (Daniel-Constantin Mierla)
- Re: Shared Call Appearances module (Andrew Mortensen)
- Re: LCR weight (Juha Heinanen)
- problem with $time Pseudo-Variables on 3.3.2 (Uri Shacked)
- Re: Dialog module not decrementing profile size (Grant Bagdasarian)
Message: 1 Date: Tue, 20 Nov 2012 22:56:10 +0100 From: Daniel-Constantin Mierla miconda@gmail.com Subject: Re: [SR-Users] Shared Call Appearances module To: Ovidiu Sas osas@voipembedded.com Cc: "SIP Router - Kamailio (OpenSER) and SIP Express Router (SER)
- Users Mailing List" sr-users@lists.sip-router.org
Message-ID: 50ABFC7A.2070602@gmail.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 11/20/12 10:41 PM, Ovidiu Sas wrote:
On Tue, Nov 20, 2012 at 4:22 PM, Andrew Mortensen admorten@isc.upenn.edu wrote:
On Nov 20, 2012, at 3:16 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
On 11/20/12 8:43 PM, Andrew Mortensen wrote:
On Nov 20, 2012, at 4:08 AM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
thank for contribution!
On 11/20/12 12:16 AM, Andrew Mortensen wrote: > On Nov 19, 2012, at 5:53 PM, David | StyleFlare david@styleflare.com wrote: > >> Also quick read at the readme, it looks like it does not support multi-domain setups? > Not yet, no. I don't think it would take much work, though. I see it binds to usrloc, what information needs from there? We have two such modules right now, it would be good to make it work with both, kamailio's one has more features in regard to GRUU and partial outbound extensions.
It's registering for contact expiration and deletion events. The callback terminates subscriptions for the expired/deleted contact. This should probably be configurable.
Ok, so it is about when a contact record in removed from location.
Just to avoid misunderstandings, do you consider to make configurable this termination of subscriptions based on location?
Yes. I can imagine a setup where the location data wouldn't be saved on the host handling SCA.
Also, you need only the AoR and contact address in a callback for location record removal event (un-registration or registration expiration), right?
Correct, although Ovidiu makes a good point about (well-behaved) clients unsubscribing at the time of unregistration. In registering for usrloc callbacks, I'm trying to handle a couple problems. First, I'd like to avoid unnecessarily sending and retransmitting NOTIFYs to offline clients. More importantly, I want to be able to hear about expired registrations so I can clear appearance state on the rest of the subscribers.
For clearing appearance state, you should rely on the dialog module and register a callback on the dialog module. When a dialog expires, you can clear up the stale appearances. Also, by enabling the sst module, you can have a tight control over the duration of the dialog. This will make the implementation cleaner and more robust.
I will not jump to such conclusions.
While dialog module is designed to track active calls, does not mean everything has to be on top of it. Just for example, dispatcher module has an embedded lightweight call tracking system.
No idea here what the broadsoft extensions require, afaik, there were some custom specs. It is no problem to have a dedicated dialog tracking system that is better designed for a particular functionality. We do have other duplicated systems, for example least cost routing, nat traversal, a.s.o.
Also, optimizations and reuse of other parts can be done later if found to be better ways.
Cheers, Daniel
-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Message: 2 Date: Tue, 20 Nov 2012 17:17:38 -0500 From: Andrew Mortensen admorten@isc.upenn.edu Subject: Re: [SR-Users] Shared Call Appearances module To: Ovidiu Sas osas@voipembedded.com Cc: "SIP Router - Kamailio (OpenSER) and SIP Express Router (SER)
- Users Mailing List" sr-users@lists.sip-router.org
Message-ID: 65EAE745-8966-4848-870E-6A50246E0AB7@isc.upenn.edu Content-Type: text/plain; charset=iso-8859-1
On Nov 20, 2012, at 3:43 PM, Ovidiu Sas osas@voipembedded.com wrote:
Hello Andrew,
First of all, thank you for sharing your work. I was following this thread and I have a couple of questions. Why do you need to bind to the usrloc module? The subscription itself should be sufficient because if a phone will unregister, it will also unsubscribe,
Yes, that's good point. However, if the phone goes off-line instead of unregistering, the contact's registration will expire, and no unsubscribe will take place. As I mentioned in my reply to Daniel, I'm most concerned about catching this so I can release any appearances seized by the expired/deleted contact, and notify other members of the group. I'm certainly open to alternatives.
which leads me to the following question: why not add a new dedicated module for call-info presence and reuse the existing infrastructure from kamailio for handling subscriptions/presence. In this case, your module should just push PUBLISH events to the presence server and the server will automatically send out notifications for subscribers that subscribed to call-info events.
We've worked extensively with the existing presence & pua modules, albeit primarily dialog;sla using OpenSIPS behind the proxy. (Thanks, Anca!)
SCA's unusual entanglement with call processing made me hesitate about building on top of the existing presence module. For a first pass, I also felt working with an entirely distinct module gave me more control and transparency during development of a very loosely documented event package, especially as I became more familiar with the available API.
I don't have any objection to revisiting design decisions, of course. I'm sure the module will continue to evolve, and it would be nice to eliminate redundancy if possible.
Based on your README file, you inspect SIP requests/replies and based on the presence of the call-info header, you create call-info events. This is great for sharing the appearances between phones, but how do you perform the retrieval of a call that was put on hold? Are you using a dedicated B2BUA behind kamailio?
No B2BUAs are involved.
The INVITE retrieving a call held by another member of an SCA group has a particular set of characteristics: RURI, To and From URIs are all the SCA AoR; new unconfirmed dialog (no to-tag); and a Call-Info header referring to the index of the held call. The module detects this type of INVITE, looks up the dialog associated with the information in the Call-Info header, and injects a Replaces header with the dialog of the held call before relaying it to the remote party. The remote party must support RFC3891. I've only worked with Polycoms and Cisco gateways to this point, and both do support that RFC.
I'm very interested in hearing from users with Cisco (and Snom and Aastra?) SCA setups. I have no doubt they'll find bugs resulting from assumptions I've made in the code because I've only tested with Polycom, not least the dependency on RFC3891 support.
Thanks for your feedback!
Best, andrew
On Tue, Nov 20, 2012 at 3:16 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
On 11/20/12 8:43 PM, Andrew Mortensen wrote:
On Nov 20, 2012, at 4:08 AM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
thank for contribution!
On 11/20/12 12:16 AM, Andrew Mortensen wrote:
On Nov 19, 2012, at 5:53 PM, David | StyleFlare david@styleflare.com wrote:
> Also quick read at the readme, it looks like it does not support > multi-domain setups?
Not yet, no. I don't think it would take much work, though.
I see it binds to usrloc, what information needs from there? We have two such modules right now, it would be good to make it work with both, kamailio's one has more features in regard to GRUU and partial outbound extensions.
It's registering for contact expiration and deletion events. The callback terminates subscriptions for the expired/deleted contact. This should probably be configurable.
Ok, so it is about when a contact record in removed from location.
Just to avoid misunderstandings, do you consider to make configurable this termination of subscriptions based on location?
Also, you need only the AoR and contact address in a callback for location record removal event (un-registration or registration expiration), right?
Would you consider adding it to main git repository and maintaining it there?
Yes, that would be great.
We will prepare write access for you.
Would you prefer to have it in modules? I started work on it in modules_s, but there's no particular reason it has to stay there.
To make it work with both variants of usrloc modules, I think it requires some split of the code. IIRC, both modules still use same names for structures, so including files from both of them will fail.
One solutions I am thinking of is to add two small modules, one that binds to usloc(k) and the other to usrloc(s). Each of these two modules will export a function that allow registering callbacks for execution when a location record expires, giving the aor, contact and event type. The existing module will use the intermediate module instead of directly binding to usrloc structures.
Usrloc module from kamailio has more enhancements in regards to standard extensions for location services, still it lacks the feature of being able to store variables per contact record. It is the reason that kept back the removal (upon merging) of usrloc module from ser. The solution with intermediary modules should work until we have a merged usrloc module.
What do you think about this proposal?
Cheers, Daniel
-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Message: 3 Date: Wed, 21 Nov 2012 01:04:52 +0200 From: Juha Heinanen jh@tutpro.com Subject: Re: [SR-Users] LCR weight To: "SIP Router - Kamailio (OpenSER) and SIP Express Router (SER)
- Users Mailing List" sr-users@lists.sip-router.org
Message-ID: 20652.3220.931000.738348@sip.test.fi Content-Type: text/plain; charset=us-ascii
Camila Troncoso writes:
scripts are provided in lcr/utils directory that can be used to check the probabilities resulting from a given set of weight values. Same can be done with command 'kamctl eval_weights'.
I really don't understand what is the probability finally assign to each gateway when they have the same priority. All I can see is that it doesn't correspond to percentage of capacity from the example above , but how can I determine what value gives the percent that I want?
Please give an example like:
Rule_id Gw_id Priority weight 36 68 1 60 36 69 1 14 36 70 1 13 36 71 1 13
you have to figure that out yourself using the script referenced in readme.
-- juha
Message: 4 Date: Wed, 21 Nov 2012 09:55:17 +0200 From: Uri Shacked ushacked@gmail.com Subject: [SR-Users] problem with $time Pseudo-Variables on 3.3.2 To: "SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing List" sr-users@lists.sip-router.org Message-ID: CAMMbDhQn1r_ke72-u2is8MyRXUV6KkLnZqYwxL5eZG44yYG_2Q@mail.gmail.com Content-Type: text/plain; charset="iso-8859-1"
Hi,
I upgraded to 3.3.2
On 3.2 i used the variable $time() to get the current time for some process.
Every 2 minutes a RTIMER process started, checked the $time(hour) and $time(min) and on a certain time executed something.
This process stopped working on 3.3.2
When i debug, i see that the $time() variable keeps on giving me the same hour and minute that was given on the first run.
Meaning the $time() variable does not give the current time.
I notice also that the $Ts that on 3.2 gave a current time stopped doing it and $TS does it now....
Any help here?
Is it OK and i need to check time another way? Or something in the $time() has changed...?
Thanks,
Uri
-
James zhu