[SR-Users] RTPPROXY & BRANCH

[m***@public.gmane.org]

Hi

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?

My rtpproxy string in the kamailio conf (in manage branch section):

rtpproxy_manage("bFAIE","192.168.10.10");


Brief extract of 2 SIP INVITE message send by kamailio to natted clients:

192.168.10.10 --> 192.168.10.20
User Datagram Protocol, Src Port: sip (5060), Dst Port: 6090 (6090)
Session Initiation Protocol (INVITE)
Request-Line: INVITE sip:1001-***@public.gmane.org:6090 SIP/2.0
Message Header
Message Body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): 1004 1476 1657 IN IP4 192.168.10.10
Session Name (s): Talk
Connection Information (c): IN IP4 192.168.10.10
Time Description, active time (t): 0 0
Media Description, name and address (m): audio 62910 RTP/AVP 111 110 0 8 101
Media Description, name and address (m): video 47160 RTP/AVP 102
Media Attribute (a): nortpproxy:yes


192.168.10.10 --> 192.168.10.50
User Datagram Protocol, Src Port: sip (5060), Dst Port: 6090 (6090)
Session Initiation Protocol (INVITE)
Request-Line: INVITE sip:1002-***@public.gmane.org:6090 SIP/2.0
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): 1004 1476 1657 IN IP4 192.168.10.10
Session Name (s): Talk
Connection Information (c): IN IP4 192.168.10.10
Time Description, active time (t): 0 0
Media Description, name and address (m): audio 62910 RTP/AVP 111 110 0 8 101
Media Description, name and address (m): video 47160 RTP/AVP 102
Media Attribute (a): nortpproxy:yes

[Richard Fuchs]

Post by m***@public.gmane.org
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

[m***@public.gmane.org]

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-is+***@public.gmane.org
Data: 24-set-2014 1.15
A: <sr-users-cR8azDVoa3IcDhw6gZKtMWD2FQJk+8+***@public.gmane.org>
Ogg: Re: [SR-Users] RTPPROXY &amp;amp; BRANCH

Post by m***@public.gmane.org
I've a problem with rtpproxy during a parallel ring scenario.
I've two client behind NAT (192.168.10.20 &amp; 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

[Marino Mileti]

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-is+***@public.gmane.org
Data: 24-set-2014 1.15
A: <sr-users-cR8azDVoa3IcDhw6gZKtMWD2FQJk+8+***@public.gmane.org>
Ogg: Re: [SR-Users] RTPPROXY &amp;amp; BRANCH

Post by m***@public.gmane.org
I've a problem with rtpproxy during a parallel ring scenario.
I've two client behind NAT (192.168.10.20 &amp; 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

[Frank Carmickle]

Post by m***@public.gmane.org
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

[Richard Fuchs]

Post by Frank Carmickle

Post by m***@public.gmane.org
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

[Richard Fuchs]

Post by Richard Fuchs

Post by Frank Carmickle

Post by m***@public.gmane.org
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.

[Marino Mileti]

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 &amp; C are group member...so Kamailio is able to call them in parallel using alias..
- B &amp; C receive the INVITEs &amp; replies with two separate 183 with SDP (in SDP they specified where they are able to receive audio&amp;video)
- A receives two 183...&amp; starts to send its RTP video stream to B &amp; C (early media)
- Once B or C answers the call the other leg is cancelled..
Everything is working fine but if B &amp; C are behind NAT rtpproxy is activated and during INVITE for B &amp;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 &amp; 200, i would like only that rtpptoxy sends INVITE for B &amp; C with differents port.Is it possible to implement this scenario or there's some turnarund?


----Messaggio originale----

Da: frank-***@public.gmane.org

Data: 25-set-2014 16.22

A: "Kamailio (SER) - Users Mailing List"<sr-users-cR8azDVoa3IcDhw6gZKtMWD2FQJk+8+***@public.gmane.org>

Ogg: Re: [SR-Users] R: Re: RTPPROXY &amp; BRANCH




