sipx 4.6 inbound ivr-->extension always not available

[Nicholas Drayer]

Hello,
I've got a test system up, everything works super, except inbound calls: they do go to the IVR, but when I choose an extension, it is always 'not available'. I can leave a voice message, and the extension's user can pick retrieve the voicemail.
I can call out just fine.
I'm using last night's 4.6 (problem has existed since I set the system up about 5 days ago) on RHEL 6.3 - 64 bit.
Maybe related to this is that MoH doesn't seem to work (but I've not looked into that too much: the bridge and the user have it set though).

I'm guessing it's some NAT related issue in conjunction with Blind Forwarding. It's on Amazon AWS, I set the security group to all open I'm not blocking anything incoming or outgoing.

I'm hoping someone can point me to where the look to solve this, I'd be most grateful!

Thanks,
Nicholas


Nicholas Drayer
Managing Director
Dyrand Systems
T. 604.408.4415 Ext. 319
www.dyrand.com

[Joegen Baclor]

Check the registration status of the phone in the admin UI. Is it
registered? If so, is it registered as NATed (sipXnonat tag not
present in contact)? If it is NATED, can you confirm if OPTIONS
keep-alive is received by the phone occasionally if you sniff the
packets from the phones network?

On 11/28/2012 09:43 AM, Nicholas Drayer wrote:
>
> Hello,
>
> I've got a test system up, everything works super, except inbound
> calls: they do go to the IVR, but when I choose an extension, it is
> always 'not available'. I can leave a voice message, and the
> extension's user can pick retrieve the voicemail.
>
> I can call out just fine.
>
> I'm using last night's 4.6 (problem has existed since I set the system
> up about 5 days ago) on RHEL 6.3 - 64 bit.
>
> Maybe related to this is that MoH doesn't seem to work (but I've not
> looked into that too much: the bridge and the user have it set though).
>
> I'm guessing it's some NAT related issue in conjunction with Blind
> Forwarding. It's on Amazon AWS, I set the security group to all open
> I'm not blocking anything incoming or outgoing.
>
> I'm hoping someone can point me to where the look to solve this, I'd
> be most grateful!
>
> Thanks,
>
> Nicholas
>
> Nicholas Drayer
>
> Managing Director
>
> Dyrand Systems
>
> T. 604.408.4415 Ext. 319
>
> www.dyrand.com
>
>
>
> _______________________________________________
> sipx-users mailing list
> sipx-***@list.sipfoundry.org
> List Archive: http://list.sipfoundry.org/archive/sipx-users/

[Nicholas Drayer]

Thank you Joegen,
Yes, it's registered and sipXnonat is not visible on the registration (on the web portal). And yes, I put the Bria logging on and it receives keep-alive (I think I'm able to make out that is says every 30 seconds). I ran "tcpdump -v host sipx.mydomain.com", which is showing the sip keep-alives; exactly every 30 seconds another 5 or-so lines appear (I disabled the XMPP account while running tcpdump).

Some other symptoms:
- outgoing to an external number rings on the calling side, and sound works both ways when picked up; when I put the call on hold, I can resume it. No MoH though. I can also transfer the call just fine to yet another external number.
- incoming external does ring, no MoH or ringing sound (dead silence on the calling end after "Please hold while I transfer your call"). After picking up still no sound either way. When I put the call on hold, I cannot resume, the Bria 'Resume" button does not work -- you have to end the call.

