From 2122920 at irwebhost5.indyarocks.com Thu Oct 16 23:05:48 2008 From: 2122920 at irwebhost5.indyarocks.com (Sunkara RaviPrakash) Date: Fri, 17 Oct 2008 11:35:48 +0530 (IST) Subject: [RTPproxy Users] Send me an SMS Message-ID: a155b54dcea16606b34c25931a8fc0ba An HTML attachment was scrubbed... URL: http://lists.rtpproxy.org/pipermail/users/attachments/20081017/deb0a09c/attachment.html From fborot at hotmail.com Mon Oct 20 12:08:07 2008 From: fborot at hotmail.com (Fabian Borot) Date: Mon, 20 Oct 2008 15:08:07 -0400 Subject: [RTPproxy Users] kamailio and rtpproxy Message-ID: hello I found this tutorial to configure openser and rtpproxy [attached] , I am using kamailio but when I try to start kamailio I see this error: Oct 20 15:26:01 sp1094a kamailio: ERROR:core:set_mod_param_regex: parameter not found in module Oct 20 15:26:01 sp1094a kamailio: CRITICAL:core:yyerror: parse error in config file, line 198, column 19-20: Can't set module parameter Oct 20 15:26:01 sp1094a kamailio: ERROR:core:set_mod_param_regex: parameter not found in module Oct 20 15:26:01 sp1094a kamailio: CRITICAL:core:yyerror: parse error in config file, line 199, column 19-20: Can't set module parameter Oct 20 15:26:01 sp1094a kamailio: ERROR:core:main: bad config file (2 errors) is there an updated guide? txs a lot fabian _________________________________________________________________ Stay organized with simple drag and drop from Windows Live Hotmail. http://windowslive.com/Explore/hotmail?ocid=TXT_TAGLM_WL_hotmail_102008 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rtpproxy.org/pipermail/users/attachments/20081020/7689557a/attachment.html From sobomax at sippysoft.com Mon Oct 20 12:21:39 2008 From: sobomax at sippysoft.com (Maxim Sobolev) Date: Mon, 20 Oct 2008 12:21:39 -0700 Subject: [RTPproxy Users] kamailio and rtpproxy In-Reply-To: References: Message-ID: <48FCDA43.9000808@sippysoft.com> Fabian Borot wrote: > hello I found this tutorial to configure openser and rtpproxy [attached] > , I am using kamailio but when I try to start kamailio I see this error: > > > Oct 20 15:26:01 sp1094a kamailio: ERROR:core:set_mod_param_regex: > parameter not found in module > Oct 20 15:26:01 sp1094a kamailio: CRITICAL:core:yyerror: parse error in > config file, line 198, column 19-20: Can't set module parameter > Oct 20 15:26:01 sp1094a kamailio: ERROR:core:set_mod_param_regex: > parameter not found in module > Oct 20 15:26:01 sp1094a kamailio: CRITICAL:core:yyerror: parse error in > config file, line 199, column 19-20: Can't set module parameter > Oct 20 15:26:01 sp1094a kamailio: ERROR:core:main: bad config file (2 > errors) > > is there an updated guide? Fabian, This flag/example only valid for openser/kamailio 1.1.x. As far as I know in more recent versions the equivalent of nat_flag in registrar is nat_bflag flag in module usrloc, and for sip_natping_flag is sipping_bflag in nathelper. However, you are better to ask for a help at the kamailio or OpenSIPS mailing list. Regards, -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts T/F: +1-646-651-1110 Web: http://www.sippysoft.com From fborot at hotmail.com Mon Oct 20 12:23:59 2008 From: fborot at hotmail.com (Fabian Borot) Date: Mon, 20 Oct 2008 15:23:59 -0400 Subject: [RTPproxy Users] kamailio and rtpproxy In-Reply-To: <48FCDA43.9000808@sippysoft.com> References: <48FCDA43.9000808@sippysoft.com> Message-ID: thank you very much, I will do it.

