Content-Type: text/plain;
charset=utf-8
Content-Transfer-Encoding: 8bit
Organization: SipXecs Forum
In-Reply-To:
CAMgKNJWQao0SctwLUTHgeO610cdARSWkxW22LTgU8n=uyay...@mail.gmail.com
X-FUDforum: 08063afcdd00a6e76393c5b9527381e8 63116
Message-ID: f68c.4e67d...@forum.sipfoundry.org
Hi Tony,
I think its important to say that sipx and sipxbridge as an sbc is designed
to handle pstn sip trunks.
I think you expect sipx and an unmanaged gateway to do more than they
should.
I do think with the patton handles a refer properly. I don't think id expect
sipx or the patton to rewrite the
You realize that in the case of a dialed call (if a SipXecs user picks up a
grandstream phone and dials) to 4495, the SipXecs server DOES rewrite the
headers, and the rules exist on the patton to route the call correctly?
I'm afraid that I don't understand why I should need an SBC simply to
you don't. you do if you don't have something parsing or rewriting it
correctly., or is incapable of doing it.
sipx is a proxy. if you are connecting as an unmanaged gateway, this should
work fine. at the same tine I ha e seen this dine with older necessary pbx
systems and have not heard of call
Thanks Tony.
You're correct, I would not like to hear 'use Polycom handsets', as the same
issue exists for me using Grandstream, Snom, and Counterpath softphone UAs, but
specifically because I have already deployed over 100 Grandstream handsets in
production, and have another 370 on hand,
sipx is a proxy. it is not a proxy for another sip system such as an
unmanaged gateway acting as its own domain. the gateway os not part of its
framework, so yeah, we're not agreeing but systemically it (the gateway) is
its own entity.
aks patton about a b2bua function on it, that might be what
grin Gee, thanks :) (About what you did with the grandstreams).
I know there is some sentiment against them, but other than this issue (and
one other one, whereby when a CALLER (not the called-party) puts a call on
hold, they're unable to retrieve it, but only if the phone is configured
Then by all means open a jira and ask the dev-list their opinions on this. i
would maintain you would want to try to maintain a native dialplan (no 99
stuff). That works fine for sending a call to a gateway to get processed and
simply place a call. Transfers are more complicated. You should dial
I think the invite is what should make the difference. I don't normally
prepend or strip digits to interconnect two systems for migration purposes
when I can help it. Have you tried changing the sipx dial plan to not
prepend digits?
i.e. - 4200-4350 are on nortel, so custom dialplan say 42 plus 2
Content-Type: text/plain;
charset=utf-8
Content-Transfer-Encoding: 8bit
Organization: SipXecs Forum
In-Reply-To: f5ec.4e5d3...@forum.sipfoundry.org
X-FUDforum: 08063afcdd00a6e76393c5b9527381e8 63017
Message-ID: f629.4e5fc...@forum.sipfoundry.org
I'm not hearing anything about this, so I'm
I've not, what phone/softphone are you having trouble with?
On Thu, Sep 1, 2011 at 1:03 PM, Steve Beaudry
steve.beau...@royalroads.cawrote:
Content-Type: text/plain;
charset=utf-8
Content-Transfer-Encoding: 8bit
Organization: SipXecs Forum
In-Reply-To: f5ec.4e5d3...@forum.sipfoundry.org
I have not either though it is a requirement to have proper dns setup at
both ends. you mentioned refer which makes me think that perhaps 1 of the
systems you are connecting with is not capable of handling refer.
explaining your call flow, gateways and user agent involved would be a good
idea.
On
In Line 439 of the attached log, you can see the REFER-TO
arriving at the Patton Smartnode 4960 gateway... the
REFER-TO is destined for mailto:'4...@voip.royalroads.ca'.
This results in the gateway trying to send the INVITE back
to the SipXecs server, instead of to the correct remote
destination
what you never said was that you were trunking a nortel option 61c to sipx
via a smartnode.
I think this has been done successfully a few times. suffice it to say your
patton gateway needs a dialplan entry changed and why would you be dialling
it via a sip domain when you should be dialling it
to be more specific, the patton should have the dialplan entry to forward
that call to the nortel. it is referring the call back to sipx becaase it's
(patton's) dialplan is telling it to do so. i think this is really a patton
config issue.
Nate you around to field this? You did this same thing a
Content-Type: text/plain;
charset=utf-8
Content-Transfer-Encoding: 8bit
Organization: SipXecs Forum
In-Reply-To:
CAMgKNJWM52QdgtXvx_yptfpQe0qecu4+cMOnRepq=lgretj...@mail.gmail.com
X-FUDforum: 08063afcdd00a6e76393c5b9527381e8 63025
Message-ID: f631.4e600...@forum.sipfoundry.org
Thanks Tony,
I have found them to be wrong on occasions...
if the destination of 4495 is on the motel side, why are we dialling or
stripping digits instead if defining the destination a d sending it as is?
On Sep 1, 2011 6:40 PM, Steve Beaudry steve.beau...@royalroads.ca wrote:
Content-Type: text/plain;
ha ha stupid auto correct. motel should be nortel.
what type of dial plan rule are you using? what type of gateway?
On Sep 1, 2011 6:47 PM, Tony Graziano tgrazi...@myitdepartment.net
wrote:
I have found them to be wrong on occasions...
if the destination of 4495 is on the motel side, why are
Content-Type: text/plain;
charset=utf-8
Content-Transfer-Encoding: 8bit
Organization: SipXecs Forum
In-Reply-To:
camgknjwqzrf18a5kxnopamq_iwgxokb_t0lwr82xv+aoe6b...@mail.gmail.com
X-FUDforum: 08063afcdd00a6e76393c5b9527381e8 63028
Message-ID: f634.4e601...@forum.sipfoundry.org
To answer
I'm not much help here - we are linking to an old NEC (not voip aware) - so we
are just routing calls via the PRI interface on the Patton.
From: sipx-users-boun...@list.sipfoundry.org
[mailto:sipx-users-boun...@list.sipfoundry.org] On Behalf Of Tony Graziano
Sent: Thursday, September 01, 2011
20 matches
Mail list logo
