Enhancement #2105
closedRFC: Groundwire configuration
0%
Description
Since Groundwire (iPhone SIP client) has many SIP account configuration options, I would wish to receive comments on my configured advanced settings.
Goals: security, low network traffic, reliability for receiving calls
Areas for improvement: Registration while in background mode (communication errors) --> to many re-registrations which can cause errors. The log file in the Groundwire application is that long, that copying and pasting "12 hours of log lines while the phone is in background mode" makes the iOS mail app crash.
Advanced settings
Incoming Calls: On with Backgrounding
Backgrounding Options
Host: <empty>
Leave empty to use proxy settings from your current account definition. It overrides your standard Outbound Proxy settings.
Transport Protocol: tls (sips) , tls (sip), tcp, auto
Expires: 3600
Track Errors: On , Off
NAT Traversal
Media: ICE , Auto, Off, STUN, TURN Always
Send Media Back: Off , On
Ensures that media streams are sent to the IP:port they are received from.
STUN Server: <empty>
TURN Username: <empty>
TURN Password: <empty>
Ignore Symmetric NAT: Off , On
Signaling:: Discover Global IP: Internal , External, Static
For providers requiring global IP discovery use External. For others you should be safe with Static or Internal. Static uses a faked private IP:port pair to solve issues when you are behind NAT and your provider groups registrations based on the full Contact URI. This option prevents changes in Contact header when network conditions change. To specify your own IP:port pair go to the Hacks section.
Signaling:: Send keepalives: Off , On
Send keepalive packets to keep the NAT ports open. Set if you have troubles getting incoming calls.
Outbound Proxy Enabled: Off , On
Optionally set to a proxy that performs some traffic manipulation e.g. TLS to UDP translation. This proxy is usually not related to the SIP provider. If regular proxy is specified as well, the SIP traffic will be routed to the proxy on the second hop.
Use the Outbound Proxy to route all SIP traffic through one server.
Proxy: proxy.sipthor.net:443
Codecs for WiFi: iLBC, G.711 u-Law, G.711 a-Law, G.722, Opus Wideband, Opus Narrowband, G.729a, GSM
Codecs for WiFi:: Packet Time: 20ms , 10ms, 30ms, 40ms, 50ms, 60ms
Codecs for WiFi:: Force Packet Time: Off , On
Higher packet times save bandwidth, but make the call quality more sensitive to packet loss. Bigger lost packets will make longer, more audible dropouts.
Codecs for WiFi:: Honor Remote Codecs: On , Off
If set, local codec order will be ignored and the first supported codec from the list sent by remote will be used.
Codecs for 3G: iLBC, Opus Narrowband, GSM, G.729a, G.711 u-Law, G.711 a-Law, Opus Wideband, G.722
Codecs for 3G:: Packet Time: 20ms , 10ms, 30ms, 40ms, 50ms, 60ms
Codecs for 3G:: Force Packet Time: Off , On
Codecs for 3G:: Honor Remote Codecs: Off , On
Auth User Name: <empty>
Transport Protocol: tls (sips) , udp, tcp, tls (sip)
VoiceMail Number: <empty>
DTMF Mode
Enabled DTMF Modes: RFC 2833, SIP INFO, audio
Send All Enabled: Off , On
When turned on all enabled DTMF methods are sent simultaneously. If pressing a single digit results in multiple presses on the receiver side, just turn this switch off.
Secure Calls :: SDES (RFC 4568)
Incoming Calls: Enabled , Disabled, Required
Outgoing Calls: Best Effort , Disabled, Required
A secure signaling channel is required for SDES. I.e. the protocol needs to be set to TLS. Due to security concerns it's also disabled for pushed calls. Please note SDES is prone to man0in-the-middle attacks and is largely dependant on the behavior of proxies along the SIP path. There may be hops between which the keys are transfered in clear text. If you would like to use SRTP over an insecure signaling channel you should try ZRTP instead.
Secure Calls :: ZRTP
Incoming Calls: Enabled , Disabled, Required
Outgoing Calls: Disabled
ZRTP is a media path key exchange method for SRTP. It can be used to secure calls even over insecure signaling channel (e.g. UDP). As opposed to SDES, it prevents eavesdropping opportunities at proxies. You will be able to accept ZRTP encrypted calls, however to initiate them you need to purchase the ZRTP add-on.
Expires: 3600
Registration period. The server may ask to increase this value.
Caller ID: <empty>
Caller Id Method: From Username , P-Preferred-Identity, P-Asserted-Identity, Remote-Party-ID
Sets caller ID headers of outgoing INVITE messages. Most VoIP providers will ignore these headers though.
Messaging
SIMPLE: Off , On
Enables SIP/SIMPLE messages to be sent and received.
Hacks
RTP Port Start: 10000
RTP Port End: 65535
SIP Port: <empty>
The listening port for SIP.
Forced Contact
Contact IP:port: <empty>
Fake fixed local IP and port can help if you are behind NAT and your provider groups registrations based on the full Contact URI. This setting prevents changes in Contact header when network conditions change. You should pick an IP from RFC 1918 range. E.g. 192.168.1.100:44444. Make sure to set Discover Global IP to Static to use this field.
Authorization
Send On Request: Off , On
Some providers do not like getting the Authorization header unless requested.
URI Scheme: sip: , tel:
The default scheme for numerical URIs is sip: or sips:. You can select tel: to enable support for RFC 3966 tel: URIs.
Nortelnetworks
Proxy-Require: Off , On
Some setups need Proxy-Require: com.nortelnetworks.firewall header to successfully traverse NAT.
SRTP
Prefer 80-bit Tags: Off , On
Prefer 80-bit authentication tags over 32-bit tags.
Registration State
Reuse: On , Off
Adjust Via: Off , On
The new registration will reuse the same Call-ID, CSeq sequence and rinstance as the previous one. We try to unregister stale contacts when network change. It's possible to alter Via headers to reflect Contact being unregistered.
Well-known codecs
Use rtpmap: Off , On
It's not necessary to include rtpmap attributes for well known codecs, but some providers erroneously require it.
Files
Updated by Adrian Georgescu over 11 years ago
- Status changed from New to In progress
You better create a wiki page here and use this ticket just to inform over updates:
Updated by Pro Backup over 11 years ago
I would have created a new wiki page our account has edit rights for http://wiki.sip2sip.info/projects/sip2sip/wiki/SipDevices
Unfortunately our account can "Watch" and view "History", but not "Edit" (see attached screen shot).
Would you please assing Edit rights to our account?
Updated by Tijmen de Mes over 11 years ago
I added you to the editors group. You should now be able to edit that page make a new one.
Updated by Pro Backup over 11 years ago
Page http://wiki.sip2sip.info/projects/sip2sip/wiki/SipDevicesAcrobitsGroundwire has been created.
Expires has been increased to maximum value of 86400, although Groundwire still (undesired) re-registers every 9 till 26 minutes when there are no network changes.
STUN Server has been set to "stun2.dns-hosting.info:3478", to prevent the extra network traffic for a DNS SRV lookup.
Updated by Adrian Georgescu over 11 years ago
Doing an extra DNS lookup does not save much battery as you still have to lookup stun2.dns-hosting.info. Secondly, this lookup is only used for ICE negotiation before starting a call. The phone is already busy with many tasks related starting the call and doing one less DNS lookup is completely useless as far as the battery life is concerned.
If you set the record manually and in the future we change the STUN SRV records to point to other server addresses, you will not learn about this change.
Updated by Pro Backup over 11 years ago
I agree, an extra DNS SRV lookup does not save much battery, and saves only 125 received bytes:
$ dig SRV _stun._udp.sip2sip.info
; <<>> DiG 9.7.6-P1 <<>> SRV _stun._udp.sip2sip.info
;; global options: +cmd
;; Got answer:
;; >>HEADER<< opcode: QUERY, status: NOERROR, id: 34644
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;_stun._udp.sip2sip.info. IN SRV
;; ANSWER SECTION:
_stun._udp.sip2sip.info. 300 IN SRV 0 0 3478 stun2.dns-hosting.info.
_stun._udp.sip2sip.info. 300 IN SRV 0 0 3478 stun1.dns-hosting.info.
;; Query time: 15 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Aug 5 18:52:09 2013
;; MSG SIZE rcvd: 125
But Groundwire doesn't lookup the SRV record before starting a call, but more often. See the fragments from 2 hours of its log file (which does not contain any INVITE):
===
2013-08-02T19:18:07.090Z
===
~~~REGSTATECHANGED-WHEN-UNREGISTERING, state = 5
2013-08-02T20:34:13.684Z
AccountResolver:
resolving A record of: proxy.sipthor.net, rqid=1002
AccountResolver:
resolving SRV record of: _stun._udp.sip2sip.info, rqid=1003
===
canceling reconnect
~~~~getCurrentState: resolver active, return Discovering
~~updateAccount: doUnregister returns false
2013-08-02T20:34:14.708Z
AccountResolver:
resolving A record of: proxy.sipthor.net, rqid=1004
AccountResolver:
resolving SRV record of: _stun._udp.sip2sip.info, rqid=1005
~~~~~getCurrentState: resolver active, return Discovering
===
2013-08-02T21:15:40.326Z
Updated by Adrian Georgescu over 11 years ago
The reason for doing STUN lookups may be the fact that the phone tries to determines its public IP (Discover Global IP) during REGISTER. This is wrong.
STUN for REGISTER (RFC3489) is an obsolete broken standard that claimed that it solved NAT traversal problem. As most of the end-points are located behind a NAT-ted router and using a private IP address, the way to obtain a public IP address was by using a protocol named STUN, which was wrongly described in 2003 as a NAT traversal solution (this is IETF standard RFC3489). Years later in 2008, this standard has been rectified (in RFC5389) to explicitly say that it does not provide a reliable solution for the original purpose and it should not be used the way it was originally thought. Using STUN is unreliable because it depends on the way the NAT routers are implemented, which is not standardized nor can be probed and guessing the IP address and port used for outbound connections was not working deterministically. Also, it is unsecure behavior for a server to trust an IP address expressed in a header by a client. The new version of the STUN protocol defined in RFC 5389 explains in which context STUN may be used and advises against the use of STUN as a standalone NAT traversal utility, quote from the standard:
Experience since the publication of RFC 3489 has found that classic STUN simply does not work sufficiently well to be a deployable solution
You should try to disable using STUN for register.
Updated by Pro Backup over 11 years ago
Setting a fixed value of "stun1.dns-hosting.info:3478" for "STUN server" seems to prevent "STUN for register".
Updated by Adrian Georgescu over 11 years ago
- Status changed from In progress to Closed
stun1 or stun2 makes no difference. Your client is simply behaving randomly and your are drawing the wrong conclusions.