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=-100.601, required 6, autolearn=not spam, AWL -0.60,
NO_RELAYS -0.00, USER_IN_WHITELIST -100.00)
X-ECN Telecoms-MailScanner-From: [EMAIL PROTECTED]
X-Spam-Status: No
Hi
I always test patches before applying them to SVN. You provided no
feedback, so it's still not in.
Regards
Damjan
> Dear Damjan,
>
> You sent me 6 months ago the patch to fix the problem that CW didn't
> realize that the RTP port changed when switching to T.38.
>
> We are planning to install a new CW, using the latest available software
> package and I was wondering if the patch that you sent me was included in
> the system in the mean time or if we should make the necessary changes to
> it and add it to the current version, too.
>
> Best regards,
>
> David
>
>
>
> ----- Original Message ----
> From: Damjan Jovanovic <[EMAIL PROTECTED]>
> To: Users Mailing List - Non-Commercial Discussion
> <[email protected]>
> Sent: Wednesday, January 23, 2008 5:29: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.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
>
>
>
> _______________________________________________
> 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