On Sep 25, 2014, at 10:09 AM, Marino Mileti <marino.mileti-1Ph4/***@public.gmane.org> 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

[Frank Carmickle]

Post by Marino Mileti
No no. The video will be sent by the caller user to all the callees.
- 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

[Richard Fuchs]

Post by Marino Mileti
No no. The video will be sent by the caller user to all the callees.
- 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

[Frank Carmickle]

Post by Richard Fuchs
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

[Richard Fuchs]

Post by Frank Carmickle

Post by Richard Fuchs
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

[Frank Carmickle]

Post by Richard Fuchs

Post by Frank Carmickle

Post by Richard Fuchs
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

[Richard Fuchs]

Post by Frank Carmickle

Post by Richard Fuchs

Post by Frank Carmickle

Post by Richard Fuchs
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

[Marino Mileti]

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-cR8azDVoa3IcDhw6gZKtMWD2FQJk+8+***@public.gmane.org
[mailto:sr-users-bounces-cR8azDVoa3IcDhw6gZKtMWD2FQJk+8+***@public.gmane.org] Per conto di Richard Fuchs
Inviato: lunedì 29 settembre 2014 19:37
A: sr-users-cR8azDVoa3IcDhw6gZKtMWD2FQJk+8+***@public.gmane.org
Oggetto: Re: [SR-Users] R: Re: R: Re: RTPPROXY & BRANCH

Post by Frank Carmickle

Post by Richard Fuchs

Post by Frank Carmickle

Post by Richard Fuchs
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).

Post by Frank Carmickle

Post by Richard Fuchs

Post by Frank Carmickle
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.

Post by Frank Carmickle
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-cR8azDVoa3IcDhw6gZKtMWD2FQJk+8+***@public.gmane.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

[Richard Fuchs]

Post by Marino Mileti
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 still don't understand what difference an RTP proxy is supposed to
make for the invite. Your offering client only opens one endpoint and
sends that out. Without RTP proxy, all receiving clients see the same
endpoint and they will all send their early media to that same endpoint.
With RTP proxy, the same thing happens. What's the difference?

cheers

[Marino Mileti]

Without rtpproxy:

- A offers port a1,a2 (audio video) in INVITE to B,C (in case of no natted
client so no needs of rtpproxy)
- B offers port b1,b2 (183)
- C offers port c1,c2 (182).
- A starts to send audio/video RTP to B on port b1,b2
- A starts to send audio/video RTP to C on port c1,c2

With rtpproxy:

- A offers port a1,a2 (audio video) in INVITE to Kamailio....
- Kamailio contact rtpproxy because B&C are natted clients
- rtpproxy check callid and offer offers port k1,k2....
- Kamailio sends INVITE to B offering k1,k2
- Kamailio sends INVITE to C offering k1,k2
- B offers port b1,b2 (183)
- C offers port c1,c2 (182)
- Kamailio sends 183 to A (for B leg) offering p1,p2
- Kamailio sends 183 to A (for B leg) offering p3,p4
- A starts to stream on p1,p2,p3,p4 but only one receiver can see the video
(B or C depends who will be the first:))

I don't know if it depends on that B & C receives same ports; i don't know
if rtpproxy is able to "duplicate" stream received from A to all "receiver"

-----Messaggio originale-----
Da: sr-users-bounces-cR8azDVoa3IcDhw6gZKtMWD2FQJk+8+***@public.gmane.org
[mailto:sr-users-bounces-cR8azDVoa3IcDhw6gZKtMWD2FQJk+8+***@public.gmane.org] Per conto di Richard Fuchs
Inviato: lunedì 29 settembre 2014 20:31
A: sr-users-cR8azDVoa3IcDhw6gZKtMWD2FQJk+8+***@public.gmane.org
Oggetto: Re: [SR-Users] R: Re: R: Re: RTPPROXY & BRANCH

Post by Marino Mileti
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 still don't understand what difference an RTP proxy is supposed to make
for the invite. Your offering client only opens one endpoint and sends that
out. Without RTP proxy, all receiving clients see the same endpoint and they
will all send their early media to that same endpoint.
With RTP proxy, the same thing happens. What's the difference?

cheers

_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users-cR8azDVoa3IcDhw6gZKtMWD2FQJk+8+***@public.gmane.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

[Richard Fuchs]

Post by Marino Mileti
- A offers port a1,a2 (audio video) in INVITE to B,C (in case of no natted
client so no needs of rtpproxy)
- B offers port b1,b2 (183)
- C offers port c1,c2 (182).
- A starts to send audio/video RTP to B on port b1,b2
- A starts to send audio/video RTP to C on port c1,c2
- A offers port a1,a2 (audio video) in INVITE to Kamailio....
- Kamailio contact rtpproxy because B&C are natted clients
- rtpproxy check callid and offer offers port k1,k2....
- Kamailio sends INVITE to B offering k1,k2
- Kamailio sends INVITE to C offering k1,k2
- B offers port b1,b2 (183)
- C offers port c1,c2 (182)
- Kamailio sends 183 to A (for B leg) offering p1,p2
- Kamailio sends 183 to A (for B leg) offering p3,p4
- A starts to stream on p1,p2,p3,p4 but only one receiver can see the video
(B or C depends who will be the first:))
I don't know if it depends on that B & C receives same ports; i don't know
if rtpproxy is able to "duplicate" stream received from A to all "receiver"

If A sends two streams, there is no need for duplication. A sending to
p1 should be forwarded to B (b1) and A sending to p3 should be forwarded
to C (c1). Both should be able to receive media sent by A. I believe
that's what rtpengine does (but I haven't tested it). The reverse
direction might be more confusing, but a final 200 OK with SDP should
fix that.

cheers

[Marino Mileti]

Unfortunately rtpengine doesn't work in this way. At the end of the calls this is the output log:
Final packet stats:

Tag 'Fw3D7R0', created 0:41 ago, in dialogue with 'TTPyT~Hdw'
Media #1, port 30224 <> 192.168.10.20:7078 , 540 p, 92880 b, 0 e
Media #1, port 30225 <> 192.168.10.20:7079 (RTCP), 3 p, 324 b, 0 e
Media #2, port 30256 <> 192.168.10.20:9078 , 0 p, 0 b, 0 e
Media #2, port 30257 <> 192.168.10.20:9079 (RTCP), 3 p, 264 b, 0 e

Tag 'qWE6Gsh', created 0:41 ago, in dialogue with 'TTPyT~Hdw'
Media #1, port 30140 <> 192.168.10.50:7078 , 533 p, 91068 b, 0 e
Media #1, port 30141 <> 192.168.10.50:7079 (RTCP), 5 p, 444 b, 0 e
Media #2, port 30170 <> 192.168.10.50:9078 , 0 p, 0 b, 0 e
Media #2, port 30171 <> 192.168.10.50:9079 (RTCP), 1 p, 88 b, 0 e

Tag 'TTPyT~Hdw', created 0:41 ago, in dialogue with 'Fw3D7R0'
Media #1, port 30206 <> 172.20.11.208:7078 , 1070 p, 183736 b, 0 e
Media #1, port 30207 <> 172.20.11.208:7079 (RTCP), 4 p, 496 b, 0 e
Media #2, port 30240 <> 172.20.11.208:9078 , 4188 p, 1435946 b, 0 e
Media #2, port 30241 <> 172.20.11.208:9079 (RTCP), 4 p, 400 b, 0 e

192.168.10.x clients are natted..it seems that rtpengine open 2 ports (for example video) for each receiver (30256 &amp; 30170) and 1 port for the caller (30240). But on the INVITE of Kamailio only video port 30170 is offered to receivers, instead on caller side there are 2 distinct 183s message that offer 30190 &amp; 30240. It's a little bit strange because some of these port doesn't appear in the log of rtpengine. At the end I can see video only on one receiver
I don't know if the problem is on Kamailio (rtpproxy-ng module) or in the rtpengine :)

Post by Marino Mileti
- A offers port a1,a2 (audio video) in INVITE to B,C (in case of no natted
client so no needs of rtpproxy)
- B offers port b1,b2 (183)
- C offers port c1,c2 (182).
- A starts to send audio/video RTP to B on port b1,b2
- A starts to send audio/video RTP to C on port c1,c2
- A offers port a1,a2 (audio video) in INVITE to Kamailio....
- Kamailio contact rtpproxy because B&amp;C are natted clients
- rtpproxy check callid and offer offers port k1,k2....
- Kamailio sends INVITE to B offering k1,k2
- Kamailio sends INVITE to C offering k1,k2
- B offers port b1,b2 (183)
- C offers port c1,c2 (182)
- Kamailio sends 183 to A (for B leg) offering p1,p2
- Kamailio sends 183 to A (for B leg) offering p3,p4
- A starts to stream on p1,p2,p3,p4 but only one receiver can see the video
(B or C depends who will be the first:))
I don't know if it depends on that B &amp; C receives same ports; i don't know
if rtpproxy is able to "duplicate" stream received from A to all "receiver"

If A sends two streams, there is no need for duplication. A sending to
p1 should be forwarded to B (b1) and A sending to p3 should be forwarded
to C (c1). Both should be able to receive media sent by A. I believe
that's what rtpengine does (but I haven't tested it). The reverse
direction might be more confusing, but a final 200 OK with SDP should
fix that.

cheers

[Carlos Ruiz Díaz]

Hi Richard,

this is more or less the same problem that I am experiencing. To understand
it better, just assume one branch needs to do SRTP, and the other simple
RTP.

To make this happen, you will have to enable rtpengine differently for the
same call, and this is where the crash/error happens.

Regards,
Carlos

Post by Marino Mileti
Unfortunately rtpengine doesn't work in this way. At the end of the calls
Tag 'Fw3D7R0', created 0:41 ago, in dialogue with 'TTPyT~Hdw'
Media #1, port 30224 <> 192.168.10.20:7078 , 540 p, 92880 b, 0 e
Media #1, port 30225 <> 192.168.10.20:7079 (RTCP), 3 p, 324 b, 0 e
Media #2, port 30256 <> 192.168.10.20:9078 , 0 p, 0 b, 0 e
Media #2, port 30257 <> 192.168.10.20:9079 (RTCP), 3 p, 264 b, 0 e
Tag 'qWE6Gsh', created 0:41 ago, in dialogue with 'TTPyT~Hdw'
Media #1, port 30140 <> 192.168.10.50:7078 , 533 p, 91068 b, 0 e
Media #1, port 30141 <> 192.168.10.50:7079 (RTCP), 5 p, 444 b, 0 e
Media #2, port 30170 <> 192.168.10.50:9078 , 0 p, 0 b, 0 e
Media #2, port 30171 <> 192.168.10.50:9079 (RTCP), 1 p, 88 b, 0 e
Tag 'TTPyT~Hdw', created 0:41 ago, in dialogue with 'Fw3D7R0'
Media #1, port 30206 <> 172.20.11.208:7078 , 1070 p, 183736 b, 0 e
Media #1, port 30207 <> 172.20.11.208:7079 (RTCP), 4 p, 496 b, 0 e
Media #2, port 30240 <> 172.20.11.208:9078 , 4188 p, 1435946 b, 0 e
Media #2, port 30241 <> 172.20.11.208:9079 (RTCP), 4 p, 400 b, 0 e
192.168.10.x clients are natted..it seems that rtpengine open 2 ports (for
example video) for each receiver (30256 & 30170) and 1 port for the caller
(30240). But on the INVITE of Kamailio only video port 30170 is offered to
receivers, instead on caller side there are 2 distinct 183s message that
offer 30190 & 30240. It's a little bit strange because some of these port
doesn't appear in the log of rtpengine. At the end I can see video only on
one receiver
I don't know if the problem is on Kamailio (rtpproxy-ng module) or in the rtpengine :)

Post by Marino Mileti
- A offers port a1,a2 (audio video) in INVITE to B,C (in case of no

natted

Post by Marino Mileti
client so no needs of rtpproxy)
- B offers port b1,b2 (183)
- C offers port c1,c2 (182).
- A starts to send audio/video RTP to B on port b1,b2
- A starts to send audio/video RTP to C on port c1,c2
- A offers port a1,a2 (audio video) in INVITE to Kamailio....
- Kamailio contact rtpproxy because B&C are natted clients
- rtpproxy check callid and offer offers port k1,k2....
- Kamailio sends INVITE to B offering k1,k2
- Kamailio sends INVITE to C offering k1,k2
- B offers port b1,b2 (183)
- C offers port c1,c2 (182)
- Kamailio sends 183 to A (for B leg) offering p1,p2
- Kamailio sends 183 to A (for B leg) offering p3,p4
- A starts to stream on p1,p2,p3,p4 but only one receiver can see the

video

Post by Marino Mileti
(B or C depends who will be the first:))
I don't know if it depends on that B & C receives same ports; i don't

know

Post by Marino Mileti
if rtpproxy is able to "duplicate" stream received from A to all

"receiver"
If A sends two streams, there is no need for duplication. A sending to
p1 should be forwarded to B (b1) and A sending to p3 should be forwarded
to C (c1). Both should be able to receive media sent by A. I believe
that's what rtpengine does (but I haven't tested it). The reverse
direction might be more confusing, but a final 200 OK with SDP should
fix that.
cheers
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users