Hi Damjan,
Thank you for your response.
To answer your questions:
[DJ]:
Do you Answer() and then SipT38SwitchOver(), or just call RxFAX()? Try
to just call RxFAX(), or at least Wait() a bit between Answer() and
SipT38SwitchOver().
[DU]: This is the call flow used. It works well in other scenarios. I also need
to point out that incoming calls from the same gateway to other SIP devices,
supporting T.38 are going through without any problem:
id | context | exten | priority | app |
appdata
-------------------------------------------------------------------------------------------------------------------
520 | fax | T38 | 1 | Set |
T38udptlsupport=yes
536 | fax | T38 | 2 | Set |
SIP_CODEC=g729
522 | fax | T38 | 3 | Answer |
534 | fax | T38 | 4 | Wait | 1
521 | fax | T38 | 5 | SipT38SwitchOver
|
523 | fax | T38 | 6 | RxFAX |
${fax_filepath}/${UNIQUEID}.tif
524 | fax | T38 | 7 | Hangup |
535 | fax | T38 | 22 | Wait | 1
-------------------------------------------------------------------------------------------------------------------------------
[DJ]: You say the RTP port is changed, but don't you mean the T.38 port is
changed?
[DU]: Yes. Initially, G.729 RTP packets are sent to remote port 4290. After the
reINVITE, CW is asked to send the T.38 packets to port 4292 and it doe it only
for the first 3 packets.
-------------------------------------------------------------------------------------------------------------------------------
[DJ]: Do you have nat=yes and/or a NAT?
[DU]: No. Both the gateway and the CW have fixed public IP addresses without
any NAT or anything of this sort.
-------------------------------------------------------------------------------------------------------------------------------
[DJ]: Does anything happen between when callweaver sends the 3 correct packets
and when it starts to send the incorrect ones, like a SIP/RTP/T.38
packet from the other side?
[DU]: No signaling is sent beyond this point (until the call is released, of
course), but a few G.729 RTP packets still arrive from port 4290 (the initial
port used) because the remote gateway requires a few more T.38 packets in order
to start responding in T.38.
-------------------------------------------------------------------------------------------------------------------------------
[DJ]: A tcpdump would also help.
[DU]: I wouldn't like to bother all the list with a large dump file. These are
examples (I change the remote and local IP address to XX.XX.XX.XX and
YY.YY.YY.YY respectively) of the packets sent from the CW after the reINVITE OK
and ACK:
Packet 127 (128 and 129 are the same):
Internet Protocol, Src: YY.YY.YY.YY (YY.YY.YY.YY), Dst: XX.XX.XX.XX
(XX.XX.XX.XX)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 34
Identification: 0x0000 (0)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: UDP (0x11)
Header checksum: 0x5c21 [correct]
[Good: True]
[Bad : False]
Source: YY.YY.YY.YY (YY.YY.YY.YY)
Destination: XX.XX.XX.XX (XX.XX.XX.XX)
User Datagram Protocol, Src Port: 12792 (12792), Dst Port: 4292 (4292)
Source port: 12792 (12792)
Destination port: 4292 (4292)
Length: 14
Checksum: 0xdd6b [correct]
ITU-T Recommendation T.38
[Stream setup by H245 (frame 122)]
[Stream frame: 122]
[Stream Method: H245]
UDPTLPacket
Sequence number: 0
IFPPacket
Type of msg: t30-indicator (0)
T30 indicator: no-signal (0)
Error recovery: secondary-ifp-packets (0)
Secondary IFPPackets
Packet 142 (after a few G.729 RTP packets were received from port 4290. Packets
143 and 144 are identical):
Internet Protocol, Src: YY.YY.YY.YY (YY.YY.YY.YY), Dst: XX.XX.XX.XX
(XX.XX.XX.XX)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 34
Identification: 0x0000 (0)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: UDP (0x11)
Header checksum: 0x5c21 [correct]
[Good: True]
[Bad : False]
Source: YY.YY.YY.YY (YY.YY.YY.YY)
Destination: XX.XX.XX.XX (XX.XX.XX.XX)
User Datagram Protocol, Src Port: 12792 (12792), Dst Port: 4290 (4290)
Source port: 12792 (12792)
Destination port: 4290 (4290)
Length: 14
Checksum: 0xdd68 [correct]
ITU-T Recommendation T.38
[Stream setup by H245 (frame 122)]
[Stream frame: 122]
[Stream Method: H245]
UDPTLPacket
Sequence number: 1
IFPPacket
Type of msg: t30-indicator (0)
T30 indicator: ced (2)
Error recovery: secondary-ifp-packets (0)
Secondary IFPPackets
I hope that this all helps and I thank you for your assistance.
David
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
_______________________________________________
Callweaver-users mailing list
[email protected]
http://lists.callweaver.org/mailman/listinfo/callweaver-users
