ICE: Media not starting in caller

[Pedro Gonçalves]

Hi!

I already managed to use ICE to establish a call between a client behind
symmetric NAT and a client directly (no NAT) connected to my SIP Server,
which proves that ICE is working fine :)

However, I have a problem when ICE can't establish a connection (ex:
Port Restricted Cone NAT to Symmetric NAT).
I think I am missing something, because the media (RTP and RTCP) is not
starting in caller when the initial answer (200 OK INVITE) is received
by the caller.

As I am using PJSIP at a low level, the process flow is like this:
[When starting a call]

== Caller ==
pjmedia_ice_create()
pjmedia_transport_media_create()
pjmedia_transport_encode_sdp()
pjsip_inv_create_uac()
pjsip_inv_invite()
pjsip_inv_send_msg()

[INVITE goes to answerer]

== Answerer ==
pjsip_inv_answer()
pjmedia_ice_create()
pjmedia_transport_media_create()
pjmedia_transport_encode_sdp()
pjsip_inv_send_msg()
pjmedia_transport_media_start()

[200 OK goes to caller]

== Caller ==
on_media_update():
pjmedia_transport_media_start()

on_ice_complete():
pjmedia_endpt_create_sdp()
pjmedia_transport_encode_sdp()
pjsip_inv_reinvite()
pjsip_inv_send_msg()
(...)

With this process flow, I can see that the default candidates (relayed
candidates) are chosen and negotiated; I can even see the media flow
going from answerer to relay sever to caller, but not the other way
around (caller to relay server to answerer).
Any idea why?

Am I missing something?

Cheers
Pedro Gonçalves

[Benny Prijono]

Post by Pedro Gonçalves
Hi!
I already managed to use ICE to establish a call between a client behind
symmetric NAT and a client directly (no NAT) connected to my SIP Server,
which proves that ICE is working fine :)
Port Restricted Cone NAT to Symmetric NAT).
I think I am missing something, because the media (RTP and RTCP) is not
starting in caller when the initial answer (200 OK INVITE) is received
by the caller.
[When starting a call]
== Caller ==
pjmedia_ice_create()
pjmedia_transport_media_create()
pjmedia_transport_encode_sdp()
pjsip_inv_create_uac()
pjsip_inv_invite()
pjsip_inv_send_msg()
[INVITE goes to answerer]
== Answerer ==
pjsip_inv_answer()
pjmedia_ice_create()
pjmedia_transport_media_create()
pjmedia_transport_encode_sdp()
pjsip_inv_send_msg()
pjmedia_transport_media_start()
[200 OK goes to caller]
== Caller ==
pjmedia_transport_media_start()
pjmedia_endpt_create_sdp()
pjmedia_transport_encode_sdp()
pjsip_inv_reinvite()
pjsip_inv_send_msg()
(...)
With this process flow, I can see that the default candidates (relayed
candidates) are chosen and negotiated; I can even see the media flow
going from answerer to relay sever to caller, but not the other way
around (caller to relay server to answerer).
Any idea why?

Nope.

Post by Pedro Gonçalves
Am I missing something?

Yes. The log. :)

And btw, in your log, all SIP messages are written as one very long line and
this makes it very hard to read. Can you fix that first?

Cheers
Benny

Post by Pedro Gonçalves
Cheers
Pedro Gonçalves

[Pedro Gonçalves]

