Relay or not using STUN

[CastB]

1. Brekeke Product Name and version: Sip Server 2.4.7.3/286.1

2. Java version: 1.6.0_17

3. OS type and the version: 2.6.18-194.32.1.el5.centos.plus

4. UA (phone), gateway or other hardware/software involved: several tested

5. Select your network pattern from http://www.brekeke-sip.com/bbs/network/networkpatterns.html : Sip server in the global network, both UA behind NAT

6. Your problem: Can not setup p2p call with stun

Hello,

I am trying to setup calls using STUN servers but i can not succeed in establishing a p2p call. The calls are always relayed throug Brekeke. I tried several NAT routers (all of them are fullcone or restricted cone, not symmetric) and i tried several stun servers but no result. Looking at wireshark traces i found out that the stun server does correct binding requests for the audio and video ports and the following happens when setting up a call:

The sip invite from caller (wireshark at caller site):
- the c line in the sip/sdp shows the correct "global nat IP adress"
- the m lines in sip/sdp show correct ports for audio and video
However the "c line" in the sip invite as it is received bij callee (wireshark at callee site) is already rewritten by Brebeke and now contains the Brebeke sip server adress.

These are my brekeke rtp sip server settings
- RTP relay: auto
- Port mapping: sdp or source port (makes no difference)
I also tried forcing to never do a relay by writing a dialplan ($rtp=off) but then there is no audio at all (call is established)

Furthermore i was able to setup a p2p call in the same network environment using other third party sip servers and clients (eyeball software)

So i have two questions:
1) Can someone tell me how to setup this scenario so that i can make p2p calls using stun and Brekeke or explain to me why it is not possible?
2) Can someone explain to me which "decision model" Brekeke uses to discover if a call should be relayed through Brekeke and which sip headers are rewritten in that case?

Thanks!

[Haddas]

> I also tried forcing to never do a relay by writing a dialplan
> ($rtp=off) but then there is no audio at all (call is established)

Why does no-audio problem happen if you set "$rtp=off"?
I wonder because you said INVITE's SDP has correct global IP address and port..
If these information are correct, audio problem will not happen.


Can the caller and callee send PING packets each other?

[CastB]

Hi Haddas,

Thanks! You are right. I tried it again and when i force a norelay it does work (p2p audio) so i am not sure what i did wrong last time..

However my questions are actually still more or less the same. I prefer a scenario in which Brekeke decides to relay if p2p is not possible (relay setting auto). Why does Brekeke thinks that it has to relay the call while p2p is possible?

[Haddas]

If Brekeke SIP Server detects both UA can not communicate each other directly, it enables RTP-Relay automatically.

For example, UA1 is in a LAN, and UA2 is in the Internet, the UA2 can not send RTP packets to UA1 directly.
In this case, the SIP Server relays RTP packets.

The SIP Server can notice the above from SDP and SIP headers.

[CastB]

Hi Haddas,

Oke, but if i use STUN with 2 UA behind NAT and Brekeke on the public, and force p2p (by applying a dial plan rule) it does p2p, meaning that a direct connection is possible.

However if i use STUN in the same network configuration as above, but do not force p2p (no dial plan rule, relay setting: auto) it always relay the call, meaning the automatic detection function is not working. Why is Brekeke relaying while p2p is definitely possible as proved by the test in which i force p2p?


The idea about the automatic decision when to relay or not is great so i would be very pleased if i can get this to work correctly.

Can you or someone else explain which SIP and SDP headers are used and in which way to make this decision? If i understand this in more detail i might be able to write my own dialplan to make it work for me


Thanks.

[Haddas]

> However if i use STUN in the same network configuration as above,

Do you mean that the SIP Server is located in the same LAN?
or do you mean that both UA are located in the same LAN?

> it always relay the call,

Are you sure that each UA set its global IP addresses in SDP which obtained from STUN?


> The idea about the automatic decision when to relay or not is great

Use $rtp= on or $rtp = off in DialPlan.


> Can you or someone else explain which SIP and SDP headers are used

It is "c=" in SDP.



What's your problem?
Do you want to disable RTP-relay if UA is in the same LAN?

