voip-telefonie SX541 hinter Router

[karpe]

That looks fine, forewarding of STUN should not be needed (my experiance), because it is initiated by the Client. It is one reqoutst to STUN server and STUN will reply with the public IP and Port.

Make an ethereal trace and I will have a look on it if you want (post the file).
That will also show wheather te SX makes STUN calls or not, without the STUN how shoud it correctly assemble SIP packages without knowledge of the public IP?

Klaus

 

[rob]

Hi karpe + jockyw,

yes, indeed, PAT is not needed for STUN - it's initiated (like karpe explained) by the client and the answer is sent back from the STUN-Port to the initiating port.

@karpe:
i believe the SX doesn't do any STUN (how then - you do not configure it and even do not have the possibility to do that). I think it uses instead the proxy (which indeed is configured) and which is, in my understanding, more powerful than a STUN-Server. I placed 2 postings concerning that issue in this forum, but still got no answers to that - I think that portforwarding is not needed if you have the right NAT (no symmetric NAT) or instead of this a proxy configured. I could call/be called without even having configured a PAT on the gateway, quite strange - will try to find an answer for that with another guy in the VoIP environment.
@ jockyw:
I also would be interested in the trace. Could you post it right here.
Concerning your codecs, I think it would be even better to place it in the following order: 711 A, 711 U, 729.a, 723.1 (from powerful to weak depending on the negotiation with the other device).
After having changed the mode to host, I just did a reboot (because it's asking anyhow to save configuration) - so I did not do an explicite write, but thought, before the reboot config is saved anyhow after having answered the question with 'y'.

BTW, for debugging STUN issues, I detected a stun-client on sourceforge which will tell you which kind of NAT your gateway uses (full cone, restricted cone or port restricted cone) - just if somebody is interested in ...

Rob

 

[karpe]

Yes Rob, you are right, there is no STUN configuration on the SX.
Also with the proxy you should be right, more info is here:
http://www.tu-chemnitz.de/urz/lehre/mmn/scripte/html/sip/begriffe.htm
Thats the theorie,
but I am currently experimenting with my Zyxel and a Vigor router and without port forewarding it doesn't work :-(

Klaus

 

[karpe]

Hallo Rob,
ich habe eben noch mal ins RFC geschaut. Zu Proxies:
http://rfc.net/rfc3261.html#s16.1

Danach bin ich mir nicht mehr sicher, ob der Proxie wirklich die Änderungen im Paket vornehmen MUß, die eine ordnungsgemäße Kommunikation über NAT braucht.

Klaus

 

[rob]

@Klaus

this is the little peace which is lacking in my theory. I think the most effective to really prove or disprove my theory would be a complete trace with any kind of constellation possible (differenet kind of NATs, different SIP provider, different SIP phones).
I made e.g. a quite strange experience with STUN without using any PAT: the port which opened a connection to a 3478/UDP-Port-STUN was a RTP-Port to which answers were sent back. Not only that the answer for the STUN-request have gone through that connection, but also the full RTP-stream (which makes the whole constellation even stranger). In my oppinion, RTP-Ports might not only be used for STUN-connections, but also (if necessary) for the SIP signaling and for the full RTP stream (I could prove that at least with the freenet soft client).
Are you interested in going in details concerning that issue? Have a lack of people ...

Kind regards,

rob

 

[karpe]

Sorry rob, I think I lack on time for going deeper in that....
But I just found a link in the Internet with more info:

http://voip-info.org/wiki-NAT+and+VOIP

and there also http://www.sipcenter.com/sip.nsf/html/WEBB5YN5GE/$FILE/SIPNATtraversal.pdf

If I have news I'll tell, perhaps we get the trace.

Klaus

 

[JOCKYW2001]

Hi again guys,
Well the ethereal trace has to wait until this evening when I can plug my pc ethernet cable into the Siemens. I currently do all my testing with VNC from the office

I made a mistake when I mentioned before that calling out was still possible when incoming calls don't work. Both incoming and outgoing calls are no longer possible. If the Sipgate 10000 testnumber is called several minutes after reboot it says something like "zur zeit nicht möglich".
I think that the problem is because of a SIP registration timeout and the SX doesn't re-register. From the serial console debug info I can see that the SX541 registers with Sipgate, but never re-registers. I seem to remember that there is a registration timeout of ca. 2 minutes, but I'm not sure. Perhaps the SX541 doesn't re-register because it thinks that with a fixed wan IP it's not necessary? Anyone ideas?

/JockyW

PS: I will try to capture the SIP log from the serial console.

 

[karpe]

Hi JockyW,

I think that can't be, because even with a fixed IP the SIP has to reregister how else can the Registrar know that you are still online (UDP is connectionless).

I suggest to look at you router, how long does it keep the NAT ports open? My idea is that, the Siemens doesn't know how to deal with NAT because it normally doesn't use it (VOIP normally sits on the public side).


Klaus

 

[rob]

Hi there,

also think it has to do with closed sockets if it works just for a while.

@jockyw:
could you determine exactly the time period where calls are still possible (I think the best is to begin a call and determine step by step by decreasing time when calls are no longer possible) - this looks to me a kind of keepalive timeout. If it's a value like 3 or 5 minutes, I think we have to search in the timeouts. But anyhow, the phenomen is quite strange.
Sorry for the question (I think you already verified it), but your D-Link-Router (VoIP-able?) does not use 5060/UDP on his own? I had problems with the binding of 5060/UDP for PAT (Softphone) and ATA-part of SX541 (which is logical, but the SX did not signal it).

Rob

 

[JOCKYW2001]

Hi Klaus, tomorrow I'll bring my SX541 into the office. then I can give it a public IP and it will connect it in front of the firewall. Should work fine then, if at least re-registration is not the problem. Re-registration seems to be an issue tho. You find a lot of problems if you google for "sip registration timeout sipgate".

/JockyW

Btw: it seems our SX541 is an Asterisk implementation. During some calls I have seen something like "agent: Asterisk" in the serial console.

 

[JOCKYW2001]

@jockyw:
could you determine exactly the time period where calls are still possible (I think the best is to begin a call and determine step by step by decreasing time when calls are no longer possible) - this looks to me a kind of keepalive timeout. If it's a value like 3 or 5 minutes, I think we have to search in the timeouts. But anyhow, the phenomen is quite strange.
Sorry for the question (I think you already verified it), but your D-Link-Router (VoIP-able?) does not use 5060/UDP on his own? I had problems with the binding of 5060/UDP for PAT (Softphone) and ATA-part of SX541 (which is logical, but the SX did not signal it).

I have the whole evening to determine possible timeouts and prepare ethereal and serial console SIP traces. I will not rest until it works
No, the D-Link doesn't use 5060/UDP for anything else.

Cheers, JockyW

 

[bobberle101]

hey guys,

...picking up on the original thread...

has anyone of you managed to connect the sx541 to a router (that doesnt support wds) via WLAN? the initial posts have inspired me to some testing, however I ain't got a clue.

As long as I dont even get the internet working, I won't even be able to take care of configuring voip.

I'd be very grateful for some ideas...

bobberle

 

[JOCKYW2001]

What follows are 3 serial console logs:
1. right after booting the SX541 when the two SIP accounts are registering with Sipgate
2. when I make a call from my fixed network phone to "JockyW Line1" on the SX541
3. When I call the Sipgate test# from "JockyW Line1"

(Note: I have edited the phone numbers somewhat)

/JockyW

---------------------------------------------------------------------------
Here is the log right after rebooting the SX541. this is where the two Sipgate accounts "5551111" ("JockyW Line1") and "5552222" ("JockyW Line2") are registering with Sipgate

UPnP is disabled
Starting Multitask...
REGISTER sip:sipgate.de:5060 SIP/2.0

Call-ID: [email protected]

Contact: "5551111"<sip:[email protected]:5060>

Content-Language: en

Content-Length: 0

CSeq: 1 REGISTER

Expires: 1800

From: "JockyW Line1"<sip:[email protected]>;tag=siemens-sx541-1.62-77833404-b3d7976b-796372492

Max-Forwards: 70

To: "JockyW Line1"<sip:[email protected]>

Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK6a4695b2fefa11794adc511dd748b1af


REGISTER sip:sipgate.de:5060 SIP/2.0

Call-ID: [email protected]

Contact: "5552222"<sip:[email protected]:5060>

Content-Language: en

Content-Length: 0

CSeq: 1 REGISTER

Expires: 1800

From: "JockyW Line1"<sip:[email protected]>;tag=siemens-sx541-1.62-1229627538-832dc8da-342495743

Max-Forwards: 70

To: "JockyW Line1"<sip:[email protected]>

Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK54d7e5eca4ca45384472ae9408010c93


SIP/2.0 401 Unauthorized

Call-ID: [email protected]

CSeq: 1 REGISTER

From: "JockyW Line1"<sip:[email protected]>;tag=siemens-sx541-1.62-77833404-b3d7976b-796372492

To: "JockyW Line1"<sip:[email protected]>;tag=b11cb9bb270104b49a99a995b8c68544.8ece

Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK6a4695b2fefa11794adc511dd748b1af;rport=5060;received=217.93.67.myIP

WWW-Authenticate: Digest realm="sipgate.de", nonce="42499a8a2a379a7959b4f5f1b108209c57b32b88"

Server: sipgate ser

Content-Length: 0

Warning: 392 217.10.79.9:5060 "Noisy feedback tells: pid=19041 req_src_ip=217.93.67.myIP req_src_port=5060 in_uri=sip:sipgate.de:5060 out_uri=sip:sipgate.de:5060 via_cnt==1"


REGISTER sip:sipgate.de:5060 SIP/2.0

Authorizationigest username="5551111",realm="sipgate.de",nonce="42499a8a2a379a7959b4f5f1b108209c57b32b88",uri="sip:sipgate.de:5060",response="e23dec1d559a3c013548e1311715f724"

Call-ID: [email protected]

Contact: "5551111"<sip:[email protected]:5060>

Content-Language: en

Content-Length: 0

CSeq: 2 REGISTER

Expires: 1800

From: "JockyW Line1"<sip:[email protected]>;tag=siemens-sx541-1.62-77833404-b3d7976b-796372492

Max-Forwards: 70

To: "JockyW Line1"<sip:[email protected]>

Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bKd4240deb5f5eb2a37055b6ad6777544c


SIP/2.0 401 Unauthorized

Call-ID: [email protected]

CSeq: 1 REGISTER

From: "JockyW Line1"<sip:[email protected]>;tag=siemens-sx541-1.62-1229627538-832dc8da-342495743

To: "JockyW Line1"<sip:[email protected]>;tag=b11cb9bb270104b49a99a995b8c68544.f58b

Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK54d7e5eca4ca45384472ae9408010c93;rport=5060;received=217.93.67.myIP

WWW-Authenticate: Digest realm="sipgate.de", nonce="42499a8b0ae2cb583de97390d303ddb5dc83e034"

Server: sipgate ser

Content-Length: 0

Warning: 392 217.10.79.9:5060 "Noisy feedback tells: pid=19042 req_src_ip=217.93.67.myIP req_src_port=5060 in_uri=sip:sipgate.de:5060 out_uri=sip:sipgate.de:5060 via_cnt==1"


REGISTER sip:sipgate.de:5060 SIP/2.0

Authorizationigest username="5552222",realm="sipgate.de",nonce="42499a8b0ae2cb583de97390d303ddb5dc83e034",uri="sip:sipgate.de:5060",response="12678588c84d8843d17ba67b761300db"

Call-ID: [email protected]

Contact: "5552222"<sip:[email protected]:5060>

Content-Language: en

Content-Length: 0

CSeq: 2 REGISTER

Expires: 1800

From: "JockyW Line1"<sip:[email protected]>;tag=siemens-sx541-1.62-1229627538-832dc8da-342495743

Max-Forwards: 70

To: "JockyW Line1"<sip:[email protected]>

Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK84689706b85cf055ee1228cd30fc4e90


SIP/2.0 200 OK

Call-ID: [email protected]

CSeq: 2 REGISTER

From: "JockyW Line1"<sip:[email protected]>;tag=siemens-sx541-1.62-77833404-b3d7976b-796372492

To: "JockyW Line1"<sip:[email protected]>;tag=b11cb9bb270104b49a99a995b8c68544.8e8b

Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bKd4240deb5f5eb2a37055b6ad6777544c;rport=5060;received=217.93.67.myIP

Contact: <sip:[email protected]:61100>;q=0.00;expires=1084

Contact: <sip:[email protected]:61104>;q=0.00;expires=1547

Contact: <sip:[email protected]:5060>;q=0.00;expires=1800

Server: sipgate ser

Content-Length: 0

Warning: 392 217.10.79.9:5060 "Noisy feedback tells: pid=19048 req_src_ip=217.93.67.myIP req_src_port=5060 in_uri=sip:sipgate.de:5060 out_uri=sip:sipgate.de:5060 via_cnt==1"


SIP/2.0 200 OK

Call-ID: [email protected]

CSeq: 2 REGISTER

From: "JockyW Line1"<sip:[email protected]>;tag=siemens-sx541-1.62-1229627538-832dc8da-342495743

To: "JockyW Line1"<sip:[email protected]>;tag=b11cb9bb270104b49a99a995b8c68544.0c4e

Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK84689706b85cf055ee1228cd30fc4e90;rport=5060;received=217.93.67.myIP

Contact: <sip:[email protected]:61100>;q=0.00;expires=1085

Contact: <sip:[email protected]:61104>;q=0.00;expires=1547

Contact: <sip:[email protected]:5060>;q=0.00;expires=1800

Server: sipgate ser

Content-Length: 0

Warning: 392 217.10.79.9:5060 "Noisy feedback tells: pid=19044 req_src_ip=217.93.67.myIP req_src_port=5060 in_uri=sip:sipgate.de:5060 out_uri=sip:sipgate.de:5060 via_cnt==1"

--------------------------------------------------------------------

Here is the serial console log when I call "49xxxx187JockyW1" from my fixed network phone number "49My_Phone_Nr" :

INVITE sip:[email protected]:5060 SIP/2.0

Record-Route: <sip:[email protected];ftag=as7c79a338;lr=on>

Max-Forwards: 9

Record-Route: <sip:[email protected];ftag=as7c79a338;lr=on>

Via: SIP/2.0/UDP 217.10.79.9;branch=z9hG4bKb433.2659a211.2

Via: SIP/2.0/UDP 217.10.79.8;branch=z9hG4bKb433.bf27c245.0

Via: SIP/2.0/UDP 217.10.67.4:5060;branch=z9hG4bK465ea7c4

From: "49My_Phone_Nr" <sip:[email protected]>;tag=as7c79a338

To: <sip:[email protected]>

Contact: <sip:[email protected]>

Call-ID: [email protected]

CSeq: 102 INVITE

User-Agent: Asterisk PBX

Date: Tue, 29 Mar 2005 17:45:40 GMT

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER

Content-Type: application/sdp

Content-Length: 372

Sipgate-Authentication: accepted


v=0

o=root 26665 26665 IN IP4 217.10.67.4

s=session

c=IN IP4 217.10.79.48

t=0 0

m=audio 37086 RTP/AVP 8 0 3 10 97 18 2 5

a=rtpmap:8 PCMA/8000

a=rtpmap:0 PCMU/8000

a=rtpmap:3 GSM/8000

a=rtpmap:10 L16/8000

a=rtpmap:97 iLBC/8000

a=rtpmap:18 G729/8000

a=rtpmap:2 G726-32/8000

a=rtpmap:5 DVI4/8000

a=silenceSuppff - - - -

a=direction:active

a=nortpproxy:yes

SIP/2.0 100 Trying

Call-ID: [email protected]

Content-Length: 0

Content-Type: application/sdp

CSeq: 102 INVITE

From: "49My_Phone_Nr"<sip:[email protected]>;tag=as7c79a338

To: <sip:[email protected]>

Via: SIP/2.0/UDP 217.10.79.9;branch=z9hG4bKb433.2659a211.2

Via: SIP/2.0/UDP 217.10.79.8;branch=z9hG4bKb433.bf27c245.0

Via: SIP/2.0/UDP 217.10.67.4:5060;branch=z9hG4bK465ea7c4


SIP/2.0 180 Ringing

Call-ID: [email protected]

Contact: "5551111"<sip:[email protected]:5060>

Content-Length: 0

CSeq: 102 INVITE

From: "49My_Phone_Nr"<sip:[email protected]>;tag=as7c79a338

Record-Route: <sip:[email protected];ftag=as7c79a338;lr=on>,<sip:[email protected];ftag=as7c79a338;lr=on>

To: <sip:[email protected]>;tag=siemens-sx541-1.62-440360516-351a8e14-1892956317

Via: SIP/2.0/UDP 217.10.79.9;branch=z9hG4bKb433.2659a211.2

Via: SIP/2.0/UDP 217.10.79.8;branch=z9hG4bKb433.bf27c245.0

Via: SIP/2.0/UDP 217.10.67.4:5060;branch=z9hG4bK465ea7c4


SIP/2.0 200 OK

Allow:INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,REFER

Call-ID: [email protected]

Contact: "5551111"<sip:[email protected]:5060>

Content-Length: 142

Content-Type: application/sdp

CSeq: 102 INVITE

From: "49My_Phone_Nr"<sip:[email protected]>;tag=as7c79a338

Record-Route: <sip:[email protected];ftag=as7c79a338;lr=on>,<sip:[email protected];ftag=as7c79a338;lr=on>

Supported: replaces

To: <sip:[email protected]>;tag=siemens-sx541-1.62-440360516-351a8e14-1892956317

Via: SIP/2.0/UDP 217.10.79.9;branch=z9hG4bKb433.2659a211.2

Via: SIP/2.0/UDP 217.10.79.8;branch=z9hG4bKb433.bf27c245.0

Via: SIP/2.0/UDP 217.10.67.4:5060;branch=z9hG4bK465ea7c4


v=0

o=5551111 2491419456 1 IN IP4 192.168.1.100

s=Session SDP

c=IN IP4 192.168.1.100

t=0 0

m=audio 5002 RTP/AVP 8

a=rtpmap:8 PCMA/8000

ACK sip:[email protected]:5060 SIP/2.0

Record-Route: <sip:[email protected];ftag=as7c79a338;lr=on>

Max-Forwards: 9

Record-Route: <sip:[email protected];ftag=as7c79a338;lr=on>

Via: SIP/2.0/UDP 217.10.79.9;branch=0

Via: SIP/2.0/UDP 217.10.79.8;branch=0

Via: SIP/2.0/UDP 217.10.67.4:5060;branch=z9hG4bK67e2cab4

From: "49My_Phone_Nr" <sip:[email protected]>;tag=as7c79a338

To: <sip:[email protected]>;tag=siemens-sx541-1.62-440360516-351a8e14-1892956317

Contact: <sip:[email protected]>

Call-ID: [email protected]

CSeq: 102 ACK

User-Agent: Asterisk PBX

Content-Length: 0


BYE sip:[email protected]:5060 SIP/2.0

Record-Route: <sip:[email protected];ftag=as7c79a338;lr=on>

Max-Forwards: 9

Record-Route: <sip:[email protected];ftag=as7c79a338;lr=on>

Via: SIP/2.0/UDP 217.10.79.9;branch=z9hG4bKc433.56ca1d11.0

Via: SIP/2.0/UDP 217.10.79.8;branch=z9hG4bKc433.c96586a3.0

Via: SIP/2.0/UDP 217.10.67.4:5060;branch=z9hG4bK4526c32f

From: "49My_Phone_Nr" <sip:[email protected]>;tag=as7c79a338

To: <sip:[email protected]>;tag=siemens-sx541-1.62-440360516-351a8e14-1892956317

Contact: <sip:[email protected]>

Call-ID: [email protected]

CSeq: 103 BYE

User-Agent: Asterisk PBX

Content-Length: 0

Route: <sip:[email protected]:5060>


SIP/2.0 200 OK

Call-ID: [email protected]

Content-Length: 0

CSeq: 103 BYE

From: "49My_Phone_Nr"<sip:[email protected]>;tag=as7c79a338

Record-Route: <sip:[email protected];ftag=as7c79a338;lr=on>,<sip:[email protected];ftag=as7c79a338;lr=on>

To: <sip:[email protected]>;tag=siemens-sx541-1.62-440360516-351a8e14-1892956317

Via: SIP/2.0/UDP 217.10.79.9;branch=z9hG4bKc433.56ca1d11.0

Via: SIP/2.0/UDP 217.10.79.8;branch=z9hG4bKc433.c96586a3.0

Via: SIP/2.0/UDP 217.10.67.4:5060;branch=z9hG4bK4526c32f

Here is the log when I call Sipgate test number 10000 from "5551111" ("JockyW Line1")

INVITE sip:[email protected] SIP/2.0

Allow:INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,REFER

Call-ID: [email protected]

Contact: "5551111"<sip:[email protected]:5060>

Content-Disposition: session

Content-Encoding: identity

Content-Language: en

Content-Length: 216

Content-Type: application/sdp

CSeq: 3 INVITE

Expires: 180

From: "JockyW Line1"<sip:[email protected]>;tag=siemens-sx541-1.62-419520849-4dfafda6-1482512430

Max-Forwards: 70

Supported: replaces

To: <sip:[email protected]>

Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK671a1714202f2669aa56b181cafb9a04



v=0

o=5551111 2491419536 1 IN IP4 192.168.1.100

s=Session SDP

c=IN IP4 192.168.1.100

t=0 0

m=audio 5002 RTP/AVP 8 0 18 4

a=rtpmap:8 PCMA/8000

a=rtpmap:0 PCMU/8000

a=rtpmap:18 G729/8000

a=rtpmap:4 G723/8000

SIP/2.0 407 Proxy Authentication Required

Call-ID: [email protected]

CSeq: 3 INVITE

From: "JockyW Line1"<sip:[email protected]>;tag=siemens-sx541-1.62-419520849-4dfafda6-1482512430

To: <sip:[email protected]>;tag=b11cb9bb270104b49a99a995b8c68544.8800

Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK671a1714202f2669aa56b181cafb9a04;rport=5060;received=217.93.67.myIP

Proxy-Authenticate: Digest realm="sipgate.de", nonce="42499fbe0ab9ee740e3f08812eb3d8bdea8b2685"

Server: sipgate ser

Content-Length: 0

Warning: 392 217.10.79.9:5060 "Noisy feedback tells: pid=19043 req_src_ip=217.93.67.myIP req_src_port=5060 in_uri=sip:[email protected] out_uri=sip:[email protected] via_cnt==1"



ACK sip:[email protected] SIP/2.0

Call-ID: [email protected]

Content-Length: 0

CSeq: 3 ACK

From: "JockyW Line1"<sip:[email protected]>;tag=siemens-sx541-1.62-419520849-4dfafda6-1482512430

Max-Forwards: 70

To: <sip:[email protected]>;tag=b11cb9bb270104b49a99a995b8c68544.8800

Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK671a1714202f2669aa56b181cafb9a04



INVITE sip:[email protected] SIP/2.0

Allow:INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,REFER

Call-ID: [email protected]

Contact: "5551111"<sip:[email protected]:5060>

Content-Disposition: session

Content-Encoding: identity

Content-Language: en

Content-Length: 216

Content-Type: application/sdp

CSeq: 4 INVITE

Expires: 180

From: "JockyW Line1"<sip:[email protected]>;tag=siemens-sx541-1.62-419520849-4dfafda6-1482512430

Max-Forwards: 70

Proxy-Authorization: Digest username="5551111",realm="sipgate.de",nonce="42499fbe0ab9ee740e3f08812eb3d8bdea8b2685",uri="sip:[email protected]",response="3a38f1864e44c5a9646feef63010f500"

Supported: replaces

To: <sip:[email protected]>

Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK9433a0da5e69ecce1982947e54e9143b



v=0

o=5551111 2491419536 1 IN IP4 192.168.1.100

s=Session SDP

c=IN IP4 192.168.1.100

t=0 0

m=audio 5002 RTP/AVP 8 0 18 4

a=rtpmap:8 PCMA/8000

a=rtpmap:0 PCMU/8000

a=rtpmap:18 G729/8000

a=rtpmap:4 G723/8000

SIP/2.0 100 trying -- your call is important to us

Call-ID: [email protected]

CSeq: 4 INVITE

From: "JockyW Line1"<sip:[email protected]>;tag=siemens-sx541-1.62-419520849-4dfafda6-1482512430

To: <sip:[email protected]>

Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK9433a0da5e69ecce1982947e54e9143b;rport=5060;received=217.93.67.myIP

Server: sipgate ser

Content-Length: 0

Warning: 392 217.10.79.9:5060 "Noisy feedback tells: pid=19045 req_src_ip=217.93.67.myIP req_src_port=5060 in_uri=sip:[email protected] out_uri=sip:[email protected] via_cnt==1"



SIP/2.0 200 OK

Via: SIP/2.0/UDP 192.168.1.100:5060;received=217.93.67.myIP;branch=z9hG4bK9433a0da5e69ecce1982947e54e9143b

Record-Route: <sip:[email protected];ftag=siemens-sx541-1.62-419520849-4dfafda6-1482512430;lr=on>

From: "JockyW Line1"<sip:[email protected]>;tag=siemens-sx541-1.62-419520849-4dfafda6-1482512430

To: <sip:[email protected]>;tag=as6c0e1229

Call-ID: [email protected]

CSeq: 4 INVITE

User-Agent: Asterisk PBX

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER

Contact: <sip:[email protected]>

Content-Type: application/sdp

Content-Length: 353



v=0

o=root 23555 23555 IN IP4 217.10.79.30

s=session

c=IN IP4 217.10.79.54

t=0 0

m=audio 35708 RTP/AVP 8 0 3 10 97 18 2 5

a=rtpmap:8 PCMA/8000

a=rtpmap:0 PCMU/8000

a=rtpmap:3 GSM/8000

a=rtpmap:10 L16/8000

a=rtpmap:97 iLBC/8000

a=rtpmap:18 G729/8000

a=rtpmap:2 G726-32/8000

a=rtpmap:5 DVI4/8000

a=silenceSuppff - - - -

a=nortpproxy:yes

ACK sip:[email protected] SIP/2.0

Call-ID: [email protected]

Content-Language: en

Content-Length: 0

CSeq: 4 ACK

From: "JockyW Line1"<sip:[email protected]>;tag=siemens-sx541-1.62-419520849-4dfafda6-1482512430

Max-Forwards: 70

Proxy-Authorization: Digest username="5551111",realm="sipgate.de",nonce="42499fbe0ab9ee740e3f08812eb3d8bdea8b2685",uri="sip:[email protected]",response="3a38f1864e44c5a9646feef63010f500"

Route: <sip:[email protected];ftag=siemens-sx541-1.62-419520849-4dfafda6-1482512430;lr=on>

To: <sip:[email protected]>;tag=as6c0e1229

Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK1f56e13cafda776a942ff104dabe0f96



BYE sip:[email protected]:5060 SIP/2.0

Max-Forwards: 10

Record-Route: <sip:[email protected];ftag=as6c0e1229;lr=on>

Via: SIP/2.0/UDP 217.10.79.9;branch=z9hG4bK8683.c5569ed.0

Via: SIP/2.0/UDP 217.10.79.30:5060;branch=z9hG4bK7bebf6e0;rport=5060

From: <sip:[email protected]>;tag=as6c0e1229

To: "JockyW Line1"<sip:[email protected]>;tag=siemens-sx541-1.62-419520849-4dfafda6-1482512430

Contact: <sip:[email protected]>

Call-ID: [email protected]

CSeq: 102 BYE

User-Agent: Asterisk PBX

Content-Length: 0

Route: <sip:[email protected]:5060>



SIP/2.0 200 OK

Call-ID: [email protected]

Content-Length: 0

CSeq: 102 BYE

From: <sip:[email protected]>;tag=as6c0e1229

Record-Route: <sip:[email protected];ftag=as6c0e1229;lr=on>

To: "JockyW Line1"<sip:[email protected]>;tag=siemens-sx541-1.62-419520849-4dfafda6-1482512430

Via: SIP/2.0/UDP 217.10.79.9;branch=z9hG4bK8683.c5569ed.0

Via: SIP/2.0/UDP 217.10.79.30:5060;rport=5060;branch=z9hG4bK7bebf6e0

 

[JOCKYW2001]

I looked into the log of my router and found that UDP packets are blocked by my router. These UDP packets are sent from Sipgate (port 5060) to the wan IP of my router (port 63150). Here is an example of what's in the log:

Mar/30/2005 11:04:11 Drop UDP packet from WAN 217.10.79.9:5060 217.93.xx.yy:63150 Rule: Default deny

217.10.79.9:5060 is Sipgate port 5060
217.93.xx.yy:63150 is my wan IP port 63150

It's very likely that these are keep-alive packets which Sipgate sends to the Siemens. I'm afraid that port 63150 is a random port which the Siemens has used before to connect to Sipgate.

I'm afraid that with the limited firewall and portforwarding options there is no way to configure the D-Link to pass traffic transparantly to the Siemens

If anyone has a good tip please let me know.

/JockyW

 

[rob]

Hi Jockyw,

- can you determine/guess what exactly 63150 did - as in the SIP-log I only see Port (outgoing) 5060/UDP -> 217.10.79.9:5060 (proxy inserted rport and received statements in Register-SDP-Part; rport should be the source port after NAT). At first, I supposed that this was the source port for the registration which ran in a timeout of the NAT-rules (the NAT engine didn't know anymore that mapping), but in the SIP-logs 63150 does not appear.
- what does the SIP log look like if it does no longer work (after some minutes, you wrote in an earlier posting)
- I think you wrote in an earlier posting that even by placing the machine in the DMZ, it didn't work. In that constellation, the keepalives shouldn't be an impact.

Rob

 

[JOCKYW2001]

Hi rob,

- can you determine/guess what exactly 63150 did - as in the SIP-log I only see Port (outgoing) 5060/UDP -> 217.10.79.9:5060 (proxy inserted rport and received statements in Register-SDP-Part; rport should be the source port after NAT). At first, I supposed that this was the source port for the registration which ran in a timeout of the NAT-rules (the NAT engine didn't know anymore that mapping), but in the SIP-logs 63150 does not appear.

I haven't been able to produce an ethereal trace yet, I need to get myself a hub. I'll take one from work 2day.

- what does the SIP log look like if it does no longer work (after some minutes, you wrote in an earlier posting)

For an incoming VoIP call there is nothing logged, simply because the Siemens can not be reached from outside.
For an outgoing call it is different. There is either:
1. a log like I posted before (trace 3) taken at the moment when Sipgate service is still working in both directions (incoming calls and outgoing calls both work)
2. there is the situation that incoming calls do no longer work, but outgoing still work, this results in the same trace 3 as posted before
3. there is the situation that both incoming calls and outgoing calls do no longer work. I can still call the Sipgate 10000 testnumber, but instead of the sweet female voice ("ihr telefon funzt ...") you then hear the unfriendly male voice ("service nicht verfügbar ... or something like that"). For this situation I haven't made a trace, I will do that this evening.

- I think you wrote in an earlier posting that even by placing the machine in the DMZ, it didn't work. In that constellation, the keepalives shouldn't be an impact.

I am just testing that again, this time I have removed the 3 portforward rules which I before still had activated in parallel. I will post results this evening

/JockyW

 

[rob]

@JockyW:

am impatient to see them ;-) ;-) ;-).

