Problem with connecting IPphone to OBi110

[drgeoff]

In my opinion Obihai never intended for people to use direct ip addressing for calling.  I don't believe it is part of their software regression testing, the admin manuals don't discuss it.

I don't know Obihai's intention, nor their testing, but IP addressing for calling is in the admin manual. http://www.obihai.com/OBiDeviceAdminGuide#_Toc367543138

(It's the last part of the manual before the specifications.  hwittenb must have thrown in the towel and quit reading before reaching it.    ) 

[azrobert]

I'm not familiar with that type of trace, but I don't see any entries for the IP Phone.

Log into the OBi200 and click Status then Call Status while you have a call in session.
You will be able to see if the RTP packets are being sent.
I suspect you won't see RTP packets flowing between the IP Phone and the OBi200.

You can check the connection between the OBi200 and OBi110 by defining a speed dial on the OBi200 like this: sp1(Phone_Number@192.168.1.101;ui=obi200)
Now dial the speed dial number from a phone attached to the OBi200.

[Siteweb65]

OBi200 status whilst call in place

Call 1	Terminal 1	Terminal 2
Terminal ID	SP1	SP1
State	connected	connected
Peer Name	obi200
Peer Number	obi200	3103@192.168.1.101:5060
Start Time	20:21:25	20:21:25
Duration	00:00:17	00:00:17
Direction	Inbound	Outbound
Peer RTP Address	192.168.1.100:5018	192.168.1.101:17612
Local RTP Address	192.168.1.102:16608	192.168.1.102:16610
RTP Transport	UDP	UDP
Audio Codec	tx=G711U; rx=G711A (bridged)	tx=G711U; rx=G711A (bridged)
RTP Packetization (ms)	tx=20; rx=20 (bridged)	tx=20; rx=20 (bridged)
RTP Packet Count	tx=877; rx=874	tx=874; rx=876
RTP Byte Count	tx=150844; rx=150328	tx=150328; rx=150672

and heres the same for the OBi110 (using a different call)

Call 1	Terminal 1	Terminal 2
Terminal ID	SP1	LINE1
State	connected	connected
Peer Name	obi200
Peer Number	obi200	3103
Start Time	20:40:25	20:40:25
Duration	00:00:21	00:00:21
Direction	Inbound	Outbound
Peer RTP Address	192.168.1.102:16614
Local RTP Address	192.168.1.101:17614
RTP Transport	UDP
Audio Codec	tx=G711A; rx=G711U
RTP Packetization (ms)	tx=20; rx=20
RTP Packet Count	tx=1058; rx=1056
RTP Byte Count	tx=181976; rx=181632

there are more lines in the tabele but most of the values are 0 except
Packets in jitter buffer  9
Jitter buffer length  190ms
Recieved interarrival jitter 4 ms


>One other note, the DX800 phone audio codec lists as "G.711a law" and "G.711u law"  not sure if that makes a difference ?

[azrobert]

This is what I would expect to see if the call had audio. When I have had audio problems the RTP packet counts were zero.

Do calls work from the OBi110? Just dial 3103 from a phone connected to the OBi110.

G711 is fine. I don't know why it's using G711U on the transmit and G711A on the receive.

[Siteweb65]

mmm, OK

I dont have a phone to hand that has the connector required to plug straight in to the Obi's, I'll find one tomorrow and test it out again directly ... thanks to you both for your continuing help, I'm learning all the time :-)

[NoelB]

G711 is fine. I don't know why it's using G711U on the transmit and G711A on the receive.

This will result in one way audio since the receive port is trying to decode G711A using a G711U algorithm presuming tx/rx use the same port. I have experienced this and needed to get rid of the G711A codec from all my codec lists in order to get 2 way audio.

[hwittenb]

Siteweb65,

When you setup the logging you might have missed step 3 in the OBi instructions.  You need to go to the SPx and also enable logging there.  The trace does not show the Sip INVITE and subsequent messages for the call.

[hwittenb]

In my opinion Obihai never intended for people to use direct ip addressing for calling.  I don't believe it is part of their software regression testing, the admin manuals don't discuss it.

I don't know Obihai's intention, nor their testing, but IP addressing for calling is in the admin manual. http://www.obihai.com/OBiDeviceAdminGuide#_Toc367543138

(It's the last part of the manual before the specifications.  hwittenb must have thrown in the towel and quit reading before reaching it.    ) 

Here is what drgeoff referenced as IP addressing for calling is in the admin manual:
A User Defined Digit Map For IPv4 Dialing
The default values of the parameters for User Defined Digit Map 1 are set the following values to support IPv4 Dialing:

-          Label: ipd

-          Digit Map: (xx.<*:@>xx?x?<*:.>xx?x?<*:.>xx?x?<*:.>xx?x?|

xx.<*:@>xx?x?<*:.>xx?x?<*:.>xx?x?<*:.>xx?x?<*::>xx?x?x?x?)

The map (Mipd) is referenced in the default setting of the DigitMap in ITSP Profile A and B. It supports the following two forms of IPv4 dialing:

a)       <user-id>*<a>*<b>*<c>*<d>

b)       <user-id>*<a>*<b>*<c>*<d>*<port>

where <user-id> is an arbitrary length numeric user-id, such as 100345, <port> is a port number in the range 0–65535, and each of <a>,<b>,<c>,<d> is a 1-3 digit pattern in the range 1–255 that identifies one byte of an IP address. The dialed number will be translated into <user-id>@<a>.<b>.<c>.<d> and <user-id>@<a>.<b>.<c>.<d>:<port> respectively. Here are some examples:

                1234*192*168*15*113                    maps to 1234@192.168.15.113

                123456*192*168*15*180*5061   maps to 123456@192.168.15.180:5061
[/i]
I would not call that discussing the making and receiving calls via direct ip dialing. That seems like useless information to me.

H

[Siteweb65]

hi All

NoelB hit the nail on the head with the mixed codecs, I limited the DX800 codec to use just the G771U and all is working :-)

Thank you everyone for your great support

[drgeoff]

I would not call that discussing the making and receiving calls via direct ip dialing. That seems like useless information to me.

1.  Your original comment and my rebuttal was only about calling via direct IP dialling.

2.  The section of the manual that I referenced and you have quoted explains the use of that Mipd digit map to enable the making of calls to IP addresses using the buttons on a standard phone.  Please explain what is useless about it or how it is deficient in respect of making such calls.

[NoelB]

hi All
I limited the DX800 codec to use just the G771U and all is working :-)

This shouldn't be necessary but there is a bug in obi's sip client. I first struck this when setting up CsipS in a mobile to connect via an obi202 to a voip provider.When calling out from the mobile 711a was the first priority codec in the Invite to the obi. The same codec order was continued in the second leg of the invite from the obi to the voip provider with 711a still on top.The voip provider accepted 711a so when the call was established 711a RTP was sent to the obi. The obi however sent this on to the mobile as 711u and when the phone sent 711a rtp to the obi this was sent on to the voip provider as 711u. Easy to work around just don't use 711a.