[CastB]

> Do you mean that the SIP Server is located in the same LAN?
or do you mean that both UA are located in the same LAN?

No, i mean that both UA are on different LAN (behind NAT), both using STUN and the BKK is somewhere else on a global IP.


>Are you sure that each UA set its global IP addresses in SDP which obtained from STUN?

Yes, i just checked again the wireshark traces at caller and callee: The initial invite from caller has the global IP adress in SDP in the "C line". However when this invite is received by the caller it is already rewritten by BKK (the c line contains the BKK adress)
(with BKK RTP relay setting : auto)


> What's your problem?
> Do you want to disable RTP-relay if UA is in the same LAN?

I want to use the "rtp relay = auto" function from BKK so that it decides to relay only if p2p is not possible. But i always end up with all calls relayed, (even if STUN set global ip 's in the c line and firewall not symmetric)

I do not want to turn rtp relay off completely

Thanks

[Haddas]

What kind of SIP UA are you using as the caller?
Can you paste its INVITE packet here?

[CastB]

Hi Haddas,

We used several different UA's with same result. Here is an example (amsip softphone). First part is the initial invite from caller, second part is the invite as it is received bij callee (With BKK rtp relay setting: auto)

Initial invite from caller
***************************
INVITE sip:callee_1@sip.castbasics.nl SIP/2.0
Via: SIP/2.0/UDP 192.168.33.199:51902;rport;branch=z9hG4bK2375776262
From: <sip:caller_1@sip.castbasics.nl>;tag=1998769363
To: <sip:callee_1@sip.castbasics.nl>
Call-ID: 3323806824
CSeq: 20 INVITE
Contact: <sip:caller_1@83.83.4.190:51902>
Content-Type: application/sdp
Max-Forwards: 70
User-Agent: antisip-a/4.5.1-Feb-17-2011
Subject: Talk
Supported: 100rel
Content-Length: 811

v=0
o=amsip 0 0 IN IP4 192.168.33.199
s=talk
c=IN IP4 83.83.4.190
t=0 0
a=ice-pwd:80908f0a40fcb91f2195dd
a=ice-ufrag:08d5
m=audio 30250 RTP/AVP 99 0 8 101
a=candidate:1 1 UDP 2130706431 192.168.33.199 30250 typ host
a=candidate:10 1 UDP 1694498815 83.83.4.190 30250 typ srflx raddr 192.168.33.199 rport 30250
a=rtpmap:99 speex/16000
a=fmtp:99 mode="6,any";vbr=on;cng=on
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11
a=setup:both
m=video 30376 RTP/AVP 114 115
b=AS:256
a=rtpmap:114 H264/90000
a=fmtp:114 profile-level-id=42800c; packetization-mode=1
a=ars
a=rtpmap:115 H263-1998/90000
a=candidate:1 1 UDP 2130706431 192.168.33.199 30376 typ host
a=candidate:10 1 UDP 1694498815 83.83.4.190 30376 typ srflx raddr 192.168.33.199 rport 30376


Invite as it is received bij callee
***********************************
INVITE sip:callee_1@87.208.103.207:5060;line=5834a76c6f121c5 SIP/2.0
Via: SIP/2.0/UDP 217.115.207.18:5060;rport;branch=z9hG4bKf272f2beadc4a5fa8244-4ba83979-b16fb973
Via: SIP/2.0/UDP 83.83.4.190:24090;rport=51902;branch=z9hG4bK2187513707
From: <sip:caller_1@sip.castbasics.nl>;tag=1998769363
To: <sip:callee_1@sip.castbasics.nl>
Call-ID: 3323806824
CSeq: 21 INVITE
Contact: <sip:caller_1@217.115.207.18:5060>
Proxy-Authorization: Digest username="caller_1", realm="castbasics.nl", nonce="6db9da364053ce40c30cb658a596b8fe2f1e5c4a", uri="sip:callee_1@sip.castbasics.nl",

response="73777623475e9606ec018766cb553b97", algorithm=MD5
Max-Forwards: 69
User-Agent: antisip-a/4.5.1-Feb-17-2011
Subject: Talk
Supported: 100rel
Record-Route: <sip:217.115.207.18:5060;lr>
Content-Type: application/sdp
Content-Length: 816

v=0
o=amsip 0 0 IN IP4 217.115.207.18
s=talk
c=IN IP4 217.115.207.18
t=0 0
a=ice-pwd:80908f0a40fcb91f2195dd
a=ice-ufrag:08d5
m=audio 10044 RTP/AVP 99 0 8 101
a=candidate:1 1 UDP 2130706431 192.168.33.199 30250 typ host
a=candidate:10 1 UDP 1694498815 83.83.4.190 30250 typ srflx raddr 192.168.33.199 rport 30250
a=rtpmap:99 speex/16000
a=fmtp:99 mode="6,any";vbr=on;cng=on
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11
a=setup:both
m=video 10542 RTP/AVP 114 115
b=AS:256
a=rtpmap:114 H264/90000
a=fmtp:114 profile-level-id=42800c; packetization-mode=1
a=ars
a=rtpmap:115 H263-1998/90000
a=candidate:1 1 UDP 2130706431 192.168.33.199 30376 typ host
a=candidate:10 1 UDP 1694498815 83.83.4.190 30376 typ srflx raddr 192.168.33.199 rport 30376

[Haddas]

Is the callee registered in the SIP Server?
Is the callee behind NAT?

Set the following setting and check the [mode:NAT] and [mode:RTPrelay] fields in the log.

http://wiki.brekeke.com/wiki/log-SIP-packets

[CastB]

Hi Haddas,


>Is the callee registered in the SIP Server?
>Is the callee behind NAT?

callee and caller are both registered and both behind NAT and both using STUN


>Set the following setting and check the [mode:NAT] and >[mode:RTPrelay] fields in the log.


mode:RTPrelay = auto
mode:NAT = on { Dst-Far-End-NAT }

[Haddas]

> mode:NAT = on { Dst-Far-End-NAT }

It means the callee (the destination user) is behind NAT..
That's why the SIP server relays RTP for traversaling NAT.

Have you enable callee's STUN?

[CastB]

>Have you enable callee's STUN?

Yes, i did and i am pretty sure that it works because p2p calls are working well if i force BKK to do not relay (using a dialplan rule)

Why does BKK not recognise callee is using stun?

[Haddas]

I'm not sure. a STUN feature is depending on client's implementation.


Set the following DialPlan rule and re-register the callee.

Matching Patterns

$request = ^REGISTER

Deploy Patterns

&register.contact.nat = false $continue = true

Then, try test calls again.

[CastB]

Hi Haddas,

I tried but it did not work, still relaying

> &register.contact.nat = false
What does this rule do exactly?

any other suggestions that i could try?

[Haddas]

After you set the above DialPlan rule, what did you see in the log?
Check the [mode:NAT] and [mode:RTPrelay] fields in the log.


> > &register.contact.nat = false
> What does this rule do exactly?

If it is "true", the server treats that the registering user is behind NAT.

[CastB]

I moved the dialplan rule to be the first rule to be executed and now it works:

mode:RTPrelay = auto
mode:Auth = auto
mode:NAT = auto

I am still wondering why BKK does not decide for himself that p2p is possible, however, i can work with this solution by writing my own dialplan

Thanks!

[Haddas]

> I moved the dialplan rule to be the first rule to be executed and now it works:

Do you mean the DialPlan rule solved your problem??


> I am still wondering why BKK does not decide for himself that p2p is possible

This is because the UAS (destination) is in behind NAT.

mode:NAT = on { Dst-Far-End-NAT }

[CastB]

>> I moved the dialplan rule to be the first rule to be executed and now it works:

>Do you mean the DialPlan rule solved your problem??

Yes, with this rule a P2P connection is established!

Since we will using the Sip server in a closed user group (with full control over the UA's) we will send information about the NAT type (obtained using STUN) within the SIP message. If the NAT type is p2p capable we will use the dialplan rule to force the register.contact.nat = false

[Haddas]

Yeah.. "&register.contact.nat = false" will meet your requirement.
Good luck.