SORRY TO HAVE REPLIED TO YOUR EMAIL!!!
I hate it when gmail does that!
Thanks,
It rather very easy, I need all calls to go through the media-proxy. I'm testing behind nat, server is on the internet. If I make a call from one UAC natted to another UAC natted, it works fine, rtps go to the proxy. If I call from behind NAT to echo test, I don't get any audio. rtps go directly to the echo test server's IP, but i don't get anything back. I'm doing something very wrong, I've modifed the script like a thousand time, and still...
On Fri, Jun 13, 2008 at 7:25 PM, David Villasmil < david.villasmil.work@gmail.com> wrote:
Thanks,
It rather very easy, I need all calls to go through the media-proxy.I'm testing behind nat, server is on the internet. If I make a call from one UAC natted to another UAC natted, it works fine, rtps go to the proxy. If I call from behind NAT to echo test, I don't get any audio. rtps go directly to the echo test server's IP, but i don't get anything back. I'm doing something very wrong, I've modifed the script like a thousand time, and still...
On Fri, Jun 13, 2008 at 7:11 PM, Raúl Alexis Betancor Santana < rabs@dimension-virtual.com> wrote:
El Viernes, 13 de Junio de 2008 17:47, David Villasmil escribió:
That was not my intention at all and I'm sorry you got it that way. I
did
take a look at my script and I thought I should do was eliminate all
tests
for nats and simply call use_media_proxy when an INVITE comes in, and an on_reply was hit. Also of course end_media_session() n a BYE or a
CANCEL...
But it is still not working, well it instruct my UAC to send rtps
directly
to the echo test ip... and this wasn't working.
And because I did not see anything work (I don't have much experience
with
media-proxy) I thought I'd ask here... my bad. ;-)
Of course I will keeo looking at this, I don't want anyone to do my
job...
;-)
Ok, so from that point on ... what it's your test scenario, paint it and we could guide you to the right point.
We do not have a crystal ball ;-)
-- Saludos.
Raúl Alexis Betancor Santana Dimensión Virtual S.L.
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
An update, if I call myself from behind nat, I get audio, but its passed directly... :S
I need it to go through the proxy..
Still, I see mediaproxy starting to listen for the rtps (I think).. 1.2.3.4=server 9.8.7.6=client
request ZDNmNmYzZTIxNDg0Zjg0MWRiNTUxOTNlMzIwNDk5NTg. 192.168.1.2:42392:audio 9.8.7.6 1.2.3.4 local 9.8.7.6 remote eyeBeam=20release=201014c=20stamp=2046090 info=from:5512344@1.2.3.4from%3A5512344@1.2.3.4 ,to:5512344@1.2.3.4 to%3A5512344@1.2.3.4,fromtag:dd265b50,totag: session ZDNmNmYzZTIxNDg0Zjg0MWRiNTUxOTNlMzIwNDk5NTg.: started. listening on 1.2.3.4:35052
jeez!
On Fri, Jun 13, 2008 at 7:29 PM, David Villasmil < david.villasmil.work@gmail.com> wrote:
SORRY TO HAVE REPLIED TO YOUR EMAIL!!!
I hate it when gmail does that!
Thanks,
It rather very easy, I need all calls to go through the media-proxy.I'm testing behind nat, server is on the internet. If I make a call from one UAC natted to another UAC natted, it works fine, rtps go to the proxy. If I call from behind NAT to echo test, I don't get any audio. rtps go directly to the echo test server's IP, but i don't get anything back. I'm doing something very wrong, I've modifed the script like a thousand time, and still...
On Fri, Jun 13, 2008 at 7:25 PM, David Villasmil < david.villasmil.work@gmail.com> wrote:
Thanks,
It rather very easy, I need all calls to go through the media-proxy.I'm testing behind nat, server is on the internet. If I make a call from one UAC natted to another UAC natted, it works fine, rtps go to the proxy. If I call from behind NAT to echo test, I don't get any audio. rtps go directly to the echo test server's IP, but i don't get anything back. I'm doing something very wrong, I've modifed the script like a thousand time, and still...
On Fri, Jun 13, 2008 at 7:11 PM, Raúl Alexis Betancor Santana < rabs@dimension-virtual.com> wrote:
El Viernes, 13 de Junio de 2008 17:47, David Villasmil escribió:
That was not my intention at all and I'm sorry you got it that way. I
did
take a look at my script and I thought I should do was eliminate all
tests
for nats and simply call use_media_proxy when an INVITE comes in, and
an
on_reply was hit. Also of course end_media_session() n a BYE or a
CANCEL...
But it is still not working, well it instruct my UAC to send rtps
directly
to the echo test ip... and this wasn't working.
And because I did not see anything work (I don't have much experience
with
media-proxy) I thought I'd ask here... my bad. ;-)
Of course I will keeo looking at this, I don't want anyone to do my
job...
;-)
Ok, so from that point on ... what it's your test scenario, paint it and we could guide you to the right point.
We do not have a crystal ball ;-)
-- Saludos.
Raúl Alexis Betancor Santana Dimensión Virtual S.L.
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
From an ngrep I just did when calling myself, openser NEVER offers the rtp
proxy's IP... This is the INVITE back from openser...
U 1.2.3.4:5060 -> 9.8.7.6:34856 INVITE sip:5512344@9.8.7.6:34856;rinstance=62bd304e8bc79a77 SIP/2.0. Record-Route: sip:1.2.3.4;lr=on;ftag=dd265b50;nat=yes. Via: SIP/2.0/UDP 1.2.3.4;branch=z9hG4bK01f4.9b50b5e3.0. Via: SIP/2.0/UDP 192.168.1.2:34856;received=9.8.7.6 ;branch=z9hG4bK-d8754z-bf19eb5a3306cc73-1---d8754z-;rport=34856. Max-Forwards: 69. Contact: sip:5512344@9.8.7.6:34856. To: "5512344"<sip:5512344@1.2.3.4 sip%3A5512344@1.2.3.4>. From: "David Villasmil"<sip:5512344@1.2.3.4 sip%3A5512344@1.2.3.4
;tag=dd265b50.
Call-ID: ZDNmNmYzZTIxNDg0Zjg0MWRiNTUxOTNlMzIwNDk5NTg.. CSeq: 2 INVITE. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. Content-Type: application/sdp. User-Agent: eyeBeam release 1014c stamp 46090. Content-Length: 387. P-hint: route(3)|setflag7,forcerport,fix_contact. P-hint: inbound->inbound . P-hint: Route[6]: mediaproxy . . v=0. o=- 9 2 IN IP4 192.168.1.2. s=CounterPath eyeBeam 1.5. c=IN IP4 1.2.3.4. t=0 0. m=audio 35052 RTP/AVP 0 97 98 8 18 101. a=alt:1 1 : 9FvoKhKL rd5+6GWR 192.168.1.2 42392. a=fmtp:18 annexb=no. a=fmtp:101 0-15. a=rtpmap:97 SPEEX/8000. a=rtpmap:98 iLBC/8000. a=rtpmap:18 G729/8000. a=rtpmap:101 telephone-event/8000. a=sendrecv. a=x-rtp-session-id:98B58B529501409082C4B9BB1259EF7A.
althoug on the "P-hint" I added that it should use mediaproxy's IP.
I wonder why...
On Fri, Jun 13, 2008 at 7:34 PM, David Villasmil < david.villasmil.work@gmail.com> wrote:
An update, if I call myself from behind nat, I get audio, but its passed directly... :S
I need it to go through the proxy..
Still, I see mediaproxy starting to listen for the rtps (I think).. 1.2.3.4=server 9.8.7.6=client
request ZDNmNmYzZTIxNDg0Zjg0MWRiNTUxOTNlMzIwNDk5NTg. 192.168.1.2:42392:audio 9.8.7.6 1.2.3.4 local 9.8.7.6 remote eyeBeam=20release=201014c=20stamp=2046090 info=from:5512344@1.2.3.4from%3A5512344@1.2.3.4 ,to:5512344@1.2.3.4 to%3A5512344@1.2.3.4,fromtag:dd265b50,totag: session ZDNmNmYzZTIxNDg0Zjg0MWRiNTUxOTNlMzIwNDk5NTg.: started. listening on 1.2.3.4:35052
jeez!
On Fri, Jun 13, 2008 at 7:29 PM, David Villasmil < david.villasmil.work@gmail.com> wrote:
SORRY TO HAVE REPLIED TO YOUR EMAIL!!!
I hate it when gmail does that!
Thanks,
It rather very easy, I need all calls to go through the media-proxy.I'm testing behind nat, server is on the internet. If I make a call from one UAC natted to another UAC natted, it works fine, rtps go to the proxy. If I call from behind NAT to echo test, I don't get any audio. rtps go directly to the echo test server's IP, but i don't get anything back. I'm doing something very wrong, I've modifed the script like a thousand time, and still...
On Fri, Jun 13, 2008 at 7:25 PM, David Villasmil < david.villasmil.work@gmail.com> wrote:
Thanks,
It rather very easy, I need all calls to go through the media-proxy.I'm testing behind nat, server is on the internet. If I make a call from one UAC natted to another UAC natted, it works fine, rtps go to the proxy. If I call from behind NAT to echo test, I don't get any audio. rtps go directly to the echo test server's IP, but i don't get anything back. I'm doing something very wrong, I've modifed the script like a thousand time, and still...
On Fri, Jun 13, 2008 at 7:11 PM, Raúl Alexis Betancor Santana < rabs@dimension-virtual.com> wrote:
El Viernes, 13 de Junio de 2008 17:47, David Villasmil escribió:
That was not my intention at all and I'm sorry you got it that way. I
did
take a look at my script and I thought I should do was eliminate all
tests
for nats and simply call use_media_proxy when an INVITE comes in, and
an
on_reply was hit. Also of course end_media_session() n a BYE or a
CANCEL...
But it is still not working, well it instruct my UAC to send rtps
directly
to the echo test ip... and this wasn't working.
And because I did not see anything work (I don't have much experience
with
media-proxy) I thought I'd ask here... my bad. ;-)
Of course I will keeo looking at this, I don't want anyone to do my
job...
;-)
Ok, so from that point on ... what it's your test scenario, paint it and we could guide you to the right point.
We do not have a crystal ball ;-)
-- Saludos.
Raúl Alexis Betancor Santana Dimensión Virtual S.L.
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Ok, I got it working (at least the echo test!)
And whats better, i KNOW what was wrong, I had it like this:
if (uri=~"^sip:301") { # ECHO TEST rewritehostport("blueface.ie"); route(6); # FIX NAT on INCOMING requests
t_on_failure("1"); if (!t_relay()) { sl_reply_error(); }; exit; };
When it should have been like this:
if (uri=~"^sip:301") { # ECHO TEST rewritehostport("blueface.ie"); route(6); route(1); exit; };
Why? That "magical" route(1) has the t_on_reply which fixes nat problems on replies to invites:
route[1] { # # -- 4 -- Forward request to target # # Forward statefully t_on_reply("1"); t_on_failure("1"); if (!t_relay()) { sl_reply_error(); }; exit; }
So there we go...
BUT!
Calls to myselt are still not working, audio is fine, but rtps aren't going to the mediaproxy
:S
On Fri, Jun 13, 2008 at 7:40 PM, David Villasmil < david.villasmil.work@gmail.com> wrote:
From an ngrep I just did when calling myself, openser NEVER offers the rtp proxy's IP... This is the INVITE back from openser...
U 1.2.3.4:5060 -> 9.8.7.6:34856 INVITE sip:5512344@9.8.7.6:34856;rinstance=62bd304e8bc79a77 SIP/2.0. Record-Route: sip:1.2.3.4;lr=on;ftag=dd265b50;nat=yes. Via: SIP/2.0/UDP 1.2.3.4;branch=z9hG4bK01f4.9b50b5e3.0. Via: SIP/2.0/UDP 192.168.1.2:34856;received=9.8.7.6 ;branch=z9hG4bK-d8754z-bf19eb5a3306cc73-1---d8754z-;rport=34856. Max-Forwards: 69. Contact: sip:5512344@9.8.7.6:34856. To: "5512344"<sip:5512344@1.2.3.4 sip%3A5512344@1.2.3.4>. From: "David Villasmil"<sip:5512344@1.2.3.4 sip%3A5512344@1.2.3.4
;tag=dd265b50.
Call-ID: ZDNmNmYzZTIxNDg0Zjg0MWRiNTUxOTNlMzIwNDk5NTg.. CSeq: 2 INVITE. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO. Content-Type: application/sdp. User-Agent: eyeBeam release 1014c stamp 46090. Content-Length: 387. P-hint: route(3)|setflag7,forcerport,fix_contact. P-hint: inbound->inbound . P-hint: Route[6]: mediaproxy . . v=0. o=- 9 2 IN IP4 192.168.1.2. s=CounterPath eyeBeam 1.5. c=IN IP4 1.2.3.4. t=0 0. m=audio 35052 RTP/AVP 0 97 98 8 18 101. a=alt:1 1 : 9FvoKhKL rd5+6GWR 192.168.1.2 42392. a=fmtp:18 annexb=no. a=fmtp:101 0-15. a=rtpmap:97 SPEEX/8000. a=rtpmap:98 iLBC/8000. a=rtpmap:18 G729/8000. a=rtpmap:101 telephone-event/8000. a=sendrecv. a=x-rtp-session-id:98B58B529501409082C4B9BB1259EF7A.
althoug on the "P-hint" I added that it should use mediaproxy's IP.
I wonder why...
On Fri, Jun 13, 2008 at 7:34 PM, David Villasmil < david.villasmil.work@gmail.com> wrote:
An update, if I call myself from behind nat, I get audio, but its passed directly... :S
I need it to go through the proxy..
Still, I see mediaproxy starting to listen for the rtps (I think).. 1.2.3.4=server 9.8.7.6=client
request ZDNmNmYzZTIxNDg0Zjg0MWRiNTUxOTNlMzIwNDk5NTg. 192.168.1.2:42392:audio 9.8.7.6 1.2.3.4 local 9.8.7.6 remote eyeBeam=20release=201014c=20stamp=2046090 info=from:5512344@1.2.3.4from%3A5512344@1.2.3.4 ,to:5512344@1.2.3.4 to%3A5512344@1.2.3.4,fromtag:dd265b50,totag: session ZDNmNmYzZTIxNDg0Zjg0MWRiNTUxOTNlMzIwNDk5NTg.: started. listening on 1.2.3.4:35052
jeez!
On Fri, Jun 13, 2008 at 7:29 PM, David Villasmil < david.villasmil.work@gmail.com> wrote:
SORRY TO HAVE REPLIED TO YOUR EMAIL!!!
I hate it when gmail does that!
Thanks,
It rather very easy, I need all calls to go through the media-proxy.I'm testing behind nat, server is on the internet. If I make a call from one UAC natted to another UAC natted, it works fine, rtps go to the proxy. If I call from behind NAT to echo test, I don't get any audio. rtps go directly to the echo test server's IP, but i don't get anything back. I'm doing something very wrong, I've modifed the script like a thousand time, and still...
On Fri, Jun 13, 2008 at 7:25 PM, David Villasmil < david.villasmil.work@gmail.com> wrote:
Thanks,
It rather very easy, I need all calls to go through themedia-proxy. I'm testing behind nat, server is on the internet. If I make a call from one UAC natted to another UAC natted, it works fine, rtps go to the proxy. If I call from behind NAT to echo test, I don't get any audio. rtps go directly to the echo test server's IP, but i don't get anything back. I'm doing something very wrong, I've modifed the script like a thousand time, and still...
On Fri, Jun 13, 2008 at 7:11 PM, Raúl Alexis Betancor Santana < rabs@dimension-virtual.com> wrote:
El Viernes, 13 de Junio de 2008 17:47, David Villasmil escribió:
That was not my intention at all and I'm sorry you got it that way. I
did
take a look at my script and I thought I should do was eliminate all
tests
for nats and simply call use_media_proxy when an INVITE comes in, and
an
on_reply was hit. Also of course end_media_session() n a BYE or a
CANCEL...
But it is still not working, well it instruct my UAC to send rtps
directly
to the echo test ip... and this wasn't working.
And because I did not see anything work (I don't have much experience
with
media-proxy) I thought I'd ask here... my bad. ;-)
Of course I will keeo looking at this, I don't want anyone to do my
job...
;-)
Ok, so from that point on ... what it's your test scenario, paint it and we could guide you to the right point.
We do not have a crystal ball ;-)
-- Saludos.
Raúl Alexis Betancor Santana Dimensión Virtual S.L.
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
El Viernes, 13 de Junio de 2008 18:59, David Villasmil escribió:
Ok, I got it working (at least the echo test!)
Congratulations ..
[...]
Why? That "magical" route(1) has the t_on_reply which fixes nat problems on replies to invites:
route[1] { # # -- 4 -- Forward request to target # # Forward statefully t_on_reply("1"); t_on_failure("1"); if (!t_relay()) { sl_reply_error(); }; exit; }
So there we go...
Jejeje, As I told you in a previous mail ... your "on_reply_route" was not correct, glad to see that you found the place where the error was.
BUT!
Calls to myselt are still not working, audio is fine, but rtps aren't going to the mediaproxy
Yes, again you have called use_media_proxy on a wrong place, take a look at the flow you follow for what you call "INBOUND->INBOUND" (I suggest you to call that route, "Local User to Local User", a clear name for what it does)
El Viernes, 13 de Junio de 2008 18:34, David Villasmil escribió:
An update, if I call myself from behind nat, I get audio, but its passed directly... :S
Well .. solving a specific nat case, when the 2 UAC are behind the same nat it's a funny challenge I promise you .. :-)
I need it to go through the proxy..
Still, I see mediaproxy starting to listen for the rtps (I think).. 1.2.3.4=server 9.8.7.6=client
request ZDNmNmYzZTIxNDg0Zjg0MWRiNTUxOTNlMzIwNDk5NTg. 192.168.1.2:42392:audio 9.8.7.6 1.2.3.4 local 9.8.7.6 remote eyeBeam=20release=201014c=20stamp=2046090 info=from:5512344@1.2.3.4from%3A5512344@1.2.3.4 ,to:5512344@1.2.3.4 to%3A5512344@1.2.3.4,fromtag:dd265b50,totag: session ZDNmNmYzZTIxNDg0Zjg0MWRiNTUxOTNlMzIwNDk5NTg.: started. listening on 1.2.3.4:35052
Thats only the request part ... then when on_reply_route you call use_media_proxy again, you should see a "lookup" statement, if not .. your UAC never will get the IP of the rtp-proxy, instead it will receive the unmodified reply from the destination UAC/UAS, so you will get one-way-audio.
El Viernes, 13 de Junio de 2008 18:29, David Villasmil escribió:
SORRY TO HAVE REPLIED TO YOUR EMAIL!!!
I hate it when gmail does that!
Yes, it's the problem of a pseudo-email client .. XDD
Thanks,
It rather very easy, I need all calls to go through the media-proxy.I'm testing behind nat, server is on the internet. If I make a call from one UAC natted to another UAC natted, it works fine, rtps go to the proxy.
Both UAC behind same NAT ?
If I call from behind NAT to echo test, I don't get any audio. rtps go directly to the echo test server's IP, but i don't get anything back. I'm doing something very wrong, I've modifed the script like a thousand time, and still...
You are not taking into account the reply, I'm sure
-
David Villasmil -
Raúl Alexis Betancor Santana