TomH Posted April 28, 2008 Report Share Posted April 28, 2008 Configuration Exchange inbound fax <> PBXnSIP <> BroadVox HT286 Fax Kapaga fax phone Issue After review we find that we consistantly work or don't work. The difference being that the inbound fax device changes to T38 with a reinvite using PORT 9001, PBXnSIP gets two ports for RTP (10001, 10002) tells Broadvox he will use port 10001, BroadVox says he will use port 20002 in an OK, If it works PBXnSIP OK's the client invite and uses 10002 so that fax to pbxnsip RTP is 9001 <> 10002 PBXnSIP to broadvox RTP is 10001 <> 20002 If it does not work PBXnSIP gets two new ports (10003, 10004) and OK's the client invite with 10003 so that: fax to pbxnsip RTP is 9001 <> 10003 PBXnSIP to broadvox RTP is 10004 <> 20002 The issue is I believe that a state/route has been setup on Broadvox linking 10001 <> 20002 when messages come in 10004 <> 20002 they go in the bit bucket. My questions is why is there an inconsistancy? Some times you use the original ports (this works), and sometimes you get new ports (this fails). Thanks for any guidance. I have included and commented the relevant part of the log. Tom Invite from fax client requesting T38 [7] 2008/04/23 13:42:28: SIP Rx tcp:172.1.1.81:5065: INVITE sip:103@172.1.1.75:4957;transport=tcp SIP/2.0 FROM: <sip:103@be7.mydomain.com;user=phone>;epid=34AEC95009;tag=54acd35ba1 TO: <sip:103@ezoutlook.com>;tag=5392 CSEQ: 1 INVITE CALL-ID: 46269039@pbx MAX-FORWARDS: 70 VIA: SIP/2.0/TCP 172.1.1.81:5065;branch=z9hG4bK12926ec CONTACT: <sip:be7.mydomain.com:5065;transport=Tcp;maddr=172.1.1.81;ms-opaque=2eb6a8402dbb9419>;automata CONTENT-LENGTH: 284 USER-AGENT: RTCC/3.0.0.0 CONTENT-TYPE: application/sdp v=0 o=- 0 1 IN IP4 172.1.1.81 s=session c=IN IP4 172.1.1.81 t=0 0 m=audio 0 RTP/AVP 0 8 101 13 a=rtpmap:0 PCMU/8000/1 a=rtpmap:8 PCMA/8000/1 a=rtpmap:101 telephone-event/8000 m=image 16861 udptl t38 a=T38FaxRateManagement:transferredTCF a=T38FaxUdpEC:t38UDPRedundancy [0] 2008/04/23 13:42:28: UDP: bind() to port 9066 failed Gets two ports, above bind failure does not always happen [7] 2008/04/23 13:42:28: UDP: Opening socket on port 9048 [7] 2008/04/23 13:42:28: UDP: Opening socket on port 9008 [9] 2008/04/23 13:42:28: Resolve 72699: url sip:5025555555@200.200.3.59:5060 [9] 2008/04/23 13:42:28: Resolve 72699: udp 200.200.3.59 5060 Invites broadvox [7] 2008/04/23 13:42:28: SIP Tx udp:200.200.3.59:5060: INVITE sip:5025555555@200.200.3.59:5060 SIP/2.0 Via: SIP/2.0/UDP 172.1.1.75:5060;branch=z9hG4bK-48ad4751e9b09902de83fe8ca58bdf61;rport From: <sip:10000555024444444@200.200.3.56:5060>;tag=bfe14f6334 To: "EZ OUTLOOK WEB " <sip:5025555555@200.200.3.59>;tag=3417961711-711590 Call-ID: 1560-3417961711-711581@NXT01.broadvox.net CSeq: 13831 INVITE Max-Forwards: 70 Contact: <sip:Anonymous@172.1.1.75:5060;transport=udp> Supported: 100rel, replaces, norefersub Allow-Events: refer Allow: INVITE, ACK, CANCEL, BYE, REFER, PRACK, INFO, UPDATE Accept: application/sdp User-Agent: pbxnsip-PBX/2.1.8.2463 Content-Type: application/sdp Content-Length: 283 v=0 o=- 17827 17828 IN IP4 172.1.1.75 s=- c=IN IP4 172.1.1.75 t=0 0 m=audio 0 RTP/AVP 0 8 101 13 a=rtpmap:0 PCMU/8000/1 a=rtpmap:8 PCMA/8000/1 a=rtpmap:101 telephone-event/8000 m=image 9008 udptl t38 a=T38FaxRateManagement:transferredTCF a=T38FaxUdpEC:t38UDPRedundancy [9] 2008/04/23 13:42:28: Resolve 72700: tcp 172.1.1.81 5065 [7] 2008/04/23 13:42:28: SIP Tx tcp:172.1.1.81:5065: SIP/2.0 100 Trying Via: SIP/2.0/TCP 172.1.1.81:5065;branch=z9hG4bK12926ec From: <sip:103@be7.mydomain.com;user=phone>;epid=34AEC95009;tag=54acd35ba1 To: <sip:103@ezoutlook.com>;tag=5392 Call-ID: 46269039@pbx CSeq: 1 INVITE Content-Length: 0 [7] 2008/04/23 13:42:29: SIP Rx udp:200.200.3.59:5060: SIP/2.0 100 Trying Via: SIP/2.0/UDP 172.1.1.75:5060;branch=z9hG4bK-48ad4751e9b09902de83fe8ca58bdf61;rport From: <sip:10000555024444444@200.200.3.56:5060>;tag=bfe14f6334 To: "EZ OUTLOOK WEB " <sip:5025555555@200.200.3.59>;tag=3417961711-711590 Call-ID: 1560-3417961711-711581@NXT01.broadvox.net CSeq: 13831 INVITE Content-Length: 0 Broadvox OK [7] 2008/04/23 13:42:29: SIP Rx udp:200.200.3.59:5060: SIP/2.0 200 OK Via: SIP/2.0/UDP 172.1.1.75:5060;branch=z9hG4bK-48ad4751e9b09902de83fe8ca58bdf61;rport To: "EZ OUTLOOK WEB " <sip:5025555555@200.200.3.59>;tag=3417961711-711590 From: <sip:10000555024444444@200.200.3.56:5060>;tag=bfe14f6334 Call-ID: 1560-3417961711-711581@NXT01.broadvox.net CSeq: 13831 INVITE Allow: INVITE, BYE, OPTIONS, CANCEL, ACK, REGISTER, NOTIFY, INFO, REFER, SUBSCRIBE, PRACK, UPDATE Contact: <sip:5025555555@200.200.3.59:5060> Call-Info: <sip:200.200.3.59>;method="NOTIFY;Event=telephone-event;Duration=1000" Content-Type: application/sdp Content-Length: 315 v=0 o=NXT01 0 1 IN IP4 200.200.3.59 s=sip call c=IN IP4 200.200.3.60 t=0 0 m=audio 16222 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=ptime:20 m=image 16228 udptl t38 a=T38FaxRateManagement:transferredTCF a=T38FaxUdpEC:t38UDPRedundancy a=sendrecv [7] 2008/04/23 13:42:29: Call 1560-3417961711-711581@NXT01.broadvox.net#bfe14f6334: Clear last INVITE HERE IS THE ISSUE IF YOU GET TWO NEW PORTS IT FAILS IF YOU KEEP THE ORIGINALS IT WORKS [7] 2008/04/23 13:42:29: UDP: Opening socket on port 9064 [7] 2008/04/23 13:42:29: UDP: Opening socket on port 9030 Now you are using a port 9064 for RTP to Broadvox instead of the stated port 9008 [9] 2008/04/23 13:42:29: Resolve 72701: tcp 172.1.1.81 5065 [7] 2008/04/23 13:42:29: SIP Tx tcp:172.1.1.81:5065: SIP/2.0 200 Ok Via: SIP/2.0/TCP 172.1.1.81:5065;branch=z9hG4bK12926ec From: <sip:103@be7.mydomain.com;user=phone>;epid=34AEC95009;tag=54acd35ba1 To: <sip:103@ezoutlook.com>;tag=5392 Call-ID: 46269039@pbx CSeq: 1 INVITE Contact: <sip:103@172.1.1.75:4957;transport=tcp> Supported: 100rel, replaces, norefersub Allow-Events: refer Allow: INVITE, ACK, CANCEL, BYE, REFER, PRACK, INFO, UPDATE Accept: application/sdp User-Agent: pbxnsip-PBX/2.1.8.2463 Content-Type: application/sdp Content-Length: 282 v=0 o=- 1981 1982 IN IP4 172.1.1.75 s=- c=IN IP4 172.1.1.75 t=0 0 m=audio 9048 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 m=image 9030 udptl t38 a=T38FaxRateManagement:transferredTCF a=T38FaxUdpEC:t38UDPRedundancy [9] 2008/04/23 13:42:29: Resolve 72702: url sip:5025555555@200.200.3.59:5060 [9] 2008/04/23 13:42:29: Resolve 72702: udp 200.200.3.59 5060 [7] 2008/04/23 13:42:29: SIP Tx udp:200.200.3.59:5060: ACK sip:5025555555@200.200.3.59:5060 SIP/2.0 Via: SIP/2.0/UDP 172.1.1.75:5060;branch=z9hG4bK-41742d16b815e8fef8a65e845f1a72cc;rport From: <sip:10000555024444444@200.200.3.56:5060>;tag=bfe14f6334 To: "EZ OUTLOOK WEB " <sip:5025555555@200.200.3.59>;tag=3417961711-711590 Call-ID: 1560-3417961711-711581@NXT01.broadvox.net CSeq: 13831 ACK Max-Forwards: 70 Contact: <sip:Anonymous@172.1.1.75:5060;transport=udp> Content-Length: 0 [7] 2008/04/23 13:42:29: Determine pass-through mode after receiving response [7] 2008/04/23 13:42:29: SIP Rx tcp:172.1.1.81:5065: ACK sip:103@172.1.1.75:4957;transport=tcp SIP/2.0 FROM: <sip:103@be7.mydomain.com;user=phone>;epid=34AEC95009;tag=54acd35ba1 TO: <sip:103@ezoutlook.com>;tag=5392 CSEQ: 1 ACK CALL-ID: 46269039@pbx MAX-FORWARDS: 70 VIA: SIP/2.0/TCP 172.1.1.81:5065;branch=z9hG4bK28915536 CONTENT-LENGTH: 0 USER-AGENT: RTCC/3.0.0.0 [8] 2008/04/23 13:42:29: Passthrough: Changing destination to 172.1.1.81:16861 [5] 2008/04/23 13:43:08: SIP port accept from 172.1.1.81:16868 [7] 2008/04/23 13:43:08: SIP Rx tcp:172.1.1.81:16868: OPTIONS sip:172.1.1.75:5060 SIP/2.0 FROM: <sip:be7.mydomain.com:5060;transport=Tcp;ms-opaque=932002b23e9bfaae>;epid=6618ACCBF4;tag=b56e3cb8e9 TO: <sip:172.1.1.75:5060> CSEQ: 6449 OPTIONS CALL-ID: d6996cf8fab742ee91d089bf12794b6b MAX-FORWARDS: 70 VIA: SIP/2.0/TCP 172.1.1.81:16868;branch=z9hG4bK13c7d83c ACCEPT: application/sdp CONTENT-LENGTH: 0 USER-AGENT: RTCC/3.0.0.0 [9] 2008/04/23 13:43:08: Resolve 72703: tcp 172.1.1.81 16868 [7] 2008/04/23 13:43:08: SIP Tx tcp:172.1.1.81:16868: SIP/2.0 200 Ok Via: SIP/2.0/TCP 172.1.1.81:16868;branch=z9hG4bK13c7d83c From: <sip:be7.mydomain.com:5060;transport=Tcp;ms-opaque=932002b23e9bfaae>;epid=6618ACCBF4;tag=b56e3cb8e9 To: <sip:172.1.1.75:5060>;tag=7905a6d1f3 Call-ID: d6996cf8fab742ee91d089bf12794b6b CSeq: 6449 OPTIONS Allow: INVITE, ACK, CANCEL, BYE, REFER, PRACK, INFO, UPDATE Content-Length: 0 [7] 2008/04/23 13:43:15: SIP Rx tcp:172.1.1.81:5065: BYE sip:103@172.1.1.75:4957;transport=tcp SIP/2.0 FROM: <sip:103@be7.mydomain.com;user=phone>;epid=34AEC95009;tag=54acd35ba1 TO: <sip:103@ezoutlook.com>;tag=5392 CSEQ: 2 BYE CALL-ID: 46269039@pbx MAX-FORWARDS: 70 VIA: SIP/2.0/TCP 172.1.1.81:5065;branch=z9hG4bK1643ff5 CONTENT-LENGTH: 0 USER-AGENT: RTCC/3.0.0.0 [9] 2008/04/23 13:43:15: Resolve 72704: tcp 172.1.1.81 5065 [7] 2008/04/23 13:43:15: SIP Tx tcp:172.1.1.81:5065: SIP/2.0 200 Ok Via: SIP/2.0/TCP 172.1.1.81:5065;branch=z9hG4bK1643ff5 From: <sip:103@be7.mydomain.com;user=phone>;epid=34AEC95009;tag=54acd35ba1 To: <sip:103@ezoutlook.com>;tag=5392 Call-ID: 46269039@pbx CSeq: 2 BYE Contact: <sip:103@172.1.1.75:4957;transport=tcp> User-Agent: pbxnsip-PBX/2.1.8.2463 RTP-RxStat: Dur=49,Pkt=129,Oct=11466,Underun=0 RTP-TxStat: Dur=49,Pkt=62,Oct=10664 Content-Length: 0 [7] 2008/04/23 13:43:15: 1560-3417961711-711581@NXT01.broadvox.net#bfe14f6334: Media-aware pass-through mode [7] 2008/04/23 13:43:15: Other Ports: 1 [7] 2008/04/23 13:43:15: Call Port: 1560-3417961711-711581@NXT01.broadvox.net#bfe14f6334 [9] 2008/04/23 13:43:15: Resolve 72705: url sip:5025555555@200.200.3.59:5060 [9] 2008/04/23 13:43:15: Resolve 72705: udp 200.200.3.59 5060 [7] 2008/04/23 13:43:15: SIP Tx udp:200.200.3.59:5060: BYE sip:5025555555@200.200.3.59:5060 SIP/2.0 Via: SIP/2.0/UDP 172.1.1.75:5060;branch=z9hG4bK-9965f8d5a9dd9483b8b0fadae730f1ec;rport From: <sip:10000555024444444@200.200.3.56:5060>;tag=bfe14f6334 To: "EZ OUTLOOK WEB " <sip:5025555555@200.200.3.59>;tag=3417961711-711590 Call-ID: 1560-3417961711-711581@NXT01.broadvox.net CSeq: 13832 BYE Max-Forwards: 70 Contact: <sip:Anonymous@172.1.1.75:5060;transport=udp> RTP-RxStat: Dur=49,Pkt=89,Oct=15308,Underun=0 RTP-TxStat: Dur=47,Pkt=170,Oct=18518 Content-Length: 0 [7] 2008/04/23 13:43:16: SIP Rx udp:200.200.3.59:5060: SIP/2.0 200 OK Via: SIP/2.0/UDP 172.1.1.75:5060;branch=z9hG4bK-9965f8d5a9dd9483b8b0fadae730f1ec;rport To: "EZ OUTLOOK WEB " <sip:5025555555@200.200.3.59>;tag=3417961711-711590 From: <sip:10000555024444444@200.200.3.56:5060>;tag=bfe14f6334 Call-ID: 1560-3417961711-711581@NXT01.broadvox.net CSeq: 13832 BYE Allow: INVITE, BYE, OPTIONS, CANCEL, ACK, REGISTER, NOTIFY, INFO, REFER, SUBSCRIBE, PRACK, UPDATE Contact: <sip:5025555555@200.200.3.59:5060> Content-Length: 0 Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted April 28, 2008 Report Share Posted April 28, 2008 The bind() message should not be the problem (we already took it out in a later build). The PBX just tries to get a port, and if that port is not available, it tries another one. Of course, make sure that you have a large RTP port range, so that you are not running out of RTP ports. I still don't clearly understand what makes the difference between the failed call and the successful call. Do you say that is depends on what port it chooses? If that is the case, can you double-check the firewall port range? Other potential reasons for such behavior are usually race conditions, e.g. the answer comes earlier or later. Is there anything in this direction? Quote Link to comment Share on other sites More sharing options...
TomH Posted April 28, 2008 Author Report Share Posted April 28, 2008 The bind() message should not be the problem (we already took it out in a later build). The PBX just tries to get a port, and if that port is not available, it tries another one. Of course, make sure that you have a large RTP port range, so that you are not running out of RTP ports. I still don't clearly understand what makes the difference between the failed call and the successful call. Do you say that is depends on what port it chooses? If that is the case, can you double-check the firewall port range? Other potential reasons for such behavior are usually race conditions, e.g. the answer comes earlier or later. Is there anything in this direction? I agree the Bind is fine. In a test situation with plenty of ports. The issue is on the faxes that do not work PBXnSIP retrieves a pair of open ports for RTP/T38 twice. Once correctly and once after after the recieved OK from BroadVox which invalidates the port number originally given to BroadVox. In the example I gave you: [7] 2008/04/23 13:42:28: UDP: Opening socket on port 9048 [7] 2008/04/23 13:42:28: UDP: Opening socket on port 9008 is the original pair and 9008 was given to BroadVox Then you retrieved a second pair this time [7] 2008/04/23 13:42:29: UDP: Opening socket on port 9064 [7] 2008/04/23 13:42:29: UDP: Opening socket on port 9030 and used 9064 to go to broadvox. i.e. all goes in the bit bucket. When you dont retrieve the secnd pair it always works. The question is why do you retrieve a second pair sometimes and not others. You are consistantly doing the same thing between devices. If its going for device A to device B it always has the problem or always works depending if you retrieve the second pair. I am guessing that the issue may be PBXnSIP: IF IT WORKS - returns from end to end understanding it is a return and remembers and uses the original pair. understands FAX > PBXnSIP > BroadVox > PBXnSIP IF IT FAILS - returns from end to end does not understanding it is a return and does not remember and get a new pair pair. thinks BroadVox > PBXnSIP Totally a guess though. Thanks Tom Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted April 29, 2008 Report Share Posted April 29, 2008 Hmm. Progress, but still I don't get it 100 %. When the PBX performs the T.38 switch over, it must choose another set of ports. That is because T.38 is "image", not "audio". That has also the consequence, that the ITSP must learn a new NAT binding for the T.38 ports. When the PBX learns the T.38 destination, it should write something like "Passthrough: Changing destination to ..." (Media, log level 8). Do you see something like that in the log? One little problem with T.38 is that there is no RTP header. That means the PBX will turn it's head around for any kind of junk hitting the port (if the transmission stalls for more that 100 ms). But I don't think that this is the problem here. Quote Link to comment Share on other sites More sharing options...
TomH Posted April 30, 2008 Author Report Share Posted April 30, 2008 When it works you go to media aware passthrough and get the rtp/t38 ports once also wanted to add I believe but not 100% that it may be pass through calls coming from extensions work, coming from trunks do not. [7] 2008/04/30 08:39:44: ac205a6825c71d48@192.168.6.102#74ebbabf04: Media-aware pass-through mode The issue is the RTP ports are incorrect and an RTP /T38 session is never established on the one that does not work. You get the ports twice My question is why do you get the ports twice sometime and once othertimes see below Passthrough log records when it does not work [7] 2008/04/30 08:30:00: Determine pass-through mode after receiving response [7] 2008/04/30 08:30:00: 62be9fb0@pbx#34346: RTP pass-through mode [7] 2008/04/30 08:30:00: 8609-3418547751-802139@NXT01.broadvox.net#945f1258df: RTP pass-through mode [7] 2008/04/30 08:30:02: Determine pass-through mode after receiving response [8] 2008/04/30 08:30:02: Passthrough: Changing destination to 172.26.1.81:8545 Passthrough log records when it Works [7] 2008/04/30 08:39:19: Determine pass-through mode after receiving response [7] 2008/04/30 08:39:19: 3297304d@pbx#64201: RTP pass-through mode [7] 2008/04/30 08:39:19: ac205a6825c71d48@192.168.6.102#74ebbabf04: RTP pass-through mode [7] 2008/04/30 08:39:21: Determine pass-through mode after receiving response [7] 2008/04/30 08:39:44: ac205a6825c71d48@192.168.6.102#74ebbabf04: Media-aware pass-through mode **************When it does not work you retrieve the RPT ports twice************ [7] 2008/04/30 08:30:02: SIP Rx tcp:172.26.1.81:5067: INVITE sip:103@172.26.1.75:2594;transport=tcp SIP/2.0 FROM: <sip:103@be7.ezoutlook.com;user=phone>;epid=BE122FA941;tag=887c2779c4 TO: <sip:103@ezoutlook.com>;tag=34346 CSEQ: 1 INVITE CALL-ID: 62be9fb0@pbx MAX-FORWARDS: 70 VIA: SIP/2.0/TCP 172.26.1.81:5067;branch=z9hG4bKb7c3d736 CONTACT: <sip:be7.ezoutlook.com:5067;transport=Tcp;maddr=172.26.1.81;ms-opaque=0d02c8b9260b7733>;automata CONTENT-LENGTH: 283 USER-AGENT: RTCC/3.0.0.0 CONTENT-TYPE: application/sdp v=0 o=- 0 1 IN IP4 172.26.1.81 s=session c=IN IP4 172.26.1.81 t=0 0 m=audio 0 RTP/AVP 0 8 101 13 a=rtpmap:0 PCMU/8000/1 a=rtpmap:8 PCMA/8000/1 a=rtpmap:101 telephone-event/8000 m=image 8545 udptl t38 a=T38FaxRateManagement:transferredTCF a=T38FaxUdpEC:t38UDPRedundancy ****************first time************************* [7] 2008/04/30 08:30:02: UDP: Opening socket on port 9098 [7] 2008/04/30 08:30:02: UDP: Opening socket on port 9050 . . . [7] 2008/04/30 08:30:02: SIP Rx udp:209.249.3.59:5060: SIP/2.0 200 OK Via: SIP/2.0/UDP 172.26.1.75:5060;branch=z9hG4bK-605578d4313fe553d739d96e6861ef95;rport To: "EZ OUTLOOK WEB " <sip:5024255328@209.249.3.59>;tag=3418547751-802148 From: <sip:10000555024102925@209.249.3.56:5060>;tag=945f1258df Call-ID: 8609-3418547751-802139@NXT01.broadvox.net CSeq: 23081 INVITE Allow: INVITE, BYE, OPTIONS, CANCEL, ACK, REGISTER, NOTIFY, INFO, REFER, SUBSCRIBE, PRACK, UPDATE Contact: <sip:5024255328@209.249.3.59:5060> Call-Info: <sip:209.249.3.59>;method="NOTIFY;Event=telephone-event;Duration=1000" Content-Type: application/sdp Content-Length: 315 v=0 o=NXT01 0 1 IN IP4 209.249.3.59 s=sip call c=IN IP4 209.249.3.60 t=0 0 m=audio 44164 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=ptime:20 m=image 44170 udptl t38 a=T38FaxRateManagement:transferredTCF a=T38FaxUdpEC:t38UDPRedundancy a=sendrecv [7] 2008/04/30 08:30:02: Call 8609-3418547751-802139@NXT01.broadvox.net#945f1258df: Clear last INVITE ****************second time************************* [7] 2008/04/30 08:30:02: UDP: Opening socket on port 9006 [7] 2008/04/30 08:30:02: UDP: Opening socket on port 9064 When it does work you get them once [7] 2008/04/30 08:39:19: SIP Rx tcp:172.26.1.81:5067: INVITE sip:103@172.26.1.75:2594;transport=tcp SIP/2.0 FROM: <sip:103@be7.ezoutlook.com;user=phone>;epid=BE122FA941;tag=7f988c487 TO: <sip:103@ezoutlook.com>;tag=64201 CSEQ: 1 INVITE CALL-ID: 3297304d@pbx MAX-FORWARDS: 70 VIA: SIP/2.0/TCP 172.26.1.81:5067;branch=z9hG4bK44a2a66f CONTACT: <sip:be7.ezoutlook.com:5067;transport=Tcp;maddr=172.26.1.81;ms-opaque=0d02c8b9260b7733>;automata CONTENT-LENGTH: 283 USER-AGENT: RTCC/3.0.0.0 CONTENT-TYPE: application/sdp v=0 o=- 0 1 IN IP4 172.26.1.81 s=session c=IN IP4 172.26.1.81 t=0 0 m=audio 0 RTP/AVP 0 8 101 13 a=rtpmap:0 PCMU/8000/1 a=rtpmap:8 PCMA/8000/1 a=rtpmap:101 telephone-event/8000 m=image 8630 udptl t38 a=T38FaxRateManagement:transferredTCF a=T38FaxUdpEC:t38UDPRedundancy ****************first time and only time************************* [7] 2008/04/30 08:39:19: UDP: Opening socket on port 9080 [7] 2008/04/30 08:39:19: UDP: Opening socket on port 9012 . . . [7] 2008/04/30 08:39:21: SIP Rx udp:74.143.31.154:14062: SIP/2.0 200 OK Via: SIP/2.0/UDP 172.26.1.75:5060;branch=z9hG4bK-3b7e804129e942888eb09361ddde3b82;rport From: <sip:103@pbx.ezoutlook.com>;tag=74ebbabf04 To: "Fax Machine" <sip:105@pbx.ezoutlook.com>;tag=a68eb379542a755d Call-ID: ac205a6825c71d48@192.168.6.102 CSeq: 28130 INVITE User-Agent: Grandstream HT287 1.1.0.3 Warning: 399 74.143.31.154 "detected NAT type is full cone" Contact: <sip:105@74.143.31.154:14062> Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE Content-Type: application/sdp Supported: replaces, timer Content-Length: 249 v=0 o=105 8000 8004 IN IP4 74.143.31.154 s=SIP Call c=IN IP4 74.143.31.154 t=0 0 m=audio 0 RTP/AVP 0 a=sendrecv a=rtpmap:0 PCMU/8000 m=image 50168 udptl t38 a=T38FaxRateManagement:transferredTCF a=T38FaxUdpEC:t38UDPRedundancy a=ptime:20 [7] 2008/04/30 08:39:21: Call ac205a6825c71d48@192.168.6.102#74ebbabf04: Clear last INVITE *************************you use the original RTP port pair******************** [9] 2008/04/30 08:39:21: Resolve 7467: tcp 172.26.1.81 5067 [7] 2008/04/30 08:39:21: SIP Tx tcp:172.26.1.81:5067: Quote Link to comment Share on other sites More sharing options...
Pradeep Posted May 8, 2008 Report Share Posted May 8, 2008 Tom, If I understand correctly, you are trying to send the fax from HT268 or a Kapanga fax phone that is registered with the broadvox. Also, I assume that broadvox has a sip trunk to pbxnsip and pbxnsip has connectivity to the MS exchange server. Can you please confirm that this is what you have in your setup? Pradeep Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.