sr-users October 2006

sr-users@lists.kamailio.org

189 participants
345 discussions

[Users] openser.org outage
by Daniel-Constantin Mierla 09 Oct '06

09 Oct '06

Hello, just to inform you, today the collocation site hosting the OpenSER site experienced lot of outages (http://www.hetzner-status.de/). We apologizes for the situation and we kindly ask you to re-summit any message which didn't get it to the mailing list. We look forward to implement a mirroring system to be able to handle smoothly such situations. Cheers, Daniel

1 0

[Users] 404 not found retransmission
by Cseke Tamas 09 Oct '06

09 Oct '06

Hi, I have a retransmission problem, i recive an ack for an 404 reply, however opener 1.1.0 retransmit it: U 213.xxx.xxx.92:5060 -> 213.xxx.xxx.32:5060 SIP/2.0 404 Not Found..Via: SIP/2.0/UDP 192.168.1.106;rport=5060;received=2 17.xxx.xxx.22;branch=z9hG4bKf0dec68a3f9e217a..From: <sip:241@callshop.peakte lecom.me.uk>;tag=25dde6813cae8747..To: <sip:1@callshop.>;t ag=D3DB214-25D2..Date: Mon, 09 Oct 2006 11:37:18 GMT..Call-ID: 3c47a6403890 c2f2@192.168.1.106..Server: Cisco-SIPGateway/IOS-12.x..CSeq: 42170 INVITE.. Allow-Events: telephone-event..Content-Length: 0.... # U 213.xxx.xxx.32:5060 -> 213.xxx.xxx.92:5060 ACK sip:1@callshop. SIP/2.0..Via: SIP/2.0/UDP 192.168.1.10 6;branch=z9hG4bKf0dec68a3f9e217a..From: <sip:241@callshop. >;tag=25dde6813cae8747..To: <sip:1@callshop.>;tag=D3DB214- 25D2..Contact: <sip:241@192.168.1.106>..Authorization: Digest username="241 ", realm="callshop.", algorithm=MD5, uri="sip:1@callshop ", nonce="452a37e35171ad890ccd763950d954c45090f992", respon se="f68ecea0d5196e8e88abeac6a68"..Call-ID: 3c47a6403890c2f2(a)192.168.1. 106..CSeq: 42170 ACK..User-Agent: Grandstream BT110 1.0.8.23..Max-Forwards: 70..Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE..Cont ent-Length: 0.... # U 213.xxx.xxx.92:5060 -> 213.xxx.xxx.32:5060 SIP/2.0 404 Not Found..Via: SIP/2.0/UDP 192.168.1.106;rport=5060;received=2 17.xxx.xxx.22;branch=z9hG4bKf0dec68a3f9e217a..From: <sip:241@callshop.peakte lecom.me.uk>;tag=25dde6813cae8747..To: <sip:1@callshop.>;t ag=D3DB214-25D2..Date: Mon, 09 Oct 2006 11:37:18 GMT..Call-ID: 3c47a6403890 c2f2@192.168.1.106..Server: Cisco-SIPGateway/IOS-12.x..CSeq: 42170 INVITE.. Allow-Events: telephone-event..Content-Length: 0.... # U 213.xxx.xxx.92:5060 -> 213.xxx.xxx.32:5060 SIP/2.0 404 Not Found..Via: SIP/2.0/UDP 192.168.1.106;rport=5060;received=2 17.xxx.xxx.22;branch=z9hG4bKf0dec68a3f9e217a..From: <sip:241@callshop.peakte lecom.me.uk>;tag=25dde6813cae8747..To: <sip:1@callshop.>;t ag=D3DB214-25D2..Date: Mon, 09 Oct 2006 11:37:18 GMT..Call-ID: 3c47a6403890 c2f2@192.168.1.106..Server: Cisco-SIPGateway/IOS-12.x..CSeq: 42170 INVITE.. Allow-Events: telephone-event..Content-Length: 0.... 0(15109) DEBUG: to body [<sip:1@callshop>] 0(15109) get_hdr_field: cseq <CSeq>: <42170> <INVITE> 0(15109) parse_headers: flags=8 0(15109) DEBUG: t_reply_matching: hash 39491 label 455964109 branch 2 0(15109) DEBUG:tm:REF_UNSAFE: after is 1 0(15109) DEBUG: t_reply_matching: reply matched (T=0xb3df7618)! 0(15109) DEBUG: t_check: msg id=35 global id=35 T end=0xb3df7618 0(15109) DEBUG:tm:reply_received: org. status uas=100, uac[2]=100 local=0 is_in vite=1) 0(15109) parse_headers: flags=8 0(15109) DEBUG:tm:build_local: using FROM=<From: <sip:241@callshop me.uk>;tag=25dde6813cae8747 >, TO=<To: <sip:1@callshop>;tag=D3DB214-25D2 >, CSEQ_N=<CSeq: 42170> 0(15109) parse_headers: flags=80 0(15109) DEBUG: get_hdr_body : content_length=0 0(15109) found end of header 0(15109) DEBUG:tm:t_should_relay_response: T_code=100, new_code=404 0(15109) DEBUG:tm:t_pick_branch: picked branch 2, code 404 0(15109) DEBUG:tm:relay_reply: branch=2, save=0, relay=2 0(15109) old size: 482, new size: 427 0(15109) build_res_from_sip_res: copied size: orig:83, new: 28, rest: 399 msg= SIP/2.0 404 Not Found Via: SIP/2.0/UDP 192.168.1.106;rport=5060;received=217.xxx.xxx.22;branch=z9hG4bKf 0dec68a3f9e217a From: <sip:241@callshop>;tag=25dde6813cae8747 To: <sip:1@callshop>;tag=D3DB214-25D2 Date: Mon, 09 Oct 2006 11:37:18 GMT Call-ID: 3c47a6403890c2f2(a)192.168.1.106 Server: Cisco-SIPGateway/IOS-12.x CSeq: 42170 INVITE Allow-Events: telephone-event Content-Length: 0 0(15109) DEBUG: add_to_tail_of_timer[4]: 0xb3df76c8 0(15109) DEBUG: add_to_tail_of_timer[0]: 0xb3df76d8 0(15109) DEBUG:tm:relay_reply: sent buf=0x812e928: SIP/2.0 4..., shmem=0xb3df8f 50: SIP/2.0 4 0(15109) DEBUG: cleanup_uac_timers: RETR/FR timers reset 0(15109) DEBUG:tm:UNREF_UNSAFE: after is 0 0(15109) DEBUG:destroy_avp_list: destroying list (nil) 0(15109) receive_msg: cleaning up 0(15109) SIP Request: 0(15109) method: <ACK> 0(15109) uri: <sip:1@callshop> 0(15109) version: <SIP/2.0> 0(15109) parse_headers: flags=2 0(15109) Found param type 232, <branch> = <z9hG4bKf0dec68a3f9e217a>; state=16 0(15109) end of header reached, state=5 0(15109) parse_headers: Via found, flags=2 0(15109) parse_headers: this is the first via 0(15109) After parse_msg... 0(15109) preparing to run routing scripts... 0(15109) parse_headers: flags=8 0(15109) DEBUG: add_param: tag=D3DB214-25D2 0(15109) DEBUG:parse_to:end of header reached, state=29 0(15109) DBUG:parse_to: display={}, ruri={sip:1@callshop} 0(15109) DEBUG: get_hdr_field: <To> [53]; uri=[sip:1@callshop ] 0(15109) DEBUG: to body [<sip:1@callshop>] 0(15109) parse_headers: flags=100 0(15109) get_hdr_field: cseq <CSeq>: <42170> <ACK> 0(15109) DEBUG:maxfwd:is_maxfwd_present: value = 70 0(15109) DEBUG: add_param: tag=25dde6813cae8747 0(15109) DEBUG:parse_to:end of header reached, state=29 0(15109) DBUG:parse_to: display={}, ruri={sip:241@callshop} 0(15109) DEBUG: t_check: msg id=36 global id=35 T start=0xffffffff 0(15109) parse_headers: flags=ffffffffffffffff 0(15109) DEBUG: get_hdr_body : content_length=0 0(15109) found end of header 0(15109) parse_headers: flags=78 0(15109) t_lookup_request: start searching: hash=39491, isACK=1 0(15109) DEBUG: RFC3261 transaction matched, tid=f0dec68a3f9e217a 0(15109) DEBUG:tm:REF_UNSAFE: after is 1 0(15109) DEBUG: t_lookup_request: transaction found (T=0xb3df7618) 0(15109) DEBUG: t_check: msg id=36 global id=36 T end=0xb3df7618 0(15109) DEBUG:t_check_status: checked status is <404> 0(15109) parse_headers: flags=58 0(15109) parse_headers: flags=200 0(15109) find_first_route: No Route headers found 0(15109) loose_route: There is no Route HF 0(15109) grep_sock_info - checking if host==us: 26==12 && [callshop. m.me.uk] == [213.166.8.92] 0(15109) grep_sock_info - checking if port 5060 matches port 5060 0(15109) grep_sock_info - checking if host==us: 26==12 && [callshop. m.me.uk] == [213.166.8.92] 0(15109) grep_sock_info - checking if port 5060 matches port 5060 0(15109) DEBUG: t_newtran: msg id=36 , global msg id=36 , T on entrance=0xb3df7 618 * 0(15109) ERROR: t_newtran: transaction already in process 0xb3df7618* 0(15109) DEBUG:tm:UNREF_UNSAFE: after is 0 0(15109) DEBUG:destroy_avp_list: destroying list (nil) 0(15109) receive_msg: cleaning up 1(15110) DEBUG: timer routine:1,tl=0xb3df78ec next=0xb3df7818 1(15110) DEBUG: timer routine:1,tl=0xb3df7818 next=0xb3df7744 1(15110) DEBUG: timer routine:1,tl=0xb3df7744 next=(nil) 1(15110) DEBUG: timer routine:4,tl=0xb3df76c8 next=0xb3df78dc 1(15110) DEBUG: retransmission_handler : reply resending (t=0xb3df7618, SIP/2.0 4 ... ) 1(15110) DEBUG:tm:t_retransmit_reply: buf=0xb7db8c60: SIP/2.0 4..., shmem=0xb3d f8f50: SIP/2.0 4 1(15110) DEBUG: add_to_tail_of_timer[5]: 0xb3df76c8 1(15110) DEBUG: retransmission_handler : done 1(15110) DEBUG: timer routine:4,tl=0xb3df78dc next=0xb3df7808 1(15110) DEBUG: timer routine:4,tl=0xb3df7808 next=0xb3df7734 1(15110) DEBUG: timer routine:4,tl=0xb3df7734 next=(nil) 1(15110) DEBUG: timer routine:5,tl=0xb3df76c8 next=(nil) 1(15110) DEBUG: retransmission_handler : reply resending (t=0xb3df7618, SIP/2.0 4 ... ) 1(15110) DEBUG:tm:t_retransmit_reply: buf=0xb7db8c60: SIP/2.0 4..., shmem=0xb3d f8f50: SIP/2.0 4 1(15110) DEBUG: add_to_tail_of_timer[6]: 0xb3df76c8 1(15110) DEBUG: retransmission_handler : done 1(15110) DEBUG: timer routine:6,tl=0xb3df76c8 next=(nil) 1(15110) DEBUG: retransmission_handler : reply resending (t=0xb3df7618, SIP/2.0 4 ... ) 1(15110) DEBUG:tm:t_retransmit_reply: buf=0xb7db8c60: SIP/2.0 4..., shmem=0xb3d f8f50: SIP/2.0 4 1(15110) DEBUG: add_to_tail_of_timer[7]: 0xb3df76c8 1(15110) DEBUG: retransmission_handler : done 1(15110) DEBUG: timer routine:7,tl=0xb3df76c8 next=(nil) 1(15110) DEBUG: retransmission_handler : reply resending (t=0xb3df7618, SIP/2.0 4 ... ) 1(15110) DEBUG:tm:t_retransmit_reply: buf=0xb7db8c60: SIP/2.0 4..., shmem=0xb3d f8f50: SIP/2.0 4 1(15110) DEBUG: add_to_tail_of_timer[7]: 0xb3df76c8 1(15110) DEBUG: retransmission_handler : done 1(15110) INFO: signal 2 received 1(15110) Memory status (pkg): 1(15110) fm_status (0x811fd80): 1(15110) heap size= 1048576 1(15110) used= 34976, used+overhead=55056, free=993520 1(15110) max used (+overhead)= 55880 1(15110) dumping free list: 1(15110) hash = 7 fragments no.: 1, unused: 0 bucket size: 56 - 56 (first 56) 1(15110) hash = 16 fragments no.: 6, unused: 0 bucket size: 128 - 128 (first 128) 1(15110) hash = 255 fragments no.: 1, unused: 0 bucket size: 2040 - 2040 (first 2040) 1(15110) hash = 2054 fragments no.: 1, unused: 0 bucket size: 524288 - 1048576 (first 990656) 1(15110) TOTAL: 9 free fragments = 993520 free bytes 1(15110) ----------------------------- thanks any help, Tamas

1 0

RE: [Serusers] DNS and IP
by Rosa De Santis 09 Oct '06

09 Oct '06

Hi, Weiter. Thanks for your answer. I already have "alias=the.domain.name" in my config, but its not working :( Any ideas??? Thanks again. Rosa. ----------------------------------------------- > Date: Sun, 8 Oct 2006 12:02:24 +0200 > From: bp4mls(a)googlemail.com > To: rosadesantis(a)hotmail.com > Subject: Re: [Serusers] DNS and IP > CC: serusers(a)iptel.org > > Make sure the box where SER is running can also resolve the name to it's own IP. > You can also use "alias=the.domain.name" in you config. > On 10/6/06, Rosa De Santis <rosadesantis(a)hotmail.com> wrote: > Hello all. > Please, I have a problem using DNS or IP on the client side. > When I use IP all calls are fine, but if I use the DNS of the server that point to the same IP some calls can't be done. > Is there any place to configure this on ser.cfg ??? > Please help. > Thanks. > _________________________________________________________________ > Busca desde cualquier página Web con una protección excepcional. Consigue la Barra de herramientas de Windows Live hoy mismo GRATUITAMENTE. > http://toolbar.live.com_______________________________________________ > Serusers mailing list > Serusers(a)lists.iptel.org > http://lists.iptel.org/mailman/listinfo/serusers _________________________________________________________________ Llama a tus amigos de PC a PC: ¡Es GRATIS! http://get.live.com/messenger/overview

1 0

Re: [Users] Multi Call-Legs accounting configuration
by Ricardo Carvalho 09 Oct '06

09 Oct '06

I've done like Rafael told in the e-mail shown bellow for 1.1.x version, although I was expecting to see in acc table to be written A B and C contacts of forwarded calls (when A calls B and B forwards to C), but there is never written B contact, the one who should be billed for that call... the entries in my acc table for forwarded calls are like this: | sip_from | sip_to | i_uri | o_uri | from_uri | to_uri | src_leg | dst_leg | |---------------------------------------------------------------------------| | A | C | C | C | A | C | A | C | As seen, my acc table doesn't show B contact!! How should I edit my openser.cfg file so that B contact be shown in acc table for forwarded calls? Thanks, Ricardo. Rafael J. Risco G.V. wrote: > hi ricardo, > for 1.1.x version, try this: > modparam("acc", "multi_leg_enabled", 1) > modparam("acc", "src_leg_avp_id", 110) > modparam("acc", "dst_leg_avp_id", 111) > ... > route { > > ## populate the avps (for Multi call leg accounting): > if (!method=="REGISTER" && !method=="NOTIFY") { > avp_write("$from/username", "$avp(i:110)"); > avp_write("$ruri/username", "$avp(i:111)"); > }; > ..... > > for 1.2 or cvs : > # for mysql-based accouting, use the names of the columns > modparam("acc", "multi_leg_info", > "leg_src=$avp(i:110);leg_dst=$avp(i:111)") > > Do not forget to add src_leg and dst_leg columns in acc table > (leg_src, leg_dst for 1.2) > > rafael > > > On 10/6/06, Ricardo Carvalho <rcarvalho(a)iric.up.pt> wrote: >> I want to use Multi Call-Legs accounting to properly account forwarded >> calls made "in the phones". For example user A calls user B which >> forwards the call to user C. There is only one SIP call but with 2 legs >> ( A to B and B to C). Accounting the legs of a call is required for >> proper billing of the calls. >> >> As can be seen in acc module documentation, I've added the following 3 >> lines to my openser.cfg script: >> >> modparam("acc", "multi_leg_enabled", 1) >> modparam("acc", "src_leg_avp_id", 110) >> modparam("acc", "dst_leg_avp_id", 110) >> >> Although, after testing some forwarded calls, nothing has been written >> to src_leg or dst_leg columns of acc table!! >> What have I done wrong? How may I implement this feature correctly? >> >> Regards, >> Ricardo. >> >> _______________________________________________ >> Users mailing list >> Users(a)openser.org >> http://openser.org/cgi-bin/mailman/listinfo/users >> >

1 0

[Users] openser.org down?
by Brandon Price 09 Oct '06

09 Oct '06

Can't access it from NYC, or Sanfran.

1 0

[Users] retransmission 404 not found
by Cseke Tamas 09 Oct '06

09 Oct '06

1 0

[Users] Multi Call-Legs accounting configuration
by Ricardo Carvalho 09 Oct '06

09 Oct '06

I want to use Multi Call-Legs accounting to properly account forwarded calls made "in the phones". For example user A calls user B which forwards the call to user C. There is only one SIP call but with 2 legs ( A to B and B to C). Accounting the legs of a call is required for proper billing of the calls. As can be seen in acc module documentation, I've added the following 3 lines to my openser.cfg script: modparam("acc", "multi_leg_enabled", 1) modparam("acc", "src_leg_avp_id", 110) modparam("acc", "dst_leg_avp_id", 110) Although, after testing some forwarded calls, nothing has been written to src_leg or dst_leg columns of acc table!! What have I done wrong? How may I implement this feature correctly? Regards, Ricardo.

3 3

[Serusers] Using forward_tcp help
by Nhadie Ramos 09 Oct '06

09 Oct '06

Hi All, I have the REGISTER part of my ser.cfg below, what do you think is wrong because it doesn't replicate it. Do i have to do any changes on parameters of required modules? if (method=="REGISTER") { if ((src_ip=="10.10.10.20") || (src_ip=="10.10.10.30")) { if (isflagset(8)) {xlog("L_INFO", "Register: Source is either 10.10.10.20 or 10.10.10.30\n");}; save_noreply("location"); } else if (!www_authorize("mydomain.com", "subscriber")) { if (isflagset(8)) {xlog("L_INFO", "Register: asking for authentication\n");}; www_challenge("mydomain.com", "0"); break; }; if (isflagset(8)) {xlog("L_INFO", "Register: Authorized, saving location\n");}; if (!save("location")) { sl_reply_error(); } else { if (isflagset(8)) {xlog("L_INFO", "Register: Authorized, saving location\n");}; if ((!src_ip=="10.10.10.20") || (!src_ip=="10.10.10.30")) { if (isflagset(8)) {xlog("L_INFO", "Register: Replicating to 10.10.10.20\n");}; forward_tcp("10.10.10.20", 5060); forward_tcp("10.10.10.30", 5060); }; }; break; };

3 4

[Serusers] RE: Serusers Digest, Vol 42, Issue 6
by Ramachandran 09 Oct '06

09 Oct '06

Deal All, Its really good news that Open IMS components are going to be available soon, Is it possible for me to download / access those currently available version of SER 0.10.99-dev41 ? Thanks a million in advance. Thanks, Ramachandran -----Original Message----- From: serusers-bounces(a)lists.iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of serusers-request(a)lists.iptel.org Sent: Saturday, October 07, 2006 5:30 PM To: serusers(a)lists.iptel.org Subject: Serusers Digest, Vol 42, Issue 6 Send Serusers mailing list submissions to serusers(a)lists.iptel.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.iptel.org/mailman/listinfo/serusers or, via email, send a message with subject or body 'help' to serusers-request(a)lists.iptel.org You can reach the person managing the list at serusers-owner(a)lists.iptel.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Serusers digest..." Today's Topics: 1. Re: SIP to AS communication (Dragos Vingarzan) 2. best way to route a huge number of calls (Sameer Ahmed) ---------------------------------------------------------------------- Message: 1 Date: Fri, 06 Oct 2006 14:14:34 +0200 From: Dragos Vingarzan <vingarzan(a)fokus.fraunhofer.de> Subject: Re: [Serusers] SIP to AS communication To: serusers(a)iptel.org Cc: Jiri Kuthan <jiri(a)iptel.org> Message-ID: <452648AA.6090106(a)fokus.fraunhofer.de> Content-Type: text/plain; charset=windows-1252; format=flowed ...This is re-post, because the previous one was sent from the wrong mail-address and now it awaits moderations... sorry for duplicates if eventually it gets accepted. Hi all, Yes, IMS is quite bloated. However, for the past years we did some work at FOKUS related to it and it will be soon released. It does not have ALL what IMS demands, but it is a start and we hope that you guys, if you think that something more is required, could help us achieve that. I am attaching the proof that it will be, on 16.11.2006 (it is also an invitation for you to participate, but I am not making publicity on this list ;-) http://www.fokus.fraunhofer.de/event/ims_ws_06/ ). If you need further info, feel free to contact us. To offer you some info about it before this date, we will release a bundle of modules: - cdp - for efficient diameter communication in SER (stands for CDiameterPeer) - pcscf - implementing some of the P-CSCF functionality - icscf - -//- ICSCF - scscf- -//- SCSCF - isc - for Initial Filter Criteria Triggering and communication between S-CSCF and AS - sip2ims - a simple MD5 to AKA authorization gateway All these modules at the moment are relatively stable on SER 0.10.99-dev41. But the problem there is that the diameter functionality is integrated into the core. We are working now on stabilizing the cdp as a module in 0.10.99-dev45. Once we succeed, I hope that the modules will be usable with any new plain-CVS SER release. Also, we will give away FHoSS - our Java HSS implementation together with the included pure Java - Java Diameter Peer - diameter functionality. So, you will have a basic IMS system to play with. Almost the same Open IMS Core is used in the ETSI/TISPAN IMS Benchmarking effort as a reference implementation for the System Under Test (look for WorkItem 06024). Don't expect too much, but at least now we have full Cx support, Initial Filter Criteria triggering, ISC support, AKA authentication, IPSec in transport mode with clients, etc... and all this plus the wonderful SER script functionality. Oh yeah :)... and don't expect carrier-grade quality though. These are research projects and we care more about experimenting with the latest features than the 99.999%. For that stability, as Jiri implies, Tekelec probably has (or will have) a good solution, but we can't do that as our budgets are much lower than those of the SPs or TEMS. As Andrey pointed out, we are not the only ones doing this, but I hope that we could converge. And Jiri is right about the complexity. There are at least 4 components that have to work together. For SigComp, because of it's complexity, I was considering TLS with compression. This could also replace the IPSec transport mode tunnel for security, which could be difficult on some embedded devices. Any thoughts on this? Anyway, SigComp is asked mainly by the mobile operators only and we should not . Looking forward for you comments, Dragos Vingarzan Jiri Kuthan wrote: > Just a warning small in size but I guess big in the impact. I think people kind > of underappreciate the effort which has to be taken. If you consider all the > 3gpp complexity (sigcomp as a prime example, one of many being real non-trivial), > size of mobile networks for which the system has to be running, number of > interfaces to speak over and achieve interoperability (management, diameter, > applications, cdr processing...), routing features (the 'scim' feature with > which this discussion began)... > > I occur to know Tekelec has gone through this exercise and generating > a reasonable result has cost quite an investment. > > > At 07:19 06/10/2006, Andrey Kuprianov wrote: > >> Hi, I suppose you need to develop modules for all the the x-CSCF + AS (where x-CSCF is P-CSCF, S-CSCF or I-CSCF). You see, the functionalities/features that x-CSCF and application servers require (for instance, P-headers or querying for subscriber information from HSS) are not available in SER. That's why you need to make your own modules *all the way*. As for HSS, i dont think you need to make some special super DIAMETER-enabled database. In my (an in many other people's btw) point of view a simple database, like MySQL is more than capable of storing subscriber info or initial filtering criterias (iFC --> im talking about SCIM/SIMF). If you are really set to develop IMS on SER, then maybe you can start with SER 0.8.14. You can still find decent development documentation for it. As for later versions, I dont think any good docs are yet available (someone, please, correct me if im wrong) >> > > The documentation is being worked on, but for the moment you are unfortunately correct. > > >> Just for your info, INT (France) joint with France Telecom are developing IMS on SER as of now (dont know if it's going to be commerial or open-source. >> Contact them if you are interested, maybe you can even help them develop it further :). Plus, Focus is also set to develop a commercial version of IMS for SER and, although, Focus said that their IMS will be available in the last quarter of this year, but nothing's been released yet. :( >> > > That's fantastic news, I'm looking forward to GPL contributions from these > very respectable institutions. This is really a big piece of work and I am > enormously positive about every single new piece of the puzzle. > > -jiri > > >> Good luck, Andrey. On 10/6/06, Kamal.Mann(a)t-systems.com <Kamal.Mann(a)t-systems.com> wrote: > Hi All > We are using SER as CSCF which communicates with HSS and Application Server. > ï§ Whenever a UA sends a request to SER then it should go to some specific table and look for services assigned to that particular UA. > ï§ If UA is authorize to use that service than SER send this to AS. > ï§ AS then send this request/response to Serving SER (S-CSCF) which further serves that UA. > I need your suggestions for the same that what kind of module we need to develop for this scenario or any valuable suggestions. > > Thanks in anticipation > Kamal Mann > > _______________________________________________ > Serusers mailing list > Serusers(a)lists.iptel.org > http://lists.iptel.org/mailman/listinfo/serusers > > > </x-flowed> >> _______________________________________________ >> Serusers mailing list >> Serusers(a)lists.iptel.org >> http://lists.iptel.org/mailman/listinfo/serusers >> > > -- > Jiri Kuthan http://iptel.org/~jiri/ > > _______________________________________________ > Serusers mailing list > Serusers(a)lists.iptel.org > http://lists.iptel.org/mailman/listinfo/serusers > > -- ----------------------------------------- Dipl. Eng. Dragos Vingarzan FOKUS/NGNI Kaiserin-Augusta-Allee 31 10589 Berlin,Germany Phone +49 (0)30 - 3463 - 7385 Mobile +49 (0)163 - 159 - 5221 eMail vingarzan(a)fokus.fraunhofer.de Web www.fokus.fraunhofer.de We could change the world if God would give us the source code... ----------------------------------------------------------------- ------------------------------ Message: 2 Date: Sat, 7 Oct 2006 13:00:54 +0500 From: "Sameer Ahmed" <sameer.ahmed(a)gmail.com> Subject: [Serusers] best way to route a huge number of calls To: serusers(a)lists.iptel.org Message-ID: <413b539b0610070100l2a65474av2c99b805bb1c1db3(a)mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" Hi What is the best way to filter through a large number of subscribers registered on SER? Hundreds of IF...ELSE statements don't look efficient, nor pretty. Regards, Sameer

1 0

[Users] rel_1_1_0 CVS seems to be badly broken
by Juha Heinanen 09 Oct '06

09 Oct '06

when i look rel_1_1_0 using ViewVC i see core directory mi and imc module for example. those should not be there: http://openser.cvs.sourceforge.net/openser/sip-server/?pathrev=rel_1_1_0 this in addition to the earlier problem that anon cvs checkout fails. -- juha

1 0

← Newer
1
...
24
25
26
27
28
29
30
...
35
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users October 2006