[OpenSIPS-Users] Parallel forking (using registrar branching) & mediaproxy

[Ruud Klaver]

Hi Erwan,

On 08 Jul 2009, at 10:33, erwan.humez at orange-ftgroup.com wrote:

> That's a much better setup than your previous one. I really can't tell
> you what a relay with two IPs when you're only listening on one does.
>
> [ERWAN] I don't quite understand your statement above since the  
> relay is only using one IP in the last target architecture :  
> 90.84.16.17. Only the initial architecture (with private IPs) used a  
> 2-IPs relay but i have given up with this architecture in order to  
> stick to your recommandations.

Sorry, maybe I wasn't clear on that. I was actually talking about your  
initial architecture there, so I agree with you.

> BTW, strictly speaking NATing to different IPs is not necessary, it
> should work when NATting all to the same IP, but it's a good
> approximation of a realistic situation.
>
> [ERWAN] agreed, PAT only might have been used but it was easier and  
> quicker to setup this way ;-) It should not have any impact on the  
> relay behaviour, provided that IP reachability is ensured.

Yes, it should be fine.

> From this I can already see that your problem is probably in your
> OpenSIPs configuration. What SHOULD happen is that any occurrence of
> SDP is sent to the relay. In this scenario that would be:
>
> 1) The original INVITE
> 2) The first 183
> 3) The second 183
> 4) The final response, 200 OK
>
> [ERWAN] Actually i found out that sending an update for 183/SDP  
> messages is worst : no media is established at all. So i de- 
> activated the sending of update for 183/SDP messages only, so that  
> only the final 200/SDP message of the answering gateway triggers an  
> update to the relay at the end of the call establishment, so at  
> least one of the call can be estabished but still not the other  
> (this is my issue).

So let me get this clear, the trace that you send are actually without  
updates to the dispatcher for the 183s?

> Now what you are trying to do with two streams of early media is quite
> weird, so between steps 1 and 4 the user placing the call could be
> quite confused about what it hears, since basically he/she should hear
> the last gateway that sent a 183. But in the end it should be fine, as
> the relay is again updated by the 200 OK, which should result in the
> user hearing whichever gateway picked up.
>
> [ERWAN]Totally agreed, this is what i was thinking about by de- 
> activating update for 183/SDP messages only (check my previous  
> remark above) : still the 200OK/SDP update of the answering gateway  
> should be enough for the relay to do his job.
>
> But from your trace I can see only two update commands. I'm guessing
> this is from the original INVITE and the first 183. So what happens is
> that the relays is locked into the RTP of whichever gateway sends it
> first. So getting your OpenSIPs config to send the SDP to the relay on
> the seconds 183 and the 200 OK should fix this.
>
> [ERWAN] I guess the update of the traces belongs to the first INVITE/ 
> SDP of the caller and the last 200OK/SDP of the called gateway. But  
> since i de-activate update for 183/SDP, we should have 2 updates for  
> one gateway (INVITE/SDP + 200OK/SDP) and only one update for the  
> other gateway (INVITE/SDP) which is not the case. Your explanations  
> is clear and i will try to tune my opensips configuration and to  
> figure out which update belongs to which SIP message exactly.

I think you are still slightly mistaken about this. If you disabled  
dispatcher updates for 183 responses I'm beginning to get a picture  
about why only one of your gateways can successfully establish media  
across the relay.

The fact that the dispatcher sees two updates in this situation is  
quite correct, one for the original INVITE and one for the final  
response, 200 OK. You seem to assume that there should be two updates,  
one for each forking INVITE, but that is not the case. What happens is  
that the SDP in the INVITE is changed to include the relay ip/port.  
Both of the gateways start sending early media to this ip/port, as  
they reply with a 183. The gateway whose RTP packet arrives first at  
the relay gets selected as the other endpoint for the media flow, the  
other gets discarded. Mind you, a normal endpoint that is not using a  
relay also has to deal with two streams coming in, it will have the  
same problem of not knowing which one to select. When one of the  
gateways picks up, the other will stop sending media. Now, if the  
gateway that was selected by the relay is the one that stops sending,  
there will be no media flow anymore. The relay has no knowledge that  
the RTP endpoint may have changed, because it only saw the 200 OK, and  
it is quite normal for media to arrive before the 200 OK arrives. So  
the relays is not aware of an early-media situation.

> On the other hand, I would be curious to see if it will be fixed, as
> the gateway that does not pick up could continue sending RTP for a
> while, causing the relay to still thing this is the correct source
> after the OK has been sent. It's a confusing situation...
>
> [ERWAN]Agreed, this is a possible situation (gateway sending RTP  
> packets before receiving final call disconnection) since we are  
> using early-media but the media relay should not pay attention to it  
> as soon as the BYE/CANCEL is issues i guess... If RTP packets  
> received by the relay are the issue, i think that one of the  
> solution would be to de-activate SDP in 183 messages on the gateway  
> side but i still haven't found the solution yet.

Could you send me some logs with updates on 183 enabled? I think the  
above problem may also occur there, but I'm not entirely sure what  
will happen.

Ruud Klaver
AG Projects