Matt,
The provider may very well be fine but maybe something in THEIR upstream
provider. I've seen this before with routing problems and they don't think
to look past their stuff.
The hard part is finding somebody at the provider who cares enough to really
dig in and find the problem.
Mike
On
>>> Michael Scheidell 07/30/10 5:42 PM >>>
>>>I went for about 3 days testing every button I could, but later foundout
that I needed to totally delete the gateway and itsp >>>account andput it back
in correctly for it to actually work.
Thanks for the tips but this call issue is not related to
On 7/30/10 5:14 PM, Matt White wrote:
This provider uses ip authentication
> which one doesn't work?
>
> I may have information for you.
The provider that uses the P-identity for authentication does not work.
it must be a friday, or I must really be stupid, but I don't un
>>> On 7/30/2010 at 03:58 PM, in message <4c532f03.40...@secnap.com>, Michael
Scheidell wrote:
> On 7/30/10 3:09 PM, Matt White wrote:
>> This provider uses ip authentication
> which one doesn't work?
>
> I may have information for you.
The provider that uses the P-identity for authentication d
On 7/30/10 3:09 PM, Matt White wrote:
This provider uses ip authentication
which one doesn't work?
I may have information for you.
--
Michael Scheidell, CTO
o: 561-999-5000
d: 561-948-2259
ISN: 1259*1300
> *| *SECNAP Network Security Corporation
* Certified SNORT Integrator
* 2008-9 Ho
>>> On 7/30/2010 at 11:16 AM, in message <4c52ecd8.3080...@secnap.com>, Michael
Scheidell wrote:
> On 7/30/10 10:52 AM, Matt White wrote:
>> This provider uses ip authentication and the other two use user/pass
>> so the sequence looks a bit different.
> is this the one that doesn't work?
> if so
Fax: 434.984.8427
Helpdesk Contract Customers:
http://www.myitdepartment.net/gethelp/
- Original Message -
From: sipx-users-boun...@list.sipfoundry.org
To: sipx-users@list.sipfoundry.org
Sent: Fri Jul 30 11:16:40 2010
Subject: Re: [sipx-users] SIP Protocal Question
On 7/30/10 10:52 AM
On 7/30/10 10:52 AM, Matt White wrote:
This provider uses ip authentication and the other two use user/pass
so the sequence looks a bit different.
is this the one that doesn't work?
if so, I suspect they are NOT sending to you on port 5080.
--
Michael Scheidell, CTO
o: 561-999-5000
d: 561-948
I've been able to add two other providers to the existing dailplan and it works
great. Which is why I'm sure its a provider issue.
The provider sees everything looking ok. Comparing the two calls from two
providers does not show anything glaring. This provider uses ip authentication
and the
Did you ask the provider what they see?
I think I would be puzzled also.
The sequence is really the same for the successful call up until that point,
"cstkcall error 6" is a call stack error. I'd really want to compare a pcap
as well as a provider interpretation too (if it were me) to understand
>>> "WORLEY, Dale R (Dale)" 07/30/10 5:07 AM >>>
>>>
>>>
>>>An 'a=rtpmap:0' is not required because payload type number 0 has a static
>>>definition. (See http://www.iana.org>>/assignments/rtp-parameters and RFC
>>>3551 section 6 for information about the static definitions.) You might
>>>wan
From: sipx-users-boun...@list.sipfoundry.org
[sipx-users-boun...@list.sipfoundry.org] On Behalf Of Matt White
[mwh...@thesummit-grp.com]
v=0
o=PITPACT-SBC-01 513746131 513746131 IN IP4 67.158.102.9
s=sip call
c=IN IP4 67.158.102.250
t=0 0
m=audio 31788 RT
I don't think it's valid because it's not something the phone can
agree to. don't take my word for it though. Who is the provider?
I don't see how the phone can agree unless it says, yeah I can do u-law.
On Thursday, July 29, 2010, Matt White wrote:
>
>
>
>
>
>
> Struggling with a sip tru
Struggling with a sip trunk provider where polycom cancels after the 183
message. The only thing different I see between this and other providers is
the SDP feilds.
This provider sends the codec in the media description but I do not see a
corresponding Media attribute for the codec. Is that
14 matches
Mail list logo
