[asterisk-dev] RFC 3264 - RTP media stream should be set to recvonly when recording messages via a SIP channel

[Iain McBride]

Hello,

Any guidance is appreciated on how to code a fix for this issue, and 
whether (and for which app) to file a bug.

During interop tests with a SIP trunking service, we hit on an issue where 
inbound calls sent to the Asterisk app_voicemail application are always 
cut off after the caller has been leaving a message for 30 seconds.  Live 
calls to UAs are always fine.

SIP tracing determined that this is not a SIP signaling malfunction.  
Everything looks fine, the only odd thing is that the PSTN gateway ends 
the call to voicemail by sending an abrupt SIP BYE message.

The root cause is a particular behavior of this PSTN gateway.  When no 
media (RTP) packets are seen in one direction or the other for 30 seconds, 
the PSTN gateway assumes that the call has died and tears it down.  This 
seems to be an interpretation of section 5.1 of RFC 3264, which says that 
the direction attributes of the media stream MUST be set appropriately.

This SIP<->PSTN gateway monitors the media stream of a call based on an 
attribute negotiated via SDP in the SIP INVITE.  How it watches can be 
controlled by the remote (Asterisk) side by setting an SDP attribute to 
'sendrecv', 'recvonly', 'sendonly', or 'ignore', which causes the PSTN 
gateway to monitor 'both', 'receiving', 'sending', or 'no' traffic on the 
RTP stream, respectively.  These terms are all RFC defined, and you can 
re-INVITE to change the stream without tearing it down.