Hello, I am working with an ITSP where the call is transfered from the Auto Attendant to Voice Mail. I am noticing that our current Voice mail system does not return an attribute like this:
a=rtpmap:101 telephone-event/8000 unless the SDP offer to it has such an attribute. Unfortunately the ITSP does not return such an attribute in its SDP Offer ( see Frame 35 of the attached trace) and hence neither does the answer from AA which is relayed back to the ITSP on Frame 66. This is causing me to be unable to type DTMF from the ITSP originating call after that call is transferred to the VMail from the Auto Attendant hence causing me to be unable to retrieve VMail from an ITSP originated call, resulting in XECS-2330 Possible Solutions: 1. I can hack the SDP going back to the ITSP in Frame 66 and add this attribute hence working around the apparent bug in the Voice Mail server. 2. I can hack the SDP returned from the re-INVITE OK to the ITSP ( frame 35) and add this attribute. I dont know if the iTSP *should* attach such an attribute in the offer. I am aware of at least one other major ITSP that does not. 3. We can modify the current Voice Mail server to always add that attribute. 4. I can wait for the new FreeSWITCH based Vmail and put the bug on hold for the next sprint. I am pretty sure FreeSWITCH does the right thing because I am able to blind transfer from FreeSWITCH to FreeSWITCH as many times as I wish with no ill effects. Hence I am sure a FreeSWITCH based Vmail would work much better The ITSP itself is well behaved if it sees that attribute line -- it happily sends DTMF thereafter ( as evidenced by trouble free AA to AA transfers). ( Presumably #4 would be the logical choice at this point since we are moving in that direction for 4.0 but if that will not happen in the 4.0 release, we need to find another solution. ) Thanks for your time in looking into this issue. Regards, Ranga -- M. Ranganathan
bandwidth-transfer-to-aa.xml.gz
Description: GNU Zip compressed data
_______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
