Hi there:
I have one LG-Nortel 6812 phone that is configured for MGCP. Is there a
way to convert to SIP?
Thanks!
tommy
Notice of Confidentiality:
**This communication and any of its attachments is intended for the use of the
person or entity to whom it is addressed and may contain informatio
> -Original Message-
> From: Martin Steinmann [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 20, 2008 11:42 AM
> To: Scott Lawrence
> Cc: Joly, Robert (CAR:9D30); Alberto; sipx-users@list.sipfoundry.org
> Subject: RE: [sipx-users] Configuring NAT Traversal in sipxconfig
>
>
> >Cc: Rob
OK, here's what I see. The REFER comes into the gateway:
17:51:12 Receive SIP message # (22/05/2008 14:51:12:790 GMT) # UDP #
856 bytes # from: 10.4.120.187:5060 # to: 10.4.120.182:5060
* SIP message buffer start
*
On Thu, 2008-06-19 at 15:57 -0600, Luis F Urrea wrote:
> On Thu, Jun 19, 2008 at 3:07 PM, Dale Worley
> <[EMAIL PROTECTED]> wrote:
>
> If you don't see that pattern, please capture a
> snapshot of the system
> durin
On Fri, 2007-05-18 at 15:36 -0700, Chris St Denis wrote:
> With both of them polycom 2.0.3 firmware they both hangup with bye
> messages. With a test of a polycom older firmware and x-lite the call
> just sat there and eventually timed out.
Polycom 2.0.x was pretty buggy, as version 2 was a comp
>Cc: Robert Joly; Alberto; sipx-users@list.sipfoundry.org
>Subject: Re: [sipx-users] Configuring NAT Traversal in sipxconfig
>
>
>On Fri, 2008-06-20 at 09:50 -0400, Martin Steinmann wrote:
>
>>
>> I think I agree with both views, which are a) We need to
>> address cases wh
"I assume that you've edited this -- the RFC says that the text value
should be within double-quotes:"
You spotted it right. I did not edit it and it should be in double
quotes. It is a strange behaviour of JAIN-SIP (that I used to implement
my test program) that the double quotes are not generate
On Fri, 2008-06-20 at 14:59 +0100, Gabor Paller wrote:
> Hi,
>
> I looked up a bit among the standards and found RFC 3326. According to
> this standard, the CANCEL message can carry a reason field. If the call
> was answered elsewhere, the CANCEL message should have a Reason header
> like this:
>
On Fri, 2008-06-20 at 14:59 +0100, Gabor Paller wrote:
> I looked up a bit among the standards and found RFC 3326. According to
> this standard, the CANCEL message can carry a reason field. If the call
> was answered elsewhere, the CANCEL message should have a Reason header
> like this:
> Reason: S
On Fri, 2008-06-20 at 09:50 -0400, Martin Steinmann wrote:
>
> I think I agree with both views, which are a) We need to
> address cases where the customer uses dynamic addresses and b)
> using STUN is not a very reliable way to discover the external
> addr
I have not still tried with SIP but with SCCP/H323 i have found useful and
stable Gre tunnels and VPDN sessions.
Ciao,
Federico
Well I don't completely agree here. I'm dealing mostly with small
> installations that rely on dynamic IPs. Dynamic IPs that are changing very
> rarely (once I force
Hi,
I looked up a bit among the standards and found RFC 3326. According to
this standard, the CANCEL message can carry a reason field. If the call
was answered elsewhere, the CANCEL message should have a Reason header
like this:
Reason: SIP ;cause=200 ;text="Call completed elsewhere"
I checked tha
Well I don't completely agree here. I'm dealing mostly with
small installations that rely on dynamic IPs. Dynamic IPs that are
changing very rarely (once I force the router to reboot). These small
installations have needs comparable to big ones but with
Hi Robert,
If my nat firewall reports to be SIP ALG capable NAT Traversal on
sipxecs is it unnecessary?
[<>] In theory, it is unnecessary if all the NATs in
your deployment have SIP ALGs however if you have remote workers
behind non-SIP-aware NATs (somebody connecting from
Hi Robert,
some more thoughts:
Robert Joly ha scritto:
The rule of thumb is that the NAT traversal feature
should be turned on
whenever you have a deployment where there are
non-SIP-aware NATs
between the sipXecs and some endpoints. A classic
exam
Not that I know of.
In 3.10.1, since it is the same line, if the user is logged into the UI
portal, they will see the outbound call in the log, but they have to be
logged in as that user/line.
Of course, the catch-all is if the caller left a voice mail and the
"second" instrument does not have a
Hi,
I have a general question about a problem that is common, I guess, to
all SIP-based systems and is also present in SipXecs.
Say, I have two SIP devices registered for the same user, realizing
multiple appearance for the user. Somebody calls the user, both devices
ring. The call is taken at on
Hi Robert,
some more thoughts:
Robert Joly ha scritto:
The rule of thumb is that the NAT traversal feature should be turned on
whenever you have a deployment where there are non-SIP-aware NATs
between the sipXecs and some endpoints. A classic example of such a
deployment is the remote worker co
18 matches
Mail list logo
