X-ECN Telecoms-MailScanner-Information: Contact ECN Telecoms
X-ECN Telecoms-MailScanner: Found to be clean
X-ECN Telecoms-MailScanner-SpamCheck: not spam, SpamAssassin (not cached,
score=-103.1, required 6, autolearn=not spam, ALL_TRUSTED -1.80,
AWL 1.30, BAYES_00 -2.60, USER_IN_WHITELIST -100.00)
X-ECN Telecoms-MailScanner-From: [EMAIL PROTECTED]
X-Spam-Status: No
On Fri, 2008-01-18 at 01:59 -0800, David wrote:
> 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.
>
Do "sip show peer X" and make sure you get "Nat: no", otherwise set
"nat=never" for that peer (if not globally) then restart callweaver and
try again.
> -------------------------------------------------------------------------------------------------------------------------------
>
> [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.
>
Callweaver uses the same port for RTP and T.38.
My understanding of the code in chan_sip.c and udptl.c is that when a
T.38 session is established, opbx_udptl_read() is called whether you get
a T.38 or an RTP packet on the socket. Now that function calls
udp_socket_recvfrom(), which, in certain cases (NAT), unconditionally
overwrites the IP:port to send packets to (info->them in the code) with
the source IP:port of the newly received packet.
So what I think happens is this: Callweaver opens port X for RTP and the
other side opens port Y. While they send audio to each other, everything
is okay, because the destination port for X keeps being modified to Y.
But when the T.38 session is established, the other side opens a port Z,
and the destination port for X is initially set to Z. Callweaver
correctly transmits 3 copies of the first T.38 message (no-signal) from
X to Z, but as soon as any RTP packet from Y comes into X, it modifies
the destination to Y instead of Z. Now if any T.38 came from Z it would
modify it back, but since Z first waits for v21-preamble + DIS +
no-signal from us before sending us anything, that never happens, and
we, incorrectly, keep sending to Y.
Callweaver should, in my opinion, completely ignore all RTP packets
during a T.38 session. At present, they are dropped, but their IP:port
modify our T.38 destination IP:port to the wrong thing. If you get this
working with nat=never, I'll work on a patch to get it fixed for
nat=yes.
If I'm wrong about all this, make a bug report and attach both a tcpdump
and a full debug log (uncomment the "full=..." line in logger.conf and
restart callweaver, then do "set debug 10", "set verbose 10", "rtp
debug" and "udptl debug" before the test).
> -------------------------------------------------------------------------------------------------------------------------------
>
> [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
>
Damjan
_______________________________________________
Callweaver-users mailing list
[email protected]
http://lists.callweaver.org/mailman/listinfo/callweaver-users
