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?
----Messaggio originale----
Da: frank@carmickle.com
Data: 25-set-2014 16.22
A: "Kamailio (SER) - Users Mailing List"sr-users@lists.sip-router.org
Ogg: Re: [SR-Users] R: Re: RTPPROXY & BRANCH
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 Sep 25, 2014, at 10:41 AM, Marino Mileti marino.mileti@alice.it wrote:
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)
The UA sending the invite can handle two 183s? This is very custom/non-standard. Does this UA also support TURN? Maybe you could do TURN instead.
--FC
On 09/25/14 10:41, Marino Mileti wrote:
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?
This may work with rtpengine, as it will open new ports for answers come from different endpoints. But the final two-way association for the actual call may still end up broken, as it has no way of knowing which client ends up receiving the call (unless they do a final re-invite).
cheers
On Sep 29, 2014, at 1:14 PM, Richard Fuchs rfuchs@sipwise.com wrote:
This may work with rtpengine, as it will open new ports for answers come from different endpoints. But the final two-way association for the actual call may still end up broken, as it has no way of knowing which client ends up receiving the call (unless they do a final re-invite).
But it should see the 200. Shouldn't that be enough?
--FC
On 09/29/14 13:19, Frank Carmickle wrote:
On Sep 29, 2014, at 1:14 PM, Richard Fuchs rfuchs@sipwise.com wrote:
This may work with rtpengine, as it will open new ports for answers come from different endpoints. But the final two-way association for the actual call may still end up broken, as it has no way of knowing which client ends up receiving the call (unless they do a final re-invite).
But it should see the 200. Shouldn't that be enough?
Unfortunately it doesn't see SIP codes, it only sees SDP bodies and some particular details from the SIP message. 200 OK would be translated to an "answer", but not every answer is from a 200 OK, so you can't use that to break other associations. Perhaps this would be a nice addition to have in the future.
cheers
On Sep 29, 2014, at 1:24 PM, Richard Fuchs rfuchs@sipwise.com wrote:
On 09/29/14 13:19, Frank Carmickle wrote:
On Sep 29, 2014, at 1:14 PM, Richard Fuchs rfuchs@sipwise.com wrote:
This may work with rtpengine, as it will open new ports for answers come from different endpoints. But the final two-way association for the actual call may still end up broken, as it has no way of knowing which client ends up receiving the call (unless they do a final re-invite).
But it should see the 200. Shouldn't that be enough?
Unfortunately it doesn't see SIP codes, it only sees SDP bodies and some particular details from the SIP message. 200 OK would be translated to an "answer", but not every answer is from a 200 OK, so you can't use that to break other associations. Perhaps this would be a nice addition to have in the future.
I will argue that the only thing that is an answer is a 200. A progress, early media or pre_answer is a 183. Yes both 183s and 200s need to set up media but as you know there could be many 183s and only one 200.
If the UA sends an sdp with both the 183 and the 200 would this work correctly?
--FC
On 09/29/14 13:29, Frank Carmickle wrote:
On Sep 29, 2014, at 1:24 PM, Richard Fuchs rfuchs@sipwise.com wrote:
On 09/29/14 13:19, Frank Carmickle wrote:
On Sep 29, 2014, at 1:14 PM, Richard Fuchs rfuchs@sipwise.com wrote:
This may work with rtpengine, as it will open new ports for answers come from different endpoints. But the final two-way association for the actual call may still end up broken, as it has no way of knowing which client ends up receiving the call (unless they do a final re-invite).
But it should see the 200. Shouldn't that be enough?
Unfortunately it doesn't see SIP codes, it only sees SDP bodies and some particular details from the SIP message. 200 OK would be translated to an "answer", but not every answer is from a 200 OK, so you can't use that to break other associations. Perhaps this would be a nice addition to have in the future.
I will argue that the only thing that is an answer is a 200. A progress, early media or pre_answer is a 183. Yes both 183s and 200s need to set up media but as you know there could be many 183s and only one 200.
If the UA sends an sdp with both the 183 and the 200 would this work correctly?
That might just work, as the last answer rtpengine sees determines the association with the offer.
cheers
The problem isn't on 183s but on the multiple INVITE that Kamailio sends to clients behind rtpengine. Rtpengine open new ports for answer but on INVITE the rtpengine ports are the same...This happens because for all these clients the callid is still the same..so for rtpengine there's no difference...for this reason I can see early media only on one of the receivers
I've tried the "b" option...but in rtpengine "via-branch" is not managed (it's commented on the source code). So I've tried some other things ..ad example I've modified rtpengine in order to use via-branch instead callid...and in this way everything works good :) but there are some other issue because in every "rtpengine command" should be made some changes to support this :)
Now my idea is...if I leave rtpengine without any modify and change rptproxy-ng module in order to modify callid (appending for example via or some other parameters in order to make it unique) should it work?
-----Messaggio originale----- Da: sr-users-bounces@lists.sip-router.org [mailto:sr-users-bounces@lists.sip-router.org] Per conto di Richard Fuchs Inviato: lunedì 29 settembre 2014 19:37 A: sr-users@lists.sip-router.org Oggetto: Re: [SR-Users] R: Re: R: Re: RTPPROXY & BRANCH
On 09/29/14 13:29, Frank Carmickle wrote:
On Sep 29, 2014, at 1:24 PM, Richard Fuchs rfuchs@sipwise.com wrote:
On 09/29/14 13:19, Frank Carmickle wrote:
On Sep 29, 2014, at 1:14 PM, Richard Fuchs rfuchs@sipwise.com wrote:
This may work with rtpengine, as it will open new ports for answers come from different endpoints. But the final two-way association for the actual call may still end up broken, as it has no way of knowing which client ends up receiving the call (unless they do a final
re-invite).
But it should see the 200. Shouldn't that be enough?
Unfortunately it doesn't see SIP codes, it only sees SDP bodies and some particular details from the SIP message. 200 OK would be translated to an "answer", but not every answer is from a 200 OK, so you can't use that to break other associations. Perhaps this would be a nice addition to have in the future.
I will argue that the only thing that is an answer is a 200. A progress,
early media or pre_answer is a 183. Yes both 183s and 200s need to set up media but as you know there could be many 183s and only one 200.
If the UA sends an sdp with both the 183 and the 200 would this work
correctly?
That might just work, as the last answer rtpengine sees determines the association with the offer.
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
--- Questa e-mail è priva di virus e malware perché è attiva la protezione avast! Antivirus. http://www.avast.com
-
Frank Carmickle -
Marino Mileti -
Richard Fuchs