WebRTC and Turn Relay is 100% accurate, but SIP servers are not even 1% accurate

[Sprogrammer]

Dear All, 

The main goal is making RFC5766-turn-server tested and making 100% sure the TURN relay works for GREEN section and RED section.

- As you can see diagram GREEN means working topology with turn relay

- RED means i am screwed, SIP is screwed for TURN RELAY.

Now i have also found that enterprise is following the first networking topology 

and that assure/guarantee 100% to make SIP works in any condition for full-duplex media exchange.

Can anyone please check and confirm why FreeSWITCH or Kamailio or Asterisk or Yate do not have 

TURN RELAY working? 

Please check this diagram where WebRTC without SIP server involvement works 100%

but same thing when we use by involving SIP server (RED Section FreeSWITCH, Asterisk, Kamelio or Yate) 

TURN server does not work. Specially TURN server never receives allocation, channel, turn relay packets from SIP Servers,

when TURN relay works one can see allocation log, channel log and packet exchange logs, but 

with SIP server involvement, turn relay setup not working accurately, its not doing the TURN relay via the turn-server and confusing the topology.

So i am bit lost weather if its a SIP standard itself screwed? 

or SIP Server programmers ignored to design/develop TURN relay module to be compatible with RFC5766-turn-server

Looking forward to the pointer. Because its confusing weather RFC5766-turn-server issue or SIP-server issue or Turn-client issue, we want to identify the culprit and

report it.

Thanks in advance

Best regards

Shamun

[Oleg Moskalenko]

The TURN specs were designed so that the TURN has to be used by the client applications. The allocated TURN relay endpoints must be used as "clients" in the network communications. The server systems (like SIP servers) must not be aware of the TURN - they will just see TURN relay endpoints as "clients".

I am not sure whether SIP servers are going to benefit from TURN. I can see that some SIP servers may include a TURN server - to be used by the clients - but I do not see how the SIP server itself would use it.

If a SIP client wants to use TURN, then it has to take care about the IP addresses in SDP.

Oleg

[Sprogrammer]

Thank you.

The TURN specs were designed so that the TURN has to be used by the client applications. The allocated TURN relay endpoints must be used as "clients" in the network communications. The server systems (like SIP servers) must not be aware of the TURN - they will just see TURN relay endpoints as "clients".

a > SIP servers need to act like TURN client application in case of when Peer 1 dials straight to IVR / Voicemail because else the relay wont ever work cause there is no Peer 2 end points for IVR/Voicemail services

b > SIP servers get call via Peer 1 and it requires to send the call to PSTN/ISDN/Cellular or other IP network, in that case still without relay candidate from SIP server to the turn server will also cause no audio call problems

c > But yes, when Peer 1 and Peer 2 is doing straight calls between them via SIP server then the call make sense that turn will work to do the relay

here:

a, b = is a SIP server problem because it does not implemented yet turn relay candidates with turn server as a result will cause one way audio problem

c     = will work because Peer 1 is chrome and Peer 2 is chrome and following the turn relay specs

I am not sure whether SIP servers are going to benefit from TURN. I can see that some SIP servers may include a TURN server - to be used by the clients - but I do not see how the SIP server itself would use it.

> SIP server needs to have TURN RELAY for IVR/Voicemail/call termination to PSTN/ISDN/Cellular when Peer 1/2 is not from Chrome else Peer 1 do not know from where to get the audio cause it was forced to use TURN RELAY only.

> if SIP srever do not implement any kind of TURN RELAY for a call made by Peer 1 (chrome, with forced TURN RELAY), then turn server never will know how to and where to do the RELAY? that was the problem i am already facing.

If a SIP client wants to use TURN, then it has to take care about the IP addresses in SDP. 

> SIP client (Chrome, PEer1, is forced to use turn relay it did everything correctly , but because SIP server do not following the specs of turn relay, therefore turnserver is unable to bridge the relay), following example is explaining it:

Mar 10 13:51:35 sun-Alienware-X51-R2 turnserver: 672: handle_udp_packet: New UDP endpoint: local addr 82.143.92.18:80, remote addr 82.143.92.22:59913

Mar 10 13:51:35 sun-Alienware-X51-R2 turnserver: 672: session 128000000000000001: user <>: incoming packet BINDING processed, success

Mar 10 13:51:35 sun-Alienware-X51-R2 turnserver: 672: IPv4. tcp or tls connected to: 82.143.92.22:58024

Mar 10 13:51:35 sun-Alienware-X51-R2 turnserver: 672: session 001000000000000001: user <>: incoming packet message processed, error 401

Mar 10 13:51:35 sun-Alienware-X51-R2 turnserver: 672: IPv4. Server relay addr: 82.143.92.18:80

Mar 10 13:51:35 sun-Alienware-X51-R2 turnserver: 672: IPv4. Local relay addr: 82.143.92.18:62022

Mar 10 13:51:35 sun-Alienware-X51-R2 turnserver: 672: session 001000000000000001: new, username=<root>, lifetime=600

Mar 10 13:51:35 sun-Alienware-X51-R2 turnserver: 672: session 001000000000000001: user <root>: incoming packet ALLOCATE processed, success

Mar 10 13:51:35 sun-Alienware-X51-R2 turnserver: 672: session 001000000000000001: user <root>: incoming packet CREATE_PERMISSION processed, success

Mar 10 13:51:45 sun-Alienware-X51-R2 turnserver: 682: session 128000000000000001: user <>: incoming packet BINDING processed, success

Mar 10 13:51:55 sun-Alienware-X51-R2 turnserver: 692: session 128000000000000001: user <>: incoming packet BINDING processed, success

Mar 10 13:52:05 sun-Alienware-X51-R2 turnserver: 702: session 128000000000000001: user <>: incoming packet BINDING processed, success

Mar 10 13:52:15 sun-Alienware-X51-R2 turnserver: 712: session 128000000000000001: user <>: incoming packet BINDING processed, success

Mar 10 13:52:25 sun-Alienware-X51-R2 turnserver: 722: session 128000000000000001: user <>: incoming packet BINDING processed, success

Mar 10 13:52:35 sun-Alienware-X51-R2 turnserver: 732: session 128000000000000001: closed (2nd stage), user <>, reason: allocation watchdog determined stale session state

Mar 10 13:52:35 sun-Alienware-X51-R2 turnserver: 732: handle_udp_packet: New UDP endpoint: local addr 82.143.92.18:80, remote addr 82.143.92.22:59913

Mar 10 13:52:35 sun-Alienware-X51-R2 turnserver: 732: session 128000000000000002: user <>: incoming packet BINDING processed, success

Mar 10 13:52:45 sun-Alienware-X51-R2 turnserver: 742: session 128000000000000002: user <>: incoming packet BINDING processed, success

Mar 10 13:52:55 sun-Alienware-X51-R2 turnserver: 752: session 128000000000000002: user <>: incoming packet BINDING processed, success

Mar 10 13:53:05 sun-Alienware-X51-R2 turnserver: 762: session 128000000000000002: user <>: incoming packet BINDING processed, success

Mar 10 13:53:15 sun-Alienware-X51-R2 turnserver: 772: session 128000000000000002: user <>: incoming packet BINDING processed, success

Mar 10 13:53:25 sun-Alienware-X51-R2 turnserver: 782: session 128000000000000002: user <>: incoming packet BINDING processed, success

Mar 10 13:53:35 sun-Alienware-X51-R2 turnserver: 792: session 128000000000000002: closed (2nd stage), user <>, reason: allocation watchdog determined stale session state

Mar 10 13:53:35 sun-Alienware-X51-R2 turnserver: 792: handle_udp_packet: New UDP endpoint: local addr 82.143.92.18:80, remote addr 82.143.92.22:59913

Mar 10 13:53:35 sun-Alienware-X51-R2 turnserver: 792: session 128000000000000003: user <>: incoming packet BINDING processed, success