> Date: Mon, 20 Oct 2008 12:21:39 -0700 > From: sobomax at sippysoft.com > To: users at rtpproxy.org > Subject: Re: [RTPproxy Users] kamailio and rtpproxy > > Fabian Borot wrote: > > hello I found this tutorial to configure openser and rtpproxy [attached] > > , I am using kamailio but when I try to start kamailio I see this error: > > > > > > Oct 20 15:26:01 sp1094a kamailio: ERROR:core:set_mod_param_regex: > > parameter not found in module > > Oct 20 15:26:01 sp1094a kamailio: CRITICAL:core:yyerror: parse error in > > config file, line 198, column 19-20: Can't set module parameter > > Oct 20 15:26:01 sp1094a kamailio: ERROR:core:set_mod_param_regex: > > parameter not found in module > > Oct 20 15:26:01 sp1094a kamailio: CRITICAL:core:yyerror: parse error in > > config file, line 199, column 19-20: Can't set module parameter > > Oct 20 15:26:01 sp1094a kamailio: ERROR:core:main: bad config file (2 > > errors) > > > > is there an updated guide? > > Fabian, > > This flag/example only valid for openser/kamailio 1.1.x. As far as I > know in more recent versions the equivalent of nat_flag in registrar is > nat_bflag flag in module usrloc, and for sip_natping_flag is > sipping_bflag in nathelper. > > However, you are better to ask for a help at the kamailio or OpenSIPS > mailing list. > > Regards, > -- > Maksym Sobolyev > Sippy Software, Inc. > Internet Telephony (VoIP) Experts > T/F: +1-646-651-1110 > Web: http://www.sippysoft.com > _______________________________________________ > Users mailing list > Users at rtpproxy.org > http://lists.rtpproxy.org/mailman/listinfo/users _________________________________________________________________ Stay organized with simple drag and drop from Windows Live Hotmail. http://windowslive.com/Explore/hotmail?ocid=TXT_TAGLM_WL_hotmail_102008 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rtpproxy.org/pipermail/users/attachments/20081020/9065c115/attachment.html From R.Voermans at global-e.nl Thu Oct 23 12:27:56 2008 From: R.Voermans at global-e.nl (Ronald Voermans) Date: Thu, 23 Oct 2008 21:27:56 +0200 Subject: [RTPproxy Users] Re-Invites Message-ID: <1EBF014F0B26AF42B43FBC1BB5974F76AE9E7156@gi-glogil-ex1.gilze.global-e.nl> Dear list, Our company is using RTP Proxy in combination with OpenSer 1.3. We are using RTPProxy in bridge mode. I have the following issue: A faxcall comes in via OpenSer, and is correctly proxied to the client. RTPProxy also works correctly. Next, the PSTN Gateway sends a Re-INVITE to check if the client supports T.38 (with SDP). The client responds with '488 Not Acceptable here', so the PSTN Gateway sends another (RE)-INVITE with alaw as the preferred codec. However, with this second re-invite a *new* RTPProxy-session is made. Is this because there was a 488 reply instead of a 200 OK (with SDP) reply? For some reason (which I don't know at the moment) the client responds with an OK which is then forwarded to the PSTN Gateway, which is then again ACKed. However, the PSTN Gateway keeps sending its RTP to the initial port, instead of the port for the *new* RTPProxy-session. Ultimately this ends up in disconnecting the call. Does anybody know what could be the cause of this, and (more important) how to solve this? Thanks, Regards, Ronald Voermans From sobomax at sippysoft.com Thu Oct 23 15:47:54 2008 From: sobomax at sippysoft.com (Maxim Sobolev) Date: Thu, 23 Oct 2008 15:47:54 -0700 Subject: [RTPproxy Users] Re-Invites In-Reply-To: <1EBF014F0B26AF42B43FBC1BB5974F76AE9E7156@gi-glogil-ex1.gilze.global-e.nl> References: <1EBF014F0B26AF42B43FBC1BB5974F76AE9E7156@gi-glogil-ex1.gilze.global-e.nl> Message-ID: <4900FF1A.8040203@sippysoft.com> Ronald Voermans wrote: > Dear list, > > Our company is using RTP Proxy in combination with OpenSer 1.3. We are using RTPProxy in bridge mode. I have the following issue: > > A faxcall comes in via OpenSer, and is correctly proxied to the client. RTPProxy also works correctly. Next, the PSTN Gateway sends a Re-INVITE to check if the client supports T.38 (with SDP). The client responds with '488 Not Acceptable here', so the PSTN Gateway sends another (RE)-INVITE with alaw as the preferred codec. However, with this second re-invite a *new* RTPProxy-session is made. Is this because there was a 488 reply instead of a 200 OK (with SDP) reply? > > For some reason (which I don't know at the moment) the client responds with an OK which is then forwarded to the PSTN Gateway, which is then again ACKed. However, the PSTN Gateway keeps sending its RTP to the initial port, instead of the port for the *new* RTPProxy-session. > > Ultimately this ends up in disconnecting the call. > > Does anybody know what could be the cause of this, and (more important) how to solve this? Ronald, It would help a lot to debug an issue if you can include SIP packet capture into your problem report. Thanks! Regards, -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts T/F: +1-646-651-1110 Web: http://www.sippysoft.com From osas at voipembedded.com Thu Oct 23 16:07:45 2008 From: osas at voipembedded.com (Ovidiu Sas) Date: Thu, 23 Oct 2008 19:07:45 -0400 Subject: [RTPproxy Users] Re-Invites In-Reply-To: <4900FF1A.8040203@sippysoft.com> References: <1EBF014F0B26AF42B43FBC1BB5974F76AE9E7156@gi-glogil-ex1.gilze.global-e.nl> <4900FF1A.8040203@sippysoft.com> Message-ID: <6f497e130810231607j6883e7ecw21ec7ece1391a0db@mail.gmail.com> Normally, rtpproxy will reuse the ports and then it is normal to see the packets coming from the PSTN GW to the same port. As Maxim mentioned, it would be helpful to perform a tcpdump on all interfaces for both SIP and rtp/udptl traffic and post it somewhere. Regards, Ovidiu Sas On Thu, Oct 23, 2008 at 6:47 PM, Maxim Sobolev wrote: > Ronald Voermans wrote: >> Dear list, >> >> Our company is using RTP Proxy in combination with OpenSer 1.3. We are using RTPProxy in bridge mode. I have the following issue: >> >> A faxcall comes in via OpenSer, and is correctly proxied to the client. RTPProxy also works correctly. Next, the PSTN Gateway sends a Re-INVITE to check if the client supports T.38 (with SDP). The client responds with '488 Not Acceptable here', so the PSTN Gateway sends another (RE)-INVITE with alaw as the preferred codec. However, with this second re-invite a *new* RTPProxy-session is made. Is this because there was a 488 reply instead of a 200 OK (with SDP) reply? >> >> For some reason (which I don't know at the moment) the client responds with an OK which is then forwarded to the PSTN Gateway, which is then again ACKed. However, the PSTN Gateway keeps sending its RTP to the initial port, instead of the port for the *new* RTPProxy-session. >> >> Ultimately this ends up in disconnecting the call. >> >> Does anybody know what could be the cause of this, and (more important) how to solve this? > > Ronald, > > It would help a lot to debug an issue if you can include SIP packet > capture into your problem report. > > Thanks! > > Regards, > -- > Maksym Sobolyev > Sippy Software, Inc. > Internet Telephony (VoIP) Experts > T/F: +1-646-651-1110 > Web: http://www.sippysoft.com > _______________________________________________ > Users mailing list > Users at rtpproxy.org > http://lists.rtpproxy.org/mailman/listinfo/users >