No subject

default, 'sendrecv', at all times unless putting the call on hold, when I 
believe it sets it to 'ignore'.

So while recording a message in app_voicemail, Asterisk is only receiving 
RTP traffic, sending nothing.  Makes sense, there's no audio to send.  
But the other side is expecting traffic in both directions (media stream 
is set to 'sendrecv'), so once we've been silent (recording) for 30 
seconds, the PSTN gateway RTP timer expires and it tears down the call.

The vendor's suggested remedy is to have Asterisk renegotiate the RTP 
stream to 'recvonly' when we are expecting only inbound RTP traffic, and 
seting the stream back to 'sendrecv' when we want to go back to 2-way 
audio.

So I pose the question: is it straightforward to set the RTP stream to 
'recvonly' while recording messages in app_voicemail, and possibly 
elsewhere (app_record comes to mind)?  Any pointers on how to have 
Asterisk generate the appropriate SIP INVITE dialogue and SDP parameters 
to change the SIP channel's settings? Basically we'd need to send out an 
INVITE to the gateway with the new SDP attributes.

After reviewing the Asterisk code docs with my limited C skills, the only 
bit I could see about changing SDP attributes was setting a call on hold 
in chan_sip.c.

N.B.  Someone else had this problem with a SIP trunk from BroadVoice in 
2004. I wonder how they resolved the issue.  For anyone else, a workaround 
we found is to use the rtpkeepalive feature of chan_sip, available in 
Asterisk 1.2.x and high.  Setting this will cause Asterisk to send an RTP 
"ping" on all media streams every 'x' seconds, which has the effect of 
keeping the PSTN gateway rtptimer happy.  However, it seems to me that 
this defeats the usefulness of the rtp dead timer, and presume that you 
could be left with orphaned RTP streams.

BroadVoice user issue from 2004 found here: 
http://www.mail-archive.com/asterisk-users@lists.digium.com/msg47770.html

Here's the relative section of "RFC 3264 - An Offer/Answer Model with 
Session Description Protocol (SDP)."

http://www.faqs.org/rfcs/rfc3264.html

=====
5.1 Unicast Streams

   If the offerer wishes to only send media on a stream to its peer, it
   MUST mark the stream as sendonly with the "a=sendonly" attribute.  We
   refer to a stream as being marked with a certain direction if a
   direction attribute was present as either a media stream attribute or
   a session attribute.  If the offerer wishes to only receive media
   from its peer, it MUST mark the stream as recvonly.  If the offerer
   wishes to communicate, but wishes to neither send nor receive media
   at this time, it MUST mark the stream with an "a=inactive" attribute.
=====

Thanks in advance for any advice.

Regards,

---
Iain McBride
Convoke Communications Corp.
http://www.convoke.com/

tel:      +1.416.361.0300   
fax:      +1.416.361.0847
tollfree: 1-888-CONVOKE