Picture of YaRbXNWnWVKKTJq
Registered 7 years 114 days
YaRbXNWnWVKKTJq Thursday, 30 August 2018, 11:17 AM
Innovaphone stun implementation BUG
hi.
Look like innovaphone embedded inside their soft old open source STUN client and server which have a mistake in stun implementation.
Due to it all innovaphone devices can work only with buggy implemented stun.innovaphone.com server and cannot work with any another RFC compatible STUN server.
It accept only stun responses which contain XOR_MAPPED_ADDRESS described in RFC 5389 but send bind requests like described on old RFC 3489.

In accordance with RFC :
bind request with magic cookie (0x2112A442) - > response have to be WITH XOR_MAPPED_ADDRESS
bind request without magic cookie - > response have to be WITHOUT XOR_MAPPED_ADDRESS

Extraction from RFC 5389:

The magic cookie field MUST contain the fixed value 0x2112A442 in
network byte order. In RFC 3489 [RFC3489], this field was part of
the transaction ID; placing the magic cookie in this location allows
a server to detect if the client will understand certain attributes
that were added in this revised specification.

Innovaphone STUN request example to innovaphone STUN server:

Simple Traversal of UDP Through NAT (this is typical RFC 3489 stun client bind request because no magic cookie 0x2112A442)
Message Type: Binding Request (0x0001)
Message Length: 0x0000
Message Transaction ID: 2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a

Simple Traversal of UDP Through NAT (this is like RFC 5389 answer. WHAT ?????. Here MUST be RFC 3489 answer. But it accepted by innovaphone device)
Message Type: Binding Response (0x0101)
Message Length: 0x0024
Message Transaction ID: 2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a
Attributes
Attribute: MAPPED-ADDRESS
Attribute: XOR_MAPPED_ADDRESS
Attribute: CHANGED-ADDRESS

Innovaphone STUN request example to RFC compatible stun servers :
Simple Traversal of UDP Through NAT (this is typical RFC 3489 stun client bind request)
Message Type: Binding Request (0x0001)
Message Length: 0x0000
Message Transaction ID: 2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a

Simple Traversal of UDP Through NAT (this is typical RFC 3489 stun server response. But it ignored by innovaphone device)
Message Type: Binding Response (0x0101)
Message Length: 0x004c
Message Transaction ID: 2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a2a
Attributes
Attribute: MAPPED-ADDRESS
Attribute: SOURCE-ADDRESS
Attribute: CHANGED-ADDRESS
Attribute: SERVER

What you think about it ?
Picture of Gerrit Beuko (innovaphone)
Moderator Registered 13 years 282 days
Gerrit Beuko (innovaphone) Thursday, 30 August 2018, 12:15 PM
Re: Innovaphone stun implementation BUG
Hello,

thank you for the hint. We have fixed this. With the next version we will release the fix. Roadmap V12

Greetings Gerrit
Picture of YaRbXNWnWVKKTJq
Registered 7 years 114 days
YaRbXNWnWVKKTJq Thursday, 30 August 2018, 12:42 PM
Re: Innovaphone stun implementation BUG
Thanks for your help. Can i ask one more question about innovaphone ? I configured Reverse proxy following way :

INTERNET -> IPVA reserve proxy -> PBX .

Everything works fine. For h323, ldap and webgui . But for sip i even not see messages in trace log. May be i do something wrong ? If for SIP clients i always forced to use SBC functionality what is purpose SIP reverse proxy ?


Picture of Gerrit Beuko (innovaphone)
Moderator Registered 13 years 282 days
Gerrit Beuko (innovaphone) Thursday, 30 August 2018, 01:11 PM
Re: Innovaphone stun implementation BUG
If the SIP Phone supports STUN and TURN we did not make any difference between H.323/TLS and SIP/TLS. If they do not support STUN and TURN you have to enable the PBX on your RP. Here you have to use SBC objects and the option Media Relay in the SBC Object.


If you have more trouble and you have the permission for support, please open a ticket.

Gerrit

Picture of YaRbXNWnWVKKTJq
Registered 7 years 114 days
YaRbXNWnWVKKTJq Friday, 31 August 2018, 10:02 PM
Re: Innovaphone stun implementation BUG
Thanks for your reply. I already understood what issue was. Appeared that RP does not support UDP SIP. It is only support TCP SIP. It was easy as you see. Do you have any plan to implement SIP UDP in RP? Nope we plan to use RP to register SIP phones .Some phones does not support TCP SIP. But SIP UDP supported by all of them. With providers we have direct links which does not require it (i mean RP functionality).
Basically we plan to use it like :

Customer PHONE -> internet -> RP on COLO -> HOSTED PBX (IPVA)-> OUR infrastruct -> TERM PROVIDER.
Such schema does not described anywhere in your wiki but for sure it works . Almost works.
← You can define your color theme preference here