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 -- _____________________________________________________________________ -- 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
