[asterisk-dev] [Code Review]: Help mitigate reinvite glares in the SIP channel driver

Mark Michelson reviewboard at asterisk.org
Tue May 29 15:04:47 CDT 2012



> On May 29, 2012, 10:04 a.m., Mark Michelson wrote:
> > /trunk/channels/chan_sip.c, lines 30604-30607
> > <https://reviewboard.asterisk.org/r/1946/diff/2/?file=28284#file28284line30604>
> >
> >     I decided to do another round of testing before committing and noticed that despite having directmedia=outgoing set, I would see reinvite glares occasionally. I then noticed this block of code. I had meant to be returning here instead of continuing with an unlocked sip_pvt and channel. Adding the return results in one-way audio in my tests, so I need to figure out why that is happening and how to fix it.

Welp, it looks like this implementation of the patch is not going to work after all.

Consider a situation where phone A places a call through Asterisk 1, which then calls through Asterisk 2, which then calls phone B. Direct media is desired. With this patch, here is what occurs:

Upon call setup, Asterisk 1 sends a direct media reinvite to phone A saying to send media to Asterisk 2.
Since the call is outgoing, Asterisk 1 also sends a direct media reinvite to Asterisk 2 saying to send media to phone A.

Upon call setup, Asterisk 2 sends a direct media reinvite to phone B saying to send media to Asterisk 1.
Since the call is outgoing, Asterisk 2 does not send a direct media reinvite to Asterisk 1.

Upon receiving the direct media reinvite from Asterisk 1, Asterisk 2 then sends out a direct media reinvite to phone B to send media to phone A.

This is the final media setup of the call. Phone B properly sends media to Phone A, but Phone A is sending media to Asterisk 2.

I actually see Asterisk 1 send another reinvite each to phone A and to Asterisk 2, but the media addresses (c= lines in SDP) are the same as the previous reinvites (perhaps this is due to a connected line change?).

The issue here is that Asterisk 1 is never told that the remote media address on the outbound call leg has been updated to be phone B. Normally, Asterisk 1 would know of this change because of a reinvite being received on the outbound call leg indicating the address change. However, reinvites from Asterisk 2 to Asterisk 1 get blocked.

The only way I could get this setup to work properly was if I set nat=comedia so that for the brief period where Phone B sends media to Asterisk 1, Asterisk 1 detects a media address change and thus reinvites Phone A to send media to Phone B. I had strictrtp turned off, so this may not have worked properly with strictrtp enabled.

I'm at a bit of a loss for how to handle this properly. Obviously, Asterisk 2 has to be able to send a reinvite to Asterisk 1 so that Asterisk 1 can reinvite phone A properly. The obvious answer is to have a setting so that directmedia=outgoing means that the outgoing leg reinvites *first* rather than meaning that only the outgoing leg reinvites. The thing to work out for this is going to be figuring out how to trigger Asterisk 2 in the above scenario to send a reinvite to Asterisk 1. Is it enough to complete a single reinvite transaction between Asterisk 1 and 2 before Asterisk 2 is allowed to send a reinvite to Asterisk 1? I don't know for sure. I think that if there are more than 2 Asterisk servers in between the phones, then waiting for a single reinvite transaction might not be enough to effectively reduce the chances of glare.

Basically, the long and short of this is that the problem is not as easily solvable as what I have hear and will need a more complex solution. I am withdrawing this review until I come up with a better solution.


- Mark


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1946/#review6336
-----------------------------------------------------------


On May 25, 2012, 2:12 p.m., Mark Michelson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1946/
> -----------------------------------------------------------
> 
> (Updated May 25, 2012, 2:12 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> There are times where multiple Asterisk servers are peered together over SIP. In such situations, it is possible for both Asterisk servers to attempt to send direct media reinvites to each other simultaneously. This results in a glare situation in which each of the Asterisk servers sends a 491 to the other. After a waiting period, the reinvites are re-attempted. This waiting period can potentially be distracting since it can cause the media to take multiple seconds to finalize, especially if more than 2 Asterisk servers are involved.
> 
> This patch introduces a new SIP peer option called "directmedia_outgoing". If enabled, then when communicating with the peer, Asterisk will only attempt to send reinvites if the call direction is outgoing. The assumption is that the peer Asterisk server will also have this setting enabled. This way, when the two Asterisk servers communicate, they will never attempt to send direct media reinvites to each other. Instead, it will always be the peer that placed the call that will send the direct media reinvite.
> 
> 
> Diffs
> -----
> 
>   /trunk/channels/chan_sip.c 367639 
>   /trunk/channels/sip/include/sip.h 367639 
>   /trunk/configs/sip.conf.sample 367639 
> 
> Diff: https://reviewboard.asterisk.org/r/1946/diff
> 
> 
> Testing
> -------
> 
> I have tested this by running two Asterisk servers and ensuring that the option was honored and that the media streams were still set up properly.
> 
> 
> Thanks,
> 
> Mark
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120529/1fc3af4b/attachment.htm>


More information about the asterisk-dev mailing list