×

Discussion Board

Results 1 to 5 of 5
  1. #1
    Registered User
    Join Date
    Jun 2008
    Posts
    4

    Question SIP: STUN used for registration but not outgoing calls

    Hi

    I'm encountering an odd issue where, when STUN is enabled on my N95 using the VoIP Settings application, the phone uses its STUN-discovered public IP address for registration but not for initiating outgoing calls.

    As a result, I can register with the PBX and receive incoming calls, but initiation of outgoing calls fails. The phone sends the INVITE request with its private inside-NAT IP address, so the SIP server/proxy has no way to route replies back to the phone.

    Code:
    202.2.2.2 -> 10.0.0.2  REGISTER sip:10.0.0.2
       To: MYUSERNAME@10.0.0.2
       Via: 10.0.0.1:5600
       Via: 202.2.2.2:5600      <-- Correct address discovered by STUN
    
    202.2.2.2 -> 10.0.0.2  INVITE   PSTNNUMBER@10.0.0.2
        Via: 10.0.0.1:5600
        Via: 192.168.44.2:5600  <-- Should be STUN-discovered address as used in REGISTER
    Anybody know how I can get the SIP user agent in the phone to use the public IP address it discovers with STUN for call initiation as well as for registration? All it needs to do is behave the same way for REGISTER and INVITE.


    Background on the network and configuration:

    (note: a config dump follows at the end of the post)

    The phone is an N95 running the 20.2.011 firmware (according to *#0000#).

    The SIP server is Asterisk based. It's not under my control; it's an applicance hosted at my work. The SIP server has a non-routable address, which for the examples below will be given as 10.0.0.2 .

    Working config 1: Direct connect to PBX / Registrar on with phone on same private network as PBX

    When connected directly to work's network by wifi (using 10.0.0.2 as the proxy as well as registration server) the phone registers with the PBX fine and can both make and receive calls. The phone gets an IP like 10.0.0.120 in this case.

    Working config 2: Connect to PBX via SIP proxy with phone on public network

    I have configured a siproxd SIP proxy on work's router/gateway, which in the examples below will be shown as having the private address 10.0.0.1 and public address 202.1.1.1. The machine is a Linux router with basic IP masquerade NAT and no SIP-specific conntrack/NAT configured. The SIP proxy is only used if explicitly configured in the phone. When the phone is connected directly to the Internet with a routable IP address I can register the phone with this proxy and both make and receive calls with it. The registration server settings still point to 10.0.0.2; the only change is the proxy server address.

    Working config 3: Connect to PBX via home SIP proxy forwarding to work SIP proxy, with phone on private home network

    My home network router, which will be given the internal IP 192.168.44.1 and public IP 202.2.2.2 in the examples below, also runs a SIP proxy using siproxd. It's a Linux router using basic IP masquerade NAT and no SIP-specific conntrack support etc. The SIP proxy is only used if explicitly configured in the phone. This SIP proxy forwards to the one at work (running on 202.1.1.1). I can register my phone with this proxy on my home network, and both make and receive calls on work's PBX. The registration server settings still point to 10.0.0.2; the only change is the proxy server address. The phone in this example has the IP address 192.168.44.2 .

    Non-working config: STUN on home network connecting to work proxy

    However, and this is the odd bit, if I connect my phone to my home network (so it gets the 192.168.44.2 address), set it to use work's SIP proxy (202.1.1.1) and use the VoIP Settings application to configure it to use a STUN server like stunserver.org, I cannot make outgoing calls. I can register with the proxy fine, and can receive calls made via work's PBX, but I cannot make calls.

    My home router is not messing with the packets except by rewriting their source/destination addresses in the IP headers for NAT. The payload is untouched.

    If I tcpdump the traffic at work's proxy and examine it with wireshark, I can see that the registration conversation looks like:

    Code:
    202.2.2.2 -> 10.0.0.2  REGISTER sip:10.0.0.2
       To: MYUSERNAME@10.0.0.2
       Via: 10.0.0.1:5600
       Via: 202.2.2.2:5600
    
    10.0.0.2 -> 202.2.2.2  200 OK
       To: MYUSERNAME@10.0.0.2
       Via: 10.0.0.1:5600
       Via: 202.2.2.2:5600
    ... which matches what I see from my home router. The phone has clearly discovered its public IP (202.2.2.2) through STUN, and is using it instead of its internal IP (192.168.44.2) in the Via: headers. If I turn STUN off, I see the internal IP instead in the VIA headers and registration stops working. So far, everything works as expected.

    With STUN enabled, the phone receives and accepts the SIP registration. I can now make a call to my direct indial PSTN number and the SIP gateway at work will successfully route the call to my N95 at home, which will ring. If I answer, voice data passes correctly in both directions. As expected.

    However, if I try to initiate a call from my N95 the INVITE message it sends looks like this at work's SIP proxy (where "PSTNNUMBER" is a known-good PSTN number that can be dialled successfully by my phone in the other non-STUN test cases above):

    Code:
    202.2.2.2 -> 10.0.0.2  INVITE   PSTNNUMBER@10.0.0.2
        Via: 10.0.0.1:5600
        Via: 192.168.44.2:5600
    In other words, the second Via header isn't using the STUN-discovered IP address, it's using the phone's internal IP address. Examination of the INVITE packet as it leaves my home network confirms this.

    So, for some reason the phone is using STUN to set its public IP address for REGISTER messages, but not for INVITE messages.

    Anybody have ideas as to why?

    (I can post less severely redacted TCP communication dumps if needed, but it'll take a while to go through the files and substitute usernames, passwords, etc).

    Right now I'm using it successfully though my home forwarding SIP proxy, but that won't be any good when I roam onto other NATed IP networks. Suggestions would be most welcome.

    Configuration

    Note:I know my public user name won't work for Internet callers. It's required to be set that way to register with work's PBX to make and receive PSTN calls through the SIP gateway. This issue isn't about receiving calls (be they Internet or PSTN) anyway.

    Tools -> Settings -> Connection -> SIP Settings:

    Code:
    Service profile: IETF
    Default access point: (my wifi)
    public user name: MYUSERNAME@10.0.0.2 
    use compression: No
    Registration: always on
    Use security: no          (Yes, I know. Working with the provider to improve that.)
    Registrar server:
        registrar server address: sip:10.0.0.2
        realm: 10.0.0.2      (As required by registrar)
        User name: MYUSERNAME
        Password: MYPASSWORD
        Transport Type: Auto
        Port: 5060
    Proxy server:
        (Address varies based on configuration given above)
        realm: 10.0.0.2
        User name: MYUSERNAME
        Password: MYPASSWORD
        Transport Type: Auto
        Port: 5060
        Allow Loose Routing: Yes
    Tools -> Settings -> Phone -> Call: All defaults, except "Send my Internet call ID" is set to "no" because of a PBX compatibility problem.

    Applications -> SIP VoIP Settings:

    ... are all defaults, except in the final test case where I explicitly mention enabling STUN with stunserver.org

    I've tried with loose routing off, but it's (as you would expect) even more broken.
    Last edited by ringerc; 2008-06-28 at 17:08. Reason: Improve summary, include config dump, mention call id

  2. #2
    Registered User
    Join Date
    Jun 2008
    Posts
    4

    SER / OpenSER

    The more I look into this, the more I think I should install a smarter SIP proxy/router like OpenSER at the remote end and have it take care of all NAT issues. I can then leave the N95's NAT handling broken (ie leave STUN off and don't use a local proxy) and it'll work even if I'm unfortunate enough to encounter symmetric NAT.

    I'm not at all sure that the N95 is smart enough to avoid rewriting SIP headers when the STUN server reports symmetric NAT, so STUN might even make things worse.

    I'm still interested in knowing whether the N95's STUN is just broken, I've misconfigured something, or I've misunderstood something - but I think I might just get around it using SER anyway.

  3. #3
    Registered User
    Join Date
    Jun 2008
    Posts
    4

    Thumbs down Re: SIP: STUN used for registration but not outgoing calls

    Good to know that Nokia take VoIP support in S60 seriously.

    </sarcasm>

  4. #4
    Registered User
    Join Date
    May 2009
    Posts
    9

    Re: SIP: STUN used for registration but not outgoing calls

    I am also having the same issue on my E71.
    STUN discovered IP address and port is used in REGISTER message, but not in INVITE.
    Is there any setting to enable it in INVITE message also ?

    I have the advanced sip settings tool from Nokia but it just enables modification of STUN server and port.


    Any reply would be appreciated.

    Thanks.

  5. #5
    Registered User
    Join Date
    May 2009
    Posts
    9

    Re: SIP: STUN used for registration but not outgoing calls

    Good to know that Nokia take VoIP support in S60 seriously.

    </sarcasm>

Similar Threads

  1. SIP calls over Packet data
    By thefamilyman in forum VoIP
    Replies: 8
    Last Post: 2010-04-27, 06:12
  2. STUN can stop your phoning instead of helping
    By bravotango in forum VoIP
    Replies: 1
    Last Post: 2008-10-15, 21:11
  3. Replies: 5
    Last Post: 2008-02-20, 09:52
  4. SIP: BYE/ 481 (No Dialog Found)!!!!!!!!!!
    By Mini Pillai in forum Symbian Networking & Messaging (Closed)
    Replies: 13
    Last Post: 2007-02-09, 04:52
  5. E61 SIP Works for outgoing, but not incoming
    By MuppetMaster in forum General Development Questions
    Replies: 1
    Last Post: 2006-11-21, 11:19

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •