sr-users March 2005

sr-users@lists.kamailio.org

250 participants
627 discussions

Re: [Serusers] Claims of ser-0.9 RFC3261 Violation
by Jan Janak 08 Mar '05

08 Mar '05

On 08-03 08:53, Jain, Rajnish wrote: > Jan, > I'm not much familiar w/ SER and at this point I've actually > unsubscribed from this mailing list, but consider the following: > > You're right in storing the NAT's IP address and port in your location > database and then later sending the SIP message to that address. > However, why even have an option that results in the 200 OK for the > REGISTER to be constructed incorrectly (that is w/ the NAT's IP/port as > Contact). Because you still need the function to rewrite the contacts of INVITE, SUBSCRIBE and other messages. > If the user fails to set the option (fix_nated_register), what are we > going to gain by putting NAT's address in 200 OK's Contact? > > Why not have > the 200 OK always carry the correct Contacts? Although it is not entirely correct, it works fine in many cases. fix_nated_contact is not going to dissapear anyway, because it is needed in other cases. Jan.

1 0

[Serusers] 0.9.0 Invalid table version
by Daniel Poulsen 08 Mar '05

08 Mar '05

Hi, I saw another serusers post on this, but didn't find an answer. I have a vanilla install of 0.9.0 on a freshly built debian box. When I run ser, I get: Mar 4 11:34:52 sip-failover ser[5055]: Maxfwd module- initializing Mar 4 11:34:52 sip-failover ser[5055]: register_udomain(): Invalid table version (use ser_mysql.sh reinstall) Mar 4 11:34:52 sip-failover ser[5055]: domain_fixup(): Error while registering domain Mar 4 11:34:52 sip-failover ser[5055]: ERROR: fix_expr : fix_actions error If I run ser_mysql.sh reinstall, I get different errors: Mar 4 11:36:42 sip-failover ser[5102]: table_version(): Invalid number of rows received: 2, uri Mar 4 11:36:42 sip-failover ser[5102]: ERROR: uri_db:mod_init(): Error while querying table version Mar 4 11:36:42 sip-failover ser[5102]: init_mod(): Error while initializing module uri_db As the previous poster defailed, the "invalid number" error occurs because the ser_mysql.sh script creates duplicate entries in the version table. The quesion is, what table version sill satisfy 'register_udomain()'? Currently, I have: mysql> select * from version; +-----------------------+---------------+ | table_name | table_version | +-----------------------+---------------+ | subscriber | 5 | | reserved | 1 | | phonebook | 1 | | pending | 4 | | missed_calls | 2 | | location | 6 | | grp | 2 | | event | 1 | | aliases | 6 | | active_sessions | 1 | | acc | 2 | | config | 1 | | silo | 3 | | realm | 1 | | domain | 1 | | uri | 1 | | server_monitoring | 1 | | server_monitoring_agg | 1 | | trusted | 1 | | usr_preferences | 1 | | preferences_types | 1 | | admin_privileges | 1 | | calls_forwarding | 1 | | speed_dial | 1 | +-----------------------+---------------+ 24 rows in set (0.00 sec) Thank you for your time, Dan Poulsen

2 2

RE: [Serusers] Claims of ser-0.9 RFC3261 Violation
by Linda Xiao 08 Mar '05

08 Mar '05

You are not the only service provider who makes this kind of changes. I also encountered the same problem recently. But so far, this problem only happened on one UA which has the same sip engine as this engineer's. All other UAs in my hand can adapt this kinds of changes. So I personally think that instead of complaining SIP proxy violation, I would rather complain the interoperatibility of this sip engine. regards/Linda -----Original Message----- From: serusers-bounces(a)iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Klaus Darilion Sent: Wednesday, March 02, 2005 9:37 AM To: Java Rockx Cc: serusers(a)lists.iptel.org Subject: Re: [Serusers] Claims of ser-0.9 RFC3261 Violation I guess the engineer is right. Thus, I use fix_nated_register() instead of fix_nated_contact which does not rewrite the contact header. regards, klaus Java Rockx wrote: > It is the same. Their IAD successfully registers the first time, but > loses its registration because re-REGISTER messages are claimed to be > in voliation of RFC3261. > > Here is exactly what their engineers are telling me: > > > Paul, > Here is the my findings regarding the contact field in the > REGISTER message... > > We suspect the registration fails because the Contact of 200OK does > not match the Contact of REGISTER: > >>From the capture, Our network toplogy is like: > TA: 192.168.0.180 <--------> Router 65.77.37.2 <----------> Softswitch > 64.84.242.120 > > Packet 4 REGISTER: > Contact: <sip:3212514276@192.168.0.180;user=phone>;expires=200 > > Packet 6 200OK: > Contact: <sip:3212514276@65.77.37.2:36323;user=phone>;expires=200, > <sip:3212514276@65.77.37.2:36235;user=phone>;expires=3 > > In RFC3261, it says: > The 200 (OK) response from the registrar contains a list of Contact > fields enumerating all current bindings. The UA compares each > contact address to see if it created the contact address, using > comparison rules in Section 19.1.4. If so, it updates the expiration > time interval according to the expires parameter or, if absent, the > Expires field value. The UA then issues a REGISTER request for each > of its bindings before the expiration interval has elapsed. It MAY > combine several updates into one REGISTER request. > > So obviously the contact addresses in 200OK don't match the one in > REGISTER. > > > On Wed, 2 Mar 2005 11:28:51 -0500, Vitaly Nikolaev > <vitaly(a)voipsonic.com> wrote: > >>Is contact field that SER sends to UAS is same for all requests ? >> >>If not probably you are not doing fix natted contact in some cases >> >> >>-----Original Message----- >>From: serusers-bounces(a)iptel.org [mailto:serusers-bounces@lists.iptel.org] >>On Behalf Of Java Rockx >>Sent: Wednesday, March 02, 2005 11:17 AM >>To: serusers(a)lists.iptel.org >>Subject: [Serusers] Claims of ser-0.9 RFC3261 Violation >> >>I just spoke with an enginee from a manufacturer of the WorldAccxx >>telephone adapter and he told me that my SIP proxy was in voliation of >>RFC3261. >> >>Below is a SIP registration against my ser-0.9 proxy. I'm using media >>proxy for NAT traversal and he says that my 200 OK is not valid and >>therefore their IAD disregards the 200 OK response. >> >>The problem he claims is with the <Contact:> header in the 200 OK. SER >>has rewritten the contact becase his IAD is NATed. Should I not be >>doing this? >> >>The actual problem is that when their IAD is NATed the device looses >>its registration with ser because (they claim) that the REGISTER >>message they send has a <Contact> header iwith a different IP than >>what ser sends back in the 200 OK message. >> >>They referenced section 10.2.4 and 19.1.4 in RFC3261. >> >>Can anyone confirm or reject their claims? >> >>Please help. >>Paul >> >>REGISTER sip:sip.mycompany.com:5060 SIP/2.0 >>Via: SIP/2.0/UDP 192.168.0.180;branch=z9hG4bKbb013e10d >>Max-Forwards: 70 >>Content-Length: 0 >>To: Accxx <sip:1000@sip.mycompany.com:5060> >>From: Accxx <sip:1000@sip.mycompany.com:5060>;tag=1eb7db0b344ac92 >>Call-ID: bd4da0ebfe98297597243a92b1b0f868(a)192.168.0.180 >>CSeq: 392547129 REGISTER >>Contact: Accxx <sip:1000@192.168.0.180;user=phone>;expires=200 >>Allow: NOTIFY >>Allow: REFER >>Allow: OPTIONS >>Allow: INVITE >>Allow: ACK >>Allow: CANCEL >>Allow: BYE >>User-Agent: WATA200 Callctrl/1.5.1.1 MxSF/v3.2.6.26 >> >>SIP/2.0 100 Trying >>Via: SIP/2.0/UDP >>192.168.0.180;branch=z9hG4bKbb013e10d;rport=36323;received=65.77.37.2 >>To: Accxx <sip:1000@sip.mycompany.com:5060> >>From: Accxx <sip:1000@sip.mycompany.com:5060>;tag=1eb7db0b344ac92 >>Call-ID: bd4da0ebfe98297597243a92b1b0f868(a)192.168.0.180 >>CSeq: 392547129 REGISTER >>Content-Length: 0 >> >>SIP/2.0 401 Unauthorized >>Via: SIP/2.0/UDP >>192.168.0.180;branch=z9hG4bKbb013e10d;rport=36323;received=65.77.37.2 >>To: Accxx >><sip:1000@sip.mycompany.com:5060>;tag=bf952ed189d8425c881b09485aa0b6f1 >>.bdad >>From: Accxx <sip:1000@sip.mycompany.com:5060>;tag=1eb7db0b344ac92 >>Call-ID: bd4da0ebfe98297597243a92b1b0f868(a)192.168.0.180 >>CSeq: 392547129 REGISTER >>WWW-Authenticate: Digest realm="sip.mycompany.com", >>nonce="42025161902f6f6af11f01f0a93ad2877e606bbc" >>Content-Length: 0 >> >>REGISTER sip:sip.mycompany.com:5060 SIP/2.0 >>Via: SIP/2.0/UDP 192.168.0.180;branch=z9hG4bK88fcb4e76 >>Max-Forwards: 70 >>Content-Length: 0 >>To: Accxx <sip:1000@sip.mycompany.com:5060> >>From: Accxx <sip:1000@sip.mycompany.com:5060>;tag=1eb7db0b344ac92 >>Call-ID: bd4da0ebfe98297597243a92b1b0f868(a)192.168.0.180 >>CSeq: 392547130 REGISTER >>Contact: Accxx <sip:1000@192.168.0.180;user=phone>;expires=200 >>Allow: NOTIFY >>Allow: REFER >>Allow: OPTIONS >>Allow: INVITE >>Allow: ACK >>Allow: CANCEL >>Allow: BYE >>Authorization:Digest >>response="18aabe984a6d89cc537cec9ce43b198d",username="1000",realm="sip >>.mycom >>pany.com",nonce="42025161902f6f6af11f01f0a93ad2877e606bbc",uri="sip:si p.myco >>mpany.com:5060" >>User-Agent: WATA200 Callctrl/1.5.1.1 MxSF/v3.2.6.26 >> >>SIP/2.0 100 Trying >>Via: SIP/2.0/UDP >>192.168.0.180;branch=z9hG4bK88fcb4e76;rport=36323;received=65.77.37.2 >>To: Accxx <sip:1000@sip.mycompany.com:5060> >>From: Accxx <sip:1000@sip.mycompany.com:5060>;tag=1eb7db0b344ac92 >>Call-ID: bd4da0ebfe98297597243a92b1b0f868(a)192.168.0.180 >>CSeq: 392547130 REGISTER >>Content-Length: 0 >> >>SIP/2.0 200 OK >>Via: SIP/2.0/UDP >>192.168.0.180;branch=z9hG4bK88fcb4e76;rport=36323;received=65.77.37.2 >>To: Accxx >><sip:1000@sip.mycompany.com:5060>;tag=bf952ed189d8425c881b09485aa0b6f1 >>.5e63 >>From: Accxx <sip:1000@sip.mycompany.com:5060>;tag=1eb7db0b344ac92 >>Call-ID: bd4da0ebfe98297597243a92b1b0f868(a)192.168.0.180 >>CSeq: 392547130 REGISTER >>Contact: <sip:1000@65.77.37.2:36323;user=phone>;expires=200, >><sip:1000@65.77.37.2:36235;user=phone>;expires=3 >>Content-Length: 0 >> >>_______________________________________________ >>Serusers mailing list >>serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers >> >> > > > _______________________________________________ > Serusers mailing list > serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers > > _______________________________________________ Serusers mailing list serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

4 6

[Serusers] MySQL
by Marc Khayat 08 Mar '05

08 Mar '05

Hello all, I just installed SER on my Linux (AS 3) Intel server, and Im trying to install MySQL. But as Im reading: To install support for a MySQL database you will need to download the package ser-mysql. Anyone can tell me or send me the link from where I can download it? Thx

2 1

[Serusers] Does loose_route ignore REGISTER messages with <Route> Headers?
by Java Rockx 08 Mar '05

08 Mar '05

Hi all. Does anyone know if the loose_route() function returns FALSE for REGISTER messages that erroneously happen to contain Route headers? In other words, do I have to do this: route { # sanity checks if (method!="REGISTER") record_route(); if (loose_route() && method!="REGISTER") { <-------Is This Necessary??? # handle loose routing break; } # Normal processing } Regards, Paul

3 2

RE: [Serusers] Claims of ser-0.9 RFC3261 Violation
by Jain, Rajnish 08 Mar '05

08 Mar '05

I'm new to this mailing list. This seems like an interesting question, so thought would put my 2 cents in: It seems like this is incorrect behavior on SER's part. SER is entitled to maintain the public IP addresses for the Contact in it's location service. But, the 200 OK that goes out on the wire to the end-point should contain the same Contact IP addresses that came in the REGISTER. _____ From: serusers-bounces(a)iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Vitaly Nikolaev Sent: Wednesday, March 02, 2005 1:25 PM To: 'Linda Xiao'; 'Java Rockx' Cc: serusers(a)lists.iptel.org Subject: RE: [Serusers] Claims of ser-0.9 RFC3261 Violation I do not agree... Contact should be same in the dialog... _____ From: serusers-bounces(a)iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Linda Xiao Sent: Wednesday, March 02, 2005 1:16 PM To: Java Rockx Cc: serusers(a)lists.iptel.org Subject: RE: [Serusers] Claims of ser-0.9 RFC3261 Violation You are not the only service provider who makes this kind of changes. I also encountered the same problem recently. But so far, this problem only happened on one UA which has the same sip engine as this engineer's. All other UAs in my hand can adapt this kinds of changes. So I personally think that instead of complaining SIP proxy violation, I would rather complain the interoperatibility of this sip engine. regards/Linda -----Original Message----- From: serusers-bounces(a)iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Klaus Darilion Sent: Wednesday, March 02, 2005 9:37 AM To: Java Rockx Cc: serusers(a)lists.iptel.org Subject: Re: [Serusers] Claims of ser-0.9 RFC3261 Violation I guess the engineer is right. Thus, I use fix_nated_register() instead of fix_nated_contact which does not rewrite the contact header. regards, klaus Java Rockx wrote: > It is the same. Their IAD successfully registers the first time, but > loses its registration because re-REGISTER messages are claimed to be > in voliation of RFC3261. > > Here is exactly what their engineers are telling me: > > > Paul, > Here is the my findings regarding the contact field in the > REGISTER message... > > We suspect the registration fails because the Contact of 200OK does > not match the Contact of REGISTER: > >>From the capture, Our network toplogy is like: > TA: 192.168.0.180 <--------> Router 65.77.37.2 <----------> Softswitch > 64.84.242.120 > > Packet 4 REGISTER: > Contact: <sip:3212514276@192.168.0.180;user=phone>;expires=200 > > Packet 6 200OK: > Contact: <sip:3212514276@65.77.37.2:36323;user=phone>;expires=200, > <sip:3212514276@65.77.37.2:36235;user=phone>;expires=3 > > In RFC3261, it says: > The 200 (OK) response from the registrar contains a list of Contact > fields enumerating all current bindings. The UA compares each > contact address to see if it created the contact address, using > comparison rules in Section 19.1.4. If so, it updates the expiration > time interval according to the expires parameter or, if absent, the > Expires field value. The UA then issues a REGISTER request for each > of its bindings before the expiration interval has elapsed. It MAY > combine several updates into one REGISTER request. > > So obviously the contact addresses in 200OK don't match the one in > REGISTER. > > > On Wed, 2 Mar 2005 11:28:51 -0500, Vitaly Nikolaev > <vitaly(a)voipsonic.com> wrote: > >>Is contact field that SER sends to UAS is same for all requests ? >> >>If not probably you are not doing fix natted contact in some cases >> >> >>-----Original Message----- >>From: serusers-bounces(a)iptel.org [mailto:serusers-bounces@lists.iptel.org] >>On Behalf Of Java Rockx >>Sent: Wednesday, March 02, 2005 11:17 AM >>To: serusers(a)lists.iptel.org >>Subject: [Serusers] Claims of ser-0.9 RFC3261 Violation >> >>I just spoke with an enginee from a manufacturer of the WorldAccxx >>telephone adapter and he told me that my SIP proxy was in voliation of >>RFC3261. >> >>Below is a SIP registration against my ser-0.9 proxy. I'm using media >>proxy for NAT traversal and he says that my 200 OK is not valid and >>therefore their IAD disregards the 200 OK response. >> >>The problem he claims is with the <Contact:> header in the 200 OK. SER >>has rewritten the contact becase his IAD is NATed. Should I not be >>doing this? >> >>The actual problem is that when their IAD is NATed the device looses >>its registration with ser because (they claim) that the REGISTER >>message they send has a <Contact> header iwith a different IP than >>what ser sends back in the 200 OK message. >> >>They referenced section 10.2.4 and 19.1.4 in RFC3261. >> >>Can anyone confirm or reject their claims? >> >>Please help. >>Paul >> >>REGISTER sip:sip.mycompany.com:5060 SIP/2.0 >>Via: SIP/2.0/UDP 192.168.0.180;branch=z9hG4bKbb013e10d >>Max-Forwards: 70 >>Content-Length: 0 >>To: Accxx <sip:1000@sip.mycompany.com:5060> >>From: Accxx <sip:1000@sip.mycompany.com:5060>;tag=1eb7db0b344ac92 >>Call-ID: bd4da0ebfe98297597243a92b1b0f868(a)192.168.0.180 >>CSeq: 392547129 REGISTER >>Contact: Accxx <sip:1000@192.168.0.180;user=phone>;expires=200 >>Allow: NOTIFY >>Allow: REFER >>Allow: OPTIONS >>Allow: INVITE >>Allow: ACK >>Allow: CANCEL >>Allow: BYE >>User-Agent: WATA200 Callctrl/1.5.1.1 MxSF/v3.2.6.26 >> >>SIP/2.0 100 Trying >>Via: SIP/2.0/UDP >>192.168.0.180;branch=z9hG4bKbb013e10d;rport=36323;received=65.77.37.2 >>To: Accxx <sip:1000@sip.mycompany.com:5060> >>From: Accxx <sip:1000@sip.mycompany.com:5060>;tag=1eb7db0b344ac92 >>Call-ID: bd4da0ebfe98297597243a92b1b0f868(a)192.168.0.180 >>CSeq: 392547129 REGISTER >>Content-Length: 0 >> >>SIP/2.0 401 Unauthorized >>Via: SIP/2.0/UDP >>192.168.0.180;branch=z9hG4bKbb013e10d;rport=36323;received=65.77.37.2 >>To: Accxx >><sip:1000@sip.mycompany.com:5060>;tag=bf952ed189d8425c881b09485aa0b6f1 >>.bdad >>From: Accxx <sip:1000@sip.mycompany.com:5060>;tag=1eb7db0b344ac92 >>Call-ID: bd4da0ebfe98297597243a92b1b0f868(a)192.168.0.180 >>CSeq: 392547129 REGISTER >>WWW-Authenticate: Digest realm="sip.mycompany.com", >>nonce="42025161902f6f6af11f01f0a93ad2877e606bbc" >>Content-Length: 0 >> >>REGISTER sip:sip.mycompany.com:5060 SIP/2.0 >>Via: SIP/2.0/UDP 192.168.0.180;branch=z9hG4bK88fcb4e76 >>Max-Forwards: 70 >>Content-Length: 0 >>To: Accxx <sip:1000@sip.mycompany.com:5060> >>From: Accxx <sip:1000@sip.mycompany.com:5060>;tag=1eb7db0b344ac92 >>Call-ID: bd4da0ebfe98297597243a92b1b0f868(a)192.168.0.180 >>CSeq: 392547130 REGISTER >>Contact: Accxx <sip:1000@192.168.0.180;user=phone>;expires=200 >>Allow: NOTIFY >>Allow: REFER >>Allow: OPTIONS >>Allow: INVITE >>Allow: ACK >>Allow: CANCEL >>Allow: BYE >>Authorization:Digest >>response="18aabe984a6d89cc537cec9ce43b198d",username="1000",realm="sip >>.mycom >>pany.com",nonce="42025161902f6f6af11f01f0a93ad2877e606bbc",uri="sip:si p.myco >>mpany.com:5060" >>User-Agent: WATA200 Callctrl/1.5.1.1 MxSF/v3.2.6.26 >> >>SIP/2.0 100 Trying >>Via: SIP/2.0/UDP >>192.168.0.180;branch=z9hG4bK88fcb4e76;rport=36323;received=65.77.37.2 >>To: Accxx <sip:1000@sip.mycompany.com:5060> >>From: Accxx <sip:1000@sip.mycompany.com:5060>;tag=1eb7db0b344ac92 >>Call-ID: bd4da0ebfe98297597243a92b1b0f868(a)192.168.0.180 >>CSeq: 392547130 REGISTER >>Content-Length: 0 >> >>SIP/2.0 200 OK >>Via: SIP/2.0/UDP >>192.168.0.180;branch=z9hG4bK88fcb4e76;rport=36323;received=65.77.37.2 >>To: Accxx >><sip:1000@sip.mycompany.com:5060>;tag=bf952ed189d8425c881b09485aa0b6f1 >>.5e63 >>From: Accxx <sip:1000@sip.mycompany.com:5060>;tag=1eb7db0b344ac92 >>Call-ID: bd4da0ebfe98297597243a92b1b0f868(a)192.168.0.180 >>CSeq: 392547130 REGISTER >>Contact: <sip:1000@65.77.37.2:36323;user=phone>;expires=200, >><sip:1000@65.77.37.2:36235;user=phone>;expires=3 >>Content-Length: 0 >> >>_______________________________________________ >>Serusers mailing list >>serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers >> >> > > > _______________________________________________ > Serusers mailing list > serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers > > _______________________________________________ Serusers mailing list serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

2 1

[Serusers] http / https in Userloc db
by Martin Koenig 08 Mar '05

08 Mar '05

Hello, how can something like this happen: ~~~Contact(0x422be558)~~~ domain : 'location' aor : 'd1089081000' Contact : 'http://192.168.0.206:80' Expires : 2981 q : 0.00 Call-ID : '3c267009b239-jdcz81xdwoag@snom360' CSeq : 547 replic : 0 User-Agent: 'snom360-3.57t' State : CS_NEW Flags : 1 next : 0x422c04d0 prev : 0x422bf330 ~~~/Contact~~~~ ~~~Contact(0x422c04d0)~~~ domain : 'location' aor : 'd1089081000' Contact : 'https://192.168.0.206:443' Expires : 2981 q : 0.00 Call-ID : '3c267009b239-jdcz81xdwoag@snom360' CSeq : 547 replic : 0 User-Agent: 'snom360-3.57t' State : CS_NEW Flags : 1 next : (nil) prev : 0x422be558 ~~~/Contact~~~~ HTTP/HTTPS contacts in userloc? Causes the following error, besides that calls to that contact will probably fail: Mar 1 15:51:23 s-p1 /usr/local/sbin/ser[1716]: ERROR: parse_uri: bad uri, state 0 parsed: <http> (4) / <http://192.168.0.206:80> (23) Mar 1 15:51:23 s-p1 /usr/local/sbin/ser[1716]: error: mediaproxy/pingClients(): can't parse contact uri Mar 1 15:51:23 s-p1 /usr/local/sbin/ser[1716]: ERROR: parse_uri: bad uri, state 0 parsed: <http> (4) / <https://192.168.0.206:443> (25) Mar 1 15:51:23 s-p1 /usr/local/sbin/ser[1716]: error: mediaproxy/pingClients(): can't parse contact uri How can this uri get into Usrloc in the first place? With best regards, Martin

4 10

Re: [Serusers] SER RADIUS Accounting and B2BUA
by Mohamed Omar 08 Mar '05

08 Mar '05

when using Cisco for billing and teardown, how do you over come the limitation of hairpinning Voip leg to Voip leg call on a cisco router if your are not connected to a PSTN network and you have to terminate on someone else gateway? Thanks Mohamed. Alistair Cunningham <acunningham(a)integrics.com> wrote: Matt, Because SER handles SIP messages, not RTP streams, it cannot 100% accurately record CDRs. For instance, if the BYE message is lost because a client crashed, SER has no way of knowing when the call ended or how much it cost. A BTBUA gets round this problem by having the RTP packets come to it, so if a client crashes, the RTP stream stops and the BTBUA knows the call has finished. The disadvantage of a BTBUA is that it adds latency and doesn't scale well, because it needs to handle all the RTP traffic. I install quite a few SER and Asterisk systems for my customers, and a fix for this issue is the most frequent item I'm asked for. It's unavoidable, however, if one wants SER's scalability. What I usually recommend for them is to install a SER system (for scalability, registrations, routing of calls that don't need a CDR, etc) fronting multiple BTBUAs such as Asterisk or Cisco (for accurate billing of PSTN calls). Alistair Cunningham, Integrics Ltd, Telephony, Database, Unix consulting worldwide +44 (0)7870 699 479 http://integrics.com/ matt morris wrote: > Hello List, > > Just wondering, what is the radius account module for SER not able to > do, that would require the use of B2BUA in terms of having a CDR? > Forgive me if it is a dumb question... > > Thanks. > > _________________________________________________________________ > Scan and help eliminate destructive viruses from your inbound and > outbound e-mail and attachments. > http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht… > Start enjoying all the benefits of MSN� Premium right now and get the > first two months FREE*. > > _______________________________________________ > Serusers mailing list > serusers(a)lists.iptel.org > http://lists.iptel.org/mailman/listinfo/serusers > > _______________________________________________ Serusers mailing list serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers --------------------------------- Post your free ad now! Yahoo! Canada Personals

2 1

[Serusers] xlog backport
by Juha Heinanen 08 Mar '05

08 Mar '05

i made available xlog 0.9.0 backport that includes at least %br and %ds specifiers on top of what vanilla 0.9.0 has: http://tutpro.com/tmp/xlog-0.9.0.tgz you can use those, for example, to debug lcr module. %br now prints ALL branches, not just the first one. -- juha

3 2

[Serusers] sdp rewrite problem
by Atif Rasheed 08 Mar '05

08 Mar '05

Hello there, I am working on SER with two network interfaces. EP1--------------->(172.16.16.160) SER (192.168.5.1) -------------> EP2 what happens, SER receives invite from EP1, it reinitiates invite for EP2. now what it does is that it writes the external IP i.e. 172.16.16.160 in the SDP contact info, where as it should be the internal one i.e. 192.168.5.1 ... now I want to overwrite the SDP contact info in that invite. I have got two options to do it one option is to use force_rtp_proxy("ei", "192.168.5.1") or use sdp_mangle_ip() function of mangler.so . but they are not working for me. when I play around with force_rtp_proxy function rtpproxy get crashed and sdp_mangle_ip() is not behaving properly ...... whats your experience ? I have used ser-0.8.14 and now using ser-0.9.0 with cvs rtpproxy. I am running rtpproxy like rtpproxy -s udp:192.168.5.1 -l 172.16.16.160 and I am using this line in ser.cfg modparam("nathelper", "rtpproxy_sock", "udp:192.168.5.1") I am really stucked please help !!!! thanking you regards, -- Atif

1 0

← Newer
1
...
47
48
49
50
51
52
53
...
63
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 March 2005