On Wed, Aug 13, 2008 at 11:27 AM, Pedro Gonçalves
Hi!
I already managed to use ICE to establish a call between a client behind
symmetric NAT and a client directly (no NAT) connected to my SIP Server,
which proves that ICE is working fine :)
Port Restricted Cone NAT to Symmetric NAT).
I think I am missing something, because the media (RTP and RTCP) is not
starting in caller when the initial answer (200 OK INVITE) is received
by the caller.
[When starting a call]
== Caller ==
pjmedia_ice_create()
pjmedia_transport_media_create()
pjmedia_transport_encode_sdp()
pjsip_inv_create_uac()
pjsip_inv_invite()
pjsip_inv_send_msg()
[INVITE goes to answerer]
== Answerer ==
pjsip_inv_answer()
pjmedia_ice_create()
pjmedia_transport_media_create()
pjmedia_transport_encode_sdp()
pjsip_inv_send_msg()
pjmedia_transport_media_start()
[200 OK goes to caller]
== Caller ==
pjmedia_transport_media_start()
pjmedia_endpt_create_sdp()
pjmedia_transport_encode_sdp()
pjsip_inv_reinvite()
pjsip_inv_send_msg()
(...)
With this process flow, I can see that the default candidates (relayed
candidates) are chosen and negotiated; I can even see the media flow
going from answerer to relay sever to caller, but not the other way
around (caller to relay server to answerer).
Any idea why?
Nope.
Am I missing something?
Yes. The log. :)

Here they are, in attachment.

And btw, in your log, all SIP messages are written as one very long
line and this makes it very hard to read. Can you fix that first?

Sorry, I can see the log perfectly with Notepad or PSPad.
Here is an example of a sip message:
15:43:33.640 LOG RX 354 bytes Response msg
100/REGISTER/cseq=18510 (rdata0AAD805C) from UDP 172.18.0.170:5060:
SIP/2.0 100 Trying

Via: SIP/2.0/UDP
10.0.0.2:1470;rport=1470;branch=z9hG4bKPj9663ef010ac74fe5bdb59f8a3731d622;received=172.18.0.78

From:
<sip:+***@webchamada.vodafone.pt>;tag=47530169257643ef812a6940a8fe5174

To: <sip:+***@webchamada.vodafone.pt>

Call-ID: da82eb3395394dfc8bc0b163cd1e01ac

CSeq: 18510 REGISTER

Content-Length: 0


Best Regards
Pedro Gonçalves

[Pedro Gonçalves]

Post by Pedro Gonçalves
Am I missing something?
Yes. The log. :)
And btw, in your log, all SIP messages are written as one very long
line and this makes it very hard to read. Can you fix that first?
Cheers
Benny

I tried again and this time I see that RTCP is going from the caller to
the answerer.
The problem is that RTP is not.
Any possible ideas why this is happening?

As I couldn't send the attachments due to the 500kb attachment size
limit, you can find the attachments here:
http://student.dei.uc.pt/~pandre/caller_not_sending_media2.zip

Cheers
Pedro Gonçalves

[Benny Prijono]

Post by Pedro Gonçalves
I tried again and this time I see that RTCP is going from the caller to
the answerer.
The problem is that RTP is not.
Any possible ideas why this is happening?

Check the audio troubleshooting Wiki:
http://trac.pjsip.org/repos/wiki/sound-problems

-benny

[Pedro Gonçalves]

On Thu, Aug 14, 2008 at 9:47 AM, Pedro Gonçalves
I tried again and this time I see that RTCP is going from the caller to
the answerer.
The problem is that RTP is not.
Any possible ideas why this is happening?
http://trac.pjsip.org/repos/wiki/sound-problems