BTW, how did U access the console logs? Didn't find that posting again (to be sincere: just too lazy).

Another thing which gets in my mind: could you please determine your NAT type of the D-Link-Box with the Stun-Client on Sourcefourge? - http://sourceforge.net/projects/stun/

Rob

 

[JOCKYW2001]

BTW, how did U access the console logs? Didn't find that posting again (to be sincere: just too lazy).

with a serial datacable, see:
http://www.ip-phone-forum.de/forum/viewtopic.php?t=13523

Another thing which gets in my mind: could you please determine your NAT type of the D-Link-Box with the Stun-Client on Sourcefourge? - http://sourceforge.net/projects/stun/

no problem, will try this evening

ciao, JockyW

 

[JOCKYW2001]

hi rob,

am impatient to see them ;-) ;-) ;-).

just did a first set of traces with interesting results!

short after the siemens successfully registers with sipgate, sipgate sends a udp packet to port 61697 of the siemens, which answers a ICMP packet "destination unreachable (port unreachable)". The same sequence repeats. When I then call the siemens from my fixed network phone a SIP INVITE packet is sent to port 61697 of the siemens which again answers a ICMP packet "destination unreachable (port unreachable)". The same sequence repeats itself until my fixed network phone displays remote partner hung up. This call is not logged in the serial console and neither is the siemens ringing. This was just a quick trace, will do more systematic tests now.

[edit1]: just did another trace in the period where both incoming and outgoing calls work perfect: during that period the SIP port is always 5060 ! So as soon as sipgate starts to use these crazy ports >60000 trouble starts.

I installed Winstun and it reports this:

Stun Server: larry.gloo.net
Cone Nat detect - VoIP will work with STUN
Does not preserve port number
Supports hairpin of media
Public IP address: 217.93.xx.yy (my wan IP)

and

Stun Server: 192.168.1.1 (my D-Link)
Could not reach the stun server - check server name is correct
Preserves port number
Does not supports hairpin of media
Public IP address: 0.0.0.0

 

[rob]

Hi Jockyw,

output of the stun-client seems strange to me. I used just the client from http://ovh.dl.sourceforge.net/sourceforge/stun/client.exe with any STUN-Server (e.g. iphone-stun.freenet.de).
Concerning the UDP-Packet to the Siemens-Box, it is strange that Sipgate wants to send Back answers to a Port the SX541 did not open. Was this port never used before - it could be that it was used for Registration (already NATed) and was no longer existing in the NAT mapping table cause the socket ran in a timeout ... Is the 61697 already "de"natted (incoming request after having left the NAT mapping table of the gateway) or is this the Port from the Sipgate-Server to your gateway?

Rob