[Users] nathelper & fax = bug ?
Dmitry Lyubimkov
loft at onego.ru
Mon Aug 14 11:57:02 CEST 2006
Hi.
The matter is that I process re-INVITE. Or it seems to me so ....
Here is the reduced algorithm of work:
route
{
.....
if (nat_uac_test("2")) {
fix_nated_contact();
setflag(4);
force_rport();
};
.......
#Check some fields and go to route(2) (3) or (4)
#All this route(n) have similar structure
.....
route(3)
.....
}
route[3] {
# forward to local PSTN gateway
route(7);
if (!t_relay("udp:62.33.22.11:5060")) {
sl_reply_error();
};
}
route[7] {
# do before forward job
if (isflagset(4)) {
# turn on/off rtp proxy
if (method=="INVITE") {
force_rtp_proxy("c");
} else if (method == "BYE" || method == "CANCEL") {
unforce_rtp_proxy();
};
};
t_on_reply("1");
}
onreply_route[1] {
# process on reply messages
if (isflagset(4)) {
fix_nated_contact();
force_rtp_proxy("c");
} else if (nat_uac_test("2")) {
fix_nated_contact();
};
}
As you can see I process reply messages. But rtp proxy it is not work.
In support of the words I can tell that when the incoming call comes
from the gateway to this UA behind NAT rtp proxy works correctly.
Where is a mistake?
Or re-INVITE does not pass through route (0)?
Dmitry
------------------------------------------------------------------------
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
>
>
More information about the Users
mailing list