Summary:ASTERISK-19857: Explore directmedia re-INVITE improvements between multiple Asterisk instances
Reporter:Matt Jordan (mjordan)Labels:
Date Opened:2012-05-10 11:18:04Date Closed:2012-08-23 08:47:41
Versions: 10.5.0 Frequency of
Environment:Attachments:( 0) ASTERISK-19857.diff
Description:In a setup with multiple Asterisk instances, the directmedia setting can result in a number of re-INVITE collisions between the intermediary Asterisk instances.  For example, consider a scenario where phone P1 initially sends its INVITE request to A1, which sends the INVITE request to A2, which delivers the INVITE request to P2.  


Initial invite sequence:
P1 => A1 => A2 => P2


When the directmedia logic begins, A1 will need to re-INVITE P1 to send its RTP to A2, and will generate re-INVITEs for both UAs.  A2 will do the same, sending re-INVITEs to P2 and A1.

First Re-INVITEs:

P1 <= A1 <=> A2 => P2

This results in A1 being removed from the media path for P1, but being in the media path for P2, and vice versa for A2/P1.  A new set of re-INVITEs will then occur to direct P1 to P2 from A2, and P2 to P1 from A1.  
However, before this, the re-INVITEs between A1 and A2 will most likely collide, resulting in the backoff timers in SIP to kick in, delaying the time it takes for the media path to be set up between P1 and P2.

Because - in this case - there is knowledge between the Asterisk servers that an additional set of re-INVITEs will occur beyond the first set, it is possible to reduce the number of re-INVITEs by not having one of the Asterisk instances send its re-INVITE to the other Asterisk instance.
Comments:By: Mark Michelson (mmichelson) 2012-06-01 15:24:04.718-0500

This is a patch that adds a directmedia=outgoing setting to chan_sip.conf. Read the sip.conf.sample change to see what the option does. This should hopefully prevent common reinvite glare scenarios.