[Users] nathelper & fax = bug ?
Daniel-Constantin Mierla
daniel at voice-system.ro
Mon Aug 14 16:32:48 CEST 2006
re-INVITE, like all other SIP requests go first in the route[0]. If you
have RR and loose_route(), the re-INVITE will follow that condition and
may be forwarded before you apply NAT processing stuff.
You can use xlog() to see how the requests go though your script. That
should help you to debug.
Cheers,
Daniel
On 08/14/06 12:57, Dmitry Lyubimkov wrote:
> 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