Hi again,
yet another query about SER performance figures (somewhat related to my
previous post):
how many users can you put on your machine running SER stateful proxy
when enabling SIP presence & IM?
And which hardware (CPU & memory) are you using?
Many thanks,
Michel
*************************************************************
Dit e-mail bericht inclusief eventuele ingesloten bestanden kan informatie bevatten die vertrouwelijk is en/of beschermd door intellectuele eigendomsrechten. Dit bericht is uitsluitend bestemd voor de geadresseerde(n). Elk gebruik van de informatie vervat in dit bericht (waaronder de volledige of gedeeltelijke reproductie of verspreiding onder elke vorm) door andere personen dan de geadresseerde(n) is verboden. Indien u dit bericht per vergissing heeft ontvangen, gelieve de afzender hiervan te verwittigen en dit bericht te verwijderen.
This e-mail and any attachment thereto may contain information which is confidential and/or protected by intellectual property rights and are intended for the sole use of the addressees. Any use of the information contained herein (including but not limited to total or partial reproduction or distribution in any form) by other persons than the addressees is prohibited. If you have received this e-mail in error, please notify the sender and delete its contents.
*************************************************************
Hi all,
I'd like to know some real life performance figures for both SER and
RTPProxy (with both applications running on separate machines):
SER (as stateful SIP proxy & registrar):
- how many calls-per-second and how many concurrent sessions do you
handle per machine?
- and of course, which hardware are you using (CPU & memory)
RTPProxy:
- how many streams do you handle per machine?
- most important of all; which hardware (CPU & memory)
- would be interesting if you also know:
- which voice/video codecs are used?
- what's the overall throughput in Mbps?
Any feedback is highly appreciated.
Michel
*************************************************************
Dit e-mail bericht inclusief eventuele ingesloten bestanden kan informatie bevatten die vertrouwelijk is en/of beschermd door intellectuele eigendomsrechten. Dit bericht is uitsluitend bestemd voor de geadresseerde(n). Elk gebruik van de informatie vervat in dit bericht (waaronder de volledige of gedeeltelijke reproductie of verspreiding onder elke vorm) door andere personen dan de geadresseerde(n) is verboden. Indien u dit bericht per vergissing heeft ontvangen, gelieve de afzender hiervan te verwittigen en dit bericht te verwijderen.
This e-mail and any attachment thereto may contain information which is confidential and/or protected by intellectual property rights and are intended for the sole use of the addressees. Any use of the information contained herein (including but not limited to total or partial reproduction or distribution in any form) by other persons than the addressees is prohibited. If you have received this e-mail in error, please notify the sender and delete its contents.
*************************************************************
Hello,
I wish to setup this scheme:
ser-0.9.4
asterisk-1.2-bêta
polycom ip300 phones
asterisk 5050--
|firewall+nat|-----192.168.
ser 5060-------
My ip phones use ser as outbound sip proxy and
asterisk as sip registrar server.
Ser Forward REGISTER requests to asterisk however when
a phone try to send an invite message then asterisk
send icmp to private ip (host=dynamic in sip.conf)
Is it possible to solve this problem ?
Regards
Harry
___________________________________________________________________________
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger
Téléchargez cette version sur http://fr.messenger.yahoo.com
I would really appreciate any feedback or clarification on my
understanding of Mediaproxy.
It appears that Mediaproxy can be setup in such a way to allow load
balancing based on domain. This seems to be the only native mechanism
for getting any sort of pseudo geo-location out of it. My
understanding is as follows...
My users ATAs will query DNS which will direct them to a SIP proxy
based on my SRV records. The SIP proxy (SER) machines will be running
proxydispatcher.py and have the required mediaproxy module loaded. In
addition, the SER machines may also have mediaproxy.py running
locally, or mediaproxy.py may be on separate machines altogether.
When a request for routing comes into the SIP proxy it is determined
then if rtp proxying is necessary based on source IP. If rtp proxying
is required, proxydispatcher.py send a DNS query to locate a suitable
mediaproxy server. This is where SRV is used to decide (based on
domain) which mediaproxy server is to be used. Given this, a separate
domain would need to be setup for each geographic region that is be
served by one or more mediaproxy servers. Then these domains are
published to SRV to facilitate the lookups performed by each
proxydispatcher.py instance.
Please let me know if I'm understanding all of this correctly.
Thanks!
- Daryl
SerUser,
I am trying to use SER and Asterisk on the same host/system. When i
try to make ser talk to asterisk, it failed and didn't want to talk to
it. But if i put asterisk on different system then ser has no problem
talking to asterisk.
Here is flow of the traffic:
UA ----------- SER ----------------<if PSTN> ------------ Asterisk
------------- Gateway.
<if another user> ---------- UA
Could someone please give me an idea how to make ser talk to asterisk
on the same host.
TIA
Hi,
I'm doing some tests using the failure route feature.
I send a call to an offline gateway and after the
timeout, I'm sending the call to an online Gateway.
It works fine if the call is not canceled, but when I
did so before the offline route timeout, SER is not
stopping and is sending the call to the online route.
It seems that in this case the Reply status is NULL
because I'm getting:
"Entering failure_route. STATUS: <null>"
in the log.
Any ideas?
Thanks for your help,
Humberto
================================
failure_route[2] {
xlog("L_INFO", "Entering failure_route. STATUS:
%rs\n");
if (t_check_status("487")) {
xlog("L_INFO", "Call cancelled\n");
break;
}
if (t_check_status("408") ) {
xlog("L_INFO", "Time out. Gateway offline\n");
break;
}
rewritehost("a.b.c.d");
append_branch();
if (!t_relay()) {
sl_reply_error();
break;
}
break;
}
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
Mark,
You suggested that I try sipc as an alternative
to Windows Messenger. Sipc sounds like a great
program since it has add-ons for voip, video,
and whiteboard, as well as support for STUN.
Sipc is also free for educational and research
users. But I am not sure that my for-profit
tutoring service would qualify as an educational
organization.
So I contacted Sipquest.com about pricing for
a commercial license. They sent me to 3Com,
who is supposed to be using sipc in their
VCX product for "medium to very large businesses".
The 3Com saleguy said he had never sold sipc to
anyone, but he would pass my name to a company
called Parallel Technologies which is considering
creating a SIP server and might be planning to
use sipc as a client. In summary, it appears
that the commercial version of sipc is
not available right now.
I will try to get a free educational copy
of sipc, just to evaluate it.
thanks
Michael
Hi
Pls. help us in resolving the problem that the SIP proxy server changes the
Source and Destination port while replying for message. Pls. find the below
message for the Reference In below message A cisco ata device (which is
behind NAT with IP 192.168.10.52) is trying to register it self with SIP
proxy server IP 172.16.101.10 with SRC port 5060 and DST port 5060, but when
SIP proxy server replies back to the message the port number gets changed
i.e SRC port 53492 and DST port 5060. Is there any way by which we can fix
this port num.
No. Time Source Destination Protocol
Info
532 152.672945 172.16.101.251 172.16.101.10 SIP
Request: REGISTER sip:172.16.101.10
Frame 532 (469 bytes on wire, 469 bytes captured)
Arrival Time: Nov 3, 2005 11:32:02.280623000
Time delta from previous packet: 0.007492000 seconds
Time since reference or first frame: 152.672945000 seconds
Frame Number: 532
Packet Length: 469 bytes
Capture Length: 469 bytes
Protocols in frame: eth:ip:udp:sip
Ethernet II, Src: Cisco_b5:15:f0 (00:04:c1:b5:15:f0), Dst: Dell_17:ea:82
(00:14:22:17:ea:82)
Destination: Dell_17:ea:82 (00:14:22:17:ea:82)
Source: Cisco_b5:15:f0 (00:04:c1:b5:15:f0)
Type: IP (0x0800)
Internet Protocol, Src: 172.16.101.251 (172.16.101.251), Dst: 172.16.101.10
(172.16.101.10)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x68 (DSCP 0x1a: Assured Forwarding 31;
ECN: 0x00)
0110 10.. = Differentiated Services Codepoint: Assured Forwarding 31
(0x1a)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 455
Identification: 0x01f8 (504)
Flags: 0x00
0... = Reserved bit: Not set
.0.. = Don't fragment: Not set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 249
Protocol: UDP (0x11)
Header checksum: 0x1e63 [correct]
Source: 172.16.101.251 (172.16.101.251)
Destination: 172.16.101.10 (172.16.101.10)
User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 5060 (5060)
Source port: 5060 (5060)
Destination port: 5060 (5060)
Length: 435
Checksum: 0x6c94 [correct]
Session Initiation Protocol
Request-Line: REGISTER sip:172.16.101.10 SIP/2.0
Method: REGISTER
Resent Packet: True
Suspected resend of frame: 34
Message Header
Via: SIP/2.0/UDP 192.168.10.52:5060;branch=z9hG4bK9749dfca14c0ffb2
From: 23456 <sip:23456@172.16.101.10;user=phone>;tag=2971075767
SIP Display info: 23456
SIP from address: sip:23456@172.16.101.10
SIP tag: 2971075767
To: 23456 <sip:23456@172.16.101.10;user=phone>
SIP Display info: 23456
SIP to address: sip:23456@172.16.101.10
Call-ID: 3431569068(a)192.168.10.52
CSeq: 1 REGISTER
Contact: 23456
<sip:23456@192.168.10.52:5060;user=phone;transport=udp>;expires=300
Contact Binding: 23456
<sip:23456@192.168.10.52:5060;user=phone;transport=udp>;expires=300
URI: 23456
<sip:23456@192.168.10.52:5060;user=phone;transport=udp>
SIP Display info: 23456
SIP contact address: sip:23456@192.168.10.52:5060
User-Agent: Cisco ATA 186 v3.2.1 atasip (050616A)
Content-Length: 0
No. Time Source Destination Protocol
Info
533 152.674292 172.16.101.10 172.16.101.251 SIP
Status: 401 Unauthorized (0 bindings)
Frame 533 (432 bytes on wire, 432 bytes captured)
Arrival Time: Nov 3, 2005 11:32:02.281970000
Time delta from previous packet: 0.001347000 seconds
Time since reference or first frame: 152.674292000 seconds
Frame Number: 533
Packet Length: 432 bytes
Capture Length: 432 bytes
Protocols in frame: eth:ip:udp:sip
Ethernet II, Src: Dell_17:ea:82 (00:14:22:17:ea:82), Dst: Cisco_b5:15:f0
(00:04:c1:b5:15:f0)
Destination: Cisco_b5:15:f0 (00:04:c1:b5:15:f0)
Source: Dell_17:ea:82 (00:14:22:17:ea:82)
Type: IP (0x0800)
Internet Protocol, Src: 172.16.101.10 (172.16.101.10), Dst: 172.16.101.251
(172.16.101.251)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x60 (DSCP 0x18: Class Selector 3; ECN:
0x00)
0110 00.. = Differentiated Services Codepoint: Class Selector 3
(0x18)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 418
Identification: 0x0000 (0)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: UDP (0x11)
Header checksum: 0x9988 [correct]
Source: 172.16.101.10 (172.16.101.10)
Destination: 172.16.101.251 (172.16.101.251)
User Datagram Protocol, Src Port: 53492 (53492), Dst Port: 5060 (5060)
Source port: 53492 (53492)
Destination port: 5060 (5060)
Length: 398
Checksum: 0x0ad1 [correct]
Session Initiation Protocol
Status-Line: SIP/2.0 401 Unauthorized
Status-Code: 401
Resent Packet: True
Suspected resend of frame: 480
Message Header
Via: SIP/2.0/UDP
192.168.10.52:5060;received=172.16.101.251;branch=z9hG4bK9749dfca14c0ffb2
Call-ID: 3431569068(a)192.168.10.52
From: 23456 <sip:23456@172.16.101.10;user=phone>;tag=2971075767
SIP Display info: 23456
SIP from address: sip:23456@172.16.101.10
SIP tag: 2971075767
To: 23456 <sip:23456@172.16.101.10;user=phone>
SIP Display info: 23456
SIP to address: sip:23456@172.16.101.10
CSeq: 1 REGISTER
WWW-Authenticate: DIGEST realm="CISCO", nonce="4369a82d",
qop="auth", algorithm=MD5
Content-Length: 0
Ritesh Jalan
Senior Engineer - Business Solution
Net4India Ltd.
D-25 Secto3
Noida - 201301
India
INDIA
Tel: 91-120-5323500
Fax: 91-120-5323520
URL: http://www.net4.in
_____
This message may contain confidential and/or privileged information. If you
are not the addressee or authorized to receive this for the addressee, you
must not use, copy, disclose or take any action based on this message or any
information herein. If you have received this message in error, please
advise the sender immediately by reply e-mail and delete this message. Thank
you for your cooperation.
_____
I found a situation where some SIP phones worked and some don't.
After a while I found that, because of the added bytes of the
"Proxy-Authorization:" header, the messages generated by some sip phones
were larger than 1480 bytes and this caused the connection with the PSTN
gateway to not work.
I tried to forwad the message with the t_relay_to_tcp() function, but by
the ngrep output it seems that it still uses UDP (but I may be wrong).
Anyway, what can be done in this situations?
What about a SER module that rewrite all header field names with their
compact form? Often, the message is only a few bytes more than 1480, so
this could be a solution...
What do you think?
Bye.
--
___________________________________________________
__
|- giannici(a)neomedia.it
|ederico Giannici http://www.neomedia.it
___________________________________________________
I finally got Serweb to work. Thanks to all who contributed to that! Now I
am running into a very stupid problem.
I can't log in!
What is the username and password?
Or do i have to create it or edit certain files?
Please let me know.
Thanks
Goran
