25 Sep
2014
25 Sep
'14
10:41 a.m.
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(a)carmickle.com
Data: 25-set-2014 16.22
A: "Kamailio (SER) - Users Mailing List"<sr-users(a)lists.sip-router.org>
Ogg: Re: [SR-Users] R: Re: RTPPROXY & BRANCH
On Sep 25, 2014, at 10:09 AM, Marino Mileti <marino.mileti(a)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
25 Sep
25 Sep
12:42 p.m.
New subject: R: Re: R: Re: RTPPROXY & BRANCH
On Sep 25, 2014, at 10:41 AM, Marino Mileti <marino.mileti(a)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
29 Sep
29 Sep
1:14 p.m.
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
1:19 p.m.
On Sep 29, 2014, at 1:14 PM, Richard Fuchs <rfuchs(a)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
1:24 p.m.
On 09/29/14 13:19, Frank Carmickle wrote:
On Sep 29, 2014, at 1:14 PM, Richard Fuchs <rfuchs(a)sipwise.com> wrote:
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
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?
1:29 p.m.
On Sep 29, 2014, at 1:24 PM, Richard Fuchs <rfuchs(a)sipwise.com> wrote:
On 09/29/14 13:19, Frank Carmickle wrote:
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 Sep 29, 2014, at 1:14 PM, Richard Fuchs <rfuchs(a)sipwise.com> wrote:
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.
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?
1:37 p.m.
On 09/29/14 13:29, Frank Carmickle wrote:
On Sep 29, 2014, at 1:24 PM, Richard Fuchs <rfuchs(a)sipwise.com> wrote:
That might just work, as the last answer rtpengine sees determines the
association with the offer.
cheers
On 09/29/14 13:19, Frank Carmickle wrote:
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?
On Sep 29, 2014, at 1:14 PM, Richard Fuchs <rfuchs(a)sipwise.com> wrote:
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.
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?
2:23 p.m.
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(a)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(a)lists.sip-router.org
Oggetto: Re: [SR-Users] R: Re: R: Re: RTPPROXY & BRANCH
On 09/29/14 13:29, Frank Carmickle wrote:
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.
On Sep 29, 2014, at 1:24 PM, Richard Fuchs <rfuchs(a)sipwise.com> wrote:
> On 09/29/14 13:19, Frank Carmickle wrote:
>>
>> On Sep 29, 2014, at 1:14 PM, Richard Fuchs <rfuchs(a)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.
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(a)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
3795
days inactive
3799
days old
7 comments
3 participants
participants (3)
-
Frank Carmickle -
Marino Mileti -
Richard Fuchs