Hi,
We are trying out sipXecs for internal usage. An important factor for
us is NAT traversal. We have some experience with Microsoft OCS and it
uses ICE for NAT traversal. It seems a good way to handle this.
I checked sipXecs docs and it is not very clear about how to configure
STUN/TURN for ICE
Hi
Can SipX (easily) be setup in the following scenario using three physical
servers:
Host 1. SipXconfig
Host 2. Primary SIP Router
Host 3. Secondary SIP Router
If this is possible, which ports would need to be open to allow the sipXconfig
to communicate
to the two SIP Router instances (Proxy/R
From: sipx-users-boun...@list.sipfoundry.org
[sipx-users-boun...@list.sipfoundry.org] On Behalf Of Martin Steinmann
[mstei...@gmail.com]
We have the same problem in Europe and actually there now is a fix for this
particular issue in the builds provided by
You guys are too funny - sounds like a hacked spam filter would do the trick
nicely...
This message and any files transmitted with it are intended only for the
individual(s) or entity named. If you are not the intended individual(s) or
entity named you are hereby notified that any disclosure, c
+1
-Original Message-
From: sipx-users-boun...@list.sipfoundry.org
[mailto:sipx-users-boun...@list.sipfoundry.org] On Behalf Of M. Ranganathan
Sent: Wednesday, June 16, 2010 9:40 AM
To: JOLY, ROBERT (ROBERT)
Cc: sipx-users@list.sipfoundry.org
Subject: Re: [sipx-users] Tightening up sipxbri
On Wed, Jun 16, 2010 at 12:29 PM, JOLY, ROBERT (ROBERT) wrote:
>> On Wed, Jun 16, 2010 at 11:07 AM, Martin Steinmann
>> wrote:
>> >>
>> >>Well, you can clamp down the codec to a single supported
>> codec such as
>> >>G711 ( i.e. filter the request and response SDP to that single
>> >>supported co
> On Wed, Jun 16, 2010 at 11:07 AM, Martin Steinmann
> wrote:
> >>
> >>Well, you can clamp down the codec to a single supported
> codec such as
> >>G711 ( i.e. filter the request and response SDP to that single
> >>supported codec and never re-invite subsequently ).
> Asterisk has that
> >>op
On Wed, Jun 16, 2010 at 11:50 AM, Martin Steinmann wrote:
>>
>>>
>>This has always been a gray area. I've posted the phrase on the lists
>>many times... "Not all ITSP's are equal." as well as "Not all SIP
>>TRUNKS are equal."
>>
>>I think at some point a line should be drawn to determine what an I
>
>
> I hope the following compromise will suffice:
>
>Because these hacks have been in the field for some time and are
>localized and because people may be depending on such ITSPs to work
>90% of the time by now. I will leave the hacks in there but they will
>be guarded by a hidden boolean flag in
>
>>
>This has always been a gray area. I've posted the phrase on the lists
>many times... "Not all ITSP's are equal." as well as "Not all SIP
>TRUNKS are equal."
>
>I think at some point a line should be drawn to determine what an ITSP
>should be able to support (in definitions) in order to mainta
On Wed, Jun 16, 2010 at 11:20 AM, M. Ranganathan wrote:
> On Wed, Jun 16, 2010 at 11:07 AM, Martin Steinmann wrote:
>>>
>>>Well, you can clamp down the codec to a single supported codec such as
>>>G711 ( i.e. filter the request and response SDP to that single
>>>supported codec and never re-invit
On Wed, Jun 16, 2010 at 11:07 AM, Martin Steinmann wrote:
>>
>>Well, you can clamp down the codec to a single supported codec such as
>>G711 ( i.e. filter the request and response SDP to that single
>>supported codec and never re-invite subsequently ). Asterisk has that
>>option ( i.e. can re-inv
On 06/16/2010 11:02 AM, Martin Steinmann wrote:
>>
>>
>> On 6/16/2010 9:55 AM, Joe Micciche wrote:
>>> I am still unable to create an account on the sipX JIRA Issue Tracker.
>>> Whenever I submit the form, it bombs out:
>>>
>>> http://track.sipfoundry.org/secure/Signup.jspa
>>>
>>> Cause:
>>> org.c
>
>Well, you can clamp down the codec to a single supported codec such as
>G711 ( i.e. filter the request and response SDP to that single
>supported codec and never re-invite subsequently ). Asterisk has that
>option ( i.e. can re-invite ). We can support that but at the moment
>the implementatio
>
>
>On 6/16/2010 9:55 AM, Joe Micciche wrote:
>> I am still unable to create an account on the sipX JIRA Issue Tracker.
>> Whenever I submit the form, it bombs out:
>>
>> http://track.sipfoundry.org/secure/Signup.jspa
>>
>> Cause:
>> org.codehaus.xfire.XFireRuntimeException: Could not invoke servi
> On Wed, Jun 16, 2010 at 7:46 AM, Martin Steinmann
> wrote:
> >>
> >> As you know we have a long
> >>> history of 'protocol purism', which generally has not
> served us well.
> >>
> >>
> >>This is really not the same thing. I am talking about basic errors
> >>with the implementation of the pr
> So, enforce all the RFC's? SIP standards to all exclusion?
> Truly bad idea, however: it IS an open source, GPL system, and anyone
> here has access to the source code and can 'fix' it themselves.
>
>> will go back to "mostly working" for such ITSPs. It is just true that
>> all call flows ha
On 6/16/2010 9:55 AM, Joe Micciche wrote:
> I am still unable to create an account on the sipX JIRA Issue Tracker.
> Whenever I submit the form, it bombs out:
>
> http://track.sipfoundry.org/secure/Signup.jspa
>
> Cause:
> org.codehaus.xfire.XFireRuntimeException: Could not invoke service..
> Neste
But in particular you have to have gateways and/or sbc's setup that can
transcode since FMC usually relies on g729.
I think things would be much easier if you sought out an SBC which could
talk to your mobile user and better traverse all kinds of remote firewalls
using g729 and transcode it to g71
On 6/16/10 9:38 AM, M. Ranganathan wrote:
Well, you can clamp down the codec to a single supported codec such as
G711 ( i.e. filter the request and response SDP to that single
some of our interoperability was in fact when calls go from G.729 to
G.711 (G.711 needed for AA, or moh)
has some s
I am still unable to create an account on the sipX JIRA Issue Tracker.
Whenever I submit the form, it bombs out:
http://track.sipfoundry.org/secure/Signup.jspa
Cause:
org.codehaus.xfire.XFireRuntimeException: Could not invoke service..
Nested exception is org.codehaus.xfire.fault.XFireFault: Coul
On Wed, Jun 16, 2010 at 7:46 AM, Martin Steinmann wrote:
>>
>> As you know we have a long
>>> history of 'protocol purism', which generally has not served us well.
>>
>>
>>This is really not the same thing. I am talking about basic errors
>>with the implementation of the protocol that makes it di
You could investigate Agito networks ( Agitonetworks.com) –it provides seamless
handovers from Wifi to cellular and cellular to Wifi
Bob Anderson
Cyrand Corp
3-4170 Sladview Drive
Mississauga, ON L5L 0A1
905-817-8208 x237
www.cyrand.com
From: sipx-dev-boun...@list.sipfoundry.org
[mai
On Wed, Jun 16, 2010 at 7:46 AM, Martin Steinmann wrote:
>>
>> As you know we have a long
>>> history of 'protocol purism', which generally has not served us well.
>>
>>
>>This is really not the same thing. I am talking about basic errors
>>with the implementation of the protocol that makes it di
Dear All, Good Afternoon every one in this forum.
I would like to inform you that I am not an xpert in voip, but trying to
understand with the help of you people thru forums. I have gone through the
features of SIPXecs, but could not find the answers that I am looking for.
Hence I am pleased to
If I can chime in here as one who deals with multiple installations and
ITSPs, perhaps there is a middle ground here.
Would it be possible to create an 'Interoperability' module similar to
the Ingate approach? This would allow not only accommodation of minor
protocol deviations, but also a way to
>
>>
>> Hello,
>>
>> I had previously put in some hacks to compensate for protocol errors
>>
> >from ITSPs such as responses to SDP solicitations that would return
>
>> an OK with NO SDP body. There are even those very badly mannered ITSPs
>> that randomly return OK to INVITE with no con
>
> As you know we have a long
>> history of 'protocol purism', which generally has not served us well.
>
>
>This is really not the same thing. I am talking about basic errors
>with the implementation of the protocol that makes it difficult to
>compensate for. Or worse, results in a solution where
"JOLY, ROBERT (ROBERT)" wrote on 11-06-2010 15:50:14:
> > I am trying to work out what would be the best method to set
> > up presence.
> > I've learned quite a lot already and will try to make some
> > wiki doc in the future, but..
> >
> > One of the things I played with was Instant Messagi
29 matches
Mail list logo