Mar 10 13:53:45 sun-Alienware-X51-R2 turnserver: 802: session 128000000000000003: user <>: incoming packet BINDING processed, success

Mar 10 13:53:55 sun-Alienware-X51-R2 turnserver: 812: session 128000000000000003: user <>: incoming packet BINDING processed, success

Mar 10 13:54:05 sun-Alienware-X51-R2 turnserver: 822: session 128000000000000003: user <>: incoming packet BINDING processed, success

This is a Big problem cause this session is waiting for Peer 2 which is FreeSWITCH IVR to do the allocation, create channel and start relay 

Reg

shamun

[Oleg Moskalenko]

OK, I see what you are saying.

I was thinking more about the case when the SIP client connects to a SIP Registrar server (over TCP) and maintains a permanent connection to it. Then no TURN server is required to make a call - if the Registrar is located in a public network.

Regards,
Oleg

--
You received this message because you are subscribed to the Google Groups "TURN Server (Open-Source project)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to turn-server-project-rfc57...@googlegroups.com.
To post to this group, send email to turn-server-project...@googlegroups.com.
Visit this group at http://groups.google.com/group/turn-server-project-rfc5766-turn-server.
For more options, visit https://groups.google.com/d/optout.

[Sprogrammer]

YES - Guru :)

I was thinking more about the case when the SIP client connects to a SIP Registrar server (over TCP) and maintains a permanent connection to it. Then no TURN server is required to make a call - if the Registrar is located in a public network.

> So, this is OK when SIP client1 and client2 connects SIP Registrar server and connect with each other, considering client1 has turn client and client2 has turn client they still work with turn server relay even having SIP registrar 

> But here is what not working (considering it as SIP bug), SIP client 1 (no client 2), connects SIP Registrar server and dial IVR or to Voicemail or to Cellular termination. Now client 1 do not have any audio coming back from SIP server (Because sip server has not made allocation to turn server where client 1 is already allocated with turnserver for the relay [ as my logs show ]) 

I think our Turnserver is FINE, but FreeSWITCH, Asterisk, and other SIP servers has to fix it by re-implementing a turn client specs in IVR, Voicemail and termination when client request force turn relay via SIP or websocket or something... (this is what i was trying to explain and that is the problem which is not working for me yet)

Reg

Shamun

To unsubscribe from this group and stop receiving emails from it, send an email to turn-server-project-rfc5766-turn-server+unsubscribe@googlegroups.com.
To post to this group, send email to turn-server-project-rfc5766-turn-...@googlegroups.com.

[Oleg Moskalenko]

OK... I have not been dealing with SIP servers for a while, but this is what I am thinking how it must be in the worst-case connectivity scenario (this is a simplified dialog):

1) Alice registers to SIP Registrar.

2) Bob registers to SIP Registrar.

2) Alice allocates a TURN server media relay.

4) Alice sends INVITE to Bob (through SIP Registrar), including the Alice's TURN relay endpoint as media address, in SDP.

5) Bob receives the INVITE from the SIP Registrar. Before replying, Bob contacts the TURN server and allocates its own TURN relay endpoint. Then it replies to the INVITE, including the Bob's relay endpoint as media endpoint, in SDP.

6) Alice accepts the Bob reply and sends ACK to Bob.

7) Both parties are communicating now: the signaling is going thru the SIP Proxy/Registrar, and the media is going thru the TURN Server.

In the dialog that I described, the SIP Server does not have to do anything with the TURN server, that's the SIP clients responsibility.

Of course a SIP Server may indeed include a TURN server and allocate/deallocate the endpoints automatically and translate the IP addresses in SDP automatically. But that is more a fantasy, as far as I know, as of now.

Oleg

To unsubscribe from this group and stop receiving emails from it, send an email to turn-server-project-rfc57...@googlegroups.com.
To post to this group, send email to turn-server-project...@googlegroups.com.

[Sprogrammer]

> YES - like you explained is working. Because Alice and Bob with there turn-client managing it themselves 

