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)
So at the moment this scenario is not possible? Is there any possible turnaround?
----Messaggio originale---- Da: rfuchs@sipwise.com Data: 24-set-2014 1.15 A: sr-users@lists.sip-router.org Ogg: Re: [SR-Users] RTPPROXY & BRANCH
On 23/09/14 04:35 AM, marino.mileti@alice.it wrote:
I've a problem with rtpproxy during a parallel ring scenario. I've two client behind NAT (192.168.10.20 & 192.168.10.50) and when I try to call them in parallel mode (ringall) rtpproxy module sends in to the INVITE the same RTP ports.
Is it possible to manage rtpproxy in order to generate a couple of new port for each branch?
Not at the moment. The logic is that one endpoint advertised by the client is mapped to one endpoint advertised by rtpengine. Why would you like a separate set of ports?
cheers
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
On Sep 25, 2014, at 10:09 AM, Marino Mileti marino.mileti@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.
--FC
On 09/25/14 10:22, Frank Carmickle wrote:
On Sep 25, 2014, at 10:09 AM, Marino Mileti <marino.mileti@alice.it mailto:marino.mileti@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.
That's also what I'm confused about. The calling client only offers one endpoint, so without RTP proxy in between, all receiving clients would be offered the same IP and port, just as they do now with an RTP proxy. In either case, the offering client would receive multiple early media streams from different endpoints. I'm not sure what difference the RTP proxy should make.
cheers
On 09/29/14 13:03, Richard Fuchs wrote:
On 09/25/14 10:22, Frank Carmickle wrote:
On Sep 25, 2014, at 10:09 AM, Marino Mileti <marino.mileti@alice.it mailto:marino.mileti@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.
That's also what I'm confused about. The calling client only offers one endpoint, so without RTP proxy in between, all receiving clients would be offered the same IP and port, just as they do now with an RTP proxy. In either case, the offering client would receive multiple early media streams from different endpoints. I'm not sure what difference the RTP proxy should make.
Sorry, I see this has already been discussed. Your email client seems to break reply threads. Ignore this email.
-
Frank Carmickle -
Marino Mileti -
Richard Fuchs