[SR-Users] I can not make call from kamailio to asterisk by 3.3
James zhu
zhulizhong at live.com
Wed Nov 21 10:26:46 CET 2012
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 at lists.sip-router.org
> Subject: sr-users Digest, Vol 90, Issue 72
> To: sr-users at lists.sip-router.org
> Date: Wed, 21 Nov 2012 08:58:40 +0100
>
> Send sr-users mailing list submissions to
> sr-users at 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 at lists.sip-router.org
>
> You can reach the person managing the list at
> sr-users-owner at 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:
>
> 1. Re: Shared Call Appearances module (Daniel-Constantin Mierla)
> 2. Re: Shared Call Appearances module (Andrew Mortensen)
> 3. Re: LCR weight (Juha Heinanen)
> 4. problem with $time Pseudo-Variables on 3.3.2 (Uri Shacked)
> 5. 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 at gmail.com>
> Subject: Re: [SR-Users] Shared Call Appearances module
> To: Ovidiu Sas <osas at voipembedded.com>
> Cc: "SIP Router - Kamailio \(OpenSER\) and SIP Express Router \(SER\)
> - Users Mailing List" <sr-users at lists.sip-router.org>
> Message-ID: <50ABFC7A.2070602 at 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 at isc.upenn.edu> wrote:
> >> On Nov 20, 2012, at 3:16 PM, Daniel-Constantin Mierla <miconda at 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 at 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 at 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 at isc.upenn.edu>
> Subject: Re: [SR-Users] Shared Call Appearances module
> To: Ovidiu Sas <osas at voipembedded.com>
> Cc: "SIP Router - Kamailio \(OpenSER\) and SIP Express Router \(SER\)
> - Users Mailing List" <sr-users at lists.sip-router.org>
> Message-ID: <65EAE745-8966-4848-870E-6A50246E0AB7 at isc.upenn.edu>
> Content-Type: text/plain; charset=iso-8859-1
>
>
> On Nov 20, 2012, at 3:43 PM, Ovidiu Sas <osas at 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 at 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 at 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 at 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 at tutpro.com>
> Subject: Re: [SR-Users] LCR weight
> To: "SIP Router - Kamailio \(OpenSER\) and SIP Express Router \(SER\)
> - Users Mailing List" <sr-users at lists.sip-router.org>
> Message-ID: <20652.3220.931000.738348 at 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 at 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 at lists.sip-router.org>
> Message-ID:
> <CAMMbDhQn1r_ke72-u2is8MyRXUV6KkLnZqYwxL5eZG44yYG_2Q at 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
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20121121/4fec9e86/attachment-0001.htm>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 20 Nov 2012 14:41:45 +0100
> From: Grant Bagdasarian <GB at cm.nl>
> Subject: Re: [SR-Users] Dialog module not decrementing profile size
> To: "miconda at gmail.com" <miconda at gmail.com>
> Cc: "SIP Router - Kamailio \(OpenSER\) and SIP Express Router \(SER\)
> - Users Mailing List" <sr-users at lists.sip-router.org>
> Message-ID:
> <FB7D97A214987F458242ACBDF876140738BFF5822F at clubvirtual40.ClubMessage.local>
>
> Content-Type: text/plain; charset="us-ascii"
>
> Hello,
>
> Alright, I've added the xlog with the additional information to log.
>
> I'm not sure if the dialog is no longer in the list of active dialogs, but still in profile, but it does look like this is the case. I haven't checked the active_dialogs when it happened, since I'm still fairly new to kamailio. The way I notice when this happens is to count the dialogs in the database and match them with the active calls count on our Cisco. This check is performed multiple times over a certain period of time, before it marks it as failure. When the check fails I know something is wrong.
>
> I'll make sure to check the active_dialogs it when it happens again. Thanks for the pointers!
>
> Regards,
>
> Grant
>
>
> From: Daniel-Constantin Mierla [mailto:miconda at gmail.com]
> Sent: dinsdag 20 november 2012 14:16
> To: Grant Bagdasarian
> Cc: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing List
> Subject: Re: [SR-Users] Dialog module not decrementing profile size
>
> Hello,
> On 11/20/12 10:02 AM, Grant Bagdasarian wrote:
> Hello Daniel,
>
> I've enabled the cfgtrace. Now all I have to do is wait till it happens again, as the problem does not occur often.
>
> For now I'm getting the following:
> 2012-11-20T09:56:15+01:00 kamailio /usr/local/sbin/kamailio[16350]: ERROR: *** cfgtrace: c=[/etc/kamailio/kamailio.cfg] l=302 a=25 n=dlg_manage
>
> Debug is currently set to 2: debug=2
> Should I set this to 4?
> no, 2 is fine, but be sure you also have an xlog message to print at least the method type, call-id, from tag and to tag. That will allow to see for which request the cfg trace is related.
>
> Just to be sure I haven't misunderstood, the dialog is no longer in the list of active dialogs, but it is still in the profile.
>
> Cheers,
> Daniel
>
>
> Grant
>
> From: Daniel-Constantin Mierla [mailto:miconda at gmail.com]
> Sent: maandag 19 november 2012 9:59
> To: Grant Bagdasarian
> Cc: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing List
> Subject: Re: [SR-Users] Dialog module not decrementing profile size
>
> Hello,
> On 11/16/12 8:54 AM, Grant Bagdasarian wrote:
> Hello Daniel,
>
> Yes, dlg_manage() is being called in the BYE, yet it sometimes still occurs that dialogs aren't being cleared.
> It is critical for us the dialogs are being cleared as we have an application which heavily relies on this.
> Do you get any error messages in syslog?
>
> Can you add an xlog(...) message (or load the debugger module and enable cfgtrace parameter), then look at the log messages to be sure dlg_manage() is executed for BYE requests?
>
> Cheers,
> Daniel
>
>
>
> Kind regards,
>
> Grant Bagdasarian
>
> From: Daniel-Constantin Mierla [mailto:miconda at gmail.com]
> Sent: donderdag 8 november 2012 8:03
> To: SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing List
> Cc: Grant Bagdasarian
> Subject: Re: [SR-Users] Dialog module not decrementing profile size
>
> Hello,
> On 10/30/12 10:51 AM, Grant Bagdasarian wrote:
> Hello Community,
>
> I've recently started to use the Dialog module to manage the amount of incoming calls from our SIP provider allowed to pass through by using profiles_with_values and setting the size of these profiles to a certain amount.
> Most of the time this works as it should, but sometimes the 'slots' available for a profile aren't cleared even though a dialog has finished. This seems to happen when an high amount of regular traffic is hitting kamailio.
>
> Has anyone else experienced this? Are there perhaps any other ways to control the slots available for certain incoming SIP traffic?
>
> Below parts of my configuration file. Perhaps I'm doing something wrong which causes this to happen.
> In my route[WITHINDLG] -> loose_route -> is_method("BYE") I'm not calling dlg_manage(), could this be the problem?
> is the dlg_manage() executed or not for BYE? You say no above, but the example has it. Because you have dlg_match_mode=2, you must call dlg_manage() for BYE explicitly.
>
> Cheers,
> Daniel
>
>
>
>
> Other comments are welcome too, as I'm fairly new to Kamailio.
>
> modparam("dialog", "enable_stats", 1)
> modparam("dialog", "dlg_flag", 4)
> modparam("dialog", "hash_size", 4096)
> modparam("dialog", "profiles_with_value", "318005004");
> modparam("dialog", "default_timeout", 43200)
> modparam("dialog", "dlg_match_mode",2)
> modparam("dialog", "detect_spirals", 1)
>
> request_route {
>
> # per request initial checks
> route(REQINIT);
>
> # handle requests within SIP dialogs
> route(WITHINDLG);
>
> ### only initial requests (no To tag)
>
> # CANCEL processing
> if (is_method("CANCEL"))
> {
> if (t_check_trans())
> t_relay();
> exit;
> }
>
> t_check_trans();
>
> # record routing for dialog forming requests (in case they are routed)
> # - remove preloaded route headers
> remove_hf("Route");
>
> if (is_method("INVITE")) {
> xlog("L_INFO", "Incoming request for $rU from $fU");
> if ($rU == "318005004") {
> route(DIALOG);
> }
> }
>
> # handle registrations
> route(REGISTRAR);
>
> if ($rU==$null)
> {
> # request with no Username in RURI
> sl_send_reply("484","Address Incomplete");
> exit;
> }
>
> # dispatch destinations
> route(DISPATCH);
>
> route(RELAY);
> }
>
> route[DIALOG] {
> dlg_manage();
> record_route();
> $var(SIZE) = 0;
>
> sql_query("vf", "exec dbo.SelectAvailableSlots '00$rU'", "ra");
> $avp(s:limit) = $dbr(ra=>[0,7]);
> xlog("L_INFO", "Maximum simultaneous calls is configured at $avp(s:limit) ....");
> sql_result_free("ra");
>
> if ($rU == "318005004") {
> get_profile_size("318005004", "$rU", "$var(SIZE)");
> }
>
>
> xlog("L_INFO", "There are currently $var(SIZE) calls for $rU, excluding the current call");
> if($var(SIZE) >= $avp(s:limit)) {
> xlog("L_INFO", "Simultaneous calls limit of $avp(s:limit) reached for $rU: $var(SIZE)\n");
> sl_send_reply("603", "Simultaneous calls limit reached");
> exit;
> }
>
> if ($rU == "318005004") {
> set_dlg_profile("318005004", "$rU");
> }
>
>
> if ($rU == "318005004") {
> if(get_profile_size("318005004", "$var(SIZE)")) {
> xlog("L_INFO", "There are currently $var(SIZE) calls for $rU, including the current call");
> }
> }
> }
>
> route[WITHINDLG] {
> if (has_totag()) {
> # sequential request withing a dialog should
> # take the path determined by record-routing
> if (loose_route()) {
> #Used for call transfer
> if($fU == "318005004") {
> if (is_method("UPDATE")) {
> sl_send_reply("405","Method not allowed");
> xlog("L_INFO", "Dropping UPDATE message...\n");
> exit;
> }
> if (is_method("INVITE")) {
> record_route();
> }
> if (is_method("BYE")) {
> dlg_manage();
> }
> }
> if (is_method("BYE")) {
> setflag(1); # do accounting ...
> setflag(3); # ... even if the transaction fails
> }
> route(RELAY);
> } else {
> if (is_method("SUBSCRIBE") && uri == myself) {
> # in-dialog subscribe requests
> route(PRESENCE);
> exit;
> }
> if ( is_method("ACK") ) {
> if ( t_check_trans() ) {
> # non loose-route, but stateful ACK;
> # must be ACK after a 487 or e.g. 404 from upstream server
> t_relay();
> exit;
> } else {
> # ACK without matching transaction ... ignore and discard.
> exit;
> }
> }
> sl_send_reply("404","Not here");
> }
> exit;
> }
> }
>
>
> Regards,
>
> Grant
>
>
>
>
>
>
>
> _______________________________________________
>
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>
> sr-users at lists.sip-router.org<mailto:sr-users at 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 Training, Berlin, Nov 5-8, 2012 - http://asipto.com/u/kat
>
> Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 - http://asipto.com/u/katu
>
>
>
>
> --
>
> Daniel-Constantin Mierla - http://www.asipto.com
>
> http://twitter.com/#!/miconda<http://twitter.com/#%21/miconda> - http://www.linkedin.com/in/miconda
>
>
>
> --
>
> Daniel-Constantin Mierla - http://www.asipto.com
>
> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20121120/043c732e/attachment.htm>
>
> ------------------------------
>
> _______________________________________________
> sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
> End of sr-users Digest, Vol 90, Issue 72
> ****************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20121121/f6a4ceb7/attachment-0001.htm>
More information about the sr-users
mailing list