Hi, I am using database files to define SIP buddies, extensions and so on.
I checked there and the Proxy is defined with "nat=no" and "type=peer". Should I replace the "nat=no" to "nat=never"? When I type "sip show peer WS6500" or "sip show peers", I get no results: vms*CLI> sip show peers Name/username Host Dyn Nat ACL Port Status 0 sip peers [0 online , 0 offline] vms*CLI> sip show peer WS6500 Peer WS6500 not found. Is it related to the fact that the peers are stored in the database or is that a problem? Thanks, David ----- Original Message ---- From: Damjan Jovanovic <[EMAIL PROTECTED]> To: Users Mailing List - Non-Commercial Discussion <[email protected]> Sent: Saturday, January 19, 2008 6:37:40 PM Subject: Re: [Callweaver-users] T.38 RTP Problem 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 ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping _______________________________________________ Callweaver-users mailing list [email protected] http://lists.callweaver.org/mailman/listinfo/callweaver-users
