perhaps he was signed up for digests which was announced to revert as part
of the change and didn't read the message and didn't realize he needs to log
back in and change it to digests again.
On Tue, Jul 27, 2010 at 9:37 AM, Michael Scheidell wrote:
> what are you talking about?
>
> this is the
what are you talking about?
this is the sipx-users list (isn't it?) and just what part of discussing
the problems with sipxbridge is spam?
did you sign up for email from the sipx-users list?
On 7/27/10 9:34 AM, Jason Bertelsen wrote:
Are you guys meaning to spam ...
Sent from my iPhone
O
Are you guys meaning to spam ...
Sent from my iPhone
On 27/07/2010, at 9:33 PM, Michael Scheidell wrote:
> On 7/26/10 8:23 PM, Douglas Hubler wrote:
>> port swapping wonkyness of sipXbridge
> yes, this part. ezuce needs to fix this, and/or someone needs to
> document that it doesn't work.
> (
On 7/26/10 8:23 PM, Douglas Hubler wrote:
> port swapping wonkyness of sipXbridge
yes, this part. ezuce needs to fix this, and/or someone needs to
document that it doesn't work.
(I have tried to get help on this for.. months. people who never tried
it always tell me the same thing. )
BUT it see
On Mon, Jul 26, 2010 at 4:13 PM, Michael Scheidell wrote:
> you got ATT? Verizon? Level3 trying to sell you enterprise SIP trunks?
>
> they want you to send to a different port? want to send to you on a
> different port?
>
> Got it nailed.
nice
>
> (hint: you don't use sipxbridge as your SBC.
That is what we do. I just wasn't going into the details.
On 7/26/2010 3:25 PM, Tony Graziano wrote:
In the event you are not supporting remote users, that should be
simple enough. If you are supporting remote users you would need to do
that ONLY for originating calls from the ITSP.
On Mon,
autentication, NOT registration, as they keep telling me.
we don't REGISTER, we AUTENTICATE.
and, hell! set up your SBC to be port 5060, on a DIFFERENT PUBLIC IP
address, and use pfsense to xlate it.
more to come.
(but, a normal ITSP account, trying to send to port 5070, like they
wanted, w
In the event you are not supporting remote users, that should be simple
enough. If you are supporting remote users you would need to do that ONLY
for originating calls from the ITSP.
On Mon, Jul 26, 2010 at 4:21 PM, Matthew Kitchin (public/usenet) <
mkitchin.pub...@gmail.com> wrote:
> Just an FY
Just an FYI. For Verizon, I simply translate inbound 5060 -> to 5080
at the router level, and all is well.
On 7/26/2010 3:13 PM, Michael Scheidell wrote:
Ready to document this and write it up.
you got ATT? Verizon? Level3 trying to sell you enterprise SIP trunks?
they want you to send to a
I don't think AT&T will agree to change the port to anything but 5060. They
have always flatly refused in the past. Not sure they use Acme packet in all
of their SIP products either.
In other words your server is behind NAT supporting remote users and you
state your RTP ports. You disable sipxbrid
Ready to document this and write it up.
you got ATT? Verizon? Level3 trying to sell you enterprise SIP trunks?
they want you to send to a different port? want to send to you on a
different port?
Got it nailed.
(hint: you don't use sipxbridge as your SBC. they go an acme SBC in
front of th
11 matches
Mail list logo