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.
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
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
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
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
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
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
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
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
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
