Re: [asterisk-users] RTP sent before the INVITE ACK (for voicemail app)
On Wed, Oct 1, 2008 at 5:37 PM, tic tac [EMAIL PROTECTED] wrote: Thanks, in my case though it looks like the originating party (polycom softphone) is hearing a clipped voicemail prompt because of that; should I look into having that fixed into their firmware? As a workaround, I was thinking to just add a few seconds delay in app_voicemail, or wait through AGI before calling voicemail, makes sense? Yes. It's fairly standard practice to add a Wait(2) or Wait(3) at the start of a call Asterisk is generating direct audio on. This gives the RTP stream a chance to get sorted out. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] RTP sent before the INVITE ACK (for voicemail app)
Hello, With asterisk 1.4.11, I am calling AGI exec voicemail upon a SIP INVITE invite - asterisk - 100 - 200 - RTP ACK - ... asterisk is sending the RTP for the greeting before the original invite is ACK-ed (confirmed with a tcpdump) as if playing the prompt as soon as it is received from the AGI. I don't see any 183 so I don't think early media should apply. CLI output does not show any error that I see. Is there any reason other than a SIP 183 that would trigger this and isn't asterisk supposed to ACK/answer the channel before playing any prompt? Thanks, Sebastien. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] RTP sent before the INVITE ACK (for voicemail app)
CLI output does not show any error that I see. Is there any reason other than a SIP 183 that would trigger this and isn't asterisk supposed to ACK/answer the channel before playing any prompt? Asterisk wil start the audio as soon as it sends back the 200 Ok response it doesn't wait for the ACK. Most SIP servers will work like that. The matching of ACK requests to a SIP transaction is not a particulalrly robust mechanism (for instance if a user agent puts its IP address in the Call-ID and a SIP ALG fiddles with the SIP packet for INVITEs but ignores ACKs then there will be a mismatch. This happens more frequently then you would think) so sending RTP after an OK response is the correct thing to do. I think Asterisk will actually cut off the call after 32s if it doesn't get an ACK which is not such a great idea but that may have been changed in later versions. The arrival of an RTP packet from the remote end should be used as the definitive indication of an answered call not the ACK. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] RTP sent before the INVITE ACK (for voicemail app)
Thanks, in my case though it looks like the originating party (polycom softphone) is hearing a clipped voicemail prompt because of that; should I look into having that fixed into their firmware? As a workaround, I was thinking to just add a few seconds delay in app_voicemail, or wait through AGI before calling voicemail, makes sense? Date: Wed, 1 Oct 2008 15:43:37 +0100 From: [EMAIL PROTECTED] To: asterisk-users@lists.digium.com Subject: Re: [asterisk-users] RTP sent before the INVITE ACK (for voicemail app) CLI output does not show any error that I see. Is there any reason other than a SIP 183 that would trigger this and isn't asterisk supposed to ACK/answer the channel before playing any prompt? Asterisk wil start the audio as soon as it sends back the 200 Ok response it doesn't wait for the ACK. Most SIP servers will work like that. The matching of ACK requests to a SIP transaction is not a particulalrly robust mechanism (for instance if a user agent puts its IP address in the Call-ID and a SIP ALG fiddles with the SIP packet for INVITEs but ignores ACKs then there will be a mismatch. This happens more frequently then you would think) so sending RTP after an OK response is the correct thing to do. I think Asterisk will actually cut off the call after 32s if it doesn't get an ACK which is not such a great idea but that may have been changed in later versions. The arrival of an RTP packet from the remote end should be used as the definitive indication of an answered call not the ACK. Regards, Greyman. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
