sr-users June 2004

sr-users@lists.kamailio.org

176 participants
387 discussions

[Serusers] Asterisk/Digium as PSTN gateway and SER as backend
by Aimable 17 Jun '04

17 Jun '04

Does anybody knows how I can configure Asterisk to work properly My* box is sending wrong messages and instead of sending the release message for invalid # it sends an ALERTING message saying that the call is going on. Thanks

1 0

[Serusers] billing with ser
by varala ramakanth 17 Jun '04

17 Jun '04

hello , thanks for your responses , iam desperatley searching for the free billing software for the reliable cvs ser-0.8.12 and freeradius-0.9.3 . i tried trabas but it s supporting only h323 attributies not sip. and if i go for ispbs i doubt it does not support radius and rtpproxy. i am expecting some leads from you. so kindly suggest me good free voip billing system for ser. with regards rama kanth __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail

1 0

[Serusers] DB Error(table admin_privileges not exist) when using serweb
by wangji 17 Jun '04

17 Jun '04

1 0

[Serusers] canceling echo
by Peter Boot 17 Jun '04

17 Jun '04

Are there any config settings for controlling echo in SER ? I have a Grandstream HT-486 connecting to SER then to Asterisk. There is a bad echo when calling from the SIP side, asterisk has several methods of canceling echo, but in this case have no effect. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.707 / Virus Database: 463 - Release Date: 6/15/2004

2 1

[Serusers] Development of IP telephony based on SER
by Rafeh Hulays 17 Jun '04

17 Jun '04

We are looking for some help in setting up a voice over IP system similar to Vonage. If you are experienced with SER and interested, contact me directly at: 778-893-9348 rhulays(a)netfone.ca Best of luck.

1 0

Re: [Serusers] t_relay through c code
by GR S 17 Jun '04

17 Jun '04

Anil, Still i dont think you need to t_relay calls through your code as there are a number of options available with SER which you can use to (re)direct the calls to the desired gateways. See the sections for handling URIs, and setting hosts in the SER Admin's Guide: http://www.iptel.org/ser/doc/seruser/seruser.html Best Regards, --- Anil Bhati <abhati_voip(a)hotmail.com> wrote: > > Hi All > > actually i m facing t_relay if i wants to relay a call in more than 3 pstn > gw that time i have to check which prefix is coming and where is call going <SNIP> > Abhati > ===== Girish Gopinath <gr_sh2003(a)yahoo.com> __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

[Serusers] pa module does not always send OK before NOTIFY
by JAY ALLISON 17 Jun '04

17 Jun '04

I have searched the archive for an answer to this question, and I did not find it. If I missed, I apologize. Please point me in the right direction. I am having a problem with the pa module of ser (0.8.12). Using ethereal, I see that in response to a SUBSCRIBE, ser will sometimes send an OK and then a NOTIFY. However, other times ser sends the NOTIFY and then the OK. For a single UA sending multiple SUBSCRIBE's to ser, about half of the OK's are sent first and about half of the NOTIFY's are sent first. This is a problem because I am running the UA behind a SIP-aware firewall which expects the OK first. If the OK is not received, the NOTIFY will not be allowed back through the firewall. Looking at RFC 3265, 3.1.4.1: "This SUBSCRIBE request will be confirmed with a final response. 200-class responses indicate that the subscription has been accepted, and that a NOTIFY will be sent immediately." Looking at RFC 3265, 3.1.6.2: "Upon successfully accepting or refreshing a subscription, notifiers MUST send a NOTIFY message immediately to communicate the current resource state to the subscriber. This NOTIFY message is sent on the same dialog as created by the SUBSCRIBE response. <snip> Note that a NOTIFY message is always sent immediately after any 200-class response to a SUBSCRIBE request, regardless of whether the subscription has already been authorized." My interpretation is that the RFC requires the OK to be sent first. Is that a valid interpretation? Is there an easy fix for this (perhaps in ser.cfg) or will this require a code change? Thanks, Jay

3 2

[Serusers] Fwd: 15 is a not a recognized RADIUS Packet
by Adrian Georgescu 16 Jun '04

16 Jun '04

As far as we dig into it, none of the following: freeradius radiusclient radius-cistron radius-livingston > Implement 15 Failed Following RFCs should not lead us falling over the cliff. Maybe 15 should be traded with something else understood by the radius servers found in the real-world? Adrian Begin forwarded message: > From: Juha Heinanen <jh(a)tutpro.com> > Date: June 16, 2004 8:26:49 PM CEST > To: Adrian Georgescu <ag(a)ag-projects.com> > Cc: iancu(a)fokus.fraunhofer.de, serusers(a)lists.iptel.org > Subject: 15 is a not a recognized RADIUS Packet > > Adrian Georgescu writes: > >> Do you know by any chance what does it mean? > > here are all official radius acct-status-types: > > Values for RADIUS Attribute 40, Acct-Status-Type [RFC 2866]: > > 1 Start [RFC 2866] > 2 Stop [RFC 2866] > 3 Interim-Update [RFC 2866] > 4-6 (unassigned) > 7 Accounting-On [RFC 2866] > 8 Accounting-Off [RFC 2866] > 9 Tunnel-Start [RFC 2867] > 10 Tunnel-Stop [RFC 2867] > 11 Tunnel-Reject [RFC 2867] > 12 Tunnel-Link-Start [RFC 2867] > 13 Tunnel-Link-Stop [RFC 2867] > 14 Tunnel-Link-Reject [RFC 2867] > 15 Failed [RFC 2866] > > you can find definition of 15 from the above mentioned rfc, but if a > fails before starting, then 15 is the right way to report it. > > -- juha

