Jump to content

RTP Port Issue


TomH
 Share

Recommended Posts

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

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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:

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...