[Users] nathelper & fax = bug ?

Connection scheme: UA - router with NAT - OpenSER with nathelper - PSTN gateway (Cisco AS5350) (192.168.13.109) (217.107.59.194) (62.33.22.14) (62.33.22.11) Both incoming and outgoing calls work right. Openser uses the nathelper module for proxing of rtp stream of NAT UA. Here is example of SIP messages (call from PSTN through a gateway): 15:37:07.406529 IP 62.33.22.11.54581 > 62.33.22.14.5060: UDP, length 1121 E..}........>!..>!...5...i.hINVITE sip:78142799233@voapp.ru:5060 SIP/2.0 Via: SIP/2.0/UDP 62.33.22.11:5060;x-route-tag="tgrp:ipphone" From: <sip:78142764164@62.33.22.11>;tag=A515D068-227D To: <sip:78142799233@voapp.ru> Date: Fri, 04 Aug 2006 11:37:07 GMT Call-ID: 64A759D3-22E411DB-8B0DFF2E-66029374(a)195.161.136.114 Supported: timer,100rel Min-SE: 1800 Cisco-Guid: 1688609156-585372123-2332753710-1711444852 User-Agent: Cisco-SIPGateway/IOS-12.x Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO CSeq: 101 INVITE Max-Forwards: 6 Remote-Party-ID: <sip:78142764164@62.33.22.11>;party=calling;screen=yes;privacy=off Timestamp: 1154691427 Contact: <sip:78142764164@62.33.22.11:5060> Expires: 180 Allow-Events: telephone-event Content-Type: application/sdp Content-Length: 316 v=0 o=CiscoSystemsSIP-GW-UserAgent 4330 9654 IN IP4 62.33.22.11 s=SIP Call c=IN IP4 62.33.22.11 t=0 0 m=audio 17088 RTP/AVP 3 18 8 0 4 c=IN IP4 62.33.22.11 a=rtpmap:3 GSM/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=yes a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:4 G723/8000 a=fmtp:4 annexa=yes Nathelper works right and in the message sent to UA you can see already IP address of Openser (62.33.22.14) instead of the address of a gateway (62.33.22.11): 15:37:07.407463 IP 62.33.22.14.5060 > 217.107.59.194.47331: UDP, length 1256 E.....@.@..|>!...k;.......n^INVITE sip:ngul@217.107.59.194:47331 SIP/2.0 Record-Route: <sip:62.33.22.14;lr;ftag=A515D068-227D> Via: SIP/2.0/UDP voapp.ru:5060;branch=z9hG4bK2d06.d63c8585.0 Via: SIP/2.0/UDP 62.33.22.11:5060;x-route-tag="tgrp:ipphone" From: <sip:78142764164@62.33.22.11>;tag=A515D068-227D To: <sip:78142799233@voapp.ru> Date: Fri, 04 Aug 2006 11:37:07 GMT Call-ID: 64A759D3-22E411DB-8B0DFF2E-66029374(a)195.161.136.114 Supported: timer,100rel Min-SE: 1800 Cisco-Guid: 1688609156-585372123-2332753710-1711444852 User-Agent: Cisco-SIPGateway/IOS-12.x Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO CSeq: 101 INVITE Max-Forwards: 5 Remote-Party-ID: <sip:78142764164@62.33.22.11>;party=calling;screen=yes;privacy=off Timestamp: 1154691427 Contact: <sip:78142764164@62.33.22.11:5060> Expires: 180 Allow-Events: telephone-event Content-Type: application/sdp Content-Length: 334 v=0 o=CiscoSystemsSIP-GW-UserAgent 4330 9654 IN IP4 62.33.22.11 s=SIP Call c=IN IP4 62.33.22.14 t=0 0 m=audio 35858 RTP/AVP 3 18 8 0 4 c=IN IP4 62.33.22.14 a=rtpmap:3 GSM/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=yes a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:4 G723/8000 a=fmtp:4 annexa=yes a=nortpproxy:yes After some talking the subscriber from PSTN tries to send a fax. PSTN gateway detects it and sends this message: 15:37:22.512722 IP 62.33.22.11.51655 > 62.33.22.14.5060: UDP, length 1276 E..........z>!..>!..........INVITE sip:62.33.22.14:5060;from-tag=A515D068-227D;lr SIP/2.0 Via: SIP/2.0/UDP 62.33.22.11:5060;x-route-tag="tgrp:ipphone" From: <sip:78142764164@62.33.22.11>;tag=A515D068-227D To: <sip:78142799233@voapp.ru>;tag=bbaac0e818284ff5 Date: Fri, 04 Aug 2006 11:37:22 GMT Call-ID: 64A759D3-22E411DB-8B0DFF2E-66029374(a)195.161.136.114 Route: <sip:ngul@217.107.59.194:47331> Supported: timer,100rel Min-SE: 1800 Cisco-Guid: 1688609156-585372123-2332753710-1711444852 User-Agent: Cisco-SIPGateway/IOS-12.x Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO CSeq: 102 INVITE Max-Forwards: 6 Remote-Party-ID: <sip:78142764164@62.33.22.11>;party=calling;screen=yes;privacy=off Timestamp: 1154691442 Contact: <sip:78142764164@62.33.22.11:5060> Expires: 180 Allow-Events: telephone-event Content-Type: application/sdp Content-Length: 393 v=0 o=CiscoSystemsSIP-GW-UserAgent 4330 9656 IN IP4 62.33.22.11 s=SIP Call c=IN IP4 62.33.22.11 t=0 0 m=image 17088 udptl t38 c=IN IP4 62.33.22.11 a=T38FaxVersion:0 a=T38MaxBitRate:14400 a=T38FaxFillBitRemoval:0 a=T38FaxTranscodingMMR:0 a=T38FaxTranscodingJBIG:0 a=T38FaxRateManagement:transferredTCF a=T38FaxMaxBuffer:200 a=T38FaxMaxDatagram:72 a=T38FaxUdpEC:t38UDPRedundancy Openser processes is and sends to UA: 15:37:22.513017 IP 62.33.22.14.5060 > 217.107.59.194.47331: UDP, length 1336 E..T..@.@..,>!...k;......@n.INVITE sip:ngul@217.107.59.194:47331 SIP/2.0 Record-Route: <sip:62.33.22.14;lr;ftag=A515D068-227D> Via: SIP/2.0/UDP voapp.ru:5060;branch=z9hG4bKfc06.4b118272.0 Via: SIP/2.0/UDP 62.33.22.11:5060;x-route-tag="tgrp:ipphone" From: <sip:78142764164@62.33.22.11>;tag=A515D068-227D To: <sip:78142799233@voapp.ru>;tag=bbaac0e818284ff5 Date: Fri, 04 Aug 2006 11:37:22 GMT Call-ID: 64A759D3-22E411DB-8B0DFF2E-66029374(a)195.161.136.114 Supported: timer,100rel Min-SE: 1800 Cisco-Guid: 1688609156-585372123-2332753710-1711444852 User-Agent: Cisco-SIPGateway/IOS-12.x Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO CSeq: 102 INVITE Max-Forwards: 5 Remote-Party-ID: <sip:78142764164@62.33.22.11>;party=calling;screen=yes;privacy=off Timestamp: 1154691442 Contact: <sip:78142764164@62.33.22.11:5060> Expires: 180 Allow-Events: telephone-event Content-Type: application/sdp Content-Length: 393 v=0 o=CiscoSystemsSIP-GW-UserAgent 4330 9656 IN IP4 62.33.22.11 s=SIP Call c=IN IP4 62.33.22.11 t=0 0 m=image 17088 udptl t38 c=IN IP4 62.33.22.11 a=T38FaxVersion:0 a=T38MaxBitRate:14400 a=T38FaxFillBitRemoval:0 a=T38FaxTranscodingMMR:0 a=T38FaxTranscodingJBIG:0 a=T38FaxRateManagement:transferredTCF a=T38FaxMaxBuffer:200 a=T38FaxMaxDatagram:72 a=T38FaxUdpEC:t38UDPRedundancy As you can see the nathelper module has not worked since the field c=IN IP4 62.33.22.11 has not changed. Probably it has taken place because m=image instead of m=audio as usual. As a result of transfer of a fax has not taken place. If to place UA outside for NAT router all works that once again confirms that bug is in the nathelper module. Questions: Why the module behaves so? What difference that to proxing (what byte stream and in what format)? How it can be bypassed? Also that the most interesting - UA refuses to accept T38 and suggests to use instead of it G.711 codec and the gateway agrees i.e. in result we have audio stream. Dmitry