But, this following not working (modified like you explained):

1) Alice registers to SIP Registrar.

2) Alice allocates a TURN server media relay.

3) Alice sends INVITE to SIP SERVER-IVR or Voicemail or CallTermination service module (through SIP Registrar), 

including the Alice's TURN relay endpoint as media address, in SDP.

4) SIP SERVER-IVR or Voicemail or CallTermination service module receives the INVITE from the SIP Registrar. 

Before replying, SIP SERVER-IVR or Voicemail or CallTermination service module DO NOT contacts the TURN server and DO NOT allocates its own TURN relay endpoint. 

Then it replies to the INVITE, including the SIP-SERVER-IVR/voicemail/calltermination service module relay endpoint as media endpoint, in SDP.

5) Alice accepts the SIP SERVER-IVR or Voicemail or CallTermination service module reply and sends ACK to SIP SERVER-IVR or Voicemail or CallTermination service module.

6) Both parties are communicating now: the signaling is going thru the SIP Proxy/Registrar, and the media is NOT going thru the TURN Server.

because that is the missing/problem.

Thank you

Shamun

[Kevin Dempsey]

The IVR/voicemail/calltermination endpoint must support ICE for the media path connectivity checks to work. However, if its media interface is public it does not need to use a TURN server and the ICE candidates it sends need only be host candidates.

[Sprogrammer]

@Kevin Dempsey: 

The IVR/voicemail/calltermination endpoint must support ICE for the media path connectivity checks to work. However, if its media interface is public it does not need to use a TURN server and the ICE candidates it sends need only be host candidates.

> CORRECT

> BUT you missing the point again ENTERPRISE NAT/ENTERPRISE NETWORK (please check the diagram RED section)

- where TCP port 80 outbound is only open from ENTERPRISE network

- ICE/STUN cant handle it when the port 80 is the only port to bypass. 

Its again "TURN RELAY" job according to RFC5766 and RFC6062 (TCP) to make even that complex situation work. But because SIP Servers/SIP Registrar do not have TURN Client as per RFC5766 / RFC6062 it will fail in Enterprise network (where all is blocked and TCP 80/443 outbound is open only)

[Sprogrammer]

@Kevin Dempsey: Please see the attached dialog, E with B or C do not work. because E should be consider same as B, C (E is also a end point like services offering IVR, Conference, Voicmail, Call terminations) . Because E is not designed or missing causing the failure. Where B and C can still communicate because both is using Turn client and instructing A for media allocation. E is not doing that.

I hope i am able to explain what is the culprit > E is the problem 

I think Oleg Guru must have understood it

 what i was referring to. He knows RFC A to Z its maybe SIP designed problem because IVR/Conference/all the rest has to act itself as end point to the turn relay server.

Thanks

Reg

Shamun

[Philipp Hancke]

On Fri, Mar 14, 2014 at 12:16 PM, Sprogrammer <sha...@companysocia.com> wrote:

@Kevin Dempsey: Please see the attached dialog, E with B or C do not work. because E should be consider same as B, C (E is also a end point like services offering IVR, Conference, Voicmail, Call terminations) . Because E is not designed or missing causing the failure. Where B and C can still communicate because both is using Turn client and instructing A for media allocation. E is not doing that.

I hope i am able to explain what is the culprit > E is the problem 

You're not talking about a protocol problem of SIP, but about implementations which don't implement certain features. Features that are not mandatory to implement and are not required in common deployment scenarios.

Your deployment scenario for the "sip server" seems to require TURN which is odd; typically, if those servers are supposed to be reachable from the outside (which most of the time they are not) they should be in the DMZ. Or have a SBC that is sitting in the DMZ.

[Sprogrammer]

@Philipp Hancke: I can understand saying NO or ignoring makes life easy. But FYI - SBC - is also used but that does not helped either, cause you do not have Media relay still like i explained you outbound port is 80 only (Kamailio and FreeSWITCH failed over SBC too)

without TURN RELAY it does not work for E