[Users] nathelper & fax = bug ?

Mon Aug 7 22:12:18 CEST 2006

Hello,

the latest openser should not care about type of media (audio or image 
is same for openser). The problem is that you do not force the rtpproxy 
for re-INVITE in your config file, but only for initial INVITE of the call.

Cheers,
Daniel

On 08/05/06 10:52, Dmitry Lyubimkov wrote:
> 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 at voapp.ru:5060 SIP/2.0
> Via: SIP/2.0/UDP  62.33.22.11:5060;x-route-tag="tgrp:ipphone"
> From: <sip:78142764164 at 62.33.22.11>;tag=A515D068-227D
> To: <sip:78142799233 at voapp.ru>
> Date: Fri, 04 Aug 2006 11:37:07 GMT
> Call-ID: 64A759D3-22E411DB-8B0DFF2E-66029374 at 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 at 62.33.22.11>;party=calling;screen=yes;privacy=off
> Timestamp: 1154691427
> Contact: <sip:78142764164 at 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..... at .@..|>!...k;.......n^INVITE sip:ngul at 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 at 62.33.22.11>;tag=A515D068-227D
> To: <sip:78142799233 at voapp.ru>
> Date: Fri, 04 Aug 2006 11:37:07 GMT
> Call-ID: 64A759D3-22E411DB-8B0DFF2E-66029374 at 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 at 62.33.22.11>;party=calling;screen=yes;privacy=off
> Timestamp: 1154691427
> Contact: <sip:78142764164 at 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 at 62.33.22.11>;tag=A515D068-227D
> To: <sip:78142799233 at voapp.ru>;tag=bbaac0e818284ff5
> Date: Fri, 04 Aug 2006 11:37:22 GMT
> Call-ID: 64A759D3-22E411DB-8B0DFF2E-66029374 at 195.161.136.114
> Route: <sip:ngul at 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 at 62.33.22.11>;party=calling;screen=yes;privacy=off
> Timestamp: 1154691442
> Contact: <sip:78142764164 at 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.. at .@..,>!...k;...... at n.INVITE sip:ngul at 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 at 62.33.22.11>;tag=A515D068-227D
> To: <sip:78142799233 at voapp.ru>;tag=bbaac0e818284ff5
> Date: Fri, 04 Aug 2006 11:37:22 GMT
> Call-ID: 64A759D3-22E411DB-8B0DFF2E-66029374 at 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 at 62.33.22.11>;party=calling;screen=yes;privacy=off
> Timestamp: 1154691442
> Contact: <sip:78142764164 at 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
>
>
>
>
> _______________________________________________
> Users mailing list
> Users at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users
>
>   