The problem occurs identically on my Mac at home as it does on my Windows 7 box at work in Vancouver, as it does on my colleagues Windows box in Toronto (i.e., three totally different firewalls and two OS's). Therefore I'm a bit hesitant to blame Bria.

I will tomorrow also send Bria a log, and ask for their input. But my gut tells me its something else than their software. I have a spare Polycom at work -- I'll also get that provisioned and working.

Nicholas
________________________________
From: Joegen Baclor [***@ezuce.com]
Sent: November 27, 2012 7:26 PM
To: Discussion list for users of sipXecs software
Cc: Nicholas Drayer
Subject: Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not available

Check the registration status of the phone in the admin UI. Is it registered? If so, is it registered as NATed (sipXnonat tag not present in contact)? If it is NATED, can you confirm if OPTIONS keep-alive is received by the phone occasionally if you sniff the packets from the phones network?

On 11/28/2012 09:43 AM, Nicholas Drayer wrote:
Hello,
I’ve got a test system up, everything works super, except inbound calls: they do go to the IVR, but when I choose an extension, it is always ‘not available’. I can leave a voice message, and the extension’s user can pick retrieve the voicemail.
I can call out just fine.
I’m using last night’s 4.6 (problem has existed since I set the system up about 5 days ago) on RHEL 6.3 - 64 bit.
Maybe related to this is that MoH doesn’t seem to work (but I’ve not looked into that too much: the bridge and the user have it set though).

I’m guessing it’s some NAT related issue in conjunction with Blind Forwarding. It’s on Amazon AWS, I set the security group to all open I’m not blocking anything incoming or outgoing.

I’m hoping someone can point me to where the look to solve this, I’d be most grateful!

Thanks,
Nicholas


Nicholas Drayer
Managing Director
Dyrand Systems
T. 604.408.4415 Ext. 319
www.dyrand.com<http://www.dyrand.com>

[Joegen Baclor]

I'm not sure if Bria supports MoH. Can someone verify this?


On 11/28/2012 04:35 PM, Nicholas Drayer wrote:
> Thank you Joegen,
> Yes, it's registered and sipXnonat is not visible on the registration
> (on the web portal). And yes, I put the Bria logging on and it
> receives keep-alive (I think I'm able to make out that is says every
> 30 seconds). I ran "tcpdump -v host sipx.mydomain.com", which is
> showing the sip keep-alives; exactly every 30 seconds another 5 or-so
> lines appear (I disabled the XMPP account while running tcpdump).
>
> Some other symptoms:
> - outgoing to an external number rings on the calling side, and sound
> works both ways when picked up; when I put the call on hold, I can
> resume it. No MoH though. I can also transfer the call just fine to
> yet another external number.
> - incoming external does ring, no MoH or ringing sound (dead silence
> on the calling end after "Please hold while I transfer your call").
> After picking up still no sound either way. When I put the call on
> hold, I cannot resume, the Bria 'Resume" button does not work -- you
> have to end the call.
>
> The problem occurs identically on my Mac at home as it does on my
> Windows 7 box at work in Vancouver, as it does on my colleagues
> Windows box in Toronto (i.e., three totally different firewalls and
> two OS's). Therefore I'm a bit hesitant to blame Bria.
>
> I will tomorrow also send Bria a log, and ask for their input. But my
> gut tells me its something else than their software. I have a spare
> Polycom at work -- I'll also get that provisioned and working.
>
> Nicholas
> ------------------------------------------------------------------------
> *From:* Joegen Baclor [***@ezuce.com]
> *Sent:* November 27, 2012 7:26 PM
> *To:* Discussion list for users of sipXecs software
> *Cc:* Nicholas Drayer
> *Subject:* Re: [sipx-users] sipx 4.6 inbound ivr-->extension always
> not available
>
> Check the registration status of the phone in the admin UI. Is it
> registered? If so, is it registered as NATed (sipXnonat tag not
> present in contact)? If it is NATED, can you confirm if OPTIONS
> keep-alive is received by the phone occasionally if you sniff the
> packets from the phones network?
>
> On 11/28/2012 09:43 AM, Nicholas Drayer wrote:
>>
>> Hello,
>>
>> I’ve got a test system up, everything works super, except inbound
>> calls: they do go to the IVR, but when I choose an extension, it is
>> always ‘not available’. I can leave a voice message, and the
>> extension’s user can pick retrieve the voicemail.
>>
>> I can call out just fine.
>>
>> I’m using last night’s 4.6 (problem has existed since I set the
>> system up about 5 days ago) on RHEL 6.3 - 64 bit.
>>
>> Maybe related to this is that MoH doesn’t seem to work (but I’ve not
>> looked into that too much: the bridge and the user have it set though).
>>
>> I’m guessing it’s some NAT related issue in conjunction with Blind
>> Forwarding. It’s on Amazon AWS, I set the security group to all open
>> I’m not blocking anything incoming or outgoing.
>>
>> I’m hoping someone can point me to where the look to solve this, I’d
>> be most grateful!
>>
>> Thanks,
>>
>> Nicholas
>>
>> Nicholas Drayer
>>
>> Managing Director
>>
>> Dyrand Systems
>>
>> T. 604.408.4415 Ext. 319
>>
>> www.dyrand.com
>>
>>
>>
>> _______________________________________________
>> sipx-users mailing list
>> sipx-***@list.sipfoundry.org
>> List Archive:http://list.sipfoundry.org/archive/sipx-users/
>

[Kumaran]

Bria won't support MoH..If Bria put on Hold other phones won't hear MoH..

Regards,
Kumaran T

On 11/28/2012 2:29 PM, Joegen Baclor wrote:
> I'm not sure if Bria supports MoH. Can someone verify this?
>
>
> On 11/28/2012 04:35 PM, Nicholas Drayer wrote:
>> Thank you Joegen,
>> Yes, it's registered and sipXnonat is not visible on the registration
>> (on the web portal). And yes, I put the Bria logging on and it
>> receives keep-alive (I think I'm able to make out that is says every
>> 30 seconds). I ran "tcpdump -v host sipx.mydomain.com", which is
>> showing the sip keep-alives; exactly every 30 seconds another 5 or-so
>> lines appear (I disabled the XMPP account while running tcpdump).
>>
>> Some other symptoms:
>> - outgoing to an external number rings on the calling side, and sound
>> works both ways when picked up; when I put the call on hold, I can
>> resume it. No MoH though. I can also transfer the call just fine to
>> yet another external number.
>> - incoming external does ring, no MoH or ringing sound (dead silence
>> on the calling end after "Please hold while I transfer your call").
>> After picking up still no sound either way. When I put the call on
>> hold, I cannot resume, the Bria 'Resume" button does not work -- you
>> have to end the call.
>>
>> The problem occurs identically on my Mac at home as it does on my
>> Windows 7 box at work in Vancouver, as it does on my colleagues
>> Windows box in Toronto (i.e., three totally different firewalls and
>> two OS's). Therefore I'm a bit hesitant to blame Bria.
>>
>> I will tomorrow also send Bria a log, and ask for their input. But my
>> gut tells me its something else than their software. I have a spare
>> Polycom at work -- I'll also get that provisioned and working.
>>
>> Nicholas
>> ------------------------------------------------------------------------
>> *From:* Joegen Baclor [***@ezuce.com]
>> *Sent:* November 27, 2012 7:26 PM
>> *To:* Discussion list for users of sipXecs software
>> *Cc:* Nicholas Drayer
>> *Subject:* Re: [sipx-users] sipx 4.6 inbound ivr-->extension always
>> not available
>>
>> Check the registration status of the phone in the admin UI. Is it
>> registered? If so, is it registered as NATed (sipXnonat tag not
>> present in contact)? If it is NATED, can you confirm if OPTIONS
>> keep-alive is received by the phone occasionally if you sniff the
>> packets from the phones network?
>>
>> On 11/28/2012 09:43 AM, Nicholas Drayer wrote:
>>>
>>> Hello,
>>>
>>> I've got a test system up, everything works super, except inbound
>>> calls: they do go to the IVR, but when I choose an extension, it is
>>> always 'not available'. I can leave a voice message, and the
>>> extension's user can pick retrieve the voicemail.
>>>
>>> I can call out just fine.
>>>
>>> I'm using last night's 4.6 (problem has existed since I set the
>>> system up about 5 days ago) on RHEL 6.3 - 64 bit.
>>>
>>> Maybe related to this is that MoH doesn't seem to work (but I've not
>>> looked into that too much: the bridge and the user have it set though).
>>>
>>> I'm guessing it's some NAT related issue in conjunction with Blind
>>> Forwarding. It's on Amazon AWS, I set the security group to all open
>>> I'm not blocking anything incoming or outgoing.
>>>
>>> I'm hoping someone can point me to where the look to solve this, I'd
>>> be most grateful!
>>>
>>> Thanks,
>>>
>>> Nicholas
>>>
>>> Nicholas Drayer
>>>
>>> Managing Director
>>>
>>> Dyrand Systems
>>>
>>> T. 604.408.4415 Ext. 319
>>>
>>> www.dyrand.com
>>>
>>>
>>>
>>> _______________________________________________
>>> sipx-users mailing list
>>> sipx-***@list.sipfoundry.org
>>> List Archive:http://list.sipfoundry.org/archive/sipx-users/
>>
>
>
>
> _______________________________________________
> sipx-users mailing list
> sipx-***@list.sipfoundry.org
> List Archive: http://list.sipfoundry.org/archive/sipx-users/

[Melcon Moraes]

Even when "other phones" are from an ITSP call coming through the
sipXbridge setup to play MoH?

-
MM


On Wed, Nov 28, 2012 at 7:07 AM, Kumaran <
***@ttplservices.com> wrote:

> Bria won't support MoH..If Bria put on Hold other phones won't hear MoH..
>
> Regards,
> Kumaran T
>
>
> On 11/28/2012 2:29 PM, Joegen Baclor wrote:
>
> I'm not sure if Bria supports MoH. Can someone verify this?
>
>
> On 11/28/2012 04:35 PM, Nicholas Drayer wrote:
>
> Thank you Joegen,
> Yes, it's registered and sipXnonat is not visible on the registration (on
> the web portal). And yes, I put the Bria logging on and it receives
> keep-alive (I think I'm able to make out that is says every 30 seconds). I
> ran "tcpdump -v host sipx.mydomain.com", which is showing the sip
> keep-alives; exactly every 30 seconds another 5 or-so lines appear (I
> disabled the XMPP account while running tcpdump).
>
> Some other symptoms:
> - outgoing to an external number rings on the calling side, and sound
> works both ways when picked up; when I put the call on hold, I can resume
> it. No MoH though. I can also transfer the call just fine to yet another
> external number.
> - incoming external does ring, no MoH or ringing sound (dead silence on
> the calling end after "Please hold while I transfer your call"). After
> picking up still no sound either way. When I put the call on hold, I cannot
> resume, the Bria 'Resume" button does not work -- you have to end the call.
>
> The problem occurs identically on my Mac at home as it does on my Windows
> 7 box at work in Vancouver, as it does on my colleagues Windows box in
> Toronto (i.e., three totally different firewalls and two OS's). Therefore
> I'm a bit hesitant to blame Bria.
>
> I will tomorrow also send Bria a log, and ask for their input. But my
> gut tells me its something else than their software. I have a spare Polycom
> at work -- I'll also get that provisioned and working.
>
> Nicholas
> ------------------------------
> *From:* Joegen Baclor [***@ezuce.com]
> *Sent:* November 27, 2012 7:26 PM
> *To:* Discussion list for users of sipXecs software
> *Cc:* Nicholas Drayer
> *Subject:* Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not
> available
>
> Check the registration status of the phone in the admin UI. Is it
> registered? If so, is it registered as NATed (sipXnonat tag not present
> in contact)? If it is NATED, can you confirm if OPTIONS keep-alive is
> received by the phone occasionally if you sniff the packets from the phones
> network?
>
> On 11/28/2012 09:43 AM, Nicholas Drayer wrote:
>
> Hello,
>
> I’ve got a test system up, everything works super, except inbound calls:
> they do go to the IVR, but when I choose an extension, it is always ‘not
> available’. I can leave a voice message, and the extension’s user can pick
> retrieve the voicemail.
>
> I can call out just fine.
>
> I’m using last night’s 4.6 (problem has existed since I set the system up
> about 5 days ago) on RHEL 6.3 - 64 bit.
>
> Maybe related to this is that MoH doesn’t seem to work (but I’ve not
> looked into that too much: the bridge and the user have it set though).
>
>
>
> I’m guessing it’s some NAT related issue in conjunction with Blind
> Forwarding. It’s on Amazon AWS, I set the security group to all open I’m
> not blocking anything incoming or outgoing.
>
>
>
> I’m hoping someone can point me to where the look to solve this, I’d be
> most grateful!
>
>
>
> Thanks,
>
> Nicholas
>
>
>
>
>
> Nicholas Drayer
>
> Managing Director
>
> Dyrand Systems
>
> T. 604.408.4415 Ext. 319
>
> www.dyrand.com
>
>
>
>
>
>
> _______________________________________________
> sipx-users mailing listsipx-***@list.sipfoundry.org
> List Archive: http://list.sipfoundry.org/archive/sipx-users/
>
>
>
>
>
> _______________________________________________
> sipx-users mailing listsipx-***@list.sipfoundry.org
> List Archive: http://list.sipfoundry.org/archive/sipx-users/
>
>
>
> _______________________________________________
> sipx-users mailing list
> sipx-***@list.sipfoundry.org
> List Archive: http://list.sipfoundry.org/archive/sipx-users/
>

[Joegen Baclor]

I was wrong. It's no sipXnonat that you should be looking for but to
make sure your registrations has x-sipX-privcontact. Can you verify
this for all your NATed registrations?

On 11/28/2012 04:35 PM, Nicholas Drayer wrote:
> Thank you Joegen,
> Yes, it's registered and sipXnonat is not visible on the registration
> (on the web portal). And yes, I put the Bria logging on and it
> receives keep-alive (I think I'm able to make out that is says every
> 30 seconds). I ran "tcpdump -v host sipx.mydomain.com", which is
> showing the sip keep-alives; exactly every 30 seconds another 5 or-so
> lines appear (I disabled the XMPP account while running tcpdump).
>
> Some other symptoms:
> - outgoing to an external number rings on the calling side, and sound
> works both ways when picked up; when I put the call on hold, I can
> resume it. No MoH though. I can also transfer the call just fine to
> yet another external number.
> - incoming external does ring, no MoH or ringing sound (dead silence
> on the calling end after "Please hold while I transfer your call").
> After picking up still no sound either way. When I put the call on
> hold, I cannot resume, the Bria 'Resume" button does not work -- you
> have to end the call.
>
> The problem occurs identically on my Mac at home as it does on my
> Windows 7 box at work in Vancouver, as it does on my colleagues
> Windows box in Toronto (i.e., three totally different firewalls and
> two OS's). Therefore I'm a bit hesitant to blame Bria.
>
> I will tomorrow also send Bria a log, and ask for their input. But my
> gut tells me its something else than their software. I have a spare
> Polycom at work -- I'll also get that provisioned and working.
>
> Nicholas
> ------------------------------------------------------------------------
> *From:* Joegen Baclor [***@ezuce.com]
> *Sent:* November 27, 2012 7:26 PM
> *To:* Discussion list for users of sipXecs software
> *Cc:* Nicholas Drayer
> *Subject:* Re: [sipx-users] sipx 4.6 inbound ivr-->extension always
> not available
>
> Check the registration status of the phone in the admin UI. Is it
> registered? If so, is it registered as NATed (sipXnonat tag not
> present in contact)? If it is NATED, can you confirm if OPTIONS
> keep-alive is received by the phone occasionally if you sniff the
> packets from the phones network?
>
> On 11/28/2012 09:43 AM, Nicholas Drayer wrote:
>>
>> Hello,
>>
>> I’ve got a test system up, everything works super, except inbound
>> calls: they do go to the IVR, but when I choose an extension, it is
>> always ‘not available’. I can leave a voice message, and the
>> extension’s user can pick retrieve the voicemail.
>>
>> I can call out just fine.
>>
>> I’m using last night’s 4.6 (problem has existed since I set the
>> system up about 5 days ago) on RHEL 6.3 - 64 bit.
>>
>> Maybe related to this is that MoH doesn’t seem to work (but I’ve not
>> looked into that too much: the bridge and the user have it set though).
>>
>> I’m guessing it’s some NAT related issue in conjunction with Blind
>> Forwarding. It’s on Amazon AWS, I set the security group to all open
>> I’m not blocking anything incoming or outgoing.
>>
>> I’m hoping someone can point me to where the look to solve this, I’d
>> be most grateful!
>>
>> Thanks,
>>
>> Nicholas
>>
>> Nicholas Drayer
>>
>> Managing Director
>>
>> Dyrand Systems
>>
>> T. 604.408.4415 Ext. 319
>>
>> www.dyrand.com
>>
>>
>>
>> _______________________________________________
>> sipx-users mailing list
>> sipx-***@list.sipfoundry.org
>> List Archive:http://list.sipfoundry.org/archive/sipx-users/
>

[Nicholas Drayer]

That all looks good Joegen:
<sip:***@x.x.x.x:39212;rinstance=307688e8aaf12fad;transport=tcp;x-sipX-privcontact=10.128.1.32%3A8180%3Btransport%3Dtcp>
Pretty much the same from all three sites I'm testing from.

From: Joegen Baclor [mailto:***@ezuce.com]
Sent: November-28-12 1:10 AM
To: Nicholas Drayer
Cc: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not available

I was wrong. It's no sipXnonat that you should be looking for but to make sure your registrations has x-sipX-privcontact. Can you verify this for all your NATed registrations?

On 11/28/2012 04:35 PM, Nicholas Drayer wrote:
Thank you Joegen,
Yes, it's registered and sipXnonat is not visible on the registration (on the web portal). And yes, I put the Bria logging on and it receives keep-alive (I think I'm able to make out that is says every 30 seconds). I ran "tcpdump -v host sipx.mydomain.com", which is showing the sip keep-alives; exactly every 30 seconds another 5 or-so lines appear (I disabled the XMPP account while running tcpdump).

Some other symptoms:
- outgoing to an external number rings on the calling side, and sound works both ways when picked up; when I put the call on hold, I can resume it. No MoH though. I can also transfer the call just fine to yet another external number.
- incoming external does ring, no MoH or ringing sound (dead silence on the calling end after "Please hold while I transfer your call"). After picking up still no sound either way. When I put the call on hold, I cannot resume, the Bria 'Resume" button does not work -- you have to end the call.

The problem occurs identically on my Mac at home as it does on my Windows 7 box at work in Vancouver, as it does on my colleagues Windows box in Toronto (i.e., three totally different firewalls and two OS's). Therefore I'm a bit hesitant to blame Bria.

I will tomorrow also send Bria a log, and ask for their input. But my gut tells me its something else than their software. I have a spare Polycom at work -- I'll also get that provisioned and working.

Nicholas
________________________________
From: Joegen Baclor [***@ezuce.com<mailto:***@ezuce.com>]
Sent: November 27, 2012 7:26 PM
To: Discussion list for users of sipXecs software
Cc: Nicholas Drayer
Subject: Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not available
Check the registration status of the phone in the admin UI. Is it registered? If so, is it registered as NATed (sipXnonat tag not present in contact)? If it is NATED, can you confirm if OPTIONS keep-alive is received by the phone occasionally if you sniff the packets from the phones network?

On 11/28/2012 09:43 AM, Nicholas Drayer wrote:
Hello,
I've got a test system up, everything works super, except inbound calls: they do go to the IVR, but when I choose an extension, it is always 'not available'. I can leave a voice message, and the extension's user can pick retrieve the voicemail.
I can call out just fine.
I'm using last night's 4.6 (problem has existed since I set the system up about 5 days ago) on RHEL 6.3 - 64 bit.
Maybe related to this is that MoH doesn't seem to work (but I've not looked into that too much: the bridge and the user have it set though).

I'm guessing it's some NAT related issue in conjunction with Blind Forwarding. It's on Amazon AWS, I set the security group to all open I'm not blocking anything incoming or outgoing.

I'm hoping someone can point me to where the look to solve this, I'd be most grateful!

Thanks,
Nicholas


Nicholas Drayer
Managing Director
Dyrand Systems
T. 604.408.4415 Ext. 319
www.dyrand.com<http://www.dyrand.com>





_______________________________________________

sipx-users mailing list

sipx-***@list.sipfoundry.org<mailto:sipx-***@list.sipfoundry.org>

List Archive: http://list.sipfoundry.org/archive/sipx-users/

[Nicholas Drayer]

Another day and yet a bit closer: the Polycom SoundPoint I managed to provision for this server has no problems whatsoever. MoH, inbound, outbound - all are no problem!
So I think I can only conclude that it is a Bria-specific problem. That's a relief - I think I now can conclude the server I've setup is good. On the other hand, I'm setting this up for 3 users who are mobile and want to use Bria...

Are there any Bria-specific provisioning settings I should look at in sipXecs that may be related to the problem?

Unless anyone reading this has a brilliant idea, I'm going to forward the Bria log to CounterPath, and cross my fingers that they will figure it out...

From: sipx-users-***@list.sipfoundry.org [mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Nicholas Drayer
Sent: November-28-12 11:58 AM
To: Joegen Baclor
Cc: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not available

That all looks good Joegen:
<sip:***@x.x.x.x:39212;rinstance=307688e8aaf12fad;transport=tcp;x-sipX-privcontact=10.128.1.32%3A8180%3Btransport%3Dtcp>
Pretty much the same from all three sites I'm testing from.

From: Joegen Baclor [mailto:***@ezuce.com]
Sent: November-28-12 1:10 AM
To: Nicholas Drayer
Cc: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not available

I was wrong. It's no sipXnonat that you should be looking for but to make sure your registrations has x-sipX-privcontact. Can you verify this for all your NATed registrations?

On 11/28/2012 04:35 PM, Nicholas Drayer wrote:
Thank you Joegen,
Yes, it's registered and sipXnonat is not visible on the registration (on the web portal). And yes, I put the Bria logging on and it receives keep-alive (I think I'm able to make out that is says every 30 seconds). I ran "tcpdump -v host sipx.mydomain.com", which is showing the sip keep-alives; exactly every 30 seconds another 5 or-so lines appear (I disabled the XMPP account while running tcpdump).

Some other symptoms:
- outgoing to an external number rings on the calling side, and sound works both ways when picked up; when I put the call on hold, I can resume it. No MoH though. I can also transfer the call just fine to yet another external number.
- incoming external does ring, no MoH or ringing sound (dead silence on the calling end after "Please hold while I transfer your call"). After picking up still no sound either way. When I put the call on hold, I cannot resume, the Bria 'Resume" button does not work -- you have to end the call.

The problem occurs identically on my Mac at home as it does on my Windows 7 box at work in Vancouver, as it does on my colleagues Windows box in Toronto (i.e., three totally different firewalls and two OS's). Therefore I'm a bit hesitant to blame Bria.

I will tomorrow also send Bria a log, and ask for their input. But my gut tells me its something else than their software. I have a spare Polycom at work -- I'll also get that provisioned and working.

Nicholas
________________________________
From: Joegen Baclor [***@ezuce.com<mailto:***@ezuce.com>]
Sent: November 27, 2012 7:26 PM
To: Discussion list for users of sipXecs software
Cc: Nicholas Drayer
Subject: Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not available
Check the registration status of the phone in the admin UI. Is it registered? If so, is it registered as NATed (sipXnonat tag not present in contact)? If it is NATED, can you confirm if OPTIONS keep-alive is received by the phone occasionally if you sniff the packets from the phones network?

On 11/28/2012 09:43 AM, Nicholas Drayer wrote:
Hello,
I've got a test system up, everything works super, except inbound calls: they do go to the IVR, but when I choose an extension, it is always 'not available'. I can leave a voice message, and the extension's user can pick retrieve the voicemail.
I can call out just fine.
I'm using last night's 4.6 (problem has existed since I set the system up about 5 days ago) on RHEL 6.3 - 64 bit.
Maybe related to this is that MoH doesn't seem to work (but I've not looked into that too much: the bridge and the user have it set though).

I'm guessing it's some NAT related issue in conjunction with Blind Forwarding. It's on Amazon AWS, I set the security group to all open I'm not blocking anything incoming or outgoing.

I'm hoping someone can point me to where the look to solve this, I'd be most grateful!

Thanks,
Nicholas


Nicholas Drayer
Managing Director
Dyrand Systems
T. 604.408.4415 Ext. 319
www.dyrand.com<http://www.dyrand.com>




_______________________________________________

sipx-users mailing list

sipx-***@list.sipfoundry.org<mailto:sipx-***@list.sipfoundry.org>

List Archive: http://list.sipfoundry.org/archive/sipx-users/

[Nicholas Drayer]

The MoH issue is related to Bria: I've now figured out that the MoH issue only occurs happens with the Mac OS X Bria client. Same for the hold/resume issue - works properly on Windows, can't resume on Mac. Both exhibit the main problem of no audio in/out for external received calls.

What I find difficult to wrap my head around is that the MoH on the calling external calling line works when the IVR connects and rings a Windows Bria client, but not for a Mac Bria client.

I haven't mentioned this, but calling from extension to extension works fine. None of the extensions are on the sipXecs server's LAN: the server is on AWS EC2, separated by the AWS Security Group from the Internet, the various clients are in their own networks with their own NATted connections to the Internet. It's only when a call comes in via the sipXecs server's 5080 port that the Bria client exhibits no audio sent/received.

Coming to think of it - I'm impressed that calling from a sip client behind NAT to a server behind NAT to another sip client behind NAT actually works :).

From: sipx-users-***@list.sipfoundry.org [mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Nicholas Drayer
Sent: November-28-12 4:11 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not available

Another day and yet a bit closer: the Polycom SoundPoint I managed to provision for this server has no problems whatsoever. MoH, inbound, outbound - all are no problem!
So I think I can only conclude that it is a Bria-specific problem. That's a relief - I think I now can conclude the server I've setup is good. On the other hand, I'm setting this up for 3 users who are mobile and want to use Bria...

Are there any Bria-specific provisioning settings I should look at in sipXecs that may be related to the problem?

Unless anyone reading this has a brilliant idea, I'm going to forward the Bria log to CounterPath, and cross my fingers that they will figure it out...

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Nicholas Drayer
Sent: November-28-12 11:58 AM
To: Joegen Baclor
Cc: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not available

That all looks good Joegen:
<sip:***@x.x.x.x:39212;rinstance=307688e8aaf12fad;transport=tcp;x-sipX-privcontact=10.128.1.32%3A8180%3Btransport%3Dtcp>
Pretty much the same from all three sites I'm testing from.

From: Joegen Baclor [mailto:***@ezuce.com]
Sent: November-28-12 1:10 AM
To: Nicholas Drayer
Cc: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not available

I was wrong. It's no sipXnonat that you should be looking for but to make sure your registrations has x-sipX-privcontact. Can you verify this for all your NATed registrations?

On 11/28/2012 04:35 PM, Nicholas Drayer wrote:
Thank you Joegen,
Yes, it's registered and sipXnonat is not visible on the registration (on the web portal). And yes, I put the Bria logging on and it receives keep-alive (I think I'm able to make out that is says every 30 seconds). I ran "tcpdump -v host sipx.mydomain.com", which is showing the sip keep-alives; exactly every 30 seconds another 5 or-so lines appear (I disabled the XMPP account while running tcpdump).

Some other symptoms:
- outgoing to an external number rings on the calling side, and sound works both ways when picked up; when I put the call on hold, I can resume it. No MoH though. I can also transfer the call just fine to yet another external number.
- incoming external does ring, no MoH or ringing sound (dead silence on the calling end after "Please hold while I transfer your call"). After picking up still no sound either way. When I put the call on hold, I cannot resume, the Bria 'Resume" button does not work -- you have to end the call.

The problem occurs identically on my Mac at home as it does on my Windows 7 box at work in Vancouver, as it does on my colleagues Windows box in Toronto (i.e., three totally different firewalls and two OS's). Therefore I'm a bit hesitant to blame Bria.

I will tomorrow also send Bria a log, and ask for their input. But my gut tells me its something else than their software. I have a spare Polycom at work -- I'll also get that provisioned and working.

Nicholas
________________________________
From: Joegen Baclor [***@ezuce.com<mailto:***@ezuce.com>]
Sent: November 27, 2012 7:26 PM
To: Discussion list for users of sipXecs software
Cc: Nicholas Drayer
Subject: Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not available
Check the registration status of the phone in the admin UI. Is it registered? If so, is it registered as NATed (sipXnonat tag not present in contact)? If it is NATED, can you confirm if OPTIONS keep-alive is received by the phone occasionally if you sniff the packets from the phones network?

On 11/28/2012 09:43 AM, Nicholas Drayer wrote:
Hello,
I've got a test system up, everything works super, except inbound calls: they do go to the IVR, but when I choose an extension, it is always 'not available'. I can leave a voice message, and the extension's user can pick retrieve the voicemail.
I can call out just fine.
I'm using last night's 4.6 (problem has existed since I set the system up about 5 days ago) on RHEL 6.3 - 64 bit.
Maybe related to this is that MoH doesn't seem to work (but I've not looked into that too much: the bridge and the user have it set though).

I'm guessing it's some NAT related issue in conjunction with Blind Forwarding. It's on Amazon AWS, I set the security group to all open I'm not blocking anything incoming or outgoing.

I'm hoping someone can point me to where the look to solve this, I'd be most grateful!

Thanks,
Nicholas


Nicholas Drayer
Managing Director
Dyrand Systems
T. 604.408.4415 Ext. 319
www.dyrand.com<http://www.dyrand.com>




_______________________________________________

sipx-users mailing list

sipx-***@list.sipfoundry.org<mailto:sipx-***@list.sipfoundry.org>

List Archive: http://list.sipfoundry.org/archive/sipx-users/

[Nicholas Drayer]

At last, I am now able to turn the problem incoming call audio problem on and off repeatably and reliably: it has something to do with XMPP. Below are the repeatable steps. Does anyone have an idea what I should do with this... put in a bug report? I don't want to do that without someone's advice, since it's entirely possible that I'm missing something vital that I don't know about.

Step 1
-------
Create a user that has IM disabled (User list-screen --> click on the User ID --> Instant Messaging --> uncheck Enabled --> OK)
Create a phone profile that has IM disabled (Devices --> click on the Line --> XMPP --> uncheck top two boxes)
Send Profiles
Login Bria
Audio works both ways when dialling in from SIP trunking provider.

Step 2
-------
User list-screen --> click on the User ID --> Instant Messaging --> check Enabled --> Apply
Incoming call from the SIP trunking provider now has no audio either way after being transferred to the Bria client by the IVR

Step 3
-------
User list-screen --> click on the User ID --> Instant Messaging --> uncheck Enabled --> Apply
Logout of Bria
Login to Bria
Audio works both ways when dialling in from SIP trunking provider.

Note A
--------
For Step 2, you do NOT have to logout of Bria. But for Step 3 (making it work properly again) you DO have to logout of and login back with Bria, even thought the profile is not changed whatsoever.

Note B
--------
Turning the Bria phone line XMPP on (Devices --> Phones --> click on Line --> XMPP --> top two checkboxes) makes no difference to the above behaviour, except that it does enable Bria's IM features if the IM is enabled on the user's screen. All IM features work properly.

The MoH issue definitely has something to do with branch settings: I removed the branch from the Server, the Gateway, and the Users (they were all identical, currently the system only has one; so now they are "All") and now it works fine. It's unrelated to the above. If I can replicate it I'll report it too.

Nicholas Drayer, Managing Director
Dyrand Systems Inc.
Tel: [phone] ext. 319
email <mailto:***@dyrand.com> | web<http://www.dyrand.com/>
________________________________
From: sipx-users-***@list.sipfoundry.org [sipx-users-***@list.sipfoundry.org] on behalf of Nicholas Drayer [***@dyrand.com]
Sent: November 28, 2012 5:05 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not available

The MoH issue is related to Bria: I’ve now figured out that the MoH issue only occurs happens with the Mac OS X Bria client. Same for the hold/resume issue – works properly on Windows, can’t resume on Mac. Both exhibit the main problem of no audio in/out for external received calls.

What I find difficult to wrap my head around is that the MoH on the calling external calling line works when the IVR connects and rings a Windows Bria client, but not for a Mac Bria client.

I haven’t mentioned this, but calling from extension to extension works fine. None of the extensions are on the sipXecs server’s LAN: the server is on AWS EC2, separated by the AWS Security Group from the Internet, the various clients are in their own networks with their own NATted connections to the Internet. It’s only when a call comes in via the sipXecs server’s 5080 port that the Bria client exhibits no audio sent/received.

Coming to think of it – I’m impressed that calling from a sip client behind NAT to a server behind NAT to another sip client behind NAT actually works :).

From: sipx-users-***@list.sipfoundry.org [mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Nicholas Drayer
Sent: November-28-12 4:11 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not available

Another day and yet a bit closer: the Polycom SoundPoint I managed to provision for this server has no problems whatsoever. MoH, inbound, outbound – all are no problem!
So I think I can only conclude that it is a Bria-specific problem. That’s a relief – I think I now can conclude the server I’ve setup is good. On the other hand, I’m setting this up for 3 users who are mobile and want to use Bria…

Are there any Bria-specific provisioning settings I should look at in sipXecs that may be related to the problem?

Unless anyone reading this has a brilliant idea, I’m going to forward the Bria log to CounterPath, and cross my fingers that they will figure it out…

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Nicholas Drayer
Sent: November-28-12 11:58 AM
To: Joegen Baclor
Cc: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not available

That all looks good Joegen:
<sip:***@x.x.x.x:39212;rinstance=307688e8aaf12fad;transport=tcp;x-sipX-privcontact=10.128.1.32%3A8180%3Btransport%3Dtcp>
Pretty much the same from all three sites I’m testing from.

From: Joegen Baclor [mailto:***@ezuce.com]
Sent: November-28-12 1:10 AM
To: Nicholas Drayer
Cc: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not available

I was wrong. It's no sipXnonat that you should be looking for but to make sure your registrations has x-sipX-privcontact. Can you verify this for all your NATed registrations?

On 11/28/2012 04:35 PM, Nicholas Drayer wrote:
Thank you Joegen,
Yes, it's registered and sipXnonat is not visible on the registration (on the web portal). And yes, I put the Bria logging on and it receives keep-alive (I think I'm able to make out that is says every 30 seconds). I ran "tcpdump -v host sipx.mydomain.com", which is showing the sip keep-alives; exactly every 30 seconds another 5 or-so lines appear (I disabled the XMPP account while running tcpdump).

Some other symptoms:
- outgoing to an external number rings on the calling side, and sound works both ways when picked up; when I put the call on hold, I can resume it. No MoH though. I can also transfer the call just fine to yet another external number.
- incoming external does ring, no MoH or ringing sound (dead silence on the calling end after "Please hold while I transfer your call"). After picking up still no sound either way. When I put the call on hold, I cannot resume, the Bria 'Resume" button does not work -- you have to end the call.

The problem occurs identically on my Mac at home as it does on my Windows 7 box at work in Vancouver, as it does on my colleagues Windows box in Toronto (i.e., three totally different firewalls and two OS's). Therefore I'm a bit hesitant to blame Bria.

I will tomorrow also send Bria a log, and ask for their input. But my gut tells me its something else than their software. I have a spare Polycom at work -- I'll also get that provisioned and working.

Nicholas
________________________________
From: Joegen Baclor [***@ezuce.com<mailto:***@ezuce.com>]
Sent: November 27, 2012 7:26 PM
To: Discussion list for users of sipXecs software
Cc: Nicholas Drayer
Subject: Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not available
Check the registration status of the phone in the admin UI. Is it registered? If so, is it registered as NATed (sipXnonat tag not present in contact)? If it is NATED, can you confirm if OPTIONS keep-alive is received by the phone occasionally if you sniff the packets from the phones network?

On 11/28/2012 09:43 AM, Nicholas Drayer wrote:
Hello,
I’ve got a test system up, everything works super, except inbound calls: they do go to the IVR, but when I choose an extension, it is always ‘not available’. I can leave a voice message, and the extension’s user can pick retrieve the voicemail.
I can call out just fine.
I’m using last night’s 4.6 (problem has existed since I set the system up about 5 days ago) on RHEL 6.3 - 64 bit.
Maybe related to this is that MoH doesn’t seem to work (but I’ve not looked into that too much: the bridge and the user have it set though).

I’m guessing it’s some NAT related issue in conjunction with Blind Forwarding. It’s on Amazon AWS, I set the security group to all open I’m not blocking anything incoming or outgoing.

I’m hoping someone can point me to where the look to solve this, I’d be most grateful!

Thanks,
Nicholas


Nicholas Drayer
Managing Director
Dyrand Systems
T. 604.408.4415 Ext. 319
www.dyrand.com<http://www.dyrand.com>




_______________________________________________

sipx-users mailing list

sipx-***@list.sipfoundry.org<mailto:sipx-***@list.sipfoundry.org>

List Archive: http://list.sipfoundry.org/archive/sipx-users/

[Michael Picher]

fwiw, i never put servers into branches.

i only use branches to have users prefer particular gateways on dial-out.
i don't see that putting a server in a particular branch has any bearing
here.

mike


On Thu, Nov 29, 2012 at 12:58 AM, Nicholas Drayer <***@dyrand.com
> wrote:

> At last, I am now able to turn the problem incoming call audio problem
> on and off repeatably and reliably: it has something to do with XMPP. Below
> are the repeatable steps. Does anyone have an idea what I should do with
> this... put in a bug report? I don't want to do that without someone's
> advice, since it's entirely possible that I'm missing something vital that
> I don't know about.
>
> Step 1
> -------
> Create a user that has IM disabled (User list-screen --> click on the User
> ID --> Instant Messaging --> uncheck Enabled --> OK)
> Create a phone profile that has IM disabled (Devices --> click on the Line
> --> XMPP --> uncheck top two boxes)
> Send Profiles
> Login Bria
> Audio works both ways when dialling in from SIP trunking provider.
>
> Step 2
> -------
> User list-screen --> click on the User ID --> Instant Messaging --> check
> Enabled --> Apply
> Incoming call from the SIP trunking provider now has no audio either way
> after being transferred to the Bria client by the IVR
>
> Step 3
> -------
> User list-screen --> click on the User ID --> Instant Messaging -->
> uncheck Enabled --> Apply
> Logout of Bria
> Login to Bria
> Audio works both ways when dialling in from SIP trunking provider.
>
> Note A
> --------
> For Step 2, you do NOT have to logout of Bria. But for Step 3 (making it
> work properly again) you DO have to logout of and login back with Bria,
> even thought the profile is not changed whatsoever.
>
> Note B
> --------
> Turning the Bria phone line XMPP on (Devices --> Phones --> click on Line
> --> XMPP --> top two checkboxes) makes no difference to the above
> behaviour, except that it does enable Bria's IM features if the IM is
> enabled on the user's screen. All IM features work properly.
>
> The MoH issue definitely has something to do with branch settings: I
> removed the branch from the Server, the Gateway, and the Users (they were
> all identical, currently the system only has one; so now they are "All")
> and now it works fine. It's unrelated to the above. If I can replicate it
> I'll report it too.
>
> Nicholas Drayer, Managing Director
> Dyrand Systems Inc.
> Tel: [phone] ext. 319
> email <***@dyrand.com>| web <http://www.dyrand.com/>****
> ------------------------------
> *From:* sipx-users-***@list.sipfoundry.org [
> sipx-users-***@list.sipfoundry.org] on behalf of Nicholas Drayer [
> ***@dyrand.com]
> *Sent:* November 28, 2012 5:05 PM
>
> *To:* Discussion list for users of sipXecs software
> *Subject:* Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not
> available
>
> The MoH issue is related to Bria: I’ve now figured out that the MoH
> issue only occurs happens with the Mac OS X Bria client. Same for the
> hold/resume issue – works properly on Windows, can’t resume on Mac. Both
> exhibit the main problem of no audio in/out for external received calls.
>
>
>
> What I find difficult to wrap my head around is that the MoH on the
> calling external calling line works when the IVR connects and rings a
> Windows Bria client, but not for a Mac Bria client.
>
>
>
> I haven’t mentioned this, but calling from extension to extension works
> fine. None of the extensions are on the sipXecs server’s LAN: the server is
> on AWS EC2, separated by the AWS Security Group from the Internet, the
> various clients are in their own networks with their own NATted connections
> to the Internet. It’s only when a call comes in via the sipXecs server’s
> 5080 port that the Bria client exhibits no audio sent/received.
>
>
>
> Coming to think of it – I’m impressed that calling from a sip client
> behind NAT to a server behind NAT to another sip client behind NAT actually
> works J.
>
>
>
> *From:* sipx-users-***@list.sipfoundry.org [mailto:
> sipx-users-***@list.sipfoundry.org] *On Behalf Of *Nicholas Drayer
> *Sent:* November-28-12 4:11 PM
> *To:* Discussion list for users of sipXecs software
> *Subject:* Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not
> available
>
>
>
> Another day and yet a bit closer: the Polycom SoundPoint I managed to
> provision for this server has no problems whatsoever. MoH, inbound,
> outbound – all are no problem!
>
> So I think I can only conclude that it is a Bria-specific problem. That’s
> a relief – I think I now can conclude the server I’ve setup is good. On the
> other hand, I’m setting this up for 3 users who are mobile and want to use
> Bria…
>
>
>
> Are there any Bria-specific provisioning settings I should look at in
> sipXecs that may be related to the problem?
>
>
>
> Unless anyone reading this has a brilliant idea, I’m going to forward the
> Bria log to CounterPath, and cross my fingers that they will figure it out…
>
>
>
> *From:* sipx-users-***@list.sipfoundry.org [
> mailto:sipx-users-***@list.sipfoundry.org<sipx-users-***@list.sipfoundry.org>]
> *On Behalf Of *Nicholas Drayer
> *Sent:* November-28-12 11:58 AM
> *To:* Joegen Baclor
> *Cc:* Discussion list for users of sipXecs software
> *Subject:* Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not
> available
>
>
>
> That all looks good Joegen:
>
> <
> sip:***@x.x.x.x:39212;rinstance=307688e8aaf12fad;transport=tcp;x-sipX-privcontact=10.128.1.32%3A8180%3Btransport%3Dtcp
> >
>
> Pretty much the same from all three sites I’m testing from.
>
>
>
> *From:* Joegen Baclor [mailto:***@ezuce.com <***@ezuce.com>]
> *Sent:* November-28-12 1:10 AM
> *To:* Nicholas Drayer
> *Cc:* Discussion list for users of sipXecs software
> *Subject:* Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not
> available
>
>
>
> I was wrong. It's no sipXnonat that you should be looking for but to make
> sure your registrations has x-sipX-privcontact. Can you verify this for
> all your NATed registrations?
>
> On 11/28/2012 04:35 PM, Nicholas Drayer wrote:
>
> Thank you Joegen,
>
> Yes, it's registered and sipXnonat is not visible on the registration (on
> the web portal). And yes, I put the Bria logging on and it receives
> keep-alive (I think I'm able to make out that is says every 30 seconds). I
> ran "tcpdump -v host sipx.mydomain.com", which is showing the sip
> keep-alives; exactly every 30 seconds another 5 or-so lines appear (I
> disabled the XMPP account while running tcpdump).
>
>
>
> Some other symptoms:
>
> - outgoing to an external number rings on the calling side, and sound
> works both ways when picked up; when I put the call on hold, I can resume
> it. No MoH though. I can also transfer the call just fine to yet another
> external number.
>
> - incoming external does ring, no MoH or ringing sound (dead silence on
> the calling end after "Please hold while I transfer your call"). After
> picking up still no sound either way. When I put the call on hold, I cannot
> resume, the Bria 'Resume" button does not work -- you have to end the call.
>
>
>
> The problem occurs identically on my Mac at home as it does on my Windows
> 7 box at work in Vancouver, as it does on my colleagues Windows box in
> Toronto (i.e., three totally different firewalls and two OS's). Therefore
> I'm a bit hesitant to blame Bria.
>
>
>
> I will tomorrow also send Bria a log, and ask for their input. But my gut
> tells me its something else than their software. I have a spare Polycom at
> work -- I'll also get that provisioned and working.
>
>
>
> Nicholas
> ------------------------------
>
> *From:* Joegen Baclor [***@ezuce.com]
> *Sent:* November 27, 2012 7:26 PM
> *To:* Discussion list for users of sipXecs software
> *Cc:* Nicholas Drayer
> *Subject:* Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not
> available
>
> Check the registration status of the phone in the admin UI. Is it
> registered? If so, is it registered as NATed (sipXnonat tag not present
> in contact)? If it is NATED, can you confirm if OPTIONS keep-alive is
> received by the phone occasionally if you sniff the packets from the phones
> network?
>
> On 11/28/2012 09:43 AM, Nicholas Drayer wrote:
>
> Hello,
>
> I’ve got a test system up, everything works super, except inbound calls:
> they do go to the IVR, but when I choose an extension, it is always ‘not
> available’. I can leave a voice message, and the extension’s user can pick
> retrieve the voicemail.
>
> I can call out just fine.
>
> I’m using last night’s 4.6 (problem has existed since I set the system up
> about 5 days ago) on RHEL 6.3 - 64 bit.
>
> Maybe related to this is that MoH doesn’t seem to work (but I’ve not
> looked into that too much: the bridge and the user have it set though).
>
>
>
> I’m guessing it’s some NAT related issue in conjunction with Blind
> Forwarding. It’s on Amazon AWS, I set the security group to all open I’m
> not blocking anything incoming or outgoing.
>
>
>
> I’m hoping someone can point me to where the look to solve this, I’d be
> most grateful!
>
>
>
> Thanks,
>
> Nicholas
>
>
>
>
>
> Nicholas Drayer
>
> Managing Director
>
> Dyrand Systems
>
> T. 604.408.4415 Ext. 319
>
> www.dyrand.com
>
>
>
>
>
>
>
> _______________________________________________
>
> sipx-users mailing list
>
> sipx-***@list.sipfoundry.org
>
> List Archive: http://list.sipfoundry.org/archive/sipx-users/
>
>
>
>
>
> _______________________________________________
> sipx-users mailing list
> sipx-***@list.sipfoundry.org
> List Archive: http://list.sipfoundry.org/archive/sipx-users/
>



--
Michael Picher, Director of Technical Services
eZuce, Inc.

300 Brickstone Square****

Suite 201****

Andover, MA. 01810
O.978-296-1005 X2015
M.207-956-0262
@mpicher <http://twitter.com/mpicher>
linkedin <http://www.linkedin.com/profile/view?id=35504760&trk=tab_pro>
www.ezuce.com

------------------------------------------------------------------------------------------------------------
There are 10 kinds of people in the world, those who understand binary and
those who don't.

[Nicholas Drayer]

I put in XX-10547 for the IM-enabled interfering with incoming audio problem. Seems pretty major to me, making the Bria softphone rather useless.

If I have time I'll see if I can make the MoH issue repeatable this weekend, and then put an issue in.

Thanks for helping - Joegen, you made me look closer at the client, at which point I realized I had one that did work, and one that didn't, even though diff-ing their phone's .ini files showed them to be identical apart from their credentials. So then I realized there had to be something different between the two users, not their phone settings.

From: sipx-users-***@list.sipfoundry.org [mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Michael Picher
Sent: November-29-12 2:38 AM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not available

fwiw, i never put servers into branches.

i only use branches to have users prefer particular gateways on dial-out. i don't see that putting a server in a particular branch has any bearing here.

mike

On Thu, Nov 29, 2012 at 12:58 AM, Nicholas Drayer <***@dyrand.com<mailto:***@dyrand.com>> wrote:
At last, I am now able to turn the problem incoming call audio problem on and off repeatably and reliably: it has something to do with XMPP. Below are the repeatable steps. Does anyone have an idea what I should do with this... put in a bug report? I don't want to do that without someone's advice, since it's entirely possible that I'm missing something vital that I don't know about.

Step 1
-------
Create a user that has IM disabled (User list-screen --> click on the User ID --> Instant Messaging --> uncheck Enabled --> OK)
Create a phone profile that has IM disabled (Devices --> click on the Line --> XMPP --> uncheck top two boxes)
Send Profiles
Login Bria
Audio works both ways when dialling in from SIP trunking provider.

Step 2
-------
User list-screen --> click on the User ID --> Instant Messaging --> check Enabled --> Apply
Incoming call from the SIP trunking provider now has no audio either way after being transferred to the Bria client by the IVR

Step 3
-------
User list-screen --> click on the User ID --> Instant Messaging --> uncheck Enabled --> Apply
Logout of Bria
Login to Bria
Audio works both ways when dialling in from SIP trunking provider.

Note A
--------
For Step 2, you do NOT have to logout of Bria. But for Step 3 (making it work properly again) you DO have to logout of and login back with Bria, even thought the profile is not changed whatsoever.

Note B
--------
Turning the Bria phone line XMPP on (Devices --> Phones --> click on Line --> XMPP --> top two checkboxes) makes no difference to the above behaviour, except that it does enable Bria's IM features if the IM is enabled on the user's screen. All IM features work properly.

The MoH issue definitely has something to do with branch settings: I removed the branch from the Server, the Gateway, and the Users (they were all identical, currently the system only has one; so now they are "All") and now it works fine. It's unrelated to the above. If I can replicate it I'll report it too.

Nicholas Drayer, Managing Director
Dyrand Systems Inc.
Tel: [phone] ext. 319<tel:[phone]%20ext.%20319>
email <mailto:***@dyrand.com> | web<http://www.dyrand.com/>
________________________________
From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org>] on behalf of Nicholas Drayer [***@dyrand.com<mailto:***@dyrand.com>]
Sent: November 28, 2012 5:05 PM

To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not available

The MoH issue is related to Bria: I've now figured out that the MoH issue only occurs happens with the Mac OS X Bria client. Same for the hold/resume issue - works properly on Windows, can't resume on Mac. Both exhibit the main problem of no audio in/out for external received calls.

What I find difficult to wrap my head around is that the MoH on the calling external calling line works when the IVR connects and rings a Windows Bria client, but not for a Mac Bria client.

I haven't mentioned this, but calling from extension to extension works fine. None of the extensions are on the sipXecs server's LAN: the server is on AWS EC2, separated by the AWS Security Group from the Internet, the various clients are in their own networks with their own NATted connections to the Internet. It's only when a call comes in via the sipXecs server's 5080 port that the Bria client exhibits no audio sent/received.

Coming to think of it - I'm impressed that calling from a sip client behind NAT to a server behind NAT to another sip client behind NAT actually works :).

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org>] On Behalf Of Nicholas Drayer
Sent: November-28-12 4:11 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not available

Another day and yet a bit closer: the Polycom SoundPoint I managed to provision for this server has no problems whatsoever. MoH, inbound, outbound - all are no problem!
So I think I can only conclude that it is a Bria-specific problem. That's a relief - I think I now can conclude the server I've setup is good. On the other hand, I'm setting this up for 3 users who are mobile and want to use Bria...

Are there any Bria-specific provisioning settings I should look at in sipXecs that may be related to the problem?

Unless anyone reading this has a brilliant idea, I'm going to forward the Bria log to CounterPath, and cross my fingers that they will figure it out...

From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Nicholas Drayer
Sent: November-28-12 11:58 AM
To: Joegen Baclor
Cc: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not available

That all looks good Joegen:
<sip:***@x.x.x.x:39212;rinstance=307688e8aaf12fad;transport=tcp;x-sipX-privcontact=10.128.1.32%3A8180%3Btransport%3Dtcp>
Pretty much the same from all three sites I'm testing from.

From: Joegen Baclor [mailto:***@ezuce.com]
Sent: November-28-12 1:10 AM
To: Nicholas Drayer
Cc: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not available

I was wrong. It's no sipXnonat that you should be looking for but to make sure your registrations has x-sipX-privcontact. Can you verify this for all your NATed registrations?

On 11/28/2012 04:35 PM, Nicholas Drayer wrote:
Thank you Joegen,
Yes, it's registered and sipXnonat is not visible on the registration (on the web portal). And yes, I put the Bria logging on and it receives keep-alive (I think I'm able to make out that is says every 30 seconds). I ran "tcpdump -v host sipx.mydomain.com<http://sipx.mydomain.com>", which is showing the sip keep-alives; exactly every 30 seconds another 5 or-so lines appear (I disabled the XMPP account while running tcpdump).

Some other symptoms:
- outgoing to an external number rings on the calling side, and sound works both ways when picked up; when I put the call on hold, I can resume it. No MoH though. I can also transfer the call just fine to yet another external number.
- incoming external does ring, no MoH or ringing sound (dead silence on the calling end after "Please hold while I transfer your call"). After picking up still no sound either way. When I put the call on hold, I cannot resume, the Bria 'Resume" button does not work -- you have to end the call.

The problem occurs identically on my Mac at home as it does on my Windows 7 box at work in Vancouver, as it does on my colleagues Windows box in Toronto (i.e., three totally different firewalls and two OS's). Therefore I'm a bit hesitant to blame Bria.

I will tomorrow also send Bria a log, and ask for their input. But my gut tells me its something else than their software. I have a spare Polycom at work -- I'll also get that provisioned and working.

Nicholas
________________________________
From: Joegen Baclor [***@ezuce.com<mailto:***@ezuce.com>]
Sent: November 27, 2012 7:26 PM
To: Discussion list for users of sipXecs software
Cc: Nicholas Drayer
Subject: Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not available
Check the registration status of the phone in the admin UI. Is it registered? If so, is it registered as NATed (sipXnonat tag not present in contact)? If it is NATED, can you confirm if OPTIONS keep-alive is received by the phone occasionally if you sniff the packets from the phones network?

On 11/28/2012 09:43 AM, Nicholas Drayer wrote:
Hello,
I've got a test system up, everything works super, except inbound calls: they do go to the IVR, but when I choose an extension, it is always 'not available'. I can leave a voice message, and the extension's user can pick retrieve the voicemail.
I can call out just fine.
I'm using last night's 4.6 (problem has existed since I set the system up about 5 days ago) on RHEL 6.3 - 64 bit.
Maybe related to this is that MoH doesn't seem to work (but I've not looked into that too much: the bridge and the user have it set though).

I'm guessing it's some NAT related issue in conjunction with Blind Forwarding. It's on Amazon AWS, I set the security group to all open I'm not blocking anything incoming or outgoing.

I'm hoping someone can point me to where the look to solve this, I'd be most grateful!

Thanks,
Nicholas


Nicholas Drayer
Managing Director
Dyrand Systems
T. 604.408.4415 Ext. 319<tel:[phone]%20Ext.%20319>
www.dyrand.com<http://www.dyrand.com>




_______________________________________________

sipx-users mailing list

sipx-***@list.sipfoundry.org<mailto:sipx-***@list.sipfoundry.org>

List Archive: http://list.sipfoundry.org/archive/sipx-users/



_______________________________________________
sipx-users mailing list
sipx-***@list.sipfoundry.org<mailto:sipx-***@list.sipfoundry.org>
List Archive: http://list.sipfoundry.org/archive/sipx-users/



--
Michael Picher, Director of Technical Services
eZuce, Inc.

300 Brickstone Square

Suite 201

Andover, MA. 01810
O.978-296-1005 X2015
M.207-956-0262
@mpicher <http://twitter.com/mpicher>
linkedin<http://www.linkedin.com/profile/view?id=35504760&trk=tab_pro>
www.ezuce.com<http://www.ezuce.com>

------------------------------------------------------------------------------------------------------------
There are 10 kinds of people in the world, those who understand binary and those who don't.

[Todd Hodgen]

I'm not sure just how important the Bria Softphone really is. Personally, I
don't use it or recommend it to customer. Many have found their support
lacking, and they don't seem to be Channel friendly.



Have you tried other clients? I've had good results with the 3CX softphone,
and they now have a network components for monitoring their use.



Additionally, eZuce has a product that comes with their licensed product -
openUC. You might want to look at that as well.







From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Nicholas Drayer
Sent: Thursday, November 29, 2012 6:11 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not
available



I put in XX-10547 for the IM-enabled interfering with incoming audio
problem. Seems pretty major to me, making the Bria softphone rather useless.



If I have time I'll see if I can make the MoH issue repeatable this weekend,
and then put an issue in.



Thanks for helping - Joegen, you made me look closer at the client, at which
point I realized I had one that did work, and one that didn't, even though
diff-ing their phone's .ini files showed them to be identical apart from
their credentials. So then I realized there had to be something different
between the two users, not their phone settings.



From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Michael Picher
Sent: November-29-12 2:38 AM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not
available



fwiw, i never put servers into branches.



i only use branches to have users prefer particular gateways on dial-out. i
don't see that putting a server in a particular branch has any bearing here.



mike



On Thu, Nov 29, 2012 at 12:58 AM, Nicholas Drayer
<***@dyrand.com> wrote:

At last, I am now able to turn the problem incoming call audio problem on
and off repeatably and reliably: it has something to do with XMPP. Below are
the repeatable steps. Does anyone have an idea what I should do with this...
put in a bug report? I don't want to do that without someone's advice, since
it's entirely possible that I'm missing something vital that I don't know
about.



Step 1

-------

Create a user that has IM disabled (User list-screen --> click on the User
ID --> Instant Messaging --> uncheck Enabled --> OK)

Create a phone profile that has IM disabled (Devices --> click on the Line
--> XMPP --> uncheck top two boxes)

Send Profiles

Login Bria

Audio works both ways when dialling in from SIP trunking provider.



Step 2

-------

User list-screen --> click on the User ID --> Instant Messaging --> check
Enabled --> Apply

Incoming call from the SIP trunking provider now has no audio either way
after being transferred to the Bria client by the IVR



Step 3

-------

User list-screen --> click on the User ID --> Instant Messaging --> uncheck
Enabled --> Apply

Logout of Bria

Login to Bria

Audio works both ways when dialling in from SIP trunking provider.



Note A

--------

For Step 2, you do NOT have to logout of Bria. But for Step 3 (making it
work properly again) you DO have to logout of and login back with Bria, even
thought the profile is not changed whatsoever.



Note B

--------

Turning the Bria phone line XMPP on (Devices --> Phones --> click on Line
--> XMPP --> top two checkboxes) makes no difference to the above behaviour,
except that it does enable Bria's IM features if the IM is enabled on the
user's screen. All IM features work properly.



The MoH issue definitely has something to do with branch settings: I removed
the branch from the Server, the Gateway, and the Users (they were all
identical, currently the system only has one; so now they are "All") and now
it works fine. It's unrelated to the above. If I can replicate it I'll
report it too.



Nicholas Drayer, Managing Director
Dyrand Systems Inc.
Tel: [phone] ext. 319 <tel:[phone]%20ext.%20319>
<mailto:***@dyrand.com> email | <http://www.dyrand.com/> web

_____

From: sipx-users-***@list.sipfoundry.org
[sipx-users-***@list.sipfoundry.org] on behalf of Nicholas Drayer
[***@dyrand.com]
Sent: November 28, 2012 5:05 PM


To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not
available



The MoH issue is related to Bria: I've now figured out that the MoH issue
only occurs happens with the Mac OS X Bria client. Same for the hold/resume
issue - works properly on Windows, can't resume on Mac. Both exhibit the
main problem of no audio in/out for external received calls.



What I find difficult to wrap my head around is that the MoH on the calling
external calling line works when the IVR connects and rings a Windows Bria
client, but not for a Mac Bria client.



I haven't mentioned this, but calling from extension to extension works
fine. None of the extensions are on the sipXecs server's LAN: the server is
on AWS EC2, separated by the AWS Security Group from the Internet, the
various clients are in their own networks with their own NATted connections
to the Internet. It's only when a call comes in via the sipXecs server's
5080 port that the Bria client exhibits no audio sent/received.



Coming to think of it - I'm impressed that calling from a sip client behind
NAT to a server behind NAT to another sip client behind NAT actually works
J.



From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Nicholas Drayer
Sent: November-28-12 4:11 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not
available



Another day and yet a bit closer: the Polycom SoundPoint I managed to
provision for this server has no problems whatsoever. MoH, inbound, outbound
- all are no problem!

So I think I can only conclude that it is a Bria-specific problem. That's a
relief - I think I now can conclude the server I've setup is good. On the
other hand, I'm setting this up for 3 users who are mobile and want to use
Bria.



Are there any Bria-specific provisioning settings I should look at in
sipXecs that may be related to the problem?



Unless anyone reading this has a brilliant idea, I'm going to forward the
Bria log to CounterPath, and cross my fingers that they will figure it out.



From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Nicholas Drayer
Sent: November-28-12 11:58 AM
To: Joegen Baclor
Cc: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not
available



That all looks good Joegen:

<sip:***@x.x.x.x:39212;rinstance=307688e8aaf12fad;transport=tcp;x-sipX-privc
ontact=10.128.1.32%3A8180%3Btransport%3Dtcp>

Pretty much the same from all three sites I'm testing from.



From: Joegen Baclor [mailto:***@ezuce.com]
Sent: November-28-12 1:10 AM
To: Nicholas Drayer
Cc: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not
available



I was wrong. It's no sipXnonat that you should be looking for but to make
sure your registrations has x-sipX-privcontact. Can you verify this for all
your NATed registrations?

On 11/28/2012 04:35 PM, Nicholas Drayer wrote:

Thank you Joegen,

Yes, it's registered and sipXnonat is not visible on the registration (on
the web portal). And yes, I put the Bria logging on and it receives
keep-alive (I think I'm able to make out that is says every 30 seconds). I
ran "tcpdump -v host sipx.mydomain.com", which is showing the sip
keep-alives; exactly every 30 seconds another 5 or-so lines appear (I
disabled the XMPP account while running tcpdump).



Some other symptoms:

- outgoing to an external number rings on the calling side, and sound works
both ways when picked up; when I put the call on hold, I can resume it. No
MoH though. I can also transfer the call just fine to yet another external
number.

- incoming external does ring, no MoH or ringing sound (dead silence on the
calling end after "Please hold while I transfer your call"). After picking
up still no sound either way. When I put the call on hold, I cannot resume,
the Bria 'Resume" button does not work -- you have to end the call.



The problem occurs identically on my Mac at home as it does on my Windows 7
box at work in Vancouver, as it does on my colleagues Windows box in Toronto
(i.e., three totally different firewalls and two OS's). Therefore I'm a bit
hesitant to blame Bria.



I will tomorrow also send Bria a log, and ask for their input. But my gut
tells me its something else than their software. I have a spare Polycom at
work -- I'll also get that provisioned and working.



Nicholas


_____


From: Joegen Baclor [***@ezuce.com]
Sent: November 27, 2012 7:26 PM
To: Discussion list for users of sipXecs software
Cc: Nicholas Drayer
Subject: Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not
available

Check the registration status of the phone in the admin UI. Is it
registered? If so, is it registered as NATed (sipXnonat tag not present in
contact)? If it is NATED, can you confirm if OPTIONS keep-alive is
received by the phone occasionally if you sniff the packets from the phones
network?

On 11/28/2012 09:43 AM, Nicholas Drayer wrote:

Hello,

I've got a test system up, everything works super, except inbound calls:
they do go to the IVR, but when I choose an extension, it is always 'not
available'. I can leave a voice message, and the extension's user can pick
retrieve the voicemail.

I can call out just fine.

I'm using last night's 4.6 (problem has existed since I set the system up
about 5 days ago) on RHEL 6.3 - 64 bit.

Maybe related to this is that MoH doesn't seem to work (but I've not looked
into that too much: the bridge and the user have it set though).



I'm guessing it's some NAT related issue in conjunction with Blind
Forwarding. It's on Amazon AWS, I set the security group to all open I'm not
blocking anything incoming or outgoing.



I'm hoping someone can point me to where the look to solve this, I'd be most
grateful!



Thanks,

Nicholas





Nicholas Drayer

Managing Director

Dyrand Systems

T. 604.408.4415 Ext. 319 <tel:[phone]%20Ext.%20319>

www.dyrand.com







_______________________________________________
sipx-users mailing list
sipx-***@list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipx-users/






_______________________________________________
sipx-users mailing list
sipx-***@list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipx-users/







--
Michael Picher, Director of Technical Services
eZuce, Inc.

300 Brickstone Square

Suite 201

Andover, MA. 01810

O.978-296-1005 X2015
M.207-956-0262
@mpicher <http://twitter.com/mpicher>

linkedin <http://www.linkedin.com/profile/view?id=35504760&trk=tab_pro>
www.ezuce.com



----------------------------------------------------------------------------
--------------------------------

There are 10 kinds of people in the world, those who understand binary and
those who don't.

[Michael Picher]

We don't have a licensed softphone that comes with our product (yet). We
have Unite which is an Instant Messaging client / phone companion. No
media services (voice/video)... yet....

Thanks,
Mike


On Thu, Nov 29, 2012 at 9:19 PM, Todd Hodgen <***@frontier.com> wrote:

> I’m not sure just how important the Bria Softphone really is. Personally,
> I don’t use it or recommend it to customer. Many have found their support
> lacking, and they don’t seem to be Channel friendly. ****
>
> ** **
>
> Have you tried other clients? I’ve had good results with the 3CX
> softphone, and they now have a network components for monitoring their use.
> ****
>
> ** **
>
> Additionally, eZuce has a product that comes with their licensed product –
> openUC. You might want to look at that as well.****
>
> ** **
>
> ** **
>
> ** **
>
> *From:* sipx-users-***@list.sipfoundry.org [mailto:
> sipx-users-***@list.sipfoundry.org] *On Behalf Of *Nicholas Drayer
> *Sent:* Thursday, November 29, 2012 6:11 PM
>
> *To:* Discussion list for users of sipXecs software
> *Subject:* Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not
> available****
>
> ** **
>
> I put in XX-10547 for the IM-enabled interfering with incoming audio
> problem. Seems pretty major to me, making the Bria softphone rather useless.
> ****
>
> ** **
>
> If I have time I’ll see if I can make the MoH issue repeatable this
> weekend, and then put an issue in.****
>
> ** **
>
> Thanks for helping – Joegen, you made me look closer at the client, at
> which point I realized I had one that did work, and one that didn’t, even
> though diff-ing their phone’s .ini files showed them to be identical apart
> from their credentials. So then I realized there had to be something
> different between the two users, not their phone settings.****
>
> ** **
>
> *From:* sipx-users-***@list.sipfoundry.org [
> mailto:sipx-users-***@list.sipfoundry.org<sipx-users-***@list.sipfoundry.org>]
> *On Behalf Of *Michael Picher
> *Sent:* November-29-12 2:38 AM
> *To:* Discussion list for users of sipXecs software
> *Subject:* Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not
> available****
>
> ** **
>
> fwiw, i never put servers into branches.****
>
> ** **
>
> i only use branches to have users prefer particular gateways on dial-out.
> i don't see that putting a server in a particular branch has any bearing
> here.****
>
> ** **
>
> mike****
>
> ** **
>
> On Thu, Nov 29, 2012 at 12:58 AM, Nicholas Drayer <
> ***@dyrand.com> wrote:****
>
> At last, I am now able to turn the problem incoming call audio problem on
> and off repeatably and reliably: it has something to do with XMPP. Below
> are the repeatable steps. Does anyone have an idea what I should do with
> this... put in a bug report? I don't want to do that without someone's
> advice, since it's entirely possible that I'm missing something vital that
> I don't know about. ****
>
> ** **
>
> Step 1****
>
> -------****
>
> Create a user that has IM disabled (User list-screen --> click on the User
> ID --> Instant Messaging --> uncheck Enabled --> OK)****
>
> Create a phone profile that has IM disabled (Devices --> click on the Line
> --> XMPP --> uncheck top two boxes)****
>
> Send Profiles****
>
> Login Bria****
>
> Audio works both ways when dialling in from SIP trunking provider.****
>
> ** **
>
> Step 2****
>
> -------****
>
> User list-screen --> click on the User ID --> Instant Messaging --> check
> Enabled --> Apply****
>
> Incoming call from the SIP trunking provider now has no audio either way
> after being transferred to the Bria client by the IVR****
>
> ** **
>
> Step 3****
>
> -------****
>
> User list-screen --> click on the User ID --> Instant Messaging -->
> uncheck Enabled --> Apply****
>
> Logout of Bria****
>
> Login to Bria****
>
> Audio works both ways when dialling in from SIP trunking provider.****
>
> ** **
>
> Note A****
>
> --------****
>
> For Step 2, you do NOT have to logout of Bria. But for Step 3 (making it
> work properly again) you DO have to logout of and login back with Bria,
> even thought the profile is not changed whatsoever.****
>
> ** **
>
> Note B****
>
> --------****
>
> Turning the Bria phone line XMPP on (Devices --> Phones --> click on Line
> --> XMPP --> top two checkboxes) makes no difference to the above
> behaviour, except that it does enable Bria's IM features if the IM is
> enabled on the user's screen. All IM features work properly.****
>
> ** **
>
> The MoH issue definitely has something to do with branch settings: I
> removed the branch from the Server, the Gateway, and the Users (they were
> all identical, currently the system only has one; so now they are "All")
> and now it works fine. It's unrelated to the above. If I can replicate it
> I'll report it too.****
>
> ** **
>
> Nicholas Drayer, Managing Director
> Dyrand Systems Inc.
> Tel: [phone] ext. 319
> email <***@dyrand.com>| web <http://www.dyrand.com/>****
> ------------------------------
>
> *From:* sipx-users-***@list.sipfoundry.org [
> sipx-users-***@list.sipfoundry.org] on behalf of Nicholas Drayer [
> ***@dyrand.com]
> *Sent:* November 28, 2012 5:05 PM****
>
>
> *To:* Discussion list for users of sipXecs software
> *Subject:* Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not
> available****
>
> ** **
>
> The MoH issue is related to Bria: I’ve now figured out that the MoH issue
> only occurs happens with the Mac OS X Bria client. Same for the hold/resume
> issue – works properly on Windows, can’t resume on Mac. Both exhibit the
> main problem of no audio in/out for external received calls.****
>
> ****
>
> What I find difficult to wrap my head around is that the MoH on the
> calling external calling line works when the IVR connects and rings a
> Windows Bria client, but not for a Mac Bria client.****
>
> ****
>
> I haven’t mentioned this, but calling from extension to extension works
> fine. None of the extensions are on the sipXecs server’s LAN: the server is
> on AWS EC2, separated by the AWS Security Group from the Internet, the
> various clients are in their own networks with their own NATted connections
> to the Internet. It’s only when a call comes in via the sipXecs server’s
> 5080 port that the Bria client exhibits no audio sent/received.****
>
> ****
>
> Coming to think of it – I’m impressed that calling from a sip client
> behind NAT to a server behind NAT to another sip client behind NAT actually
> works J.****
>
> ****
>
> *From:* sipx-users-***@list.sipfoundry.org [mailto:
> sipx-users-***@list.sipfoundry.org] *On Behalf Of *Nicholas Drayer
> *Sent:* November-28-12 4:11 PM
> *To:* Discussion list for users of sipXecs software
> *Subject:* Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not
> available****
>
> ****
>
> Another day and yet a bit closer: the Polycom SoundPoint I managed to
> provision for this server has no problems whatsoever. MoH, inbound,
> outbound – all are no problem!****
>
> So I think I can only conclude that it is a Bria-specific problem. That’s
> a relief – I think I now can conclude the server I’ve setup is good. On the
> other hand, I’m setting this up for 3 users who are mobile and want to use
> Bria…****
>
> ****
>
> Are there any Bria-specific provisioning settings I should look at in
> sipXecs that may be related to the problem?****
>
> ****
>
> Unless anyone reading this has a brilliant idea, I’m going to forward the
> Bria log to CounterPath, and cross my fingers that they will figure it out…
> ****
>
> ****
>
> *From:* sipx-users-***@list.sipfoundry.org [
> mailto:sipx-users-***@list.sipfoundry.org<sipx-users-***@list.sipfoundry.org>]
> *On Behalf Of *Nicholas Drayer
> *Sent:* November-28-12 11:58 AM
> *To:* Joegen Baclor
> *Cc:* Discussion list for users of sipXecs software
> *Subject:* Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not
> available****
>
> ****
>
> That all looks good Joegen:****
>
> <
> sip:***@x.x.x.x:39212;rinstance=307688e8aaf12fad;transport=tcp;x-sipX-privcontact=10.128.1.32%3A8180%3Btransport%3Dtcp
> >****
>
> Pretty much the same from all three sites I’m testing from.****
>
> ****
>
> *From:* Joegen Baclor [mailto:***@ezuce.com <***@ezuce.com>]
> *Sent:* November-28-12 1:10 AM
> *To:* Nicholas Drayer
> *Cc:* Discussion list for users of sipXecs software
> *Subject:* Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not
> available****
>
> ****
>
> I was wrong. It's no sipXnonat that you should be looking for but to make
> sure your registrations has x-sipX-privcontact. Can you verify this for
> all your NATed registrations?
>
> On 11/28/2012 04:35 PM, Nicholas Drayer wrote:****
>
> Thank you Joegen, ****
>
> Yes, it's registered and sipXnonat is not visible on the registration (on
> the web portal). And yes, I put the Bria logging on and it receives
> keep-alive (I think I'm able to make out that is says every 30 seconds). I
> ran "tcpdump -v host sipx.mydomain.com", which is showing the sip
> keep-alives; exactly every 30 seconds another 5 or-so lines appear (I
> disabled the XMPP account while running tcpdump).****
>
> ****
>
> Some other symptoms:****
>
> - outgoing to an external number rings on the calling side, and sound
> works both ways when picked up; when I put the call on hold, I can resume
> it. No MoH though. I can also transfer the call just fine to yet another
> external number.****
>
> - incoming external does ring, no MoH or ringing sound (dead silence on
> the calling end after "Please hold while I transfer your call"). After
> picking up still no sound either way. When I put the call on hold, I cannot
> resume, the Bria 'Resume" button does not work -- you have to end the call.
> ****
>
> ****
>
> The problem occurs identically on my Mac at home as it does on my Windows
> 7 box at work in Vancouver, as it does on my colleagues Windows box in
> Toronto (i.e., three totally different firewalls and two OS's). Therefore
> I'm a bit hesitant to blame Bria.****
>
> ****
>
> I will tomorrow also send Bria a log, and ask for their input. But my gut
> tells me its something else than their software. I have a spare Polycom at
> work -- I'll also get that provisioned and working.****
>
> ****
>
> Nicholas****
> ------------------------------
>
> *From:* Joegen Baclor [***@ezuce.com]
> *Sent:* November 27, 2012 7:26 PM
> *To:* Discussion list for users of sipXecs software
> *Cc:* Nicholas Drayer
> *Subject:* Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not
> available****
>
> Check the registration status of the phone in the admin UI. Is it
> registered? If so, is it registered as NATed (sipXnonat tag not present
> in contact)? If it is NATED, can you confirm if OPTIONS keep-alive is
> received by the phone occasionally if you sniff the packets from the phones
> network?
>
> On 11/28/2012 09:43 AM, Nicholas Drayer wrote:****
>
> Hello,****
>
> I’ve got a test system up, everything works super, except inbound calls:
> they do go to the IVR, but when I choose an extension, it is always ‘not
> available’. I can leave a voice message, and the extension’s user can pick
> retrieve the voicemail.****
>
> I can call out just fine.****
>
> I’m using last night’s 4.6 (problem has existed since I set the system up
> about 5 days ago) on RHEL 6.3 - 64 bit.****
>
> Maybe related to this is that MoH doesn’t seem to work (but I’ve not
> looked into that too much: the bridge and the user have it set though).***
> *
>
> ****
>
> I’m guessing it’s some NAT related issue in conjunction with Blind
> Forwarding. It’s on Amazon AWS, I set the security group to all open I’m
> not blocking anything incoming or outgoing.****
>
> ****
>
> I’m hoping someone can point me to where the look to solve this, I’d be
> most grateful!****
>
> ****
>
> Thanks,****
>
> Nicholas****
>
> ****
>
> ****
>
> Nicholas Drayer****
>
> Managing Director****
>
> Dyrand Systems****
>
> T. 604.408.4415 Ext. 319****
>
> www.dyrand.com****
>
> ****
>
> ****
>
> ****
>
> _______________________________________________****
>
> sipx-users mailing list****
>
> sipx-***@list.sipfoundry.org****
>
> List Archive: http://list.sipfoundry.org/archive/sipx-users/****
>
> ****
>
> ****
>
>
> _______________________________________________
> sipx-users mailing list
> sipx-***@list.sipfoundry.org
> List Archive: http://list.sipfoundry.org/archive/sipx-users/****
>
>
>
> ****
>
> ** **
>
> --
> Michael Picher, Director of Technical Services
> eZuce, Inc.****
>
> 300 Brickstone Square****
>
> Suite 201****
>
> Andover, MA. 01810****
>
> O.978-296-1005 X2015
> M.207-956-0262
> @mpicher <http://twitter.com/mpicher> ****
>
> linkedin <http://www.linkedin.com/profile/view?id=35504760&trk=tab_pro>
> www.ezuce.com****
>
> ** **
>
>
> ------------------------------------------------------------------------------------------------------------
> ****
>
> There are 10 kinds of people in the world, those who understand binary and
> those who don't.****
>
> ** **
>
> _______________________________________________
> sipx-users mailing list
> sipx-***@list.sipfoundry.org
> List Archive: http://list.sipfoundry.org/archive/sipx-users/
>



--
Michael Picher, Director of Technical Services
eZuce, Inc.

300 Brickstone Square****

Suite 201****

Andover, MA. 01810
O.978-296-1005 X2015
M.207-956-0262
@mpicher <http://twitter.com/mpicher>
linkedin <http://www.linkedin.com/profile/view?id=35504760&trk=tab_pro>
www.ezuce.com

------------------------------------------------------------------------------------------------------------
"The best way to predict the future is to invent it." - Alan Kay

[Todd Hodgen]

Oops, guess I overstated.



From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Michael Picher
Sent: Friday, November 30, 2012 1:58 AM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not
available



We don't have a licensed softphone that comes with our product (yet). We
have Unite which is an Instant Messaging client / phone companion. No media
services (voice/video)... yet....



Thanks,

Mike



On Thu, Nov 29, 2012 at 9:19 PM, Todd Hodgen <***@frontier.com> wrote:

I'm not sure just how important the Bria Softphone really is. Personally, I
don't use it or recommend it to customer. Many have found their support
lacking, and they don't seem to be Channel friendly.



Have you tried other clients? I've had good results with the 3CX softphone,
and they now have a network components for monitoring their use.



Additionally, eZuce has a product that comes with their licensed product -
openUC. You might want to look at that as well.







From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Nicholas Drayer
Sent: Thursday, November 29, 2012 6:11 PM


To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not
available



I put in XX-10547 for the IM-enabled interfering with incoming audio
problem. Seems pretty major to me, making the Bria softphone rather useless.



If I have time I'll see if I can make the MoH issue repeatable this weekend,
and then put an issue in.



Thanks for helping - Joegen, you made me look closer at the client, at which
point I realized I had one that did work, and one that didn't, even though
diff-ing their phone's .ini files showed them to be identical apart from
their credentials. So then I realized there had to be something different
between the two users, not their phone settings.



From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Michael Picher
Sent: November-29-12 2:38 AM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not
available



fwiw, i never put servers into branches.



i only use branches to have users prefer particular gateways on dial-out. i
don't see that putting a server in a particular branch has any bearing here.



mike



On Thu, Nov 29, 2012 at 12:58 AM, Nicholas Drayer
<***@dyrand.com> wrote:

At last, I am now able to turn the problem incoming call audio problem on
and off repeatably and reliably: it has something to do with XMPP. Below are
the repeatable steps. Does anyone have an idea what I should do with this...
put in a bug report? I don't want to do that without someone's advice, since
it's entirely possible that I'm missing something vital that I don't know
about.



Step 1

-------

Create a user that has IM disabled (User list-screen --> click on the User
ID --> Instant Messaging --> uncheck Enabled --> OK)

Create a phone profile that has IM disabled (Devices --> click on the Line
--> XMPP --> uncheck top two boxes)

Send Profiles

Login Bria

Audio works both ways when dialling in from SIP trunking provider.



Step 2

-------

User list-screen --> click on the User ID --> Instant Messaging --> check
Enabled --> Apply

Incoming call from the SIP trunking provider now has no audio either way
after being transferred to the Bria client by the IVR



Step 3

-------

User list-screen --> click on the User ID --> Instant Messaging --> uncheck
Enabled --> Apply

Logout of Bria

Login to Bria

Audio works both ways when dialling in from SIP trunking provider.



Note A

--------

For Step 2, you do NOT have to logout of Bria. But for Step 3 (making it
work properly again) you DO have to logout of and login back with Bria, even
thought the profile is not changed whatsoever.



Note B

--------

Turning the Bria phone line XMPP on (Devices --> Phones --> click on Line
--> XMPP --> top two checkboxes) makes no difference to the above behaviour,
except that it does enable Bria's IM features if the IM is enabled on the
user's screen. All IM features work properly.



The MoH issue definitely has something to do with branch settings: I removed
the branch from the Server, the Gateway, and the Users (they were all
identical, currently the system only has one; so now they are "All") and now
it works fine. It's unrelated to the above. If I can replicate it I'll
report it too.



Nicholas Drayer, Managing Director
Dyrand Systems Inc.
Tel: [phone] ext. 319 <tel:[phone]%20ext.%20319>
<mailto:***@dyrand.com> email | <http://www.dyrand.com/> web

_____

From: sipx-users-***@list.sipfoundry.org
[sipx-users-***@list.sipfoundry.org] on behalf of Nicholas Drayer
[***@dyrand.com]
Sent: November 28, 2012 5:05 PM


To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not
available



The MoH issue is related to Bria: I've now figured out that the MoH issue
only occurs happens with the Mac OS X Bria client. Same for the hold/resume
issue - works properly on Windows, can't resume on Mac. Both exhibit the
main problem of no audio in/out for external received calls.



What I find difficult to wrap my head around is that the MoH on the calling
external calling line works when the IVR connects and rings a Windows Bria
client, but not for a Mac Bria client.



I haven't mentioned this, but calling from extension to extension works
fine. None of the extensions are on the sipXecs server's LAN: the server is
on AWS EC2, separated by the AWS Security Group from the Internet, the
various clients are in their own networks with their own NATted connections
to the Internet. It's only when a call comes in via the sipXecs server's
5080 port that the Bria client exhibits no audio sent/received.



Coming to think of it - I'm impressed that calling from a sip client behind
NAT to a server behind NAT to another sip client behind NAT actually works
J.



From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Nicholas Drayer
Sent: November-28-12 4:11 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not
available



Another day and yet a bit closer: the Polycom SoundPoint I managed to
provision for this server has no problems whatsoever. MoH, inbound, outbound
- all are no problem!

So I think I can only conclude that it is a Bria-specific problem. That's a
relief - I think I now can conclude the server I've setup is good. On the
other hand, I'm setting this up for 3 users who are mobile and want to use
Bria.



Are there any Bria-specific provisioning settings I should look at in
sipXecs that may be related to the problem?



Unless anyone reading this has a brilliant idea, I'm going to forward the
Bria log to CounterPath, and cross my fingers that they will figure it out.



From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Nicholas Drayer
Sent: November-28-12 11:58 AM
To: Joegen Baclor
Cc: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not
available



That all looks good Joegen:

<sip:***@x.x.x.x:39212;rinstance=307688e8aaf12fad;transport=tcp;x-sipX-privc
ontact=10.128.1.32%3A8180%3Btransport%3Dtcp>

Pretty much the same from all three sites I'm testing from.



From: Joegen Baclor [mailto:***@ezuce.com]
Sent: November-28-12 1:10 AM
To: Nicholas Drayer
Cc: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not
available



I was wrong. It's no sipXnonat that you should be looking for but to make
sure your registrations has x-sipX-privcontact. Can you verify this for all
your NATed registrations?

On 11/28/2012 04:35 PM, Nicholas Drayer wrote:

Thank you Joegen,

Yes, it's registered and sipXnonat is not visible on the registration (on
the web portal). And yes, I put the Bria logging on and it receives
keep-alive (I think I'm able to make out that is says every 30 seconds). I
ran "tcpdump -v host sipx.mydomain.com", which is showing the sip
keep-alives; exactly every 30 seconds another 5 or-so lines appear (I
disabled the XMPP account while running tcpdump).



Some other symptoms:

- outgoing to an external number rings on the calling side, and sound works
both ways when picked up; when I put the call on hold, I can resume it. No
MoH though. I can also transfer the call just fine to yet another external
number.

- incoming external does ring, no MoH or ringing sound (dead silence on the
calling end after "Please hold while I transfer your call"). After picking
up still no sound either way. When I put the call on hold, I cannot resume,
the Bria 'Resume" button does not work -- you have to end the call.



The problem occurs identically on my Mac at home as it does on my Windows 7
box at work in Vancouver, as it does on my colleagues Windows box in Toronto
(i.e., three totally different firewalls and two OS's). Therefore I'm a bit
hesitant to blame Bria.



I will tomorrow also send Bria a log, and ask for their input. But my gut
tells me its something else than their software. I have a spare Polycom at
work -- I'll also get that provisioned and working.



Nicholas


_____


From: Joegen Baclor [***@ezuce.com]
Sent: November 27, 2012 7:26 PM
To: Discussion list for users of sipXecs software
Cc: Nicholas Drayer
Subject: Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not
available

Check the registration status of the phone in the admin UI. Is it
registered? If so, is it registered as NATed (sipXnonat tag not present in
contact)? If it is NATED, can you confirm if OPTIONS keep-alive is
received by the phone occasionally if you sniff the packets from the phones
network?

On 11/28/2012 09:43 AM, Nicholas Drayer wrote:

Hello,

I've got a test system up, everything works super, except inbound calls:
they do go to the IVR, but when I choose an extension, it is always 'not
available'. I can leave a voice message, and the extension's user can pick
retrieve the voicemail.

I can call out just fine.

I'm using last night's 4.6 (problem has existed since I set the system up
about 5 days ago) on RHEL 6.3 - 64 bit.

Maybe related to this is that MoH doesn't seem to work (but I've not looked
into that too much: the bridge and the user have it set though).



I'm guessing it's some NAT related issue in conjunction with Blind
Forwarding. It's on Amazon AWS, I set the security group to all open I'm not
blocking anything incoming or outgoing.



I'm hoping someone can point me to where the look to solve this, I'd be most
grateful!



Thanks,

Nicholas





Nicholas Drayer

Managing Director

Dyrand Systems

T. 604.408.4415 Ext. 319 <tel:[phone]%20Ext.%20319>

www.dyrand.com







_______________________________________________
sipx-users mailing list
sipx-***@list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipx-users/






_______________________________________________
sipx-users mailing list
sipx-***@list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipx-users/







--
Michael Picher, Director of Technical Services
eZuce, Inc.

300 Brickstone Square

Suite 201

Andover, MA. 01810

O.978-296-1005 X2015 <tel:[phone]%20X2015>
M.207-956-0262
@mpicher <http://twitter.com/mpicher>

linkedin <http://www.linkedin.com/profile/view?id=35504760&trk=tab_pro>
www.ezuce.com



----------------------------------------------------------------------------
--------------------------------

There are 10 kinds of people in the world, those who understand binary and
those who don't.




_______________________________________________
sipx-users mailing list
sipx-***@list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipx-users/







--
Michael Picher, Director of Technical Services
eZuce, Inc.

300 Brickstone Square

Suite 201

Andover, MA. 01810

O.978-296-1005 X2015
M.207-956-0262
@mpicher <http://twitter.com/mpicher>

linkedin <http://www.linkedin.com/profile/view?id=35504760&trk=tab_pro>
www.ezuce.com



----------------------------------------------------------------------------
--------------------------------

"The best way to predict the future is to invent it." - Alan Kay

[Trevor L Benson]

Nicholas,

This has been on my mind a little over the past few days, was this just a typo from the 4.4 configuration for ITSP's using 5080 inbound, or is the ITSP still sending to you on 5080? We tested out inbound on 5060 (albeit weeks ago and many updates) and it was working fine. I am guessing its a typo, or you configured your system properly to still use 5080, but it's sticking in my craw that maybe this isn't a typo or the ITSP is sending to the wrong port?

I have not tested the 5080 inbound on openUC 4.6 instead of 5060. Checking Devices -> SIP Trunk SBCs shows that sipXbridge-1 has port 5080 listed. Features -> NAT Traversal under Server Config shows the private IP, public IP, and 5060 for SIP port and 5061 for TLS SIP port. It could very well work that 5080 inbound from ITSP's still functions as it did in 4.4 and I think I remember someone saying you could use either or both? However I haven't bothered to test it yet since I was ecstatic to get native 5060 for some picky providers and since that appeared to be working over a month ago in our tests I just wanted to ask if the calls were really sent to 5080 or 5060?

Trevor

On Nov 28, 2012, at 5:05 PM, Nicholas Drayer <***@dyrand.com> wrote:

> It’s only when a call comes in via the sipXecs server’s 5080 port that the Bria client exhibits no audio sent/received.

[Michael Picher]

you'll find you have transfer issues and whatnot with port 5060... it is
not the right port. 5080 is where sipXbridge is listening on. this is not
a typo. the proxy listens on port 5080.

mike


On Fri, Nov 30, 2012 at 4:21 PM, Trevor L Benson <***@a-1networks.com>wrote:

> Nicholas,
>
> This has been on my mind a little over the past few days, was this just
> a typo from the 4.4 configuration for ITSP's using 5080 inbound, or is the
> ITSP still sending to you on 5080? We tested out inbound on 5060 (albeit
> weeks ago and many updates) and it was working fine. I am guessing its a
> typo, or you configured your system properly to still use 5080, but it's
> sticking in my craw that maybe this isn't a typo or the ITSP is sending to
> the wrong port?
>
> I have not tested the 5080 inbound on openUC 4.6 instead of 5060.
> Checking Devices -> SIP Trunk SBCs shows that sipXbridge-1 has port 5080
> listed. Features -> NAT Traversal under Server Config shows the private
> IP, public IP, and 5060 for SIP port and 5061 for TLS SIP port. It could
> very well work that 5080 inbound from ITSP's still functions as it did in
> 4.4 and I think I remember someone saying you could use either or both?
> However I haven't bothered to test it yet since I was ecstatic to get
> native 5060 for some picky providers and since that appeared to be working
> over a month ago in our tests I just wanted to ask if the calls were really
> sent to 5080 or 5060?
>
> Trevor
>
> On Nov 28, 2012, at 5:05 PM, Nicholas Drayer <***@dyrand.com>
> wrote:
>
> It’s only when a call comes in via the sipXecs server’s 5080 port that the
> Bria client exhibits no audio sent/received.
>
>
>
> _______________________________________________
> sipx-users mailing list
> sipx-***@list.sipfoundry.org
> List Archive: http://list.sipfoundry.org/archive/sipx-users/
>



--
Michael Picher, Director of Technical Services
eZuce, Inc.

300 Brickstone Square****

Suite 201****

Andover, MA. 01810
O.978-296-1005 X2015
M.207-956-0262
@mpicher <http://twitter.com/mpicher>
linkedin <http://www.linkedin.com/profile/view?id=35504760&trk=tab_pro>
www.ezuce.com

------------------------------------------------------------------------------------------------------------
"The best way to predict the future is to invent it." - Alan Kay

[Michael Picher]

doh... the proxy listens on 5060


On Fri, Nov 30, 2012 at 5:49 PM, Michael Picher <***@ezuce.com> wrote:

> you'll find you have transfer issues and whatnot with port 5060... it is
> not the right port. 5080 is where sipXbridge is listening on. this is not
> a typo. the proxy listens on port 5080.
>
> mike
>
>
> On Fri, Nov 30, 2012 at 4:21 PM, Trevor L Benson <***@a-1networks.com>wrote:
>
>> Nicholas,
>>
>> This has been on my mind a little over the past few days, was this just
>> a typo from the 4.4 configuration for ITSP's using 5080 inbound, or is the
>> ITSP still sending to you on 5080? We tested out inbound on 5060 (albeit
>> weeks ago and many updates) and it was working fine. I am guessing its a
>> typo, or you configured your system properly to still use 5080, but it's
>> sticking in my craw that maybe this isn't a typo or the ITSP is sending to
>> the wrong port?
>>
>> I have not tested the 5080 inbound on openUC 4.6 instead of 5060.
>> Checking Devices -> SIP Trunk SBCs shows that sipXbridge-1 has port 5080
>> listed. Features -> NAT Traversal under Server Config shows the private
>> IP, public IP, and 5060 for SIP port and 5061 for TLS SIP port. It could
>> very well work that 5080 inbound from ITSP's still functions as it did in
>> 4.4 and I think I remember someone saying you could use either or both?
>> However I haven't bothered to test it yet since I was ecstatic to get
>> native 5060 for some picky providers and since that appeared to be working
>> over a month ago in our tests I just wanted to ask if the calls were really
>> sent to 5080 or 5060?
>>
>> Trevor
>>
>> On Nov 28, 2012, at 5:05 PM, Nicholas Drayer <***@dyrand.com>
>> wrote:
>>
>> It’s only when a call comes in via the sipXecs server’s 5080 port that
>> the Bria client exhibits no audio sent/received.
>>
>>
>>
>> _______________________________________________
>> sipx-users mailing list
>> sipx-***@list.sipfoundry.org
>> List Archive: http://list.sipfoundry.org/archive/sipx-users/
>>
>
>
>
> --
> Michael Picher, Director of Technical Services
> eZuce, Inc.
>
> 300 Brickstone Square****
>
> Suite 201****
>
> Andover, MA. 01810
> O.978-296-1005 X2015
> M.207-956-0262
> @mpicher <http://twitter.com/mpicher>
> linkedin <http://www.linkedin.com/profile/view?id=35504760&trk=tab_pro>
> www.ezuce.com
>
>
> ------------------------------------------------------------------------------------------------------------
> "The best way to predict the future is to invent it." - Alan Kay
>
>


--
Michael Picher, Director of Technical Services
eZuce, Inc.

300 Brickstone Square****

Suite 201****

Andover, MA. 01810
O.978-296-1005 X2015
M.207-956-0262
@mpicher <http://twitter.com/mpicher>
linkedin <http://www.linkedin.com/profile/view?id=35504760&trk=tab_pro>
www.ezuce.com

------------------------------------------------------------------------------------------------------------
"The best way to predict the future is to invent it." - Alan Kay

[Nicholas Drayer]

Yes, just to confirm, it's 100% 5080 that I'm using. I use IP authentication for the SIP trunk, with incoming calls going to ***@pbx.domain.com:5080.

________________________________
From: sipx-users-***@list.sipfoundry.org [sipx-users-***@list.sipfoundry.org] on behalf of Michael Picher [***@ezuce.com]
Sent: November 30, 2012 2:49 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not available

you'll find you have transfer issues and whatnot with port 5060... it is not the right port. 5080 is where sipXbridge is listening on. this is not a typo. the proxy listens on port 5080.

mike


On Fri, Nov 30, 2012 at 4:21 PM, Trevor L Benson <***@a-1networks.com<mailto:***@a-1networks.com>> wrote:
Nicholas,

This has been on my mind a little over the past few days, was this just a typo from the 4.4 configuration for ITSP's using 5080 inbound, or is the ITSP still sending to you on 5080? We tested out inbound on 5060 (albeit weeks ago and many updates) and it was working fine. I am guessing its a typo, or you configured your system properly to still use 5080, but it's sticking in my craw that maybe this isn't a typo or the ITSP is sending to the wrong port?

I have not tested the 5080 inbound on openUC 4.6 instead of 5060. Checking Devices -> SIP Trunk SBCs shows that sipXbridge-1 has port 5080 listed. Features -> NAT Traversal under Server Config shows the private IP, public IP, and 5060 for SIP port and 5061 for TLS SIP port. It could very well work that 5080 inbound from ITSP's still functions as it did in 4.4 and I think I remember someone saying you could use either or both? However I haven't bothered to test it yet since I was ecstatic to get native 5060 for some picky providers and since that appeared to be working over a month ago in our tests I just wanted to ask if the calls were really sent to 5080 or 5060?

Trevor

On Nov 28, 2012, at 5:05 PM, Nicholas Drayer <***@dyrand.com<mailto:***@dyrand.com>> wrote:

It’s only when a call comes in via the sipXecs server’s 5080 port that the Bria client exhibits no audio sent/received.


_______________________________________________
sipx-users mailing list
sipx-***@list.sipfoundry.org<mailto:sipx-***@list.sipfoundry.org>
List Archive: http://list.sipfoundry.org/archive/sipx-users/



--
Michael Picher, Director of Technical Services
eZuce, Inc.

300 Brickstone Square

Suite 201

Andover, MA. 01810

O.978-296-1005 X2015
M.207-956-0262
@mpicher <http://twitter.com/mpicher>
linkedin<http://www.linkedin.com/profile/view?id=35504760&trk=tab_pro>
www.ezuce.com<http://www.ezuce.com>

------------------------------------------------------------------------------------------------------------
"The best way to predict the future is to invent it." - Alan Kay

[Trevor L Benson]

The provider I have tied into my 4.6 system is specifically because they refuse to redirect inbound to anything but 5060. So I would have to URI dial and rely on SRV to test, and then still tcpdump to verify it was happening as your configuration is currently. In Mikes follow up email he clarified Proxy was working externally on 5060, maybe just give it a test and see if there is any difference.

At this point I have to admit I think I am confusing the actual problem with the Subject of the original thread. Is the problem extension not available, or did I just zone out this has been a MoH issue the whole time since its the Bria components?

In any case if proxy is on 5060, I would potentially test inbound signaling to 5060 from your provider. If I get time to upgrade my 4.4 server this weekend now that we finished our basic testing for contact center I should be able to use Bandwidth.com and simulate your environment on port 5080 and compare to normal 5060 through my alternate provider.

Were you using strictly desktop Bria versions, or were any iPhone/iPad/Android versions being tested as well?

Thanks,
Trevor Benson, Network Engineer
A1 Networks
Voice: 707-703-1041

For support issues please email ***@a-1networks.com or call 707-703-1050





On Nov 30, 2012, at 4:45 PM, Nicholas Drayer <***@dyrand.com> wrote:

> Yes, just to confirm, it's 100% 5080 that I'm using. I use IP authentication for the SIP trunk, with incoming calls going to ***@pbx.domain.com:5080.
>
> From: sipx-users-***@list.sipfoundry.org [sipx-users-***@list.sipfoundry.org] on behalf of Michael Picher [***@ezuce.com]
> Sent: November 30, 2012 2:49 PM
> To: Discussion list for users of sipXecs software
> Subject: Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not available
>
> you'll find you have transfer issues and whatnot with port 5060... it is not the right port. 5080 is where sipXbridge is listening on. this is not a typo. the proxy listens on port 5080.
>
> mike
>
>
> On Fri, Nov 30, 2012 at 4:21 PM, Trevor L Benson <***@a-1networks.com> wrote:
> Nicholas,
>
> This has been on my mind a little over the past few days, was this just a typo from the 4.4 configuration for ITSP's using 5080 inbound, or is the ITSP still sending to you on 5080? We tested out inbound on 5060 (albeit weeks ago and many updates) and it was working fine. I am guessing its a typo, or you configured your system properly to still use 5080, but it's sticking in my craw that maybe this isn't a typo or the ITSP is sending to the wrong port?
>
> I have not tested the 5080 inbound on openUC 4.6 instead of 5060. Checking Devices -> SIP Trunk SBCs shows that sipXbridge-1 has port 5080 listed. Features -> NAT Traversal under Server Config shows the private IP, public IP, and 5060 for SIP port and 5061 for TLS SIP port. It could very well work that 5080 inbound from ITSP's still functions as it did in 4.4 and I think I remember someone saying you could use either or both? However I haven't bothered to test it yet since I was ecstatic to get native 5060 for some picky providers and since that appeared to be working over a month ago in our tests I just wanted to ask if the calls were really sent to 5080 or 5060?
>
> Trevor
>
> On Nov 28, 2012, at 5:05 PM, Nicholas Drayer <***@dyrand.com> wrote:
>
>> It’s only when a call comes in via the sipXecs server’s 5080 port that the Bria client exhibits no audio sent/received.
>
>
> _______________________________________________
> sipx-users mailing list
> sipx-***@list.sipfoundry.org
> List Archive: http://list.sipfoundry.org/archive/sipx-users/
>
>
>
> --
> Michael Picher, Director of Technical Services
> eZuce, Inc.
> 300 Brickstone Square
> Suite 201
> Andover, MA. 01810
> O.978-296-1005 X2015
> M.207-956-0262
> @mpicher <http://twitter.com/mpicher>
> linkedin
> www.ezuce.com
>
> ------------------------------------------------------------------------------------------------------------
> "The best way to predict the future is to invent it." - Alan Kay
>
> _______________________________________________
> sipx-users mailing list
> sipx-***@list.sipfoundry.org
> List Archive: http://list.sipfoundry.org/archive/sipx-users/

[Nicholas Drayer]

No Trevor: the MoH is a different issue, once I changed the Server, the Gateway, and the User to have no branch (aka all branches), that problem went away. I still think there's an issue there, but MoH is definitely a different issue.

The actual problem is that under the following conditions audio is not received or sent either way:
- An incoming call from the outside (i.e. to provider --> sipXecs over port 5080 --> IVR --> extension with Bria softphone)
- A Bria softphone
- The User has their setting for IM enabled.

These conditions are very precise:
- a call from one extension to another works fine;
- an outgoing call works fine;
- substituting the Bria phone with a SoundPoint desktop works fine -- toggling the IM setting for the user makes no difference to the SoundPoint;
- it doesn't matter whether or not the Bria phone settings are provisioned for XMPP or not, it's merely the User IM setting that's important;
- the ini file generated by sipXecs for the Bria is identical whether or not the IM setting for the User is enabled;

I would surmise that port 5080 is working fine -- the Bria does ring, you can answer the call and the other side sees that you answered. You can hang up. It's the audio that is missing. In this particular situation the RTP is nog going either way.

I put an issue in: xx-10547. Hopefully I'm explaining the issue clearly enough. I've tested it on two separate setups of sipXecs 4.6 over two weeks, with identical repeatable results.


________________________________
From: sipx-users-***@list.sipfoundry.org [sipx-users-***@list.sipfoundry.org] on behalf of Trevor L Benson [***@a-1networks.com]
Sent: November 30, 2012 6:23 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not available

The provider I have tied into my 4.6 system is specifically because they refuse to redirect inbound to anything but 5060. So I would have to URI dial and rely on SRV to test, and then still tcpdump to verify it was happening as your configuration is currently. In Mikes follow up email he clarified Proxy was working externally on 5060, maybe just give it a test and see if there is any difference.

At this point I have to admit I think I am confusing the actual problem with the Subject of the original thread. Is the problem extension not available, or did I just zone out this has been a MoH issue the whole time since its the Bria components?

In any case if proxy is on 5060, I would potentially test inbound signaling to 5060 from your provider. If I get time to upgrade my 4.4 server this weekend now that we finished our basic testing for contact center I should be able to use Bandwidth.com<http://Bandwidth.com> and simulate your environment on port 5080 and compare to normal 5060 through my alternate provider.

Were you using strictly desktop Bria versions, or were any iPhone/iPad/Android versions being tested as well?

Thanks,
Trevor Benson, Network Engineer
A1 Networks
Voice: 707-703-1041

For support issues please email ***@a-1networks.com<mailto:***@a-1networks.com> or call 707-703-1050





On Nov 30, 2012, at 4:45 PM, Nicholas Drayer <***@dyrand.com<mailto:***@dyrand.com>> wrote:

Yes, just to confirm, it's 100% 5080 that I'm using. I use IP authentication for the SIP trunk, with incoming calls going to ***@pbx.domain.com<mailto:***@pbx.domain.com>:5080.

________________________________
From: sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org> [sipx-users-***@list.sipfoundry.org<mailto:sipx-users-***@list.sipfoundry.org>] on behalf of Michael Picher [***@ezuce.com<mailto:***@ezuce.com>]
Sent: November 30, 2012 2:49 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not available

you'll find you have transfer issues and whatnot with port 5060... it is not the right port. 5080 is where sipXbridge is listening on. this is not a typo. the proxy listens on port 5080.

mike


On Fri, Nov 30, 2012 at 4:21 PM, Trevor L Benson <***@a-1networks.com<mailto:***@a-1networks.com>> wrote:
Nicholas,

This has been on my mind a little over the past few days, was this just a typo from the 4.4 configuration for ITSP's using 5080 inbound, or is the ITSP still sending to you on 5080? We tested out inbound on 5060 (albeit weeks ago and many updates) and it was working fine. I am guessing its a typo, or you configured your system properly to still use 5080, but it's sticking in my craw that maybe this isn't a typo or the ITSP is sending to the wrong port?

I have not tested the 5080 inbound on openUC 4.6 instead of 5060. Checking Devices -> SIP Trunk SBCs shows that sipXbridge-1 has port 5080 listed. Features -> NAT Traversal under Server Config shows the private IP, public IP, and 5060 for SIP port and 5061 for TLS SIP port. It could very well work that 5080 inbound from ITSP's still functions as it did in 4.4 and I think I remember someone saying you could use either or both? However I haven't bothered to test it yet since I was ecstatic to get native 5060 for some picky providers and since that appeared to be working over a month ago in our tests I just wanted to ask if the calls were really sent to 5080 or 5060?

Trevor

On Nov 28, 2012, at 5:05 PM, Nicholas Drayer <***@dyrand.com<mailto:***@dyrand.com>> wrote:

It’s only when a call comes in via the sipXecs server’s 5080 port that the Bria client exhibits no audio sent/received.


_______________________________________________
sipx-users mailing list
sipx-***@list.sipfoundry.org<mailto:sipx-***@list.sipfoundry.org>
List Archive: http://list.sipfoundry.org/archive/sipx-users/



--
Michael Picher, Director of Technical Services
eZuce, Inc.
300 Brickstone Square
Suite 201
Andover, MA. 01810
O.978-296-1005 X2015
M.207-956-0262
@mpicher <http://twitter.com/mpicher>
linkedin<http://www.linkedin.com/profile/view?id=35504760&trk=tab_pro>
www.ezuce.com<http://www.ezuce.com>

------------------------------------------------------------------------------------------------------------
"The best way to predict the future is to invent it." - Alan Kay

[Todd Hodgen]

Nicholas - Your details are pretty extensive here, so I may be pointing out
the obvious - but have you confirmed what ports the RTP is using, and if it
is configured in the router to be passed. Not always, but many times I
find RTP issues are generally related to ports configuration (or not) in the
routers, SIP ALG's, etc.



From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Nicholas Drayer
Sent: Sunday, December 02, 2012 9:54 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not
available



No Trevor: the MoH is a different issue, once I changed the Server, the
Gateway, and the User to have no branch (aka all branches), that problem
went away. I still think there's an issue there, but MoH is definitely a
different issue.



The actual problem is that under the following conditions audio is not
received or sent either way:

- An incoming call from the outside (i.e. to provider --> sipXecs over port
5080 --> IVR --> extension with Bria softphone)

- A Bria softphone

- The User has their setting for IM enabled.



These conditions are very precise:

- a call from one extension to another works fine;

- an outgoing call works fine;

- substituting the Bria phone with a SoundPoint desktop works fine --
toggling the IM setting for the user makes no difference to the SoundPoint;

- it doesn't matter whether or not the Bria phone settings are provisioned
for XMPP or not, it's merely the User IM setting that's important;

- the ini file generated by sipXecs for the Bria is identical whether or not
the IM setting for the User is enabled;



I would surmise that port 5080 is working fine -- the Bria does ring, you
can answer the call and the other side sees that you answered. You can hang
up. It's the audio that is missing. In this particular situation the RTP is
nog going either way.



I put an issue in: xx-10547. Hopefully I'm explaining the issue clearly
enough. I've tested it on two separate setups of sipXecs 4.6 over two weeks,
with identical repeatable results.





_____

From: sipx-users-***@list.sipfoundry.org
[sipx-users-***@list.sipfoundry.org] on behalf of Trevor L Benson
[***@a-1networks.com]
Sent: November 30, 2012 6:23 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not
available

The provider I have tied into my 4.6 system is specifically because they
refuse to redirect inbound to anything but 5060. So I would have to URI
dial and rely on SRV to test, and then still tcpdump to verify it was
happening as your configuration is currently. In Mikes follow up email he
clarified Proxy was working externally on 5060, maybe just give it a test
and see if there is any difference.



At this point I have to admit I think I am confusing the actual problem with
the Subject of the original thread. Is the problem extension not available,
or did I just zone out this has been a MoH issue the whole time since its
the Bria components?



In any case if proxy is on 5060, I would potentially test inbound signaling
to 5060 from your provider. If I get time to upgrade my 4.4 server this
weekend now that we finished our basic testing for contact center I should
be able to use Bandwidth.com and simulate your environment on port 5080 and
compare to normal 5060 through my alternate provider.



Were you using strictly desktop Bria versions, or were any
iPhone/iPad/Android versions being tested as well?



Thanks,

Trevor Benson, Network Engineer

A1 Networks

Voice: 707-703-1041



For support issues please email ***@a-1networks.com or call 707-703-1050









On Nov 30, 2012, at 4:45 PM, Nicholas Drayer <***@dyrand.com>
wrote:





Yes, just to confirm, it's 100% 5080 that I'm using. I use IP authentication
for the SIP trunk, with incoming calls going to ***@pbx.domain.com:5080.



_____

From: sipx-users-***@list.sipfoundry.org
[sipx-users-***@list.sipfoundry.org] on behalf of Michael Picher
[***@ezuce.com]
Sent: November 30, 2012 2:49 PM
To: Discussion list for users of sipXecs software
Subject: Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not
available

you'll find you have transfer issues and whatnot with port 5060... it is
not the right port. 5080 is where sipXbridge is listening on. this is not
a typo. the proxy listens on port 5080.



mike



On Fri, Nov 30, 2012 at 4:21 PM, Trevor L Benson <***@a-1networks.com>
wrote:

Nicholas,



This has been on my mind a little over the past few days, was this just a
typo from the 4.4 configuration for ITSP's using 5080 inbound, or is the
ITSP still sending to you on 5080? We tested out inbound on 5060 (albeit
weeks ago and many updates) and it was working fine. I am guessing its a
typo, or you configured your system properly to still use 5080, but it's
sticking in my craw that maybe this isn't a typo or the ITSP is sending to
the wrong port?



I have not tested the 5080 inbound on openUC 4.6 instead of 5060.
Checking Devices -> SIP Trunk SBCs shows that sipXbridge-1 has port 5080
listed. Features -> NAT Traversal under Server Config shows the private IP,
public IP, and 5060 for SIP port and 5061 for TLS SIP port. It could very
well work that 5080 inbound from ITSP's still functions as it did in 4.4 and
I think I remember someone saying you could use either or both? However I
haven't bothered to test it yet since I was ecstatic to get native 5060 for
some picky providers and since that appeared to be working over a month ago
in our tests I just wanted to ask if the calls were really sent to 5080 or
5060?



Trevor



On Nov 28, 2012, at 5:05 PM, Nicholas Drayer <***@dyrand.com>
wrote:





It's only when a call comes in via the sipXecs server's 5080 port that the
Bria client exhibits no audio sent/received.




_______________________________________________
sipx-users mailing list
sipx-***@list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipx-users/







--
Michael Picher, Director of Technical Services
eZuce, Inc.

300 Brickstone Square

Suite 201

Andover, MA. 01810

O.978-296-1005 X2015
M.207-956-0262
@mpicher <http://twitter.com/mpicher>

linkedin <http://www.linkedin.com/profile/view?id=35504760&trk=tab_pro>
www.ezuce.com



----------------------------------------------------------------------------
--------------------------------

"The best way to predict the future is to invent it." - Alan Kay

[Tony Graziano]

IF the Bria user is remote, be aware if the user is behind a firewall with
a SIP ALG, this can happen. We use teleworker appliances and dont have
these issues (smart auto IPSEC VPN in a tiny box). I've never found
Counterpath to be consistent enough (build to build) to use.

What you have is an audio RTP issue. Something is in the way. If the user
(bria) is local can you provide a siptrace or pcap?

On Mon, Dec 3, 2012 at 12:54 AM, Nicholas Drayer
<***@dyrand.com>wrote:

> No Trevor: the MoH is a different issue, once I changed the Server, the
> Gateway, and the User to have no branch (aka all branches), that problem
> went away. I still think there's an issue there, but MoH is definitely a
> different issue.
>
> The actual problem is that under the following conditions audio is not
> received or sent either way:
> - An incoming call from the outside (i.e. to provider --> sipXecs over
> port 5080 --> IVR --> extension with Bria softphone)
> - A Bria softphone
> - The User has their setting for IM enabled.
>
> These conditions are very precise:
> - a call from one extension to another works fine;
> - an outgoing call works fine;
> - substituting the Bria phone with a SoundPoint desktop works fine --
> toggling the IM setting for the user makes no difference to the SoundPoint;
> - it doesn't matter whether or not the Bria phone settings are provisioned
> for XMPP or not, it's merely the User IM setting that's important;
> - the ini file generated by sipXecs for the Bria is identical whether or
> not the IM setting for the User is enabled;
>
> I would surmise that port 5080 is working fine -- the Bria does ring,
> you can answer the call and the other side sees that you answered. You can
> hang up. It's the audio that is missing. In this particular situation the
> RTP is nog going either way.
>
> I put an issue in: xx-10547. Hopefully I'm explaining the issue clearly
> enough. I've tested it on two separate setups of sipXecs 4.6 over two
> weeks, with identical repeatable results.
>
>
> ------------------------------
> *From:* sipx-users-***@list.sipfoundry.org [
> sipx-users-***@list.sipfoundry.org] on behalf of Trevor L Benson [
> ***@a-1networks.com]
> *Sent:* November 30, 2012 6:23 PM
>
> *To:* Discussion list for users of sipXecs software
> *Subject:* Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not
> available
>
> The provider I have tied into my 4.6 system is specifically because they
> refuse to redirect inbound to anything but 5060. So I would have to URI
> dial and rely on SRV to test, and then still tcpdump to verify it was
> happening as your configuration is currently. In Mikes follow up email he
> clarified Proxy was working externally on 5060, maybe just give it a test
> and see if there is any difference.
>
> At this point I have to admit I think I am confusing the actual problem
> with the Subject of the original thread. Is the problem extension not
> available, or did I just zone out this has been a MoH issue the whole time
> since its the Bria components?
>
> In any case if proxy is on 5060, I would potentially test inbound
> signaling to 5060 from your provider. If I get time to upgrade my 4.4
> server this weekend now that we finished our basic testing for contact
> center I should be able to use Bandwidth.com and simulate your
> environment on port 5080 and compare to normal 5060 through my alternate
> provider.
>
> Were you using strictly desktop Bria versions, or were any
> iPhone/iPad/Android versions being tested as well?
>
> Thanks,
> Trevor Benson, Network Engineer
> A1 Networks
> Voice: 707-703-1041
>
> For support issues please email ***@a-1networks.com or call
> 707-703-1050
>
>
>
>
>
> On Nov 30, 2012, at 4:45 PM, Nicholas Drayer <***@dyrand.com>
> wrote:
>
> Yes, just to confirm, it's 100% 5080 that I'm using. I use IP
> authentication for the SIP trunk, with incoming calls going to
> ***@pbx.domain.com:5080.
>
> ------------------------------
> *From:* sipx-users-***@list.sipfoundry.org [
> sipx-users-***@list.sipfoundry.org] on behalf of Michael Picher [
> ***@ezuce.com]
> *Sent:* November 30, 2012 2:49 PM
> *To:* Discussion list for users of sipXecs software
> *Subject:* Re: [sipx-users] sipx 4.6 inbound ivr-->extension always not
> available
>
> you'll find you have transfer issues and whatnot with port 5060... it
> is not the right port. 5080 is where sipXbridge is listening on. this is
> not a typo. the proxy listens on port 5080.
>
> mike
>
>
> On Fri, Nov 30, 2012 at 4:21 PM, Trevor L Benson <***@a-1networks.com>
> wrote:
>
>> Nicholas,
>>
>> This has been on my mind a little over the past few days, was this
>> just a typo from the 4.4 configuration for ITSP's using 5080 inbound, or is
>> the ITSP still sending to you on 5080? We tested out inbound on 5060
>> (albeit weeks ago and many updates) and it was working fine. I am guessing
>> its a typo, or you configured your system properly to still use 5080, but
>> it's sticking in my craw that maybe this isn't a typo or the ITSP is
>> sending to the wrong port?
>>
>> I have not tested the 5080 inbound on openUC 4.6 instead of 5060.
>> Checking Devices -> SIP Trunk SBCs shows that sipXbridge-1 has port 5080
>> listed. Features -> NAT Traversal under Server Config shows the private
>> IP, public IP, and 5060 for SIP port and 5061 for TLS SIP port. It could
>> very well work that 5080 inbound from ITSP's still functions as it did in
>> 4.4 and I think I remember someone saying you could use either or both?
>> However I haven't bothered to test it yet since I was ecstatic to get
>> native 5060 for some picky providers and since that appeared to be working
>> over a month ago in our tests I just wanted to ask if the calls were really
>> sent to 5080 or 5060?
>>
>> Trevor
>>
>> On Nov 28, 2012, at 5:05 PM, Nicholas Drayer <***@dyrand.com>
>> wrote:
>>
>> It’s only when a call comes in via the sipXecs server’s 5080 port that
>> the Bria client exhibits no audio sent/received.
>>
>>
>>
>> _______________________________________________
>> sipx-users mailing list
>> sipx-***@list.sipfoundry.org
>> List Archive: http://list.sipfoundry.org/archive/sipx-users/
>>
>
>
>
> --
> Michael Picher, Director of Technical Services
> eZuce, Inc.
> 300 Brickstone Square****
> Suite 201****
> Andover, MA. 01810
> O.978-296-1005 X2015
> M.207-956-0262
> @mpicher <http://twitter.com/mpicher>
> linkedin <http://www.linkedin.com/profile/view?id=35504760&trk=tab_pro>
> www.ezuce.com
>
>
> ------------------------------------------------------------------------------------------------------------
> "The best way to predict the future is to invent it." - Alan Kay
>
> _______________________________________________
> sipx-users mailing list
> sipx-***@list.sipfoundry.org
> List Archive: http://list.sipfoundry.org/archive/sipx-users/
>
>
>
> _______________________________________________
> sipx-users mailing list
> sipx-***@list.sipfoundry.org
> List Archive: http://list.sipfoundry.org/archive/sipx-users/
>



--
~~~~~~~~~~~~~~~~~~
Tony Graziano, Manager
Telephone: [phone]
sip: ***@voice.myitdepartment.net
Fax: [phone]
~~~~~~~~~~~~~~~~~~
Linked-In Profile:
http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4
Ask about our Internet Fax services!
~~~~~~~~~~~~~~~~~~

Using or developing for sipXecs from SIPFoundry? Ask me about sipX-CoLab
2013!
<http://sipxcolab2013.eventbrite.com/?discount=tony2013>

--
LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: [phone]
sip: ***@voice.myitdepartment.net

Helpdesk Customers: http://myhelp.myitdepartment.net
Blog: http://blog.myitdepartment.net