[SR-Users] R: Re: R: Re: RTPPROXY & BRANCH
marino.mileti at alice.it
Thu Sep 25 16:41:56 CEST 2014
No no. The video will be sent by the caller user to all the callees.
I'l try to explain better. My scenario is:
- A make a call to a group... B & C are group member...so Kamailio is able to call them in parallel using alias..
- B & C receive the INVITEs & replies with two separate 183 with SDP (in SDP they specified where they are able to receive audio&video)
- A receives two 183...& starts to send its RTP video stream to B & C (early media)
- Once B or C answers the call the other leg is cancelled..
Everything is working fine but if B & C are behind NAT rtpproxy is activated and during INVITE for B &C rtprpoxy doesn't generate a couple of new ports for each of them but it uses always the same ports. So the only fastest client (B or C) get the video.
I don't want to change IP between 183 & 200, i would like only that rtpptoxy sends INVITE for B & C with differents port.Is it possible to implement this scenario or there's some turnarund?
Da: frank at carmickle.com
Data: 25-set-2014 16.22
A: "Kamailio (SER) - Users Mailing List"<sr-users at lists.sip-router.org>
Ogg: Re: [SR-Users] R: Re: RTPPROXY & BRANCH
On Sep 25, 2014, at 10:09 AM, Marino Mileti <marino.mileti at alice.it> wrote:Because I've more than 1 client behind NAT (1,2,3 mobile phones) and I would like to reach all of them in parallel mode. I can't use for all of them same ports because all mobile clients have early media (the receive video media before they answer)
I don't understand. Are you saying that you have clients that when they receive an invite sent video with 183? How do you want to composite the video to show to the caller? It is not RFC3261 compliant to change IP and port from 183 to 200. Of course you can reinvite after the 200. Most B2BUAs require you to ignore early media and generate something locally to send to the caller or just send them 180.
Maybe if you explain your use case someone can help you.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the sr-users