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.306, required 6, autolearn=not spam, ALL_TRUSTED -1.80,
AWL 1.09, BAYES_00 -2.60, USER_IN_WHITELIST -100.00)
X-ECN Telecoms-MailScanner-From: [EMAIL PROTECTED]
X-Spam-Status: No
On Sun, 2008-01-20 at 22:57 -0800, David wrote:
> 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?
I don't know much about realtime.
Try this patch:
Index: corelib/udptl.c
===================================================================
--- corelib/udptl.c (revision 4317)
+++ corelib/udptl.c (working copy)
@@ -703,6 +703,7 @@
{
int res;
int actions;
+ struct sockaddr_in original_dest;
struct sockaddr_in sin;
socklen_t len;
char iabuf[INET_ADDRSTRLEN];
@@ -710,6 +711,8 @@
static struct opbx_frame null_frame = { OPBX_FRAME_NULL, };
len = sizeof(sin);
+
+ memcpy(&original_dest, udp_socket_get_them(udptl->udptl_sock_info),
sizeof(original_dest));
/* Cache where the header will go */
res = udp_socket_recvfrom(udptl->udptl_sock_info,
@@ -748,7 +751,9 @@
#if 0
printf("Got UDPTL packet from %s:%d (len %d)\n",
opbx_inet_ntoa(iabuf, sizeof(iabuf), sin.sin_addr), ntohs(sin.sin_port),
res);
#endif
- udptl_rx_packet(udptl, udptl->rawdata + OPBX_FRIENDLY_OFFSET, res);
+ /* If it wasn't a valid UDPTL packet, restore the original IP:port
*/
+ if (udptl_rx_packet(udptl, udptl->rawdata + OPBX_FRIENDLY_OFFSET,
res) < 0)
+ udp_socket_set_them(udptl->udptl_sock_info, &original_dest);
return &udptl->f[0];
}
Damjan
> 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
_______________________________________________
Callweaver-users mailing list
[email protected]
http://lists.callweaver.org/mailman/listinfo/callweaver-users
