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@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@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@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@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
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@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@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@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@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@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
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Hi, Is there anybody who will share his config file,( or a samle configuration ) which is working properly with rtp_proxy or mediaproxy ? ( handle re-INVITEs properly ). As I see, there are some people have the same problem,like me. Thanks,
----- Original Message ----- From: "Daniel-Constantin Mierla" daniel@voice-system.ro To: "Dmitry Lyubimkov" loft@onego.ru Cc: users@openser.org Sent: Monday, August 07, 2006 11:12 PM Subject: Re: [Users] nathelper & fax = bug ?
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@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@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@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@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@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
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Hello,
start with:
http://voip-info.org/wiki/view/OpenSER+And+RTPProxy
The re-INVITEs should be handled there.
Cheers, Daniel
On 08/08/06 09:38, Hakan YASTI wrote:
Hi, Is there anybody who will share his config file,( or a samle configuration ) which is working properly with rtp_proxy or mediaproxy ? ( handle re-INVITEs properly ). As I see, there are some people have the same problem,like me. Thanks,
----- Original Message ----- From: "Daniel-Constantin Mierla" daniel@voice-system.ro To: "Dmitry Lyubimkov" loft@onego.ru Cc: users@openser.org Sent: Monday, August 07, 2006 11:12 PM Subject: Re: [Users] nathelper & fax = bug ?
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@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@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@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@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@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
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
tryed with this config. Reinvite not handled properly. Can anybody provide example configs?
-- Pavel D.Kuzin System Administrator Nodex ISP St. Petersburg, Russia pk@nodex.ru http://nodex.ru ----- Original Message ----- From: "Daniel-Constantin Mierla" daniel@voice-system.ro To: "Hakan YASTI" hakanyasti@gmail.com Cc: users@openser.org Sent: Thursday, August 10, 2006 12:35 AM Subject: Re: [Users] nathelper & fax = bug ?
Hello,
start with:
http://voip-info.org/wiki/view/OpenSER+And+RTPProxy
The re-INVITEs should be handled there.
Cheers, Daniel
On 08/08/06 09:38, Hakan YASTI wrote:
Hi, Is there anybody who will share his config file,( or a samle configuration ) which is working properly with rtp_proxy or mediaproxy ? ( handle re-INVITEs properly ). As I see, there are some people have the same problem,like me. Thanks,
----- Original Message ----- From: "Daniel-Constantin Mierla" daniel@voice-system.ro To: "Dmitry Lyubimkov" loft@onego.ru Cc: users@openser.org Sent: Monday, August 07, 2006 11:12 PM Subject: Re: [Users] nathelper & fax = bug ?
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@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@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@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@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@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
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Did you used that config, or you imported parts in your config? If you can provide a network trace of the call, maybe we will be able to detect the error.
Cheers, Daniel
On 08/10/06 14:39, Pavel D. Kuzin wrote:
tryed with this config. Reinvite not handled properly. Can anybody provide example configs?
-- Pavel D.Kuzin System Administrator Nodex ISP St. Petersburg, Russia pk@nodex.ru http://nodex.ru ----- Original Message ----- From: "Daniel-Constantin Mierla" daniel@voice-system.ro To: "Hakan YASTI" hakanyasti@gmail.com Cc: users@openser.org Sent: Thursday, August 10, 2006 12:35 AM Subject: Re: [Users] nathelper & fax = bug ?
Hello,
start with:
http://voip-info.org/wiki/view/OpenSER+And+RTPProxy
The re-INVITEs should be handled there.
Cheers, Daniel
On 08/08/06 09:38, Hakan YASTI wrote:
Hi, Is there anybody who will share his config file,( or a samle configuration ) which is working properly with rtp_proxy or mediaproxy ? ( handle re-INVITEs properly ). As I see, there are some people have the same problem,like me. Thanks,
----- Original Message ----- From: "Daniel-Constantin Mierla" daniel@voice-system.ro To: "Dmitry Lyubimkov" loft@onego.ru Cc: users@openser.org Sent: Monday, August 07, 2006 11:12 PM Subject: Re: [Users] nathelper & fax = bug ?
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@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@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@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@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@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
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
i`m tryed to user exacly equals config. http://voip-info.org/wiki/view/OpenSER+And+RTPProxy and 2 users refistered with openser.
-- Pavel D.Kuzin System Administrator Nodex ISP St. Petersburg, Russia pk@nodex.ru http://nodex.ru ----- Original Message ----- From: "Daniel-Constantin Mierla" daniel@voice-system.ro To: "Pavel D. Kuzin" pk@nodex.ru Cc: "Hakan YASTI" hakanyasti@gmail.com; users@openser.org Sent: Thursday, August 10, 2006 3:53 PM Subject: Re: [Users] nathelper & fax = bug ?
Did you used that config, or you imported parts in your config? If you can provide a network trace of the call, maybe we will be able to detect the error.
Cheers, Daniel
On 08/10/06 14:39, Pavel D. Kuzin wrote:
tryed with this config. Reinvite not handled properly. Can anybody provide example configs?
-- Pavel D.Kuzin System Administrator Nodex ISP St. Petersburg, Russia pk@nodex.ru http://nodex.ru ----- Original Message ----- From: "Daniel-Constantin Mierla" daniel@voice-system.ro To: "Hakan YASTI" hakanyasti@gmail.com Cc: users@openser.org Sent: Thursday, August 10, 2006 12:35 AM Subject: Re: [Users] nathelper & fax = bug ?
Hello,
start with:
http://voip-info.org/wiki/view/OpenSER+And+RTPProxy
The re-INVITEs should be handled there.
Cheers, Daniel
On 08/08/06 09:38, Hakan YASTI wrote:
Hi, Is there anybody who will share his config file,( or a samle configuration ) which is working properly with rtp_proxy or mediaproxy ? ( handle re-INVITEs properly ). As I see, there are some people have the same problem,like me. Thanks,
----- Original Message ----- From: "Daniel-Constantin Mierla" daniel@voice-system.ro To: "Dmitry Lyubimkov" loft@onego.ru Cc: users@openser.org Sent: Monday, August 07, 2006 11:12 PM Subject: Re: [Users] nathelper & fax = bug ?
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@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@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@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@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@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
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
this is a debug view with debug=5
2(14161) INFO: no fifo_db_url given - fifo DB commands disabled! 0(14154) SIP Request: 0(14154) method: <INVITE> 0(14154) uri: sip:500@192.168.39.54 0(14154) version: <SIP/2.0> 0(14154) parse_headers: flags=2 0(14154) DEBUG:parse_to:end of header reached, state=10 0(14154) DBUG:parse_to: display={}, ruri={sip:500@192.168.39.54} 0(14154) DEBUG: get_hdr_field: <To> [25]; uri=[sip:500@192.168.39.54] 0(14154) DEBUG: to body [sip:500@192.168.39.54 ] 0(14154) get_hdr_field: cseq <CSeq>: <1> <INVITE> 0(14154) Found param type 232, <branch> = <z9hG4bK-44db1c5c-b38bc-452a>; state=16 0(14154) end of header reached, state=5 0(14154) parse_headers: Via found, flags=2 0(14154) parse_headers: this is the first via 0(14154) After parse_msg... 0(14154) preparing to run routing scripts... 0(14154) parse_headers: flags=100 0(14154) DEBUG:maxfwd:is_maxfwd_present: value = 70 0(14154) check_via_address(192.168.39.50, 192.168.39.50, 0) 0(14154) parse_headers: flags=80 0(14154) parse_headers: flags=80 0(14154) DEBUG: add_param: tag=0-13c4-44db1c5c-b38bc-7e15 0(14154) DEBUG:parse_to:end of header reached, state=29 0(14154) DBUG:parse_to: display={}, ruri={sip:anonymous@anonymous.com} 0(14154) parse_headers: flags=200 0(14154) DEBUG: get_hdr_body : content_length=230 0(14154) found end of header 0(14154) find_first_route: No Route headers found 0(14154) loose_route: There is no Route HF 0(14154) grep_sock_info - checking if host==us: 13==13 && [192.168.39.54] == [192.168.39.54] 0(14154) grep_sock_info - checking if port 5060 matches port 5060 0(14154) grep_sock_info - checking if host==us: 13==13 && [192.168.39.54] == [192.168.39.54] 0(14154) grep_sock_info - checking if port 5060 matches port 5060 0(14154) rewrite_uri: Rewriting Request-URI with 'sip:500@192.168.39.50' 0(14154) parse_headers: flags=ffffffffffffffff 0(14154) subst_run: running. r=1 0(14154) subst_str: no match 0(14154) parse_headers: flags=ffffffffffffffff 0(14154) DEBUG:check_content_type: type <application/sdp> found valid 0(14154) parse_headers: flags=40 0(14154) force_rtp_proxy2: proxy reply: 35026 192.168.39.54
0(14154) DEBUG: t_newtran: msg id=1 , global msg id=0 , T on entrance=0xffffffffffffffff 0(14154) parse_headers: flags=ffffffffffffffff 0(14154) parse_headers: flags=78 0(14154) t_lookup_request: start searching: hash=34382, isACK=0 0(14154) DEBUG: RFC3261 transaction matching failed 0(14154) DEBUG: t_lookup_request: no transaction found 0(14154) DEBUG:tm:t_relay: new INVITE 0(14154) parse_headers: flags=ffffffffffffffff 0(14154) check_via_address(192.168.39.50, 192.168.39.50, 0) 0(14154) WARNING:vqm_resize: resize(0) called 0(14154) DEBUG:tm:_reply_light: reply sent out. buf=0x615de0: SIP/2.0 1..., shmem=0x2ba62f3c3c50: SIP/2.0 1 0(14154) DEBUG:tm:_reply_light: finished 0(14154) DEBUG: mk_proxy: doing DNS lookup... 0(14154) parse_headers: flags=2000 0(14154) parse_headers: flags=ffffffffffffffff 0(14154) clen_builder: content-length: 248 (248) 0(14154) check_via_address(192.168.39.50, 192.168.39.50, 0) 0(14154) DEBUG: add_to_tail_of_timer[4]: 0x2ba62f3c16a8 0(14154) DEBUG: add_to_tail_of_timer[0]: 0x2ba62f3c16c8 0(14154) SER: new transaction fwd'ed 0(14154) DEBUG:tm:UNREF_UNSAFE: after is 0 0(14154) DEBUG:destroy_avp_list: destroying list (nil) 0(14154) receive_msg: cleaning up 0(14154) SIP Reply (status): 0(14154) version: <SIP/2.0> 0(14154) status: <100> 0(14154) reason: <Trying> 0(14154) parse_headers: flags=2 0(14154) DEBUG: add_param: tag=0-13c4-44db1c5c-b390c-6691 0(14154) DEBUG:parse_to:end of header reached, state=29 0(14154) DBUG:parse_to: display={}, ruri={sip:500@192.168.39.54} 0(14154) DEBUG: get_hdr_field: <To> [56]; uri=[sip:500@192.168.39.54] 0(14154) DEBUG: to body [sip:500@192.168.39.54] 0(14154) get_hdr_field: cseq <CSeq>: <1> <INVITE> 0(14154) Found param type 232, <branch> = <z9hG4bKe468.e73bf65.0>; state=16 0(14154) end of header reached, state=5 0(14154) parse_headers: Via found, flags=2 0(14154) parse_headers: this is the first via 0(14154) After parse_msg... 0(14154) forward_reply: found module nathelper, passing reply to it 0(14154) forward_reply: found module tm, passing reply to it 0(14154) DEBUG: t_check: msg id=2 global id=1 T start=0xffffffffffffffff 0(14154) parse_headers: flags=22 0(14154) parse_headers: flags=8 0(14154) DEBUG: t_reply_matching: hash 34382 label 91206526 branch 0 0(14154) DEBUG:tm:REF_UNSAFE: after is 1 0(14154) DEBUG: t_reply_matching: reply matched (T=0x2ba62f3c14c8)! 0(14154) DEBUG: t_check: msg id=2 global id=2 T end=0x2ba62f3c14c8 0(14154) DEBUG:tm:reply_received: org. status uas=100, uac[0]=0 local=0 is_invite=1) 0(14154) parse_headers: flags=80 0(14154) Found param type 235, <rport> = <5060>; state=6 0(14154) Found param type 232, <branch> = <z9hG4bK-44db1c5c-b38bc-452a>; state=16 0(14154) end of header reached, state=5 0(14154) parse_headers: Via found, flags=80 0(14154) parse_headers: this is the second via 0(14154) DEBUG:tm:t_should_relay_response: T_code=100, new_code=100 0(14154) DEBUG:tm:relay_reply: branch=0, save=0, relay=-1 0(14154) DEBUG: add_to_tail_of_timer[1]: 0x2ba62f3c16c8 0(14154) DEBUG:tm:UNREF_UNSAFE: after is 0 0(14154) DEBUG:destroy_avp_list: destroying list (nil) 0(14154) receive_msg: cleaning up 0(14154) SIP Reply (status): 0(14154) version: <SIP/2.0> 0(14154) status: <180> 0(14154) reason: <Ringing> 0(14154) parse_headers: flags=2 0(14154) DEBUG: add_param: tag=0-13c4-44db1c5c-b390c-6691 0(14154) DEBUG:parse_to:end of header reached, state=29 0(14154) DBUG:parse_to: display={}, ruri={sip:500@192.168.39.54} 0(14154) DEBUG: get_hdr_field: <To> [56]; uri=[sip:500@192.168.39.54] 0(14154) DEBUG: to body [sip:500@192.168.39.54] 0(14154) get_hdr_field: cseq <CSeq>: <1> <INVITE> 0(14154) Found param type 232, <branch> = <z9hG4bKe468.e73bf65.0>; state=16 0(14154) end of header reached, state=5 0(14154) parse_headers: Via found, flags=2 0(14154) parse_headers: this is the first via 0(14154) After parse_msg... 0(14154) forward_reply: found module nathelper, passing reply to it 0(14154) forward_reply: found module tm, passing reply to it 0(14154) DEBUG: t_check: msg id=3 global id=2 T start=0xffffffffffffffff 0(14154) parse_headers: flags=22 0(14154) parse_headers: flags=8 0(14154) DEBUG: t_reply_matching: hash 34382 label 91206526 branch 0 0(14154) DEBUG:tm:REF_UNSAFE: after is 1 0(14154) DEBUG: t_reply_matching: reply matched (T=0x2ba62f3c14c8)! 0(14154) DEBUG: t_check: msg id=3 global id=3 T end=0x2ba62f3c14c8 0(14154) DEBUG:tm:reply_received: org. status uas=100, uac[0]=100 local=0 is_invite=1) 0(14154) parse_headers: flags=80 0(14154) Found param type 235, <rport> = <5060>; state=6 0(14154) Found param type 232, <branch> = <z9hG4bK-44db1c5c-b38bc-452a>; state=16 0(14154) end of header reached, state=5 0(14154) parse_headers: Via found, flags=80 0(14154) parse_headers: this is the second via 0(14154) DEBUG:tm:t_should_relay_response: T_code=100, new_code=180 0(14154) DEBUG:tm:relay_reply: branch=0, save=0, relay=0 0(14154) old size: 466, new size: 413 0(14154) build_res_from_sip_res: copied size: orig:442, new: 389, rest: 24 msg= SIP/2.0 180 Ringing From: sip:anonymous@anonymous.com;tag=0-13c4-44db1c5c-b38bc-7e15 To: sip:500@192.168.39.54;tag=0-13c4-44db1c5c-b390c-6691 Call-ID: c8ea3c-0-13c4-44db1c5c-b38bc-31ff@anonymous.com CSeq: 1 INVITE Via: SIP/2.0/UDP 192.168.39.50:5060;rport=5060;branch=z9hG4bK-44db1c5c-b38bc-452a Supported: 100rel User-Agent: SIP-RG Contact: sip:500@192.168.39.50:5060;nat=yes Content-Length: 0
0(14154) DEBUG:tm:relay_reply: sent buf=0x616348: SIP/2.0 1..., shmem=0x2ba62f3c3c50: SIP/2.0 1 0(14154) DEBUG: add_to_tail_of_timer[1]: 0x2ba62f3c16c8 0(14154) DEBUG:tm:UNREF_UNSAFE: after is 0 0(14154) DEBUG:destroy_avp_list: destroying list (nil) 0(14154) receive_msg: cleaning up 1(14160) DEBUG: timer routine:4,tl=0x2ba62f3c16a8 next=(nil) 0(14154) SIP Reply (status): 0(14154) version: <SIP/2.0> 0(14154) status: <200> 0(14154) reason: <OK> 0(14154) parse_headers: flags=2 0(14154) DEBUG: add_param: tag=0-13c4-44db1c5c-b390c-6691 0(14154) DEBUG:parse_to:end of header reached, state=29 0(14154) DBUG:parse_to: display={}, ruri={sip:500@192.168.39.54} 0(14154) DEBUG: get_hdr_field: <To> [56]; uri=[sip:500@192.168.39.54] 0(14154) DEBUG: to body [sip:500@192.168.39.54] 0(14154) get_hdr_field: cseq <CSeq>: <1> <INVITE> 0(14154) Found param type 232, <branch> = <z9hG4bKe468.e73bf65.0>; state=16 0(14154) end of header reached, state=5 0(14154) parse_headers: Via found, flags=2 0(14154) parse_headers: this is the first via 0(14154) After parse_msg... 0(14154) forward_reply: found module nathelper, passing reply to it 0(14154) forward_reply: found module tm, passing reply to it 0(14154) DEBUG: t_check: msg id=4 global id=3 T start=0xffffffffffffffff 0(14154) parse_headers: flags=22 0(14154) parse_headers: flags=8 0(14154) DEBUG: t_reply_matching: hash 34382 label 91206526 branch 0 0(14154) DEBUG:tm:REF_UNSAFE: after is 1 0(14154) DEBUG: t_reply_matching: reply matched (T=0x2ba62f3c14c8)! 0(14154) DEBUG: t_check: msg id=4 global id=4 T end=0x2ba62f3c14c8 0(14154) DEBUG:tm:reply_received: org. status uas=180, uac[0]=180 local=0 is_invite=1) 0(14154) parse_headers: flags=ffffffffffffffff 0(14154) Found param type 235, <rport> = <5060>; state=6 0(14154) Found param type 232, <branch> = <z9hG4bK-44db1c5c-b38bc-452a>; state=16 0(14154) end of header reached, state=5 0(14154) parse_headers: Via found, flags=ffffffffffffffff 0(14154) parse_headers: this is the second via 0(14154) DEBUG: get_hdr_body : content_length=158 0(14154) found end of header 0(14154) DEBUG:check_content_type: type <application/sdp> found valid 0(14154) parse_headers: flags=40 0(14154) DEBUG: add_param: tag=0-13c4-44db1c5c-b38bc-7e15 0(14154) DEBUG:parse_to:end of header reached, state=29 0(14154) DBUG:parse_to: display={}, ruri={sip:anonymous@anonymous.com} 0(14154) force_rtp_proxy2: proxy reply: 35028 192.168.39.54
0(14154) parse_headers: flags=80 0(14154) DEBUG:tm:t_should_relay_response: T_code=180, new_code=200 0(14154) DEBUG:tm:relay_reply: branch=0, save=0, relay=0 0(14154) parse_headers: flags=2000 0(14154) parse_headers: flags=ffffffffffffffff 0(14154) clen_builder: content-length: 176 (176) 0(14154) old size: 722, new size: 687 0(14154) build_res_from_sip_res: copied size: orig:722, new: 687, rest: 0 msg= SIP/2.0 200 OK From: sip:anonymous@anonymous.com;tag=0-13c4-44db1c5c-b38bc-7e15 To: sip:500@192.168.39.54;tag=0-13c4-44db1c5c-b390c-6691 Call-ID: c8ea3c-0-13c4-44db1c5c-b38bc-31ff@anonymous.com CSeq: 1 INVITE Via: SIP/2.0/UDP 192.168.39.50:5060;rport=5060;branch=z9hG4bK-44db1c5c-b38bc-452a Supported: 100rel User-Agent: SIP-RG Contact: sip:500@192.168.39.50:5060;nat=yes Record-Route: sip:192.168.39.54;lr;ftag=0-13c4-44db1c5c-b38bc-7e15 Content-Type: application/sdp Content-Length: 176
v=0 o=SIP-N-TA 0 0 IN IP4 192.168.39.50 s=C0A82732 0000 C0A82732 0000 01 0 c=IN IP4 192.168.39.54 t=0 0 m=audio 35028 RTP/AVP 18 a=rtpmap:18 G729/8000 a=nortpproxy:yes
0(14154) DEBUG: add_to_tail_of_timer[2]: 0x2ba62f3c1548 0(14154) DEBUG:tm:relay_reply: sent buf=0x6166b8: SIP/2.0 2..., shmem=0x2ba62f3c3c50: SIP/2.0 2 0(14154) DEBUG: cleanup_uac_timers: RETR/FR timers reset 0(14154) DEBUG:tm:UNREF_UNSAFE: after is 0 0(14154) DEBUG:destroy_avp_list: destroying list (nil) 0(14154) receive_msg: cleaning up 0(14154) SIP Request: 0(14154) method: <ACK> 0(14154) uri: sip:500@192.168.39.50:5060;nat=yes 0(14154) version: <SIP/2.0> 0(14154) parse_headers: flags=2 0(14154) DEBUG: add_param: tag=0-13c4-44db1c5c-b390c-6691 0(14154) DEBUG:parse_to:end of header reached, state=29 0(14154) DBUG:parse_to: display={}, ruri={sip:500@192.168.39.54} 0(14154) DEBUG: get_hdr_field: <To> [56]; uri=[sip:500@192.168.39.54] 0(14154) DEBUG: to body [sip:500@192.168.39.54] 0(14154) get_hdr_field: cseq <CSeq>: <1> <ACK> 0(14154) Found param type 232, <branch> = <z9hG4bK-44db1c5e-b3e5c-9f6>; state=16 0(14154) end of header reached, state=5 0(14154) parse_headers: Via found, flags=2 0(14154) parse_headers: this is the first via 0(14154) After parse_msg... 0(14154) preparing to run routing scripts... 0(14154) DEBUG : sl_filter_ACK: to late to be a local ACK! 0(14154) parse_headers: flags=100 0(14154) DEBUG:maxfwd:is_maxfwd_present: value = 70 0(14154) check_via_address(192.168.39.50, 192.168.39.50, 0) 0(14154) parse_headers: flags=80 0(14154) parse_headers: flags=80 0(14154) DEBUG: add_param: tag=0-13c4-44db1c5c-b38bc-7e15 0(14154) DEBUG:parse_to:end of header reached, state=29 0(14154) DBUG:parse_to: display={}, ruri={sip:anonymous@anonymous.com} 0(14154) parse_headers: flags=200 0(14154) is_preloaded: No 0(14154) grep_sock_info - checking if host==us: 13==13 && [192.168.39.50] == [192.168.39.54] 0(14154) grep_sock_info - checking if port 5060 matches port 5060 0(14154) grep_sock_info - checking if host==us: 13==13 && [192.168.39.50] == [192.168.39.54] 0(14154) grep_sock_info - checking if port 5060 matches port 5060 0(14154) check_self: host != me 0(14154) grep_sock_info - checking if host==us: 13==13 && [192.168.39.54] == [192.168.39.54] 0(14154) grep_sock_info - checking if port 5060 matches port 5060 0(14154) after_loose: Topmost route URI: 'sip:192.168.39.54;lr;ftag=0-13c4-44db1c5c-b38bc-7e15' is me 0(14154) parse_headers: flags=200 0(14154) DEBUG: get_hdr_body : content_length=0 0(14154) found end of header 0(14154) find_next_route: No next Route HF found 0(14154) after_loose: No next URI found 0(14154) parse_headers: flags=ffffffffffffffff 0(14154) subst_run: running. r=0 0(14154) subst_run: matched (0, 34): [sip:500@192.168.39.50:5060;nat=yes] 0(14154) textops: subst_uri_f: match - old uri= [sip:500@192.168.39.50:5060;nat=yes], new uri= [sip:500@192.168.39.50:5060] 0(14154) DEBUG: t_newtran: msg id=5 , global msg id=4 , T on entrance=0xffffffffffffffff 0(14154) parse_headers: flags=ffffffffffffffff 0(14154) parse_headers: flags=78 0(14154) t_lookup_request: start searching: hash=34382, isACK=1 0(14154) parse_headers: flags=38 0(14154) DEBUG: t_lookup_request: e2e proxy ACK found 0(14154) DEBUG:tm:REF_UNSAFE: after is 1 0(14154) DEBUG:tm:t_newtran: building branch for end2end ACK 0(14154) DEBUG:tm:UNREF_UNSAFE: after is 0 0(14154) DEBUG:tm:t_relay: forwarding ACK 0(14154) DEBUG: mk_proxy: doing DNS lookup... 0(14154) check_via_address(192.168.39.50, 192.168.39.50, 0) 0(14154) Sending: ACK sip:500@192.168.39.50:5060 SIP/2.0 Record-Route: sip:192.168.39.54;lr=on;ftag=0-13c4-44db1c5c-b38bc-7e15 From: sip:anonymous@anonymous.com;tag=0-13c4-44db1c5c-b38bc-7e15 To: sip:500@192.168.39.54;tag=0-13c4-44db1c5c-b390c-6691 Call-ID: c8ea3c-0-13c4-44db1c5c-b38bc-31ff@anonymous.com CSeq: 1 ACK Via: SIP/2.0/UDP 192.168.39.54;branch=z9hG4bKe468.e73bf65.2 Via: SIP/2.0/UDP 192.168.39.50:5060;rport=5060;branch=z9hG4bK-44db1c5e-b3e5c-9f6 Max-Forwards: 69 User-Agent: SIP-RG Contact: sip:400@192.168.39.50:5060;nat=yes Content-Length: 0 P-hint: rr-enforced
. 0(14154) orig. len=474, new_len=582, proto=1 0(14154) DEBUG:destroy_avp_list: destroying list (nil) 0(14154) receive_msg: cleaning up 1(14160) DEBUG: timer routine:1,tl=0x2ba62f3c16c8 next=(nil) 1(14160) DEBUG: timer routine:2,tl=0x2ba62f3c1548 next=(nil) 1(14160) DEBUG: wait_handler : removing 0x2ba62f3c14c8 from table 1(14160) DEBUG: delete transaction 0x2ba62f3c14c8 1(14160) DEBUG: wait_handler : done 0(14154) SIP Request: 0(14154) method: <INVITE> 0(14154) uri: sip:400@192.168.39.50:5060;nat=yes 0(14154) version: <SIP/2.0> 0(14154) parse_headers: flags=2 0(14154) DEBUG: add_param: tag=0-13c4-44db1c5c-b38bc-7e15 0(14154) DEBUG:parse_to:end of header reached, state=29 0(14154) DBUG:parse_to: display={}, ruri={sip:anonymous@anonymous.com} 0(14154) DEBUG: get_hdr_field: <To> [62]; uri=[sip:anonymous@anonymous.com] 0(14154) DEBUG: to body [sip:anonymous@anonymous.com] 0(14154) get_hdr_field: cseq <CSeq>: <1> <INVITE> 0(14154) Found param type 232, <branch> = <z9hG4bK-44db1c63-b5374-2864>; state=16 0(14154) end of header reached, state=5 0(14154) parse_headers: Via found, flags=2 0(14154) parse_headers: this is the first via 0(14154) After parse_msg... 0(14154) preparing to run routing scripts... 0(14154) parse_headers: flags=100 0(14154) DEBUG:maxfwd:is_maxfwd_present: value = 70 0(14154) check_via_address(192.168.39.50, 192.168.39.50, 0) 0(14154) parse_headers: flags=80 0(14154) parse_headers: flags=80 0(14154) DEBUG: add_param: tag=0-13c4-44db1c5c-b390c-6691 0(14154) DEBUG:parse_to:end of header reached, state=29 0(14154) DBUG:parse_to: display={}, ruri={sip:500@192.168.39.54} 0(14154) parse_headers: flags=200 0(14154) is_preloaded: No 0(14154) grep_sock_info - checking if host==us: 13==13 && [192.168.39.50] == [192.168.39.54] 0(14154) grep_sock_info - checking if port 5060 matches port 5060 0(14154) grep_sock_info - checking if host==us: 13==13 && [192.168.39.50] == [192.168.39.54] 0(14154) grep_sock_info - checking if port 5060 matches port 5060 0(14154) check_self: host != me 0(14154) grep_sock_info - checking if host==us: 13==13 && [192.168.39.54] == [192.168.39.54] 0(14154) grep_sock_info - checking if port 5060 matches port 5060 0(14154) after_loose: Topmost route URI: 'sip:192.168.39.54;lr;ftag=0-13c4-44db1c5c-b38bc-7e15' is me 0(14154) parse_headers: flags=200 0(14154) DEBUG: get_hdr_body : content_length=318 0(14154) found end of header 0(14154) find_next_route: No next Route HF found 0(14154) after_loose: No next URI found 0(14154) parse_headers: flags=ffffffffffffffff 0(14154) parse_headers: flags=40 0(14154) parse_headers: flags=ffffffffffffffff 0(14154) DEBUG:check_content_type: type <application/sdp> found valid 0(14154) parse_headers: flags=40 0(14154) force_rtp_proxy2: proxy reply: 35030 192.168.39.54
0(14154) subst_run: running. r=0 0(14154) subst_run: matched (0, 34): [sip:400@192.168.39.50:5060;nat=yes] 0(14154) textops: subst_uri_f: match - old uri= [sip:400@192.168.39.50:5060;nat=yes], new uri= [sip:400@192.168.39.50:5060] 0(14154) parse_headers: flags=ffffffffffffffff 0(14154) DEBUG:check_content_type: type <application/sdp> found valid 0(14154) parse_headers: flags=40 0(14154) force_rtp_proxy2: proxy reply: 35030 192.168.39.54
0(14154) DEBUG: t_newtran: msg id=6 , global msg id=5 , T on entrance=0xffffffffffffffff 0(14154) parse_headers: flags=ffffffffffffffff 0(14154) parse_headers: flags=78 0(14154) t_lookup_request: start searching: hash=34382, isACK=0 0(14154) DEBUG: RFC3261 transaction matching failed 0(14154) DEBUG: t_lookup_request: no transaction found 0(14154) DEBUG:tm:t_relay: new INVITE 0(14154) parse_headers: flags=ffffffffffffffff 0(14154) check_via_address(192.168.39.50, 192.168.39.50, 0) 0(14154) WARNING:vqm_resize: resize(0) called 0(14154) DEBUG:tm:_reply_light: reply sent out. buf=0x6166b8: SIP/2.0 1..., shmem=0x2ba62f3c3f30: SIP/2.0 1 0(14154) DEBUG:tm:_reply_light: finished 0(14154) DEBUG: mk_proxy: doing DNS lookup... 0(14154) parse_headers: flags=2000 0(14154) parse_headers: flags=ffffffffffffffff 0(14154) clen_builder: content-length: 372 (372) 0(14154) check_via_address(192.168.39.50, 192.168.39.50, 0) 0(14154) DEBUG: add_to_tail_of_timer[4]: 0x2ba62f3c16a8 0(14154) DEBUG: add_to_tail_of_timer[0]: 0x2ba62f3c16c8 0(14154) SER: new transaction fwd'ed 0(14154) DEBUG:tm:UNREF_UNSAFE: after is 0 0(14154) DEBUG:destroy_avp_list: destroying list (nil) 0(14154) receive_msg: cleaning up 0(14154) SIP Reply (status): 0(14154) version: <SIP/2.0> 0(14154) status: <200> 0(14154) reason: <OK> 0(14154) parse_headers: flags=2 0(14154) DEBUG: add_param: tag=0-13c4-44db1c5c-b38bc-7e15 0(14154) DEBUG:parse_to:end of header reached, state=29 0(14154) DBUG:parse_to: display={}, ruri={sip:anonymous@anonymous.com} 0(14154) DEBUG: get_hdr_field: <To> [62]; uri=[sip:anonymous@anonymous.com] 0(14154) DEBUG: to body [sip:anonymous@anonymous.com] 0(14154) get_hdr_field: cseq <CSeq>: <1> <INVITE> 0(14154) Found param type 232, <branch> = <z9hG4bKe468.f73bf65.0>; state=16 0(14154) end of header reached, state=5 0(14154) parse_headers: Via found, flags=2 0(14154) parse_headers: this is the first via 0(14154) After parse_msg... 0(14154) forward_reply: found module nathelper, passing reply to it 0(14154) forward_reply: found module tm, passing reply to it 0(14154) DEBUG: t_check: msg id=7 global id=6 T start=0xffffffffffffffff 0(14154) parse_headers: flags=22 0(14154) parse_headers: flags=8 0(14154) DEBUG: t_reply_matching: hash 34382 label 91206527 branch 0 0(14154) DEBUG:tm:REF_UNSAFE: after is 1 0(14154) DEBUG: t_reply_matching: reply matched (T=0x2ba62f3c14c8)! 0(14154) DEBUG: t_check: msg id=7 global id=7 T end=0x2ba62f3c14c8 0(14154) DEBUG:tm:reply_received: org. status uas=100, uac[0]=0 local=0 is_invite=1) 0(14154) parse_headers: flags=ffffffffffffffff 0(14154) Found param type 235, <rport> = <5060>; state=6 0(14154) Found param type 232, <branch> = <z9hG4bK-44db1c63-b5374-2864>; state=16 0(14154) end of header reached, state=5 0(14154) parse_headers: Via found, flags=ffffffffffffffff 0(14154) parse_headers: this is the second via 0(14154) DEBUG: get_hdr_body : content_length=156 0(14154) found end of header 0(14154) DEBUG:check_content_type: type <application/sdp> found valid 0(14154) parse_headers: flags=40 0(14154) DEBUG: add_param: tag=0-13c4-44db1c5c-b390c-6691 0(14154) DEBUG:parse_to:end of header reached, state=29 0(14154) DBUG:parse_to: display={}, ruri={sip:500@192.168.39.54} 0(14154) force_rtp_proxy2: proxy reply: 35032 192.168.39.54
0(14154) parse_headers: flags=80 0(14154) DEBUG:tm:t_should_relay_response: T_code=100, new_code=200 0(14154) DEBUG:tm:relay_reply: branch=0, save=0, relay=0 0(14154) parse_headers: flags=2000 0(14154) parse_headers: flags=ffffffffffffffff 0(14154) clen_builder: content-length: 174 (174) 0(14154) old size: 645, new size: 615 0(14154) build_res_from_sip_res: copied size: orig:645, new: 615, rest: 0 msg= SIP/2.0 200 OK From: sip:500@192.168.39.54;tag=0-13c4-44db1c5c-b390c-6691 To: sip:anonymous@anonymous.com;tag=0-13c4-44db1c5c-b38bc-7e15 Call-ID: c8ea3c-0-13c4-44db1c5c-b38bc-31ff@anonymous.com CSeq: 1 INVITE Via: SIP/2.0/UDP 192.168.39.50:5060;rport=5060;branch=z9hG4bK-44db1c63-b5374-2864 Supported: 100rel User-Agent: SIP-RG Contact: sip:400@192.168.39.50:5060;nat=yes Content-Type: application/sdp Content-Length: 174
v=0 o=SIP-N-TA 0 0 IN IP4 192.168.39.50 s=C0A82732 0000 C0A82732 0000 02 0 c=IN IP4 192.168.39.54 t=0 0 m=audio 35032 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=nortpproxy:yes
0(14154) DEBUG: add_to_tail_of_timer[2]: 0x2ba62f3c1548 0(14154) DEBUG:tm:relay_reply: sent buf=0x6166b8: SIP/2.0 2..., shmem=0x2ba62f3c3c50: SIP/2.0 2 0(14154) DEBUG: cleanup_uac_timers: RETR/FR timers reset 0(14154) DEBUG:tm:UNREF_UNSAFE: after is 0 0(14154) DEBUG:destroy_avp_list: destroying list (nil) 0(14154) receive_msg: cleaning up 0(14154) SIP Request: 0(14154) method: <ACK> 0(14154) uri: sip:400@192.168.39.50:5060;nat=yes 0(14154) version: <SIP/2.0> 0(14154) parse_headers: flags=2 0(14154) DEBUG: add_param: tag=0-13c4-44db1c5c-b38bc-7e15 0(14154) DEBUG:parse_to:end of header reached, state=29 0(14154) DBUG:parse_to: display={}, ruri={sip:anonymous@anonymous.com} 0(14154) DEBUG: get_hdr_field: <To> [62]; uri=[sip:anonymous@anonymous.com] 0(14154) DEBUG: to body [sip:anonymous@anonymous.com] 0(14154) get_hdr_field: cseq <CSeq>: <1> <ACK> 0(14154) Found param type 232, <branch> = <z9hG4bK-44db1c63-b5464-4f82>; state=16 0(14154) end of header reached, state=5 0(14154) parse_headers: Via found, flags=2 0(14154) parse_headers: this is the first via 0(14154) After parse_msg... 0(14154) preparing to run routing scripts... 0(14154) DEBUG : sl_filter_ACK: to late to be a local ACK! 0(14154) parse_headers: flags=100 0(14154) DEBUG:maxfwd:is_maxfwd_present: value = 70 0(14154) check_via_address(192.168.39.50, 192.168.39.50, 0) 0(14154) parse_headers: flags=80 0(14154) parse_headers: flags=80 0(14154) DEBUG: add_param: tag=0-13c4-44db1c5c-b390c-6691 0(14154) DEBUG:parse_to:end of header reached, state=29 0(14154) DBUG:parse_to: display={}, ruri={sip:500@192.168.39.54} 0(14154) parse_headers: flags=200 0(14154) is_preloaded: No 0(14154) grep_sock_info - checking if host==us: 13==13 && [192.168.39.50] == [192.168.39.54] 0(14154) grep_sock_info - checking if port 5060 matches port 5060 0(14154) grep_sock_info - checking if host==us: 13==13 && [192.168.39.50] == [192.168.39.54] 0(14154) grep_sock_info - checking if port 5060 matches port 5060 0(14154) check_self: host != me 0(14154) grep_sock_info - checking if host==us: 13==13 && [192.168.39.54] == [192.168.39.54] 0(14154) grep_sock_info - checking if port 5060 matches port 5060 0(14154) after_loose: Topmost route URI: 'sip:192.168.39.54;lr;ftag=0-13c4-44db1c5c-b38bc-7e15' is me 0(14154) parse_headers: flags=200 0(14154) DEBUG: get_hdr_body : content_length=0 0(14154) found end of header 0(14154) find_next_route: No next Route HF found 0(14154) after_loose: No next URI found 0(14154) parse_headers: flags=ffffffffffffffff 0(14154) subst_run: running. r=0 0(14154) subst_run: matched (0, 34): [sip:400@192.168.39.50:5060;nat=yes] 0(14154) textops: subst_uri_f: match - old uri= [sip:400@192.168.39.50:5060;nat=yes], new uri= [sip:400@192.168.39.50:5060] 0(14154) DEBUG: t_newtran: msg id=8 , global msg id=7 , T on entrance=0xffffffffffffffff 0(14154) parse_headers: flags=ffffffffffffffff 0(14154) parse_headers: flags=78 0(14154) t_lookup_request: start searching: hash=34382, isACK=1 0(14154) parse_headers: flags=38 0(14154) DEBUG: t_lookup_request: e2e proxy ACK found 0(14154) DEBUG:tm:REF_UNSAFE: after is 1 0(14154) DEBUG:tm:t_newtran: building branch for end2end ACK 0(14154) DEBUG:tm:UNREF_UNSAFE: after is 0 0(14154) DEBUG:tm:t_relay: forwarding ACK 0(14154) DEBUG: mk_proxy: doing DNS lookup... 0(14154) check_via_address(192.168.39.50, 192.168.39.50, 0) 0(14154) Sending: ACK sip:400@192.168.39.50:5060 SIP/2.0 Record-Route: sip:192.168.39.54;lr=on;ftag=0-13c4-44db1c5c-b390c-6691 From: sip:500@192.168.39.54;tag=0-13c4-44db1c5c-b390c-6691 To: sip:anonymous@anonymous.com;tag=0-13c4-44db1c5c-b38bc-7e15 Call-ID: c8ea3c-0-13c4-44db1c5c-b38bc-31ff@anonymous.com CSeq: 1 ACK Via: SIP/2.0/UDP 192.168.39.54;branch=z9hG4bKe468.f73bf65.2 Via: SIP/2.0/UDP 192.168.39.50:5060;rport=5060;branch=z9hG4bK-44db1c63-b5464-4f82 Max-Forwards: 69 User-Agent: SIP-RG Contact: sip:500@192.168.39.50:5060;nat=yes Content-Length: 0 P-hint: rr-enforced
. 0(14154) orig. len=480, new_len=583, proto=1 0(14154) DEBUG:destroy_avp_list: destroying list (nil) 0(14154) receive_msg: cleaning up 1(14160) DEBUG: timer routine:0,tl=0x2ba62f3c16c8 next=(nil) 1(14160) DEBUG: timer routine:4,tl=0x2ba62f3c16a8 next=(nil) 1(14160) DEBUG: timer routine:2,tl=0x2ba62f3c1548 next=(nil) 1(14160) DEBUG: wait_handler : removing 0x2ba62f3c14c8 from table 1(14160) DEBUG: delete transaction 0x2ba62f3c14c8 1(14160) DEBUG: wait_handler : done 0(14154) SIP Request: 0(14154) method: <BYE> 0(14154) uri: sip:500@192.168.39.50:5060;nat=yes 0(14154) version: <SIP/2.0> 0(14154) parse_headers: flags=2 0(14154) DEBUG: add_param: tag=0-13c4-44db1c5c-b390c-6691 0(14154) DEBUG:parse_to:end of header reached, state=29 0(14154) DBUG:parse_to: display={}, ruri={sip:500@192.168.39.54} 0(14154) DEBUG: get_hdr_field: <To> [56]; uri=[sip:500@192.168.39.54] 0(14154) DEBUG: to body [sip:500@192.168.39.54] 0(14154) get_hdr_field: cseq <CSeq>: <2> <BYE> 0(14154) Found param type 232, <branch> = <z9hG4bK-44db1c6a-b6f94-66d0>; state=16 0(14154) end of header reached, state=5 0(14154) parse_headers: Via found, flags=2 0(14154) parse_headers: this is the first via 0(14154) After parse_msg... 0(14154) preparing to run routing scripts... 0(14154) parse_headers: flags=100 0(14154) DEBUG:maxfwd:is_maxfwd_present: value = 70 0(14154) check_via_address(192.168.39.50, 192.168.39.50, 0) 0(14154) parse_headers: flags=80 0(14154) DEBUG: get_hdr_body : content_length=0 0(14154) found end of header 0(14154) DEBUG: add_param: tag=0-13c4-44db1c5c-b38bc-7e15 0(14154) DEBUG:parse_to:end of header reached, state=29 0(14154) DBUG:parse_to: display={}, ruri={sip:anonymous@anonymous.com} 0(14154) parse_headers: flags=200 0(14154) is_preloaded: No 0(14154) grep_sock_info - checking if host==us: 13==13 && [192.168.39.50] == [192.168.39.54] 0(14154) grep_sock_info - checking if port 5060 matches port 5060 0(14154) grep_sock_info - checking if host==us: 13==13 && [192.168.39.50] == [192.168.39.54] 0(14154) grep_sock_info - checking if port 5060 matches port 5060 0(14154) check_self: host != me 0(14154) grep_sock_info - checking if host==us: 13==13 && [192.168.39.54] == [192.168.39.54] 0(14154) grep_sock_info - checking if port 5060 matches port 5060 0(14154) after_loose: Topmost route URI: 'sip:192.168.39.54;lr;ftag=0-13c4-44db1c5c-b38bc-7e15' is me 0(14154) parse_headers: flags=200 0(14154) found end of header 0(14154) find_next_route: No next Route HF found 0(14154) after_loose: No next URI found 0(14154) parse_headers: flags=ffffffffffffffff 0(14154) subst_run: running. r=0 0(14154) subst_run: matched (0, 34): [sip:500@192.168.39.50:5060;nat=yes] 0(14154) textops: subst_uri_f: match - old uri= [sip:500@192.168.39.50:5060;nat=yes], new uri= [sip:500@192.168.39.50:5060] 0(14154) parse_headers: flags=40 0(14154) DEBUG: t_newtran: msg id=9 , global msg id=8 , T on entrance=0xffffffffffffffff 0(14154) parse_headers: flags=ffffffffffffffff 0(14154) parse_headers: flags=78 0(14154) t_lookup_request: start searching: hash=34379, isACK=0 0(14154) DEBUG: RFC3261 transaction matching failed 0(14154) DEBUG: t_lookup_request: no transaction found 0(14154) DEBUG: mk_proxy: doing DNS lookup... 0(14154) check_via_address(192.168.39.50, 192.168.39.50, 0) 0(14154) DEBUG: add_to_tail_of_timer[4]: 0x2ba62f3c16a8 0(14154) DEBUG: add_to_tail_of_timer[0]: 0x2ba62f3c16c8 0(14154) SER: new transaction fwd'ed 0(14154) DEBUG:tm:UNREF_UNSAFE: after is 0 0(14154) DEBUG:destroy_avp_list: destroying list (nil) 0(14154) receive_msg: cleaning up 0(14154) SIP Reply (status): 0(14154) version: <SIP/2.0> 0(14154) status: <200> 0(14154) reason: <OK> 0(14154) parse_headers: flags=2 0(14154) DEBUG: add_param: tag=0-13c4-44db1c5c-b390c-6691 0(14154) DEBUG:parse_to:end of header reached, state=29 0(14154) DBUG:parse_to: display={}, ruri={sip:500@192.168.39.54} 0(14154) DEBUG: get_hdr_field: <To> [56]; uri=[sip:500@192.168.39.54] 0(14154) DEBUG: to body [sip:500@192.168.39.54] 0(14154) get_hdr_field: cseq <CSeq>: <2> <BYE> 0(14154) Found param type 232, <branch> = <z9hG4bKb468.e8013011.0>; state=16 0(14154) end of header reached, state=5 0(14154) parse_headers: Via found, flags=2 0(14154) parse_headers: this is the first via 0(14154) After parse_msg... 0(14154) forward_reply: found module nathelper, passing reply to it 0(14154) forward_reply: found module tm, passing reply to it 0(14154) DEBUG: t_check: msg id=10 global id=9 T start=0xffffffffffffffff 0(14154) parse_headers: flags=22 0(14154) DEBUG: t_reply_matching: hash 34379 label 285413518 branch 0 0(14154) DEBUG:tm:REF_UNSAFE: after is 1 0(14154) DEBUG: t_reply_matching: reply matched (T=0x2ba62f3c14c8)! 0(14154) DEBUG: t_check: msg id=10 global id=10 T end=0x2ba62f3c14c8 0(14154) DEBUG:tm:reply_received: org. status uas=0, uac[0]=0 local=0 is_invite=0) 0(14154) parse_headers: flags=ffffffffffffffff 0(14154) Found param type 235, <rport> = <5060>; state=6 0(14154) Found param type 232, <branch> = <z9hG4bK-44db1c6a-b6f94-66d0>; state=16 0(14154) end of header reached, state=5 0(14154) parse_headers: Via found, flags=ffffffffffffffff 0(14154) parse_headers: this is the second via 0(14154) DEBUG: get_hdr_body : content_length=0 0(14154) found end of header 0(14154) ERROR: extract_body: message body has length zero 0(14154) ERROR: force_rtp_proxy2: can't extract body from the message 0(14154) parse_headers: flags=80 0(14154) DEBUG:tm:t_should_relay_response: T_code=0, new_code=200 0(14154) DEBUG:tm:relay_reply: branch=0, save=0, relay=0 0(14154) old size: 420, new size: 358 0(14154) build_res_from_sip_res: copied size: orig:277, new: 215, rest: 143 msg= SIP/2.0 200 OK From: sip:anonymous@anonymous.com;tag=0-13c4-44db1c5c-b38bc-7e15 To: sip:500@192.168.39.54;tag=0-13c4-44db1c5c-b390c-6691 Call-ID: c8ea3c-0-13c4-44db1c5c-b38bc-31ff@anonymous.com CSeq: 2 BYE Via: SIP/2.0/UDP 192.168.39.50:5060;rport=5060;branch=z9hG4bK-44db1c6a-b6f94-66d0 Supported: 100rel User-Agent: SIP-RG Content-Length: 0
0(14154) WARNING:vqm_resize: resize(0) called 0(14154) DEBUG: add_to_tail_of_timer[2]: 0x2ba62f3c1548 0(14154) DEBUG:tm:relay_reply: sent buf=0x6166b8: SIP/2.0 2..., shmem=0x2ba62f3c3f30: SIP/2.0 2 0(14154) DEBUG: cleanup_uac_timers: RETR/FR timers reset 0(14154) DEBUG:tm:UNREF_UNSAFE: after is 0 0(14154) DEBUG:destroy_avp_list: destroying list (nil) 0(14154) receive_msg: cleaning up 1(14160) DEBUG: timer routine:0,tl=0x2ba62f3c16c8 next=(nil) 1(14160) DEBUG: timer routine:4,tl=0x2ba62f3c16a8 next=(nil) 1(14160) DEBUG: timer routine:2,tl=0x2ba62f3c1548 next=(nil) 1(14160) DEBUG: wait_handler : removing 0x2ba62f3c14c8 from table 1(14160) DEBUG: delete transaction 0x2ba62f3c14c8 1(14160) DEBUG: wait_handler : done 1(14160) INFO: signal 2 received 1(14160) Memory status (pkg): 1(14160) fm_status (0x605460): 1(14160) heap size= 1048576 1(14160) used= 23256, used+overhead=61944, free=986632 1(14160) max used (+overhead)= 65384 1(14160) dumping free list: 1(14160) hash = 13 fragments no.: 1, unused: 0 bucket size: 104 - 104 (first 104) 1(14160) hash = 23 fragments no.: 1, unused: 0 bucket size: 184 - 184 (first 184) 1(14160) hash = 39 fragments no.: 1, unused: 0 bucket size: 312 - 312 (first 312) 1(14160) hash = 851 fragments no.: 1, unused: 0 bucket size: 6808 - 6808 (first 6808) 1(14160) hash = 2054 fragments no.: 1, unused: 0 bucket size: 524288 - 1048576 (first 979224) 1(14160) TOTAL: 5 free fragments = 986632 free bytes 1(14160) ----------------------------- 0(14154) INT received, program terminates 2(14161) INFO: signal 15 received 2(14161) Memory status (pkg): 2(14161) fm_status (0x605460): 2(14161) heap size= 1048576 2(14161) used= 23576, used+overhead=62376, free=986200 2(14161) max used (+overhead)= 65384 2(14161) dumping free list: 2(14161) hash = 21 fragments no.: 1, unused: 0 bucket size: 168 - 168 (first 168) 2(14161) hash = 851 fragments no.: 1, unused: 0 bucket size: 6808 - 6808 (first 6808) 2(14161) hash = 2054 fragments no.: 1, unused: 0 bucket size: 524288 - 1048576 (first 979224) 2(14161) TOTAL: 3 free fragments = 986200 free bytes 2(14161) ----------------------------- 0(14154) pool_remove: Connection still kept in the pool 0(14154) pool_remove: Connection still kept in the pool 0(14154) pool_remove: Removing connection from the pool
-- Pavel D.Kuzin System Administrator Nodex ISP St. Petersburg, Russia pk@nodex.ru http://nodex.ru
As you can see in the snippet a left from the debug, the re-INVITE is managed by the nathelper module. Please provide network trace to be able to see the result of the processing (received and sent messages). Use:
ngrep -qt -d any port 5060
on your sip server.
Cheers, Daniel
On 08/10/06 14:57, Pavel D. Kuzin wrote:
this is a debug view with debug=5
[...]
0(14154) SIP Request: 0(14154) method: <INVITE> 0(14154) uri: sip:400@192.168.39.50:5060;nat=yes 0(14154) version: <SIP/2.0> 0(14154) parse_headers: flags=2 0(14154) DEBUG: add_param: tag=0-13c4-44db1c5c-b38bc-7e15 0(14154) DEBUG:parse_to:end of header reached, state=29 0(14154) DBUG:parse_to: display={}, ruri={sip:anonymous@anonymous.com} 0(14154) DEBUG: get_hdr_field: <To> [62]; uri=[sip:anonymous@anonymous.com] 0(14154) DEBUG: to body [sip:anonymous@anonymous.com] 0(14154) get_hdr_field: cseq <CSeq>: <1> <INVITE> 0(14154) Found param type 232, <branch> = <z9hG4bK-44db1c63-b5374-2864>; state=16 0(14154) end of header reached, state=5 0(14154) parse_headers: Via found, flags=2 0(14154) parse_headers: this is the first via 0(14154) After parse_msg... 0(14154) preparing to run routing scripts... 0(14154) parse_headers: flags=100 0(14154) DEBUG:maxfwd:is_maxfwd_present: value = 70 0(14154) check_via_address(192.168.39.50, 192.168.39.50, 0) 0(14154) parse_headers: flags=80 0(14154) parse_headers: flags=80 0(14154) DEBUG: add_param: tag=0-13c4-44db1c5c-b390c-6691 0(14154) DEBUG:parse_to:end of header reached, state=29 0(14154) DBUG:parse_to: display={}, ruri={sip:500@192.168.39.54} 0(14154) parse_headers: flags=200 0(14154) is_preloaded: No 0(14154) grep_sock_info - checking if host==us: 13==13 && [192.168.39.50] == [192.168.39.54] 0(14154) grep_sock_info - checking if port 5060 matches port 5060 0(14154) grep_sock_info - checking if host==us: 13==13 && [192.168.39.50] == [192.168.39.54] 0(14154) grep_sock_info - checking if port 5060 matches port 5060 0(14154) check_self: host != me 0(14154) grep_sock_info - checking if host==us: 13==13 && [192.168.39.54] == [192.168.39.54] 0(14154) grep_sock_info - checking if port 5060 matches port 5060 0(14154) after_loose: Topmost route URI: 'sip:192.168.39.54;lr;ftag=0-13c4-44db1c5c-b38bc-7e15' is me 0(14154) parse_headers: flags=200 0(14154) DEBUG: get_hdr_body : content_length=318 0(14154) found end of header 0(14154) find_next_route: No next Route HF found 0(14154) after_loose: No next URI found 0(14154) parse_headers: flags=ffffffffffffffff 0(14154) parse_headers: flags=40 0(14154) parse_headers: flags=ffffffffffffffff 0(14154) DEBUG:check_content_type: type <application/sdp> found valid 0(14154) parse_headers: flags=40 0(14154) force_rtp_proxy2: proxy reply: 35030 192.168.39.54
0(14154) subst_run: running. r=0 0(14154) subst_run: matched (0, 34): [sip:400@192.168.39.50:5060;nat=yes] 0(14154) textops: subst_uri_f: match - old uri= [sip:400@192.168.39.50:5060;nat=yes], new uri= [sip:400@192.168.39.50:5060] 0(14154) parse_headers: flags=ffffffffffffffff 0(14154) DEBUG:check_content_type: type <application/sdp> found valid 0(14154) parse_headers: flags=40 0(14154) force_rtp_proxy2: proxy reply: 35030 192.168.39.54
0(14154) DEBUG: t_newtran: msg id=6 , global msg id=5 , T on entrance=0xffffffffffffffff 0(14154) parse_headers: flags=ffffffffffffffff 0(14154) parse_headers: flags=78 0(14154) t_lookup_request: start searching: hash=34382, isACK=0 0(14154) DEBUG: RFC3261 transaction matching failed 0(14154) DEBUG: t_lookup_request: no transaction found 0(14154) DEBUG:tm:t_relay: new INVITE 0(14154) parse_headers: flags=ffffffffffffffff 0(14154) check_via_address(192.168.39.50, 192.168.39.50, 0) 0(14154) WARNING:vqm_resize: resize(0) called 0(14154) DEBUG:tm:_reply_light: reply sent out. buf=0x6166b8: SIP/2.0 1..., shmem=0x2ba62f3c3f30: SIP/2.0 1 0(14154) DEBUG:tm:_reply_light: finished 0(14154) DEBUG: mk_proxy: doing DNS lookup... 0(14154) parse_headers: flags=2000 0(14154) parse_headers: flags=ffffffffffffffff 0(14154) clen_builder: content-length: 372 (372) 0(14154) check_via_address(192.168.39.50, 192.168.39.50, 0) 0(14154) DEBUG: add_to_tail_of_timer[4]: 0x2ba62f3c16a8 0(14154) DEBUG: add_to_tail_of_timer[0]: 0x2ba62f3c16c8 0(14154) SER: new transaction fwd'ed 0(14154) DEBUG:tm:UNREF_UNSAFE: after is 0 0(14154) DEBUG:destroy_avp_list: destroying list (nil) 0(14154) receive_msg: cleaning up
Hello!
This is ngrep output: U 2006/08/11 14:31:52.996709 192.168.39.50:5060 -> 192.168.39.54:5060 INVITE sip:500@192.168.39.54 SIP/2.0..From: sip:anonymous@anonymous.com;tag=0-13c4-44dc5c97-4ee1e30-4451..To: sip:500@192.168.39.54 ..Call-ID: c8ece4-0-13c4-44dc5c97-4ee1e30-26db@anonymous.com..CSeq: 1 INVITE..Via: SIP/2.0/UDP 192.168.39.50:5060;branch=z9hG4bK-44dc5c 97-4ee1e30-74b6..Max-Forwards: 70..Supported: 100rel..User-Agent: SIP-RG..Contact: sip:400@192.168.39.50..Content-Type: application/s dp..Content-Length: 230....v=0..o=SIP-N-TA 0 0 IN IP4 192.168.39.50..s=C0A82732 0000 C0A82732 0000 02 0..c=IN IP4 192.168.39.50..t=0 0. .m=audio 20050 RTP/AVP 18 4 0 8..a=rtpmap:18 G729/8000..a=rtpmap:4 G723/8000..a=rtpmap:0 PCMU/8000..a=rtpmap:8 PCMA/8000..
U 2006/08/11 14:31:52.997676 192.168.39.54:5060 -> 192.168.39.50:5060 SIP/2.0 100 trying -- your call is important to us..From: sip:anonymous@anonymous.com;tag=0-13c4-44dc5c97-4ee1e30-4451..To: <sip:500@ 192.168.39.54>..Call-ID: c8ece4-0-13c4-44dc5c97-4ee1e30-26db@anonymous.com..CSeq: 1 INVITE..Via: SIP/2.0/UDP 192.168.39.50:5060;branch= z9hG4bK-44dc5c97-4ee1e30-74b6;rport=5060..Server: OpenSer (1.1.0-notls (x86_64/linux))..Content-Length: 0..Warning: 392 192.168.39.54:5 060 "Noisy feedback tells: pid=2902 req_src_ip=192.168.39.50 req_src_port=5060 in_uri=sip:500@192.168.39.54 out_uri=sip:500@192.168.39 .50 via_cnt==1"....
U 2006/08/11 14:31:52.997813 192.168.39.54:5060 -> 192.168.39.50:5060 INVITE sip:500@192.168.39.50 SIP/2.0..Record-Route: sip:192.168.39.54;lr=on;ftag=0-13c4-44dc5c97-4ee1e30-4451..From: <sip:anonymous@a nonymous.com>;tag=0-13c4-44dc5c97-4ee1e30-4451..To: sip:500@192.168.39.54..Call-ID: c8ece4-0-13c4-44dc5c97-4ee1e30-26db@anonymous.com ..CSeq: 1 INVITE..Via: SIP/2.0/UDP 192.168.39.54;branch=z9hG4bK9017.69c65191.0..Via: SIP/2.0/UDP 192.168.39.50:5060;rport=5060;branch=z 9hG4bK-44dc5c97-4ee1e30-74b6..Max-Forwards: 69..Supported: 100rel..User-Agent: SIP-RG..Contact: sip:400@192.168.39.50:5060;nat=yes..C ontent-Type: application/sdp..Content-Length: 248..P-hint: usrloc applied....v=0..o=SIP-N-TA 0 0 IN IP4 192.168.39.50..s=C0A82732 0000 C0A82732 0000 02 0..c=IN IP4 192.168.39.54..t=0 0..m=audio 35034 RTP/AVP 18 4 0 8..a=rtpmap:18 G729/8000..a=rtpmap:4 G723/8000..a=rtpma p:0 PCMU/8000..a=rtpmap:8 PCMA/8000..a=nortpproxy:yes..
U 2006/08/11 14:31:53.065819 192.168.39.50:5060 -> 192.168.39.54:5060 SIP/2.0 100 Trying..From: sip:anonymous@anonymous.com;tag=0-13c4-44dc5c97-4ee1e30-4451..To: sip:500@192.168.39.54;tag=0-13c4-44dc5c 97-4ee1e80-548d..Call-ID: c8ece4-0-13c4-44dc5c97-4ee1e30-26db@anonymous.com..CSeq: 1 INVITE..Via: SIP/2.0/UDP 192.168.39.54;branch=z9hG 4bK9017.69c65191.0..Via: SIP/2.0/UDP 192.168.39.50:5060;rport=5060;branch=z9hG4bK-44dc5c97-4ee1e30-74b6..Supported: 100rel..User-Agent: SIP-RG..Contact: sip:500@192.168.39.50:5060..Content-Length: 0....
U 2006/08/11 14:31:53.075279 192.168.39.50:5060 -> 192.168.39.54:5060 SIP/2.0 180 Ringing..From: sip:anonymous@anonymous.com;tag=0-13c4-44dc5c97-4ee1e30-4451..To: sip:500@192.168.39.54;tag=0-13c4-44dc5 c97-4ee1e80-548d..Call-ID: c8ece4-0-13c4-44dc5c97-4ee1e30-26db@anonymous.com..CSeq: 1 INVITE..Via: SIP/2.0/UDP 192.168.39.54;branch=z9h G4bK9017.69c65191.0..Via: SIP/2.0/UDP 192.168.39.50:5060;rport=5060;branch=z9hG4bK-44dc5c97-4ee1e30-74b6..Supported: 100rel..User-Agent : SIP-RG..Contact: sip:500@192.168.39.50:5060..Content-Length: 0....
U 2006/08/11 14:31:53.075643 192.168.39.54:5060 -> 192.168.39.50:5060 SIP/2.0 180 Ringing..From: sip:anonymous@anonymous.com;tag=0-13c4-44dc5c97-4ee1e30-4451..To: sip:500@192.168.39.54;tag=0-13c4-44dc5 c97-4ee1e80-548d..Call-ID: c8ece4-0-13c4-44dc5c97-4ee1e30-26db@anonymous.com..CSeq: 1 INVITE..Via: SIP/2.0/UDP 192.168.39.50:5060;rport =5060;branch=z9hG4bK-44dc5c97-4ee1e30-74b6..Supported: 100rel..User-Agent: SIP-RG..Contact: sip:500@192.168.39.50:5060;nat=yes..Conte nt-Length: 0....
U 2006/08/11 14:31:54.124581 192.168.39.50:5060 -> 192.168.39.54:5060 SIP/2.0 200 OK..From: sip:anonymous@anonymous.com;tag=0-13c4-44dc5c97-4ee1e30-4451..To: sip:500@192.168.39.54;tag=0-13c4-44dc5c97-4 ee1e80-548d..Call-ID: c8ece4-0-13c4-44dc5c97-4ee1e30-26db@anonymous.com..CSeq: 1 INVITE..Via: SIP/2.0/UDP 192.168.39.54;branch=z9hG4bK9 017.69c65191.0..Via: SIP/2.0/UDP 192.168.39.50:5060;rport=5060;branch=z9hG4bK-44dc5c97-4ee1e30-74b6..Supported: 100rel..User-Agent: SIP -RG..Contact: sip:500@192.168.39.50:5060..Record-Route: sip:192.168.39.54;lr;ftag=0-13c4-44dc5c97-4ee1e30-4451..Content-Type: appli cation/sdp..Content-Length: 158....v=0..o=SIP-N-TA 0 0 IN IP4 192.168.39.50..s=C0A82732 0000 C0A82732 0000 01 0..c=IN IP4 192.168.39.50 ..t=0 0..m=audio 20048 RTP/AVP 18..a=rtpmap:18 G729/8000..
U 2006/08/11 14:31:54.125711 192.168.39.54:5060 -> 192.168.39.50:5060 SIP/2.0 200 OK..From: sip:anonymous@anonymous.com;tag=0-13c4-44dc5c97-4ee1e30-4451..To: sip:500@192.168.39.54;tag=0-13c4-44dc5c97-4 ee1e80-548d..Call-ID: c8ece4-0-13c4-44dc5c97-4ee1e30-26db@anonymous.com..CSeq: 1 INVITE..Via: SIP/2.0/UDP 192.168.39.50:5060;rport=5060 ;branch=z9hG4bK-44dc5c97-4ee1e30-74b6..Supported: 100rel..User-Agent: SIP-RG..Contact: sip:500@192.168.39.50:5060;nat=yes..Record-Rou te: sip:192.168.39.54;lr;ftag=0-13c4-44dc5c97-4ee1e30-4451..Content-Type: application/sdp..Content-Length: 176....v=0..o=SIP-N-TA 0 0 IN IP4 192.168.39.50..s=C0A82732 0000 C0A82732 0000 01 0..c=IN IP4 192.168.39.54..t=0 0..m=audio 35036 RTP/AVP 18..a=rtpmap:18 G729/80 00..a=nortpproxy:yes..
U 2006/08/11 14:31:54.166435 192.168.39.50:5060 -> 192.168.39.54:5060 ACK sip:500@192.168.39.50:5060;nat=yes SIP/2.0..From: sip:anonymous@anonymous.com;tag=0-13c4-44dc5c97-4ee1e30-4451..To: <sip:500@192. 168.39.54>;tag=0-13c4-44dc5c97-4ee1e80-548d..Call-ID: c8ece4-0-13c4-44dc5c97-4ee1e30-26db@anonymous.com..CSeq: 1 ACK..Via: SIP/2.0/UDP 192.168.39.50:5060;branch=z9hG4bK-44dc5c98-4ee22cc-2642..Max-Forwards: 70..User-Agent: SIP-RG..Contact: sip:400@192.168.39.50..Route: sip:192.168.39.54;lr;ftag=0-13c4-44dc5c97-4ee1e30-4451..Content-Length: 0....
U 2006/08/11 14:31:54.167136 192.168.39.54:5060 -> 192.168.39.50:5060 ACK sip:500@192.168.39.50:5060 SIP/2.0..Record-Route: sip:192.168.39.54;lr=on;ftag=0-13c4-44dc5c97-4ee1e30-4451..From: <sip:anonymous @anonymous.com>;tag=0-13c4-44dc5c97-4ee1e30-4451..To: sip:500@192.168.39.54;tag=0-13c4-44dc5c97-4ee1e80-548d..Call-ID: c8ece4-0-13c4- 44dc5c97-4ee1e30-26db@anonymous.com..CSeq: 1 ACK..Via: SIP/2.0/UDP 192.168.39.54;branch=z9hG4bK9017.69c65191.2..Via: SIP/2.0/UDP 192.16 8.39.50:5060;rport=5060;branch=z9hG4bK-44dc5c98-4ee22cc-2642..Max-Forwards: 69..User-Agent: SIP-RG..Contact: <sip:400@192.168.39.50:506 0;nat=yes>..Content-Length: 0..P-hint: rr-enforced....
U 2006/08/11 14:31:59.598473 192.168.39.50:5060 -> 192.168.39.54:5060 INVITE sip:400@192.168.39.50:5060;nat=yes SIP/2.0..From: sip:500@192.168.39.54;tag=0-13c4-44dc5c97-4ee1e80-548d..To: <sip:anonymous@a nonymous.com>;tag=0-13c4-44dc5c97-4ee1e30-4451..Call-ID: c8ece4-0-13c4-44dc5c97-4ee1e30-26db@anonymous.com..CSeq: 1 INVITE..Via: SIP/2. 0/UDP 192.168.39.50:5060;branch=z9hG4bK-44dc5c9d-4ee37f8-7b90..Max-Forwards: 70..Supported: 100rel..User-Agent: SIP-RG..Contact: <sip:5 00@192.168.39.50:5060>..Route: sip:192.168.39.54;lr;ftag=0-13c4-44dc5c97-4ee1e30-4451..Content-Type: application/sdp..Content-Length: 318....v=0..o=SIP-N-TA 0 0 IN IP4 192.168.39.50..s=C0A82732 0000 C0A82732 0000 01 0..c=IN IP4 192.168.39.50..t=0 0..m=image 20032 udpt l t38..c=IN IP4 192.168.39.50..a=T38FaxVersion:0..a=T38MaxBitRate:14400..a=T38FaxFillBitRemoval:0..a=T38FaxTranscodingMMR:0..a=T38FaxTr anscodingJBIG:0..a=T38FaxRateManagement:transferredTCF..
U 2006/08/11 14:31:59.615017 192.168.39.54:5060 -> 192.168.39.50:5060 SIP/2.0 100 trying -- your call is important to us..From: sip:500@192.168.39.54;tag=0-13c4-44dc5c97-4ee1e80-548d..To: <sip:anonymous@ anonymous.com>;tag=0-13c4-44dc5c97-4ee1e30-4451..Call-ID: c8ece4-0-13c4-44dc5c97-4ee1e30-26db@anonymous.com..CSeq: 1 INVITE..Via: SIP/2 .0/UDP 192.168.39.50:5060;branch=z9hG4bK-44dc5c9d-4ee37f8-7b90;rport=5060..Server: OpenSer (1.1.0-notls (x86_64/linux))..Content-Length : 0..Warning: 392 192.168.39.54:5060 "Noisy feedback tells: pid=2902 req_src_ip=192.168.39.50 req_src_port=5060 in_uri=sip:400@192.168 .39.50:5060;nat=yes out_uri=sip:400@192.168.39.50:5060 via_cnt==1"....
U 2006/08/11 14:31:59.615113 192.168.39.54:5060 -> 192.168.39.50:5060 INVITE sip:400@192.168.39.50:5060 SIP/2.0..Record-Route: sip:192.168.39.54;lr=on;ftag=0-13c4-44dc5c97-4ee1e80-548d..From: <sip:500@19 2.168.39.54>;tag=0-13c4-44dc5c97-4ee1e80-548d..To: sip:anonymous@anonymous.com;tag=0-13c4-44dc5c97-4ee1e30-4451..Call-ID: c8ece4-0-13 c4-44dc5c97-4ee1e30-26db@anonymous.com..CSeq: 1 INVITE..Via: SIP/2.0/UDP 192.168.39.54;branch=z9hG4bK9017.79c65191.0..Via: SIP/2.0/UDP 192.168.39.50:5060;rport=5060;branch=z9hG4bK-44dc5c9d-4ee37f8-7b90..Max-Forwards: 69..Supported: 100rel..User-Agent: SIP-RG..Contact: < sip:500@192.168.39.50:5060;nat=yes>..Content-Type: application/sdp..Content-Length: 372..P-hint: rr-enforced....v=0..o=SIP-N-TA 0 0 IN IP4 192.168.39.50..s=C0A82732 0000 C0A82732 0000 01 0..c=IN IP4 192.168.39.50..t=0 0..m=image 3503835038 udptl t38..c=IN IP4 192.168.39 .54192.168.39.54..a=T38FaxVersion:0..a=T38MaxBitRate:14400..a=T38FaxFillBitRemoval:0..a=T38FaxTranscodingMMR:0..a=T38FaxTranscodingJBIG :0..a=T38FaxRateManagement:transferredTCF..a=nortpproxy:yes..a=nortpproxy:yes..
U 2006/08/11 14:31:59.805239 192.168.39.50:5060 -> 192.168.39.54:5060 SIP/2.0 200 OK..From: sip:500@192.168.39.54;tag=0-13c4-44dc5c97-4ee1e80-548d..To: sip:anonymous@anonymous.com;tag=0-13c4-44dc5c97-4 ee1e30-4451..Call-ID: c8ece4-0-13c4-44dc5c97-4ee1e30-26db@anonymous.com..CSeq: 1 INVITE..Via: SIP/2.0/UDP 192.168.39.54;branch=z9hG4bK9 017.79c65191.0..Via: SIP/2.0/UDP 192.168.39.50:5060;rport=5060;branch=z9hG4bK-44dc5c9d-4ee37f8-7b90..Supported: 100rel..User-Agent: SIP -RG..Contact: sip:400@192.168.39.50..Content-Type: application/sdp..Content-Length: 156....v=0..o=SIP-N-TA 0 0 IN IP4 192.168.39.50.. s=C0A82732 0000 C0A82732 0000 02 0..c=IN IP4 192.168.39.50..t=0 0..m=audio 20050 RTP/AVP 0..a=rtpmap:0 PCMU/8000..
U 2006/08/11 14:31:59.806703 192.168.39.54:5060 -> 192.168.39.50:5060 SIP/2.0 200 OK..From: sip:500@192.168.39.54;tag=0-13c4-44dc5c97-4ee1e80-548d..To: sip:anonymous@anonymous.com;tag=0-13c4-44dc5c97-4 ee1e30-4451..Call-ID: c8ece4-0-13c4-44dc5c97-4ee1e30-26db@anonymous.com..CSeq: 1 INVITE..Via: SIP/2.0/UDP 192.168.39.50:5060;rport=5060 ;branch=z9hG4bK-44dc5c9d-4ee37f8-7b90..Supported: 100rel..User-Agent: SIP-RG..Contact: sip:400@192.168.39.50:5060;nat=yes..Content-Ty pe: application/sdp..Content-Length: 174....v=0..o=SIP-N-TA 0 0 IN IP4 192.168.39.50..s=C0A82732 0000 C0A82732 0000 02 0..c=IN IP4 192. 168.39.54..t=0 0..m=audio 35040 RTP/AVP 0..a=rtpmap:0 PCMU/8000..a=nortpproxy:yes..
U 2006/08/11 14:31:59.843381 192.168.39.50:5060 -> 192.168.39.54:5060 ACK sip:400@192.168.39.50:5060;nat=yes SIP/2.0..From: sip:500@192.168.39.54;tag=0-13c4-44dc5c97-4ee1e80-548d..To: <sip:anonymous@anon ymous.com>;tag=0-13c4-44dc5c97-4ee1e30-4451..Call-ID: c8ece4-0-13c4-44dc5c97-4ee1e30-26db@anonymous.com..CSeq: 1 ACK..Via: SIP/2.0/UDP 192.168.39.50:5060;branch=z9hG4bK-44dc5c9e-4ee38fc-648e..Max-Forwards: 70..User-Agent: SIP-RG..Contact: sip:500@192.168.39.50:5060..R oute: sip:192.168.39.54;lr;ftag=0-13c4-44dc5c97-4ee1e30-4451..Content-Length: 0....
U 2006/08/11 14:31:59.844014 192.168.39.54:5060 -> 192.168.39.50:5060 ACK sip:400@192.168.39.50:5060 SIP/2.0..Record-Route: sip:192.168.39.54;lr=on;ftag=0-13c4-44dc5c97-4ee1e80-548d..From: <sip:500@192.1 68.39.54>;tag=0-13c4-44dc5c97-4ee1e80-548d..To: sip:anonymous@anonymous.com;tag=0-13c4-44dc5c97-4ee1e30-4451..Call-ID: c8ece4-0-13c4- 44dc5c97-4ee1e30-26db@anonymous.com..CSeq: 1 ACK..Via: SIP/2.0/UDP 192.168.39.54;branch=z9hG4bK9017.79c65191.2..Via: SIP/2.0/UDP 192.16 8.39.50:5060;rport=5060;branch=z9hG4bK-44dc5c9e-4ee38fc-648e..Max-Forwards: 69..User-Agent: SIP-RG..Contact: <sip:500@192.168.39.50:506 0;nat=yes>..Content-Length: 0..P-hint: rr-enforced....
U 2006/08/11 14:32:05.562560 192.168.39.50:5060 -> 192.168.39.54:5060 BYE sip:500@192.168.39.50:5060;nat=yes SIP/2.0..From: sip:anonymous@anonymous.com;tag=0-13c4-44dc5c97-4ee1e30-4451..To: <sip:500@192. 168.39.54>;tag=0-13c4-44dc5c97-4ee1e80-548d..Call-ID: c8ece4-0-13c4-44dc5c97-4ee1e30-26db@anonymous.com..CSeq: 2 BYE..Via: SIP/2.0/UDP 192.168.39.50:5060;branch=z9hG4bK-44dc5ca3-4ee4f54-40bc..Max-Forwards: 70..Supported: 100rel..User-Agent: SIP-RG..Route: <sip:192.168.3 9.54;lr;ftag=0-13c4-44dc5c97-4ee1e30-4451>..Content-Length: 0....
U 2006/08/11 14:32:05.563260 192.168.39.54:5060 -> 192.168.39.50:5060 BYE sip:500@192.168.39.50:5060 SIP/2.0..Record-Route: sip:192.168.39.54;lr=on;ftag=0-13c4-44dc5c97-4ee1e30-4451..From: <sip:anonymous @anonymous.com>;tag=0-13c4-44dc5c97-4ee1e30-4451..To: sip:500@192.168.39.54;tag=0-13c4-44dc5c97-4ee1e80-548d..Call-ID: c8ece4-0-13c4- 44dc5c97-4ee1e30-26db@anonymous.com..CSeq: 2 BYE..Via: SIP/2.0/UDP 192.168.39.54;branch=z9hG4bK6017.5cbd9b75.0..Via: SIP/2.0/UDP 192.16 8.39.50:5060;rport=5060;branch=z9hG4bK-44dc5ca3-4ee4f54-40bc..Max-Forwards: 69..Supported: 100rel..User-Agent: SIP-RG..Content-Length: 0..P-hint: rr-enforced....
U 2006/08/11 14:32:05.600066 192.168.39.50:5060 -> 192.168.39.54:5060 SIP/2.0 200 OK..From: sip:anonymous@anonymous.com;tag=0-13c4-44dc5c97-4ee1e30-4451..To: sip:500@192.168.39.54;tag=0-13c4-44dc5c97-4 ee1e80-548d..Call-ID: c8ece4-0-13c4-44dc5c97-4ee1e30-26db@anonymous.com..CSeq: 2 BYE..Via: SIP/2.0/UDP 192.168.39.54;branch=z9hG4bK6017 .5cbd9b75.0..Via: SIP/2.0/UDP 192.168.39.50:5060;rport=5060;branch=z9hG4bK-44dc5ca3-4ee4f54-40bc..Supported: 100rel..User-Agent: SIP-RG ..Content-Length: 0....
U 2006/08/11 14:32:05.600463 192.168.39.54:5060 -> 192.168.39.50:5060 SIP/2.0 200 OK..From: sip:anonymous@anonymous.com;tag=0-13c4-44dc5c97-4ee1e30-4451..To: sip:500@192.168.39.54;tag=0-13c4-44dc5c97-4 ee1e80-548d..Call-ID: c8ece4-0-13c4-44dc5c97-4ee1e30-26db@anonymous.com..CSeq: 2 BYE..Via: SIP/2.0/UDP 192.168.39.50:5060;rport=5060;br anch=z9hG4bK-44dc5ca3-4ee4f54-40bc..Supported: 100rel..User-Agent: SIP-RG..Content-Length: 0....
U 2006/08/11 14:32:11.214003 192.168.39.54:5060 -> 192.168.39.50:5060 ....
U 2006/08/11 14:32:11.214011 192.168.39.54:5060 -> 192.168.39.50:5060 ....
-- Pavel D.Kuzin System Administrator Nodex ISP St. Petersburg, Russia pk@nodex.ru http://nodex.ru
Hello,
please send me your config file. It seems that is a bit different than the one on voip-info.org. The re-INVITE is managed via nathelper, but the force_rtp_proxy() is called twice, the re-invite sent by openser contains:
c=IN IP4 192.168.39.54192.168.39.54 and a=nortpproxy:yes..a=nortpproxy:yes..
This is a bug in the configuration file.
Cheers, Daniel
U 2006/08/11 14:31:59.615113 192.168.39.54:5060 -> 192.168.39.50:5060 INVITE sip:400@192.168.39.50:5060 SIP/2.0..Record-Route: sip:192.168.39.54;lr=on;ftag=0-13c4-44dc5c97-4ee1e80-548d..From: <sip:500@19 2.168.39.54>;tag=0-13c4-44dc5c97-4ee1e80-548d..To: sip:anonymous@anonymous.com;tag=0-13c4-44dc5c97-4ee1e30-4451..Call-ID: c8ece4-0-13 c4-44dc5c97-4ee1e30-26db@anonymous.com..CSeq: 1 INVITE..Via: SIP/2.0/UDP 192.168.39.54;branch=z9hG4bK9017.79c65191.0..Via: SIP/2.0/UDP 192.168.39.50:5060;rport=5060;branch=z9hG4bK-44dc5c9d-4ee37f8-7b90..Max-Forwards: 69..Supported: 100rel..User-Agent: SIP-RG..Contact: < sip:500@192.168.39.50:5060;nat=yes>..Content-Type: application/sdp..Content-Length: 372..P-hint: rr-enforced....v=0..o=SIP-N-TA 0 0 IN IP4 192.168.39.50..s=C0A82732 0000 C0A82732 0000 01 0..c=IN IP4 192.168.39.50..t=0 0..m=image 3503835038 udptl t38..c=IN IP4 192.168.39.54192.168.39.54..a=T38FaxVersion:0..a=T38MaxBitRate:14400..a=T38FaxFillBitRemoval:0..a=T38FaxTranscodingMMR:0..a=T38FaxTranscodingJBIG
:0..a=T38FaxRateManagement:transferredTCF..a=nortpproxy:yes..a=nortpproxy:yes..
On 08/11/06 13:31, Pavel D. Kuzin wrote:
[...]
# # sample config file to be used with nathelper/rtpproxy # # start RTPProxy with: rtpproxy -l your_public_ip -s udp:localhost:8899 #
# ----------- global configuration parameters ------------------------
debug=5 # debug level (cmd line: -dddddddddd) fork=yes log_stderror=no # (cmd line: -E)
fork=no log_stderror=yes
check_via=no # (cmd. line: -v) dns=no # (cmd. line: -r) rev_dns=no # (cmd. line: -R) port=5060 listen=192.168.39.54 children=4 fifo="/tmp/openser_fifo"
# --- module loading
mpath="/usr/local/lib64/openser/modules/" loadmodule "mysql.so" loadmodule "sl.so" loadmodule "tm.so" loadmodule "rr.so" loadmodule "maxfwd.so" loadmodule "usrloc.so" loadmodule "registrar.so" loadmodule "textops.so" loadmodule "nathelper.so" loadmodule "auth.so" loadmodule "auth_db.so" loadmodule "lcr.so"
# --- setting module parameters
#modparam("usrloc|auth_db","db_url","mysql://openser:openserrw@localhost/openser") modparam("usrloc|lcr|domain|auth_db|lcr", "db_url", "mysql://openser:openser@mysql1.nodex.ru/openser")
# -- usrloc params -- modparam("usrloc", "db_mode", 2)
# -- registrar params -- modparam("registrar", "nat_flag", 6) modparam("registrar", "sip_natping_flag", 7)
# -- auth params -- modparam("auth_db", "calculate_ha1", yes) modparam("auth_db", "password_column", "password")
# -- rr params -- modparam("rr", "enable_full_lr", 1)
# -- nathelper modparam("nathelper", "rtpproxy_sock", "udp:127.0.0.1:7890") modparam("nathelper", "natping_interval", 30) modparam("nathelper", "ping_nated_only", 1) modparam("nathelper", "sipping_from", "sip:pinger@openser.org")
# --- main routing logic route{ if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); exit; }; if (msg:len >= 2048 ) { sl_send_reply("513", "Message too big"); exit; };
# NAT detection route(2);
if (!method=="REGISTER") record_route();
if (loose_route()) { append_hf("P-hint: rr-enforced\r\n"); if (method == INVITE || method==REFER){ unforce_rtp_proxy(); force_rtp_proxy(); } route(1); };
if (!uri==myself) { append_hf("P-hint: outbound\r\n"); route(1); }; if (uri==myself) { if (method=="REGISTER") { if (!www_authorize("nodex.ru", "subscriber")) { www_challenge("nodex.ru", "0"); exit; };
if (isflagset(5)) { setflag(6); # if you want OPTIONS natpings uncomment next # setflag(7); }; save("location"); exit; };
if (!lookup("location")) { sl_send_reply("404", "Not Found"); exit; }; append_hf("P-hint: usrloc applied\r\n"); };
route(1); }
route[1] { if (subst_uri('/(sip:.*);nat=yes/\1/')){ setflag(6); };
if (isflagset(5)||isflagset(6)) { route(3); } if (!t_relay()) { sl_reply_error(); }; exit; }
route[2]{ force_rport(); if (nat_uac_test("19")) { if (method=="REGISTER") { fix_nated_register(); } else { fix_nated_contact(); }; setflag(5); }; }
route[3] { if (is_method("BYE|CANCEL")) { unforce_rtp_proxy(); } else if (is_method("INVITE")){ force_rtp_proxy(); t_on_failure("1"); }; if (isflagset(5)) search_append('Contact:.*sip:[^>[:cntrl:]]*', ';nat=yes'); t_on_reply("1"); }
failure_route[1] { if (isflagset(6) || isflagset(5)) { unforce_rtp_proxy(); } }
onreply_route[1] { if ((isflagset(5) || isflagset(6)) && status=~"(183)|(2[0-9][0-9])") { force_rtp_proxy(); } search_append('Contact:.*sip:[^>[:cntrl:]]*', ';nat=yes');
if (isflagset(6)) { fix_nated_contact(); } exit; }
-- Pavel D.Kuzin System Administrator Nodex ISP St. Petersburg, Russia pk@nodex.ru http://nodex.ru ----- Original Message ----- From: "Daniel-Constantin Mierla" daniel@voice-system.ro To: "Pavel D. Kuzin" pk@nodex.ru Cc: "Hakan YASTI" hakanyasti@gmail.com; users@openser.org Sent: Friday, August 11, 2006 2:57 PM Subject: Re: [Users] nathelper & fax = bug ?
Hello,
please send me your config file. It seems that is a bit different than the one on voip-info.org. The re-INVITE is managed via nathelper, but the force_rtp_proxy() is called twice, the re-invite sent by openser contains:
c=IN IP4 192.168.39.54192.168.39.54 and a=nortpproxy:yes..a=nortpproxy:yes..
This is a bug in the configuration file.
Cheers, Daniel
U 2006/08/11 14:31:59.615113 192.168.39.54:5060 -> 192.168.39.50:5060 INVITE sip:400@192.168.39.50:5060 SIP/2.0..Record-Route: sip:192.168.39.54;lr=on;ftag=0-13c4-44dc5c97-4ee1e80-548d..From: sip:500@19 2.168.39.54;tag=0-13c4-44dc5c97-4ee1e80-548d..To: sip:anonymous@anonymous.com;tag=0-13c4-44dc5c97-4ee1e30-4451..Call-ID: c8ece4-0-13 c4-44dc5c97-4ee1e30-26db@anonymous.com..CSeq: 1 INVITE..Via: SIP/2.0/UDP 192.168.39.54;branch=z9hG4bK9017.79c65191.0..Via: SIP/2.0/UDP 192.168.39.50:5060;rport=5060;branch=z9hG4bK-44dc5c9d-4ee37f8-7b90..Max-Forwards: 69..Supported: 100rel..User-Agent: SIP-RG..Contact: < sip:500@192.168.39.50:5060;nat=yes>..Content-Type: application/sdp..Content-Length: 372..P-hint: rr-enforced....v=0..o=SIP-N-TA 0 0 IN IP4 192.168.39.50..s=C0A82732 0000 C0A82732 0000 01 0..c=IN IP4 192.168.39.50..t=0 0..m=image 3503835038 udptl t38..c=IN IP4 192.168.39.54192.168.39.54..a=T38FaxVersion:0..a=T38MaxBitRate:14400..a=T38FaxFillBitRemoval:0..a=T38FaxTranscodingMMR:0..a=T38FaxTranscodingJBIG :0..a=T38FaxRateManagement:transferredTCF..a=nortpproxy:yes..a=nortpproxy:yes..
On 08/11/06 13:31, Pavel D. Kuzin 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@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@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@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@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@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
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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@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@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@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@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@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
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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:
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@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@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@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@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
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users