News:

On Tuesday September 6th the forum will be down for maintenance from 9:30 PM to 11:59 PM PDT

Main Menu

Can't register IP Phone through OBi200 Proxy after upgrade to 5898EX

Started by CloudTalkGuy, July 26, 2018, 01:59:58 PM

Previous topic - Next topic

CloudTalkGuy

Hi all,

Hope somebody can shed some light on this...

When the OBi200 was on 5757EX, proxying SIP through it was working fine.  After upgrade due to the GV protocol upgrade, we can no longer register our SIP phone through the same config.  Syslog of the SIP traffic shows error 401-Unauthorized now.  Everything checks out, the auth username and password.

Did OBi remove the ability to proxy a SIP connection through the device???

We have even gone so far as to clear the entire config and start over from scratch just configuring as follows:

Polycom VVX Phone = 192.168.2.42
OBi200 = 192.168.2.41

ITSP-D/General/SignalingProtocol=SIP
VoiceServices/SP4 Service/X_ServProvProfile=D
VoiceServices/SP4 Service/X_RegisterEnable=unchecked
VoiceServices/SP4 Service/X_UserAgentPort=5063
VoiceServices/SP4 Service/X_SipDebugOption=Log All Messages
VoiceServices/SP4 Service/AuthUserName=testsip
VoiceServices/SP4 Service/AuthPassword=****
VoiceServices/SP4 Service/URI=testsip@192.168.2.41 (this was also tried as blank)

Here is the dump from syslog:


<7> RxFrom:c0a8022a:5060
   192.168.2.41   26/07 13:32:41.551   
<7> REGISTER sip:192.168.2.41:5063 SIP/2.0
Via: SIP/2.0/UDP 192.168.2.42;branch=z9hG4bKb4f7602867FE67AB
From: "Test SIP" <sip:testsip@192.168.2.41:5063>;tag=66D5D066-AAFB2DD9
To: <sip:testsip@192.168.2.41:5063>
CSeq: 1 REGISTER
Call-ID:    192.168.2.41   26/07 13:32:41.553   
<7> sendto c0a8022a:5060(500)
   192.168.2.41   26/07 13:32:41.556   
<7> SIP/2.0 401 Unauthorized
Call-ID: 30f8f60bf7febe5d73c572359264baa6
CSeq: 1 REGISTER
Content-Length: 0
From: "Test SIP" <sip:testsip@192.168.2.41:5063>;tag=66D5D066-AAFB2DD9
To: <sip:testsip@192.168.2.41:5063>
Via: SIP/2.0/UDP 192.16   192.168.2.41   26/07 13:32:41.559   
<7> RxFrom:c0a8022a:5060
   192.168.2.41   26/07 13:32:41.568   
<7> REGISTER sip:192.168.2.41:5063 SIP/2.0
Via: SIP/2.0/UDP 192.168.2.42;branch=z9hG4bK672ad461E1231B9
From: "Test SIP" <sip:testsip@192.168.2.41:5063>;tag=66D5D066-AAFB2DD9
To: <sip:testsip@192.168.2.41:5063>
CSeq: 2 REGISTER
Call-ID: 3   192.168.2.41   26/07 13:32:41.586   
<7> sendto c0a8022a:5060(499)
   192.168.2.41   26/07 13:32:41.587   
<7> SIP/2.0 401 Unauthorized
Call-ID: 30f8f60bf7febe5d73c572359264baa6
CSeq: 2 REGISTER
Content-Length: 0
From: "Test SIP" <sip:testsip@192.168.2.41:5063>;tag=66D5D066-AAFB2DD9
To: <sip:testsip@192.168.2.41:5063>
Via: SIP/2.0/UDP 192.16   192.168.2.41   26/07 13:32:41.588   
<7> RxFrom:c0a8022a:5060
   192.168.2.41   26/07 13:32:41.589   
<7> REGISTER sip:192.168.2.41:5063 SIP/2.0
Via: SIP/2.0/UDP 192.168.2.42;branch=z9hG4bKca8b7bc4D005C827
From: "Test SIP" <sip:testsip@192.168.2.41:5063>;tag=66D5D066-AAFB2DD9
To: <sip:testsip@192.168.2.41:5063>
CSeq: 3 REGISTER
Call-ID:    192.168.2.41   26/07 13:32:41.590   
<7> sendto c0a8022a:5060(500)
   192.168.2.41   26/07 13:32:41.591   
<7> SIP/2.0 401 Unauthorized
Call-ID: 30f8f60bf7febe5d73c572359264baa6
CSeq: 3 REGISTER
Content-Length: 0
From: "Test SIP" <sip:testsip@192.168.2.41:5063>;tag=66D5D066-AAFB2DD9
To: <sip:testsip@192.168.2.41:5063>
Via: SIP/2.0/UDP 192.16   192.168.2.41   26/07 13:32:41.591   
<7> RxFrom:c0a8022a:5060
   192.168.2.41   26/07 13:32:41.606   
