No offence made. If you want to start contributing code, first thing
you need to accomplish is how to create custom RPMS. Here is a good
place to start
http://wiki.sipfoundry.org/display/sipXecs/Building+RPMS+on+CentOS+or+Fedora.
If you are lost, ask the dev list.
On 11/15/2011 05:52 AM, A
I'll be there... maybe even with bells on :-)
On Nov 14, 2011 5:19 PM, "Ari Sonesh" wrote:
>
> Content-Type: text/plain;
> charset="utf-8"
> Content-Transfer-Encoding: 8bit
> Organization: SipXecs Forum
> In-Reply-To: <4ec05eb2.1080...@ezuce.com>
> X-FUDforum: 08063afcdd00a6e76393c5b9527381e8 <
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: 8bit
Organization: SipXecs Forum
In-Reply-To: <4ec05eb2.1080...@ezuce.com>
X-FUDforum: 08063afcdd00a6e76393c5b9527381e8 <64498>
Message-ID:
Jeogen, I am new to the SipXecs and the forum, and didn't
mean to offend anybody...
Here is what I suggest you do. Instead of quoting RFC's (which IMHO)
this community has enough understanding of, that you create a patch to
make this satisfy your need. Submit it for approval via a jira and
lobby for it to be accepted in trunk via the dev list. Retranmission of
request is de
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: 8bit
Organization: SipXecs Forum
In-Reply-To: <4ebdc89e.4030...@ezuce.com>
X-FUDforum: 08063afcdd00a6e76393c5b9527381e8 <64493>
Message-ID:
Joergen, again thank you for suggesting the Karoo solution.
I understand the issue
There is really no RFC violation here. The value written in the RFC is
a mere recommendation. Whether to lower or make that higher is a matter
of design. As Dale pointed out, the default RFC timeout of 64 * T1 (32
seconds!) is not realistic. Most people would abandon that call prior
to sip
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: 8bit
Organization: SipXecs Forum
In-Reply-To:
X-FUDforum: 08063afcdd00a6e76393c5b9527381e8 <64454>
Message-ID:
We have two issues here:
1. Invite is being sent only 4 times, while according to the
RFC we need to send 7 fo
SipUserAgent.h:30
#define SIP_DEFAULT_RTT 100 // Default T1 value (RFC 3261), in msec.
// Intended to be estimate of RTT of
network.
On 11/11/2011 04:35 PM, pscheep...@epo.org wrote:
The answer is in the 2 issues and Dale's answer:
I don't recall where t
The answer is in the 2 issues and Dale's answer:
I don't recall where the timeout is set, but it is a variable
parameter in the SIP stack and can be adjusted straightforwardly.
XX-6065:sipX seems to be configured with T1 timer set to 100msec
instead of the recommended default of 500msec.
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: 8bit
Organization: SipXecs Forum
In-Reply-To:
X-FUDforum: 08063afcdd00a6e76393c5b9527381e8 <64445>
Message-ID:
There are 2 open related incidents on this issue:
http://track.sipfoundry.org/browse/XX-7037
http://track.s
If SipX would follow the RFC then it would send out 7 INVITE's totalling
to
0+0.5+1+2+4+8+16=31.5 seconds of INVITE's.
I don't think the client will wait that long, but the current SipX could
be improved.
If the client would terminate the call before the 31.5 seconds expire then
I assume the
By
> From: Ari Sonesh [ason...@gmail.com]
>
> I believe that the issue is inherent to mobile data networks
> that are buffering initial (after standby) data traffic
> until it can allocate a channel to transmit the data to a
> receiver. Once channel is allocated the traffic is flowing
> well.
The
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: 8bit
Organization: SipXecs Forum
In-Reply-To:
X-FUDforum: 08063afcdd00a6e76393c5b9527381e8 <64388>
Message-ID:
Tony, consider a scenario where most phones are connected to
wireless modems, and servers are on a public IP.
t.sipfoundry.org wrote on 08-11-2011 12:41:21:
> From:
>
> Tony Graziano
>
> To:
>
> Discussion list for users of sipXecs software
>
> Date:
>
> 08-11-2011 13:24
>
> Subject:
>
> Re: [sipx-users] Please HelpTimeout of INVITE too short.
>
On Mon, Nov 7, 2011 at 7:28 PM, Ari Sonesh wrote:
>
> Content-Type: text/plain;
> charset="utf-8"
> Content-Transfer-Encoding: 8bit
> Organization: SipXecs Forum
> In-Reply-To:
> X-FUDforum: 08063afcdd00a6e76393c5b9527381e8 <64373>
> Message-ID:
>
>
>
> I believe that the issue is inherent to m
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: 8bit
Organization: SipXecs Forum
In-Reply-To:
X-FUDforum: 08063afcdd00a6e76393c5b9527381e8 <64373>
Message-ID:
I believe that the issue is inherent to mobile data networks
that are buffering initial (after standby) data t
16 matches
Mail list logo