I already did that :(
However, those instructions are for use with PJSUA, and as you know I am
using PJSIP at a lower level (PJNATH / PJLIB / etc.)

I tried to translate those instructions to what was happening in the
code, and everything looks normal.
As no RTP packets are going from caller to answerer, I think the best
troubleshooting guide for me is
http://trac.pjsip.org/repos/wiki/audio-problem-remote-no-audio

1. Check that correct audio device is being used
<http://trac.pjsip.org/repos/wiki/audio-check-correct-device>

The correct audio device is being used, because my application has a
configuration setting which allows us to select the audio device, to
adjust volume and to hear from it. I can hear myself perfectly.

1. Check that microphone is functioning properly (level is correct
etc.) by looping the microphone to the speaker with pjsua
<http://trac.pjsip.org/repos/wiki/audio-check-loopback>

Same as above

1. Check that no other application is using the sound devices. It is
common to not be able to use sound device when other application
is using the device.

No other app is using the device. Only my app is running

1. Check that the call's media is connected to the sound device in
the conference bridge
<http://trac.pjsip.org/repos/wiki/audio-check-conf-connection>

I think this is being done correctly:
19:36:20.500 strm1631D8AC VAD temporarily disabled
19:36:20.500 rtp.c pjmedia_rtp_session_init: ses=1631EAD4,
default_pt=0, ssrc=0x4ae13d6c
19:36:20.562 rtp.c pjmedia_rtp_session_init: ses=1631F6DC,
default_pt=0, ssrc=0x4ae13d6c
19:36:20.578 stream.c Stream strm1631D8AC created
19:36:20.578 strm1631D8AC Encoder stream started
19:36:20.578 strm1631D8AC Decoder stream started
19:36:20.703 pasound.c Opened device Realtek AC97
Audio(MME)/Realtek AC97 Audio(MME) for recording and playback, sample
rate=8000, ch=1, bits=16, 400 samples per frame, input latency=100 ms,
output latency=100 ms
19:36:20.703 pasound.c Starting Realtek AC97 Audio stream..
19:36:20.703 pasound.c PA message: Pa_StartStream: waveInStart
returned = 0x0.

19:36:20.703 pasound.c Done, status=0
19:36:20.703 ec16662EF8 Creating AEC
19:36:20.750 pasound.c Player thread started
19:36:20.750 pasound.c Recorder thread started
19:36:20.921 ec16662EF8 AEC created, clock_rate=8000, channel=1,
samples per frame=400, tail length=800 ms, latency=100 ms
19:36:20.921 conference.c Port 1 (strm1631D8AC) transmitting to port
0 (Master/sound)
19:36:20.921 conference.c Port 0 (Master/sound) transmitting to port
1 (strm1631D8AC)
(you can see the complete log and capture in
http://student.dei.uc.pt/~pandre/caller_not_sending_media2.zip)

1. Check that pjsua is transmitting RTP packet to the correct address
<http://trac.pjsip.org/repos/wiki/audio-check-remote-address>

This is where the problem starts. No RTP packets are leaving the caller,
and I don't have any idea why.
Strangely, RTCP packets are going to the correct address.

1. Use pjsua on the remote side to check that packets are received.
Follow the instruction on this page
<http://trac.pjsip.org/repos/wiki/audio-check-rx-rtp> on how to
use pjsua to verify receipt of incoming RTP packets.
2. Check that CPU utilization is not too high
<http://trac.pjsip.org/repos/wiki/audio-check-cpu>
3. Check that echo canceller doesn't cut audio too aggressively?
<http://trac.pjsip.org/repos/wiki/audio-check-ec>


When using ICE, wasn't PJSIP supposed to send RTP/RTCP packets between
the initial answer and the subsequent offer, to the address negotiated
in the initial offer/answer?

Best Regards
Pedro Gonçalves

[Benny Prijono]

Post by Pedro Gonçalves

Post by Benny Prijono
http://trac.pjsip.org/repos/wiki/sound-problems

I already did that :(
However, those instructions are for use with PJSUA, and as you know I am
using PJSIP at a lower level (PJNATH / PJLIB / etc.)

The instructions should give you an idea on what could be the reason, and
even if you're not using PJSUA API you should be able to translate it to the
lower level API.

Post by Pedro Gonçalves
When using ICE, wasn't PJSIP supposed to send RTP/RTCP packets between
the initial answer and the subsequent offer, to the address negotiated
in the initial offer/answer?

Sure. Btw your log shows why there's no RTP sent by the caller. Please check
it out.

-benny

[Pedro Gonçalves]

On Thu, Aug 14, 2008 at 10:09 AM, Pedro Gonçalves

Post by Benny Prijono
http://trac.pjsip.org/repos/wiki/sound-problems

I already did that :(
However, those instructions are for use with PJSUA, and as you know I am
using PJSIP at a lower level (PJNATH / PJLIB / etc.)
The instructions should give you an idea on what could be the reason,
and even if you're not using PJSUA API you should be able to translate
it to the lower level API.
When using ICE, wasn't PJSIP supposed to send RTP/RTCP packets between
the initial answer and the subsequent offer, to the address negotiated
in the initial offer/answer?
Sure. Btw your log shows why there's no RTP sent by the caller. Please
check it out.
-benny

I can assure you that to check the caller's log and capture is what I've
been doing yesterday and today.
Sorry, but I'm no way as expert in PJSIP as you are.
I relatively new to PJSIP, I am still learning, so that's why I am
asking for help: I tried myself to figure out what was wrong, and as I
was (and still am) stuck on this problem, I asked for your help.
If the logs tell what's wrong, could you help me understand what the
problem is?

Cheers
Pedro Gonçalves

[Benny Prijono]

Post by Pedro Gonçalves
I can assure you that to check the caller's log and capture is what I've
been doing yesterday and today.
Sorry, but I'm no way as expert in PJSIP as you are.
I relatively new to PJSIP, I am still learning, so that's why I am
asking for help: I tried myself to figure out what was wrong, and as I
was (and still am) stuck on this problem, I asked for your help.
If the logs tell what's wrong, could you help me understand what the
problem is?

Well it's written there very clearly:

15:44:37.062 stuntsx16EF0D6 STUN timeout waiting for response
15:44:37.062 ICEVoiceTransp Check 1: [2]
10.0.0.2:1476-->172.18.0.211:1308(nominated): connectivity check
FAILED: Unknown error 370004
15:44:37.062 ICEVoiceTransp Check 1: [2] 10.0.0.2:1476-->172.18.0.211:1308:
state changed from In Progress to Failed
15:44:37.234 stuntsx16E34D6 STUN timeout waiting for response
15:44:37.234 ICEVoiceTransp Check 2: [1] 10.0.0.2:1475-->
169.254.127.178:2028 (nominated): connectivity check FAILED: Unknown error
370004
15:44:37.234 ICEVoiceTransp Check 2: [1] 10.0.0.2:1475-->
169.254.127.178:2028: state changed from In Progress to Failed
15:44:37.328 stuntsx16E40D6 STUN timeout waiting for response
15:44:37.328 ICEVoiceTransp Check 7: [2]
10.0.0.2:1476-->192.168.1.91:5107(nominated): connectivity check
FAILED: Unknown error 370004
15:44:37.328 ICEVoiceTransp Check 7: [2] 10.0.0.2:1476-->192.168.1.91:5107:
state changed from In Progress to Failed
15:44:37.328 stuntsx16EFDD6 STUN timeout waiting for response
15:44:37.328 ICEVoiceTransp Check 6: [1]
10.0.0.2:1475-->192.168.1.91:5106(nominated): connectivity check
FAILED: Unknown error 370004
15:44:37.328 ICEVoiceTransp Check 6: [1] 10.0.0.2:1475-->192.168.1.91:5106:
state changed from In Progress to Failed
15:44:37.328 stuntsx16E65D6 STUN timeout waiting for response
15:44:37.328 ICEVoiceTransp Check 5: [2] 10.0.0.2:1476-->
169.254.127.178:2029 (nominated): connectivity check FAILED: Unknown error
370004
15:44:37.328 ICEVoiceTransp Check 5: [2] 10.0.0.2:1476-->
169.254.127.178:2029: state changed from In Progress to Failed
15:44:37.328 stuntsx16EE8D6 STUN timeout waiting for response
15:44:37.328 ICEVoiceTransp Check 4: [2] 10.0.0.2:1476-->
192.168.100.100:2029 (nominated): connectivity check FAILED: Unknown error
370004
15:44:37.328 ICEVoiceTransp Check 4: [2] 10.0.0.2:1476-->
192.168.100.100:2029: state changed from In Progress to Failed
15:44:37.328 stuntsx16E3AD6 STUN timeout waiting for response
15:44:37.328 ICEVoiceTransp Check 3: [1] 10.0.0.2:1475-->
192.168.100.100:2028 (nominated): connectivity check FAILED: Unknown error
370004
15:44:37.328 ICEVoiceTransp Check 3: [1] 10.0.0.2:1475-->
192.168.100.100:2028: state changed from In Progress to Failed
15:44:37.328 ICEVoiceTransp ICE process complete, status=Unknown error
370082
15:44:37.328 ICEVoiceTransp Valid list
15:44:37.328 ICEVoiceTransp ICE negotiation failed after 8s:422: Unknown
error 370082

Post by Pedro Gonçalves
Cheers
Pedro Gonçalves
_______________________________________________
Visit our blog: http://blog.pjsip.org
pjsip mailing list
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org

[Pedro Gonçalves]

On Thu, Aug 14, 2008 at 10:46 AM, Pedro Gonçalves
I can assure you that to check the caller's log and capture is what I've
been doing yesterday and today.
Sorry, but I'm no way as expert in PJSIP as you are.
I relatively new to PJSIP, I am still learning, so that's why I am
asking for help: I tried myself to figure out what was wrong, and as I
was (and still am) stuck on this problem, I asked for your help.
If the logs tell what's wrong, could you help me understand what the
problem is?
15:44:37.062 stuntsx16EF0D6 STUN timeout waiting for response
15:44:37.062 ICEVoiceTransp Check 1: [2]
10.0.0.2:1476-->172.18.0.211:1308 <http://172.18.0.211:1308>
(nominated): connectivity check FAILED: Unknown error 370004
15:44:37.062 ICEVoiceTransp Check 1: [2]
10.0.0.2:1476-->172.18.0.211:1308 <http://172.18.0.211:1308>: state
changed from In Progress to Failed
15:44:37.234 stuntsx16E34D6 STUN timeout waiting for response
15:44:37.234 ICEVoiceTransp Check 2: [1]
10.0.0.2:1475-->169.254.127.178:2028 <http://169.254.127.178:2028>
(nominated): connectivity check FAILED: Unknown error 370004
15:44:37.234 ICEVoiceTransp Check 2: [1]
state changed from In Progress to Failed
15:44:37.328 stuntsx16E40D6 STUN timeout waiting for response
15:44:37.328 ICEVoiceTransp Check 7: [2]
10.0.0.2:1476-->192.168.1.91:5107 <http://192.168.1.91:5107>
(nominated): connectivity check FAILED: Unknown error 370004
15:44:37.328 ICEVoiceTransp Check 7: [2]
10.0.0.2:1476-->192.168.1.91:5107 <http://192.168.1.91:5107>: state
changed from In Progress to Failed
15:44:37.328 stuntsx16EFDD6 STUN timeout waiting for response
15:44:37.328 ICEVoiceTransp Check 6: [1]
10.0.0.2:1475-->192.168.1.91:5106 <http://192.168.1.91:5106>
(nominated): connectivity check FAILED: Unknown error 370004
15:44:37.328 ICEVoiceTransp Check 6: [1]
10.0.0.2:1475-->192.168.1.91:5106 <http://192.168.1.91:5106>: state
changed from In Progress to Failed
15:44:37.328 stuntsx16E65D6 STUN timeout waiting for response
15:44:37.328 ICEVoiceTransp Check 5: [2]
10.0.0.2:1476-->169.254.127.178:2029 <http://169.254.127.178:2029>
(nominated): connectivity check FAILED: Unknown error 370004
15:44:37.328 ICEVoiceTransp Check 5: [2]
state changed from In Progress to Failed
15:44:37.328 stuntsx16EE8D6 STUN timeout waiting for response
15:44:37.328 ICEVoiceTransp Check 4: [2]
10.0.0.2:1476-->192.168.100.100:2029 <http://192.168.100.100:2029>
(nominated): connectivity check FAILED: Unknown error 370004
15:44:37.328 ICEVoiceTransp Check 4: [2]
state changed from In Progress to Failed
15:44:37.328 stuntsx16E3AD6 STUN timeout waiting for response
15:44:37.328 ICEVoiceTransp Check 3: [1]
10.0.0.2:1475-->192.168.100.100:2028 <http://192.168.100.100:2028>
(nominated): connectivity check FAILED: Unknown error 370004
15:44:37.328 ICEVoiceTransp Check 3: [1]
state changed from In Progress to Failed
15:44:37.328 ICEVoiceTransp ICE process complete, status=Unknown
error 370082
15:44:37.328 ICEVoiceTransp Valid list
Unknown error 370082

Hummm...
So basically, PJSIP won't send RTP packets until a STUN response is
received?
If so, why?!
192.168.1.91 is a relay server (not a standard TURN, unfortunately), and
the initial INVITE and the initial 200 OK INVITE should be enough to
establish connectivity between the two clients.
At that moment, they should be exchanging RTP / RTCP using that relay
server (at least that's what I wanted them to do).

So ICE simply fails and because of so no RTP data is sent?

Cheers
Pedro Gonçalves

[Benny Prijono]

Post by Pedro Gonçalves

Unknown error 370082

Hummm...
So basically, PJSIP won't send RTP packets until a STUN response is
received?
If so, why?!

Because we don't know yet where to send the RTP packets to. And this is not
the problem anyway. The problem is ICE negotiation has failed, and you can't
expect RTP traffic to flow on this situation.

Post by Pedro Gonçalves
192.168.1.91 is a relay server (not a standard TURN, unfortunately), and
the initial INVITE and the initial 200 OK INVITE should be enough to
establish connectivity between the two clients.
At that moment, they should be exchanging RTP / RTCP using that relay
server (at least that's what I wanted them to do).

Obviously the relay server is not working (i.e. it doesn't seem to forward
STUN packets).

Post by Pedro Gonçalves
So ICE simply fails and because of so no RTP data is sent?

Yep. If ICE connectivity checks fails, then there's no point in sending RTP
since it will not reach the destination anyway. The media transport gives
you a callback to notify the application about ICE negotiation status, and
in PJSUA we disconnect the call if ICE negotiation fails. That's probably
what you should do too.

[Pedro Gonçalves]

On Thu, Aug 14, 2008 at 11:05 AM, Pedro Gonçalves

Unknown error 370082

Hummm...
So basically, PJSIP won't send RTP packets until a STUN response is
received?
If so, why?!
Because we don't know yet where to send the RTP packets to. And this
is not the problem anyway. The problem is ICE negotiation has failed,
and you can't expect RTP traffic to flow on this situation.

Yes we do know where to send packets to!
In 200 OK's SDP, the following lines give us all the info we need:
c=IN IP4 192.168.1.91
m=audio 5134 RTP/AVP 0 101
a=rtcp:5135 IN IP4 192.168.1.91

Here is the full SDP:
v=0
o=- 3427644972 3427644973 IN IP4 192.168.100.100
s=pjmedia
c=IN IP4 192.168.1.91
t=0 0
m=audio 5134 RTP/AVP 0 101
a=rtcp:5135 IN IP4 192.168.1.91
a=rtpmap:0 PCMU/8000
a=sendrecv
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ice-ufrag:301c0bdb
a=ice-pwd:56ae0732
a=candidate:S 1 UDP 31 172.18.0.211 1134 typ srflx raddr 192.168.100.100
rport 2396
a=candidate:H 1 UDP 23 192.168.100.100 2396 typ host
a=candidate:H 1 UDP 23 169.254.127.178 2396 typ host
a=candidate:S 2 UDP 30 172.18.0.211 1135 typ srflx raddr 192.168.100.100
rport 2397
a=candidate:H 2 UDP 22 192.168.100.100 2397 typ host
a=candidate:H 2 UDP 22 169.254.127.178 2397 typ host
a=candidate:Rac1200d4 1 UDP 0 192.168.1.91 5134 typ relay raddr
192.168.100.100 4000
a=candidate:Rac1200d4 2 UDP 0 192.168.1.91 5135 typ relay raddr
192.168.100.100 4001

This way, IMHO, caller should be able to send RTP packets to
192.168.1.91:5134 and RTCP packets to 192.168.1.91:5135.
Why doesn't he do that?
If I disable ICE, the above works.

192.168.1.91 <http://192.168.1.91> is a relay server (not a
standard TURN, unfortunately), and
the initial INVITE and the initial 200 OK INVITE should be enough to
establish connectivity between the two clients.
At that moment, they should be exchanging RTP / RTCP using that relay
server (at least that's what I wanted them to do).
Obviously the relay server is not working (i.e. it doesn't seem to
forward STUN packets).

The relay server is indeed working.
The problem is that it doesn't understand STUN (as it is just a relay
server) so it simply relays the STUN request to the answerer, which
receives it in the rtp media stream, causing a decode error.

So ICE simply fails and because of so no RTP data is sent?
Yep. If ICE connectivity checks fails, then there's no point in
sending RTP since it will not reach the destination anyway. The media
transport gives you a callback to notify the application about ICE
negotiation status, and in PJSUA we disconnect the call if ICE
negotiation fails. That's probably what you should do too.

So, as my relay server is not turn and it already has some hacks
(actually, it introduces relay candidates that correspond to its relay
addresses and ports), do you have some suggestion?

I am starting to look to this recent TurnServer project:
https://sourceforge.net/projects/turnserver/
Has anyone ever tried it?
I will try to install it and use it with PJSIP.

Best Regards
Pedro Gonçalves

[Benny Prijono]

Post by Pedro Gonçalves

Post by Benny Prijono
Because we don't know yet where to send the RTP packets to. And this
is not the problem anyway. The problem is ICE negotiation has failed,
and you can't expect RTP traffic to flow on this situation.

Yes we do know where to send packets to!
c=IN IP4 192.168.1.91
m=audio 5134 RTP/AVP 0 101
a=rtcp:5135 IN IP4 192.168.1.91

Like I said, that's not the point. ICE negotiation fails, and that's it. Fix
the server.

Post by Pedro Gonçalves
This way, IMHO, caller should be able to send RTP packets to
192.168.1.91:5134 and RTCP packets to 192.168.1.91:5135.
Why doesn't he do that?

If connectivity check succeeds to that destination, then packets will be
sent to that address. But it failed, so it doesn't send it to there. That's
what ICE is supposed to do.

Post by Pedro Gonçalves
If I disable ICE, the above works.

This is exactly what frustrates me. You're building a B2BUA, which modifies
the SDP and ICE, it somehow breaks ICE connectivity checks, and now you're
complaining that the client needs to be fixed. This is frustrating for me.

Post by Pedro Gonçalves

Post by Benny Prijono
192.168.1.91 <http://192.168.1.91> is a relay server (not a
standard TURN, unfortunately), and
the initial INVITE and the initial 200 OK INVITE should be enough to
establish connectivity between the two clients.
At that moment, they should be exchanging RTP / RTCP using that relay
server (at least that's what I wanted them to do).
Obviously the relay server is not working (i.e. it doesn't seem to
forward STUN packets).

The relay server is indeed working.

If it's working, then why there's no connectivity checks received by caller?
Nor connectivity check response for that matter.

Post by Pedro Gonçalves
The problem is that it doesn't understand STUN (as it is just a relay
server) so it simply relays the STUN request to the answerer, which
receives it in the rtp media stream, causing a decode error.

Well that's the problem. If you're building an ICE aware B2BUA, then you
must know how ICE works and how to make it to play friendly with any ICE
clients (i.e. how to not break ICE). I can't tell you how, and there's no
IETF drafts to explain this yet, so you must work this out yourself from
reading ICE protocol.


So, as my relay server is not turn and it already has some hacks

Post by Pedro Gonçalves
(actually, it introduces relay candidates that correspond to its relay
addresses and ports), do you have some suggestion?
https://sourceforge.net/projects/turnserver/
Has anyone ever tried it?
I will try to install it and use it with PJSIP.

I have not tried that myself, but I've tried with four other TURN servers
(can't name them here for confidentiality reason) and the TURN client in
pjnath works fine. So as long as that project follows the latest TURN draft
I wouldn't expect any problems with it.

-benny

[Pedro Gonçalves]

On Thu, Aug 14, 2008 at 11:51 AM, Pedro Gonçalves

Post by Benny Prijono
Because we don't know yet where to send the RTP packets to. And this
is not the problem anyway. The problem is ICE negotiation has

failed,

Post by Benny Prijono
and you can't expect RTP traffic to flow on this situation.

Yes we do know where to send packets to!
c=IN IP4 192.168.1.91 <http://192.168.1.91>
m=audio 5134 RTP/AVP 0 101
a=rtcp:5135 IN IP4 192.168.1.91 <http://192.168.1.91>
Like I said, that's not the point. ICE negotiation fails, and that's
it. Fix the server.
This way, IMHO, caller should be able to send RTP packets to
192.168.1.91:5134 <http://192.168.1.91:5134> and RTCP packets to
192.168.1.91:5135 <http://192.168.1.91:5135>.
Why doesn't he do that?
If connectivity check succeeds to that destination, then packets will
be sent to that address. But it failed, so it doesn't send it to
there. That's what ICE is supposed to do.
If I disable ICE, the above works.
This is exactly what frustrates me. You're building a B2BUA, which
modifies the SDP and ICE, it somehow breaks ICE connectivity checks,
and now you're complaining that the client needs to be fixed. This is
frustrating for me.

Post by Benny Prijono
192.168.1.91 <http://192.168.1.91> <http://192.168.1.91> is

a relay server (not a

Post by Benny Prijono
standard TURN, unfortunately), and
the initial INVITE and the initial 200 OK INVITE should be

enough to

Post by Benny Prijono
establish connectivity between the two clients.
At that moment, they should be exchanging RTP / RTCP using

that relay

Post by Benny Prijono
server (at least that's what I wanted them to do).
Obviously the relay server is not working (i.e. it doesn't seem to
forward STUN packets).

The relay server is indeed working.
If it's working, then why there's no connectivity checks received by
caller? Nor connectivity check response for that matter.
The problem is that it doesn't understand STUN (as it is just a relay
server) so it simply relays the STUN request to the answerer, which
receives it in the rtp media stream, causing a decode error.
Well that's the problem. If you're building an ICE aware B2BUA, then
you must know how ICE works and how to make it to play friendly with
any ICE clients (i.e. how to not break ICE). I can't tell you how, and
there's no IETF drafts to explain this yet, so you must work this out
yourself from reading ICE protocol.
So, as my relay server is not turn and it already has some hacks
(actually, it introduces relay candidates that correspond to its relay
addresses and ports), do you have some suggestion?
https://sourceforge.net/projects/turnserver/
Has anyone ever tried it?
I will try to install it and use it with PJSIP.
I have not tried that myself, but I've tried with four other TURN
servers (can't name them here for confidentiality reason) and the TURN
client in pjnath works fine. So as long as that project follows the
latest TURN draft I wouldn't expect any problems with it.

If you can't name the servers you used, could you tell us about a free
TURN server implementation?

I am trying TurnServer, and I already managed to install and run it.
I am using PJSUA to test it, but PJSUA is complaing about its responses:

18:53:28.397 stun_msg.c Error parsing STUN attribute
XOR-MAPPED-ADDRESS: Invalid STUN attribute length (PJNATH_ESTUNINATTRLEN)
18:53:28.397 udprel01FCA278 STUN msg_decode() error: Invalid STUN
attribute length (PJNATH_ESTUNINATTRLEN)

I attached the log and the capture I made.
What is your opinion about this?
Is it a problem in TurnServer?

Cheers
Pedro Gonçalves