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. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: [email protected] Check us out at www.digium.com & www.asterisk.org -- _____________________________________________________________________ -- 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
