14 Aug
2006
14 Aug
'06
7:30 p.m.
Hi!
Of course I use loose_route () in route (0):
..........
if (nat_uac_test("2")) {
fix_nated_contact();
setflag(4);
force_rport();
};
.........
if (loose_route()) {
route(2);
exit;
}
........
Before other checks for definition of a route.
But all call forwarding script do in 3 functions (as I already wrote):
route[2] {
# forward to internal subscriber
route(7);
if (!t_relay()) {
sl_reply_error();
};
}
route[3] {
# forward to local PSTN gateway
route(7);
if (!t_relay("udp:62.33.22.11:5060")) {
sl_reply_error();
};
}
route[4] {
# forward to SIP/H.323 converter
route(7);
if (!t_relay("udp:172.16.2.6:5060")) {
sl_reply_error();
};
}
In other places t_relay () is not present more.
As you see before t_relay always there is a route (7):
route[7] {
# do before forward job
if (isflagset(4)) {
# turn on/off media proxy
if (method=="INVITE") {
force_rtp_proxy("c");
} else if (method == "BYE" || method == "CANCEL") {
unforce_rtp_proxy();
};
};
t_on_reply("1");
}
I.e. any message will not pass without attempt to include rtp proxing.
May be the problem is in use of parameter "c" in force_rtp_proxy
("c")?
Dmitry
------------------------------------------------------------------------
------------
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:
format)?
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 > 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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users