----- "Steve Underwood" <ste...@coppice.org> escreveu: > On 02/02/2010 10:11 PM, Kevin P. Fleming wrote: > > Steve Underwood wrote: > > > >> Hi Kevin, > >> > >> On 02/02/2010 09:12 PM, Kevin P. Fleming wrote: > >> > >>> Vinícius Fontes wrote: > >>> > >>> > >>> > >>>> [Feb 2 08:38:06] DEBUG[21032]: chan_sip.c:7589 process_sdp: > Processing session-level SDP v=0... UNSUPPORTED. > >>>> [Feb 2 08:38:06] DEBUG[21032]: chan_sip.c:7589 process_sdp: > Processing session-level SDP o=PVG 1265107000170 1265107000170 IN IP4 > 10.152.0.164... UNSUPPORTED. > >>>> [Feb 2 08:38:06] DEBUG[21032]: chan_sip.c:7589 process_sdp: > Processing session-level SDP s=-... UNSUPPORTED. > >>>> [Feb 2 08:38:06] DEBUG[21032]: chan_sip.c:7589 process_sdp: > Processing session-level SDP p=+1 6135555555... UNSUPPORTED. > >>>> [Feb 2 08:38:06] DEBUG[21032]: chan_sip.c:7589 process_sdp: > Processing session-level SDP c=IN IP4 10.152.0.164... OK. > >>>> [Feb 2 08:38:06] DEBUG[21032]: chan_sip.c:7589 process_sdp: > Processing session-level SDP t=0 0... UNSUPPORTED. > >>>> [Feb 2 08:38:06] DEBUG[21032]: chan_sip.c:7589 process_sdp: > Processing session-level SDP a=sqn: 0... UNSUPPORTED. > >>>> [Feb 2 08:38:06] DEBUG[21032]: chan_sip.c:7589 process_sdp: > Processing session-level SDP a=cdsc: 1 image udptl t38... > UNSUPPORTED. > >>>> [Feb 2 08:38:06] DEBUG[21032]: chan_sip.c:7589 process_sdp: > Processing session-level SDP a=cpar: a=T38FaxVersion:0... > UNSUPPORTED. > >>>> [Feb 2 08:38:06] DEBUG[21032]: chan_sip.c:7589 process_sdp: > Processing session-level SDP a=cpar: a=T38FaxUdpEC:t38UDPRedundancy... > UNSUPPORTED. > >>>> [Feb 2 08:38:06] DEBUG[21032]: chan_sip.c:7753 process_sdp: > Processing media-level (audio) SDP a=rtpmap:101 > telephone-event/8000... OK. > >>>> [Feb 2 08:38:06] DEBUG[21032]: chan_sip.c:7753 process_sdp: > Processing media-level (audio) SDP a=fmtp:101 0-15... UNSUPPORTED. > >>>> [Feb 2 08:38:06] DEBUG[21032]: chan_sip.c:7753 process_sdp: > Processing media-level (audio) SDP a=ptime:20... OK. > >>>> [Feb 2 08:38:06] DEBUG[21032]: chan_sip.c:4653 change_t38_state: > T38 state changed to 0 on channel SIP/voxip-00000000 > >>>> [Feb 2 08:38:06] DEBUG[21032]: chan_sip.c:7932 process_sdp: > We're settling with these formats: 0x8 (alaw) > >>>> [Feb 2 08:38:06] DEBUG[21032]: chan_sip.c:7937 process_sdp: We > have an owner, now see if we need to change this call > >>>> [Feb 2 08:38:06] DEBUG[21032]: chan_sip.c:5231 > update_call_counter: Updating call counter for incoming call > >>>> [Feb 2 08:38:06] DEBUG[21032]: chan_sip.c:3172 __sip_xmit: > Trying to put 'ACK sip:10.' onto UDP socket destined for > 10.150.65.16:5060 > >>>> [Feb 2 08:38:06] DEBUG[21064]: app_fax.c:699 transmit_t38: Shut > down T.38 on SIP/voxip-00000000 > >>>> > >>>> > >>>> Note how items like T38FaxUdpEC are listed as OK on one call and > unsupported on another one. Could that be a bug? I can show the entire > SIP conversations if that's necessary for debugging this. > >>>> > >>>> > >>> That's not quite correct; in the second example, the T38 > parameters are > >>> being sent as 'capabilities' (a=cdsc and a=cpar) which Asterisk > does not > >>> support. The second example does not provide backwards > compatibility for > >>> SIP endpoints that do not support capability-based negotiation, > whereas > >>> the first one does. > >>> > >>> > >> What do you mean by that? Surely if you don't understand the cdsc > and > >> cpar lines you are supposed to simply ignore them, and carry on. > >> > >> If it were harmless, that capability information seems enormously > >> useful, especially in the context of the current discussions on > sorting > >> out the mess that T.38 has become. Sadly, it does cause some > systems to > >> choke, which is probably why it is rarely included. > >> > > In this case, the re-INVITE did *not* include a > non-capabilities-based > > offer for T.38. The SDP parser listed the cdsc and cpar lines as > > unsupported, but it did not see any media stream offer for T.38 > (unlike > > the OP's first example), so it set the internal T.38 state on the > > channel to 'not in use'. > > > That's how T.38 calls normally start. They mostly start as audio, and > > switch into T.38 mode later. We have only seen an initial fragment in > > the log. We haven't seen anything that's actually wrong. We see an > offer > to do telephony events, and from there things might progress to T.38 > or > something else. I can't see anything invalid in that, even if the > cdsc/cpar stuff is not understood. > > Steve
I couldn't agree more Steve. Is there any other info I could provide in order to help you find out what's wrong? I could even open an issue on Mantis if the Digium staff think it's worth it. -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