2 1

[Serusers] voicemail access by phone
by mohammad mirzaee 16 Jun '04

16 Jun '04

HI ALL; vonage system offers voicemail service in 2 forms: 1- email with a .wav file attachment 2-the user can access his voicemail box by phone. As I know the first one is exutable by ser+sems. My question is, with ser+sems can we dial a number and then recive our voicemail via phone. thank you in advance mohammad

1 0

[Serusers] Incorrect RTP Audio Path?! (no NAT involved!)
by Jamie Yukes 16 Jun '04

16 Jun '04

INVITE, 100, 183 look good but then the ringing RTP audio is sent to SER/proxy server instead of our media server! The SDP looks accurate... any ideas? Jamie Yukes ---------------------------------------------------------------------- ngrep call trace 64.158.AAA.AAA is our media server 64.158.BBB.BBB is our proxy server ( SER ) 209.247.CCC.CCC is far end proxy server 209.247.DDD.DDD is far end media server ----------------------------------------------------------------------- interface: any filter: ip and ( port 5060 or port 5070 or port 30000 or port 30036 ) # U 64.158.AAA.AAA:5060 -> 64.158.BBB.BBB:5060 INVITE sip:609XXXXXXX@64.158.BBB.BBB:5060 SIP/2.0. Via: SIP/2.0/UDP 64.158.AAA.AAA:5060. From: "609YYYYYYY" <sip:609YYYYYYY@64.158.AAA.AAA:5060;user=phone>;tag=L9-a4857c4577b880bf. To: <sip:609XXXXXXX@64.158.BBB.BBB:5060;user=phone>. Call-ID: L9-C8-424dd29dd3cf142d(a)64.158.AAA.AAA. CSeq: 1 INVITE. Contact: "609YYYYYYY" <sip:609YYYYYYY@64.158.AAA.AAA:5060;user=phone>. Max-Forwards: 10. User-Agent: ZZZ Gateway. Content-Type: application/sdp. Content-Length: 189. . v=0. o=609YYYYYYY 0 0 IN IP4 64.158.AAA.AAA. s=SIP Call. c=IN IP4 64.158.AAA.AAA. t=0 0. m=audio 30036 RTP/AVP 0 121. a=rtpmap:0 PCMU/8000. a=rtpmap:121 frf-dialed-digit/8000. a=fmtp:121 0-15. # U 64.158.BBB.BBB:5060 -> 64.158.AAA.AAA:5060 SIP/2.0 100 trying -- your call is important to us. Via: SIP/2.0/UDP 64.158.AAA.AAA:5060. From: "609YYYYYYY" <sip:609YYYYYYY@64.158.AAA.AAA:5060;user=phone>;tag=L9-a4857c4577b880bf. To: <sip:609XXXXXXX@64.158.BBB.BBB:5060;user=phone>. Call-ID: L9-C8-424dd29dd3cf142d(a)64.158.AAA.AAA. CSeq: 1 INVITE. Server: Sip EXpress router (0.8.12 (i386/linux)). Content-Length: 0. Warning: 392 64.158.BBB.BBB:5060 "Noisy feedback tells: pid=21192 req_src_ip=64.158.AAA.AAA req_src_port=5060 in_uri=sip:609XXXXXXX@64.158.BBB.BBB:5060 out_uri=sip:+1609XXXXXXX@209.247.CCC.CCC:5060 via_cnt==1". . # U 64.158.BBB.BBB:5060 -> 209.247.CCC.CCC:5060 INVITE sip:+1609XXXXXXX@209.247.CCC.CCC:5060 SIP/2.0. Record-Route: <sip:609XXXXXXX@64.158.BBB.BBB;ftag=L9-a4857c4577b880bf;lr>. Via: SIP/2.0/UDP 64.158.BBB.BBB;branch=z9hG4bKfbcc.e26d4cc7.0. Via: SIP/2.0/UDP 64.158.AAA.AAA:5060. From: <sip:+1609YYYYYYY@64.158.AAA.AAA:5060;user=phone>;tag=L9-a4857c4577b880bf. To: <sip:+1609XXXXXXX@64.158.AAA.AAA:5060;user=phone>. Call-ID: L9-C8-424dd29dd3cf142d(a)64.158.AAA.AAA. CSeq: 1 INVITE. Contact: <sip:+1609YYYYYYY@64.158.AAA.AAA:5060;user=phone>. Max-Forwards: 9 . User-Agent: ZZZ Gateway. Content-Type: application/sdp. Content-Length: 189. P-to: updated to e164. P-from: updated to e164. P-contact: updated to e164. . v=0. o=609YYYYYYY 0 0 IN IP4 64.158.AAA.AAA. s=SIP Call. c=IN IP4 64.158.AAA.AAA. t=0 0. m=audio 30036 RTP/AVP 0 121. a=rtpmap:0 PCMU/8000. a=rtpmap:121 frf-dialed-digit/8000. a=fmtp:121 0-15. # U 209.247.CCC.CCC:44660 -> 64.158.BBB.BBB:5060 SIP/2.0 100 Trying. Via: SIP/2.0/UDP 64.158.BBB.BBB:5060;branch=z9hG4bKfbcc.e26d4cc7.0,SIP/2.0/UDP 64.158.AAA.AAA:5060. From: <sip:+1609YYYYYYY@64.158.AAA.AAA:5060;user=phone>;tag=L9-a4857c4577b880bf. To: <sip:+1609XXXXXXX@64.158.AAA.AAA:5060;user=phone>. Call-ID: L9-C8-424dd29dd3cf142d(a)64.158.AAA.AAA. CSeq: 1 INVITE. Content-Length: 0. . # U 209.247.CCC.CCC:44660 -> 64.158.BBB.BBB:5060 SIP/2.0 183 Session Progress. Via: SIP/2.0/UDP 64.158.BBB.BBB:5060;branch=z9hG4bKfbcc.e26d4cc7.0,SIP/2.0/UDP 64.158.AAA.AAA:5060. Record-Route: <sip:609XXXXXXX@64.158.BBB.BBB;ftag=L9-a4857c4577b880bf;lr>. From: <sip:+1609YYYYYYY@64.158.AAA.AAA:5060;user=phone>;tag=L9-a4857c4577b880bf. To: <sip:+1609XXXXXXX@64.158.AAA.AAA:5060;user=phone>;tag=VPST50603522629633. Call-ID: L9-C8-424dd29dd3cf142d(a)64.158.AAA.AAA. CSeq: 1 INVITE. Contact: <sip:209.247.CCC.CCC:5060;transport=udp>. Content-Type: application/sdp. Content-Length: 124. . v=0. o=- 1087411692 1087411693 IN IP4 209.247.DDD.DDD. s=-. c=IN IP4 209.247.DDD.DDD. t=0 0. m=audio 60590 RTP/AVP 0. a=ptime:20. # U 64.158.BBB.BBB:5060 -> 64.158.AAA.AAA:5060 SIP/2.0 183 Session Progress. Via: SIP/2.0/UDP 64.158.AAA.AAA:5060. Record-Route: <sip:609XXXXXXX@64.158.BBB.BBB;ftag=L9-a4857c4577b880bf;lr>. From: <sip:+1609YYYYYYY@64.158.AAA.AAA:5060;user=phone>;tag=L9-a4857c4577b880bf. To: <sip:+1609XXXXXXX@64.158.AAA.AAA:5060;user=phone>;tag=VPST50603522629633. Call-ID: L9-C8-424dd29dd3cf142d(a)64.158.AAA.AAA. CSeq: 1 INVITE. Contact: <sip:209.247.CCC.CCC:5060;transport=udp>. Content-Type: application/sdp. Content-Length: 124. . v=0. o=- 1087411692 1087411693 IN IP4 209.247.DDD.DDD. s=-. c=IN IP4 209.247.DDD.DDD. t=0 0. m=audio 60590 RTP/AVP 0. a=ptime:20. # U 209.247.DDD.DDD:60590 -> 64.158.BBB.BBB:30036 ....>*.. ..a....._B83238BZ.........O@<9;<FV.........cQJHGKQ\w........}rpu~....xi^YTTW]q.........WJB?>AHZ.........VB:658;Is........bB8///3=T.........F7/+,.6F.........Q:/,+,0 # U 209.247.DDD.DDD:60590 -> 64.158.BBB.BBB:30036 ....>*.o ..a=^........o@3-+,09L.........K:0-..7Dy........_B93038B\.........O@<9;=FV.........cPJHGKP\u........|qqu~....xi]XTTV]p.........VKB?>AHY.........VB:657;Is........aC # U 209.247.DDD.DDD:60590 -> 64.158.BBB.BBB:30036 ....>*.. ..a.i..8///3=T.........F7/,,.6F.........R:/,+,0=^........s?3-*-08J.........L:1-./7Cw........_C92038BZ.........OA<9;=GU.........cRJHGKP]t........|qpv.....xi]XTRW\p..... #

1 1

← Newer
1
...
14
15
16
17
18
19
20
...
39
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 June 2004