<7> REGISTER sip:192.168.2.41:5063 SIP/2.0
Via: SIP/2.0/UDP 192.168.2.42;branch=z9hG4bK3a0ab9a2E2DD88F5
From: "Test SIP" <sip:testsip@192.168.2.41:5063>;tag=66D5D066-AAFB2DD9
To: <sip:testsip@192.168.2.41:5063>
CSeq: 4 REGISTER
Call-ID:    192.168.2.41   26/07 13:32:41.628   
<7> sendto c0a8022a:5060(500)
   192.168.2.41   26/07 13:32:41.629   
<7> SIP/2.0 401 Unauthorized
Call-ID: 30f8f60bf7febe5d73c572359264baa6
CSeq: 4 REGISTER
Content-Length: 0
From: "Test SIP" <sip:testsip@192.168.2.41:5063>;tag=66D5D066-AAFB2DD9
To: <sip:testsip@192.168.2.41:5063>
Via: SIP/2.0/UDP 192.16   192.168.2.41   26/07 13:32:41.631   

drgeoff

That's a known bug/feature.

Can your IP phone call without being registered?

http://www.obitalk.com/forum/index.php?topic=14515.msg92425#msg92425

CloudTalkGuy

Thanks!  Not registering did the trick.  I also had to wipe the Obi and redo the config from scratch online to re-register with GV.  Was having one-way audio.

Now I have one more issue... DTMF.  I can't seem to push any buttons on the Polycom IP phone when dialing.  Looking at the logs, I see the Polycom trying to send DTMF inband.  But the Obi isn't listening and ignores all the button presses.

Is there something I should be doing?

5898EX software as before.

Thanks!
Chris

drgeoff

Quote from: CloudTalkGuy on July 27, 2018, 12:08:08 PM

Now I have one more issue... DTMF.  I can't seem to push any buttons on the Polycom IP phone when dialing.  Looking at the logs, I see the Polycom trying to send DTMF inband.  But the Obi isn't listening and ignores all the button presses.

Is there something I should be doing?

5898EX software as before.

Thanks!
Chris
An IP phone never uses DTMF when dialling. DTMF tones go over the voice channel once it is established, ie while the call is in progress. Before that there is only the digital SIP signalling channel.

CloudTalkGuy

My apologies.  I mean the button presses.  I know they can go RFC2833 or SIP INFO.  But it can also go In-Band.  What I was suggesting is that while I'm in a call, the Obi device isn't picking up button presses on the call.  On the Polycom, I can see them being sent using InBand.  When I dial a live person, they can hear the DTMF sound, pretty loud too.  But when I call an IVR from my SIP phone through GV, I can never seem to get the other end to recognize any button presses.

Any help?

Chris

drgeoff

Quote from: CloudTalkGuy on July 27, 2018, 04:16:23 PM
My apologies.  I mean the button presses.  I know they can go RFC2833 or SIP INFO.  But it can also go In-Band.  What I was suggesting is that while I'm in a call, the Obi device isn't picking up button presses on the call.  On the Polycom, I can see them being sent using InBand.  When I dial a live person, they can hear the DTMF sound, pretty loud too.  But when I call an IVR from my SIP phone through GV, I can never seem to get the other end to recognize any button presses.

Any help?

Chris
Why would the OBi pick up the button presses?  It isn't going to do anything with them.  The Inband DTMF is just part of the digitised voice signal from the IP phone that is passing through the OBi on its way to GV and thence to the IVR on the called number.

Does your IP phone have any options for adjusting the duration of the tones and/or their amplitude?

SteveInWA

This appears to be a very old issue with some Polycom phones.  Take this with a shaker of salt, since the linked post is from nearly seven years ago, but if you search on "Polycom VVX DTMF" you'll see more links.

https://community.polycom.com/t5/VoIP-SIP-Phones/FAQ-Phone-unable-to-send-DTMF-to-an-IVR-system-or-how-to/td-p/4237

CloudTalkGuy

I think I'm not being clear enough...

The Polycom VVX worked when the software on the OBi200 was 5757EX.  After upgrading to 5898EX, the SP4 which I used for the SIP proxy stopped listening for DTMF signals (whether inband or out-of-band).  Was wondering if this had to do with the registration bug?  When I dump the logs on both devices, I see the Polycom still sending out the tones (and people on the other end hear it) using the same SP4->GV (SP1) proxy.  But when dumping the logs on the OBi200, I don't see the tones being picked up by the SP4 on the syslog.  Is there something I am missing to dump recognized DTMF signals on the syslog of the OBi200?

CloudTalkGuy

Thanks SteveinWA!  Your solution was the answer.  I set the RFC2833 to "101" per the old Polycom info you sent and it works again.

Cheers!