Anthony Francis wrote: > Jeff LaCoursiere wrote: > >> On Fri, 17 Apr 2009, Jeff LaCoursiere wrote: >> >> >> >>> On Fri, 17 Apr 2009, Jeff LaCoursiere wrote: >>> >>> >>> >>>>> I went ahead and switched to SIP just for grins, and made sure >>>>> "dtmfmode=rfc2833" is in the peer config on both sides and in the entry >>>>> for the phone. So now it is: >>>>> >>>>> polycom501---SIP/ulaw--->ast1---SIP/g729--->ast2---IAX/ulaw--->ITSP >>>>> >>>>> >>> A bit more information. ast1 is running 1.4.23.1 and I noticed a debug >>> line >>> in rtp.c: >>> >>> if (rtpdebug || option_debug > 2) >>> ast_log(LOG_DEBUG, "- RTP 2833 Event: %08x (len = %d)\n", >>> event, len); >>> >>> So I set debug to 10 and caught this line: >>> >>> [Apr 17 17:28:02] DEBUG[27264] rtp.c: - RTP 2833 Event: 00000002 (len = 4) >>> >>> So I guess that proves that from the phone to ast1 RFC2833 is in effect (I >>> did actually press the digit '2', which I assume is the event code above?). >>> >>> I tried to do the same on ast2, which is running 1.4.22.1, and with debug >>> set >>> to 10 I did *not* get this message, which makes me think that RCF2833 is >>> NOT >>> in effect for the trunk between ast1 and ast2. Is that reasonable? >>> >>> >>> >> The main problem turned out to be at my ITSP, and is now resolved. The >> question remains for me, though, how to interpret the debug lines I was >> able to catch (or not) above. >> >> How do you really know if RFC2833 signalling is being received? I caught >> the debug message on ast1 but not on ast2. I am using ulaw between ast2 >> and the ITSP, and I am now wondering if the DTMF is being sent inband on >> that last leg since I could not catch the debug messages on ast2. Perhaps >> what they did to fix on their end is simply remove compression between >> themselves and the PSTN. >> >> I would really like a concrete method of verifying that DTMF signalling is >> being sent out of band on my outbound IAX link. Any ideas? >> >> Thanks, >> >> j >> >> >> > You are correct, not seeing that means that the signaling was either in > the audio stream (which doesn't survive compression) or it was sent in > the sip signaling. However one must also note that your ITSP's gateway > may have been having problems with their DTMF detection on their PRI's. > > Anthony >
Also, to determine if you are sending DTMF out of band (as part of IAX signalling) do iax2 debug peer <connection name> in the CLI. You will see when it creates DTMF events. _______________________________________________ -- 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