Hi Matthias, Can you do a packet capture of an entire failed call, and send it to me?
Steve Matthias Gelbhardt wrote: > Still speaking to myself here ;) > > Coming to my mind: Perhaps there is an equivalent to SipT38SwitchOver > to disable T.38 for an incoming call? > > Regards, > > Matthias > > Am 27.06.2007 um 09:31 schrieb Matthias Gelbhardt: > > >> Hi! >> >> I've investigated this matter further. >> >> Maybe I've found a bug? >> >> whithout t38udptlsupport=yes: >> >> from the SIP "handshake": >> (...) >> Using INVITE request as basis request - >> [EMAIL PROTECTED] >> Sending to 213.218.12.2 : 5060 (NAT) >> Found peer 'toplink' >> Found RTP audio format 8 >> Found RTP audio format 0 >> Found RTP audio format 18 >> Found RTP audio format 4 >> Found RTP audio format 2 >> Found RTP audio format 96 >> Jun 27 10:31:33 WARNING[3049241520]: chan_sip.c:4797 process_sdp: >> Unknown or ignored SDP media type in offer: image 10362 udptl t38 >> Peer audio RTP is at port 195.2.163.101:10360 >> (...) >> Callweaver does not recognize the T.38 offer, but the audio port is >> at 10360. >> >> Sniffing with tcpdump gives me: >> "10:31:36.832474 IP 91.190.224.66.11232 > mgw2-isw1-fra3.de.toplink- >> voice.net.10360: UDP, length 172" >> >> So it is sent to the right port and the voice connection is working. >> >> with t38udptlsupport=yes: >> >> from the SIP "handshake": >> (...) >> Using INVITE request as basis request - >> [EMAIL PROTECTED] >> Sending to 213.218.12.2 : 5060 (NAT) >> Found peer 'toplink' >> Found RTP audio format 8 >> Found RTP audio format 0 >> Found RTP audio format 18 >> Found RTP audio format 4 >> Found RTP audio format 2 >> Found RTP audio format 96 >> Got T.38 offer in SDP >> Peer audio RTP is at port 195.2.163.101:11040 >> Peer T.38 UDPTL is at port 195.2.163.101:11042 >> (...) >> >> So the Peer audio is at Port 11040 and T.38 at 11042. But sniffing >> with tcpdump gives me the following: >> "10:21:10.395872 IP 91.190.224.66.13584 > mgw2-isw1-fra3.de.toplink- >> voice.net.11042: UDP, length 172" >> >> So the voice-RTP stream seems to be sent to the T.38 port of the >> trunk, and I do not hear anything. >> >> Is the problem the trunk or am I lacking some parameter in my config >> to disable T.38 connection in voice calls? >> >> Regards, >> >> Matthias >> >> >> >> >> Am 26.06.2007 um 15:57 schrieb Matthias Gelbhardt: >> >> >>> Hi! >>> >>> Have found out something. When I am deactivating T.38 support >>> (commenting out t38udptlsupport=yes) the incoming audio works. What >>> is going on there? Which SIP messages will you need to see what is >>> going on? >>> >>> Regards, >>> >>> Matthias >>> >>> >>> Am 26.06.2007 um 12:54 schrieb Matthias Gelbhardt: >>> >>> >>>> Hi there, >>>> >>>> I am testing callweaver at the moment and have a problem. >>>> >>>> On outgoing calls it works perfectly, the calling and called party >>>> could here each other. >>>> >>>> On incoming calls there is no voice. When I use tcpdump, I see only >>>> RTP packets flowing to the SIP provider, but no packet coming from >>>> it. On outgoing calls I can see the communication flowing in both >>>> ways. >>>> >>>> The strange thing is, although I have canreinvite=no in my sip.conf, >>>> I have a "Attempting native bridge of" in my log. >>>> >>>> The callweaver itself is directly connected to the internet, the >>>> phones are connected via a second nic on a private net. >>>> >>>> A trixbox on a parallel installation works. >>>> >>>> I would be happy to provide you with any information you need to >>>> help >>>> me. >>>> >>>> Regards, >>>> >>>> Matthias >>>> _______________________________________________ >>>> >>>> > _______________________________________________ Callweaver-users mailing list [email protected] http://lists.callweaver.org/mailman/listinfo/callweaver-users
