November 2005 - sr-users

[Serusers] Checking Authorization Username == From: Username
by Russell James Bate 04 Nov '05

04 Nov '05

I have a requirement to ensure that Authorization Username == From: Username before a call is allowed. I would appreciate any advice, guidance or reference to other resources that may enable me to do this. Kind regards, Russell Bate Livewire International -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.362 / Virus Database: 267.12.6/152 - Release Date: 31/10/2005 The information transmitted including any attachments is intended only for the exclusive use of the person(s) or entity to which it is addressed and may contain confidential and privileged material that may be subject to legal privilege. Any perusal, review, retransmission, dissemination, distribution, reproduction or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient without the sender's prior consent is unauthorised and strictly prohibited. If you have received this message in error, please notify the sender immediately and delete the message from your computer.

2 1

[Serusers] SER performance when enabling presence & IM
by Vanlandschoote Michel 04 Nov '05

04 Nov '05

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

1 0

[Serusers] SER & RTPProxy performance figures
by Vanlandschoote Michel 04 Nov '05

04 Nov '05

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

1 0

[Serusers] SER+ASTERISK
by harry gaillac 04 Nov '05

04 Nov '05

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

1 0

[Users] Mediaproxy Clarification
by Daryl Sanders 04 Nov '05

04 Nov '05

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

2 1

[Serusers] Ser and Asterisk
by Aster 04 Nov '05

04 Nov '05

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

3 4

[Serusers] Failure route and CANCEL
by H Quintana 04 Nov '05

04 Nov '05

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

1 0

[Serusers] sipc unavailable for commercial users
by Michael Kendall 03 Nov '05

03 Nov '05

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

1 0

[Serusers] SRC Port change
by Ritesh Jalan 03 Nov '05

03 Nov '05

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

2 1

[Serusers] Packets fragmentation and message reduction
by Federico Giannici 03 Nov '05

03 Nov '05

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 ___________________________________________________

5 7