Removing a VIA line required by Telco.

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Removing a VIA line required by Telco.

David Gilbert-2
I've read a considerable number of posts.  It doesn't seem like anyone
has had to do this.

My Telco (no choice in this matter) doesn't "support" using proxies.  My
call must come from a specific IP (running the proxy) but it must not
contain VIA lines with anything other than the IP.  Currently, I have:

Asterisk (client) --IAX--> Asterisk (mine) --SIP--> OpenSIPS --SIP--> Telco

The Telco only wants to see the OpenSIPS IP in a single VIA header.
Asterisk puts in a VIA header, OpenSIPS adds one, call fails.

I've tried send('Telco'), but this fails as the VIA header has the
Asterisk(mine) IP.  I've tried remove_hf('Via'), but this seems to just
make a mess of things --- one big extended VIA header (and it fails).

So... I believe I need to remove the VIA header, but I can't find a way
that works...



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Removing a VIA line required by Telco.

Iñaki Baz Castillo
El Lunes, 20 de Abril de 2009, David Gilbert escribió:

> I've read a considerable number of posts.  It doesn't seem like anyone
> has had to do this.
>
> My Telco (no choice in this matter) doesn't "support" using proxies.  My
> call must come from a specific IP (running the proxy) but it must not
> contain VIA lines with anything other than the IP.  Currently, I have:
>
> Asterisk (client) --IAX--> Asterisk (mine) --SIP--> OpenSIPS --SIP--> Telco
>
> The Telco only wants to see the OpenSIPS IP in a single VIA header.
> Asterisk puts in a VIA header, OpenSIPS adds one, call fails.
>
> I've tried send('Telco'), but this fails as the VIA header has the
> Asterisk(mine) IP.  I've tried remove_hf('Via'), but this seems to just
> make a mess of things --- one big extended VIA header (and it fails).
>
> So... I believe I need to remove the VIA header, but I can't find a way
> that works...

Are you *completely* sure that your telco requires just one Via? I've already
listened to that stupid argument from a carrier, and this is a typical reply
when the carrier has no idea of what it's talking about.

A proxy cannot remove a second Via (if so, how to route responses from the
carrier back to the users???).

Your telco is a pain and IMHO the best you can do is changing of provider.



--
Iñaki Baz Castillo <[hidden email]>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Removing a VIA line required by Telco.

Jeff Pyle
In reply to this post by David Gilbert-2
David,

As I understand it, a SIP proxy needs the Via lines to properly route.  It
sounds like in your case you need to move Asterisk (or any B2BUA) forward in
your diagram to be the entity that communicates with your telco.  No Via
lines, no proxy.  A B2BUA, however, by design hides the topology of the
network behind it.  No extra Via lines.  Other SBC-class products do that as
well but probably aren't worth the potential cost.

Or, find a telco that sucks less.  Unfortunately that doesn't sound like a
possibility.


- Jeff



On 4/20/09 3:25 PM, "David Gilbert" <[hidden email]> wrote:

> I've read a considerable number of posts.  It doesn't seem like anyone
> has had to do this.
>
> My Telco (no choice in this matter) doesn't "support" using proxies.  My
> call must come from a specific IP (running the proxy) but it must not
> contain VIA lines with anything other than the IP.  Currently, I have:
>
> Asterisk (client) --IAX--> Asterisk (mine) --SIP--> OpenSIPS --SIP--> Telco
>
> The Telco only wants to see the OpenSIPS IP in a single VIA header.
> Asterisk puts in a VIA header, OpenSIPS adds one, call fails.
>
> I've tried send('Telco'), but this fails as the VIA header has the
> Asterisk(mine) IP.  I've tried remove_hf('Via'), but this seems to just
> make a mess of things --- one big extended VIA header (and it fails).
>
> So... I believe I need to remove the VIA header, but I can't find a way
> that works...
>
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Removing a VIA line required by Telco.

David Gilbert-2
Jeff Pyle wrote:

> David,
>
> As I understand it, a SIP proxy needs the Via lines to properly route.  It
> sounds like in your case you need to move Asterisk (or any B2BUA) forward in
> your diagram to be the entity that communicates with your telco.  No Via
> lines, no proxy.  A B2BUA, however, by design hides the topology of the
> network behind it.  No extra Via lines.  Other SBC-class products do that as
> well but probably aren't worth the potential cost.
>
> Or, find a telco that sucks less.  Unfortunately that doesn't sound like a
> possibility.
>
>  
That's our current fallback position.  The issue is complex.  We're
using the OpenSIPS proxy for two reasons: a) reliability (it's in a
configuration with CARP and other fancy stuff)... and b) to divide
billing.  The issue is that we "receive" multiple PRI with different
parameters from the Telco and they require that be on a different IP for
each one.  OpenSIPS makes that fairly easy.  Asterisk will only talk to
one IP per installation (requiring multiple machines or virtualization).

Can't OpenSIPS be smart and remember the other VIA line as part of the
"state" it keeps?  I know that the solution we replaced (run by another
company) used a switch that didn't handle the media and yet still
managed to deliver only one VIA line to this telco.


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Removing a VIA line required by Telco.

Jeff Pyle
David,

Opensips is a proxy.  A proxy's role is dictated by RFC3261.  It's fast,
lightweight, very scalable, and has some very nice features you're already
taking advantages of.  But, it's still only a proxy.  A proxy needs Via
lines.  Period.  To otherwise manipulate the traffic or keep state in other
ways turns it into something it's not.

Iñaki's right.  You need to find a new telco.  The fact they don't permit
proxies illustrates they really don't understand what they're getting into
with SIP, and sooner or later you're going to encounter something they can't
fix.  Or, if they do know what they're doing, their business model is
certainly not friendly towards your goals.  But that's a discussion for
another place and time.

One fact remains -- you will not be able to use any proxy as you're looking
to with your current telco.


- Jeff



On 4/20/09 3:48 PM, "David Gilbert" <[hidden email]> wrote:

> Jeff Pyle wrote:
>> David,
>>
>> As I understand it, a SIP proxy needs the Via lines to properly route.  It
>> sounds like in your case you need to move Asterisk (or any B2BUA) forward in
>> your diagram to be the entity that communicates with your telco.  No Via
>> lines, no proxy.  A B2BUA, however, by design hides the topology of the
>> network behind it.  No extra Via lines.  Other SBC-class products do that as
>> well but probably aren't worth the potential cost.
>>
>> Or, find a telco that sucks less.  Unfortunately that doesn't sound like a
>> possibility.
>>
>>  
> That's our current fallback position.  The issue is complex.  We're
> using the OpenSIPS proxy for two reasons: a) reliability (it's in a
> configuration with CARP and other fancy stuff)... and b) to divide
> billing.  The issue is that we "receive" multiple PRI with different
> parameters from the Telco and they require that be on a different IP for
> each one.  OpenSIPS makes that fairly easy.  Asterisk will only talk to
> one IP per installation (requiring multiple machines or virtualization).
>
> Can't OpenSIPS be smart and remember the other VIA line as part of the
> "state" it keeps?  I know that the solution we replaced (run by another
> company) used a switch that didn't handle the media and yet still
> managed to deliver only one VIA line to this telco.
>


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Removing a VIA line required by Telco.

Iñaki Baz Castillo
In reply to this post by David Gilbert-2
El Lunes, 20 de Abril de 2009, David Gilbert escribió:

> Can't OpenSIPS be smart and remember the other VIA line as part of the
> "state" it keeps?

This would require storing the second (and others) Via headers in memory and
appending them back in the responses. Obviously OpenSIPS (as any proxy in the
world) is not designed for such a mess. Why would a proxy behave as anything
but a proxy? It doesn't make sense.


> I know that the solution we replaced (run by another
> company) used a switch that didn't handle the media and yet still
> managed to deliver only one VIA line to this telco.

Then that is not a proxy, but a B2BUA.


PD: Please, say something unpleasant to your carrier in my name.




--
Iñaki Baz Castillo <[hidden email]>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Removing a VIA line required by Telco.

David Gilbert-2
In reply to this post by Jeff Pyle
Jeff Pyle wrote:
> David,
>
> Opensips is a proxy.  A proxy's role is dictated by RFC3261.  It's fast,
> lightweight, very scalable, and has some very nice features you're already
> taking advantages of.  But, it's still only a proxy.  A proxy needs Via
> lines.  Period.  To otherwise manipulate the traffic or keep state in other
> ways turns it into something it's not.
>  
OK.  I understand.  I was looking for a hack.  I was hoping to keep the
current setup, but I can munge an asterisk solution for it.
> Iñaki's right.  You need to find a new telco.  The fact they don't permit
> proxies illustrates they really don't understand what they're getting into
> with SIP, and sooner or later you're going to encounter something they can't
> fix.  Or, if they do know what they're doing, their business model is
> certainly not friendly towards your goals.  But that's a discussion for
> another place and time.
>  
Well... what telco to use is a business decision.  In the end, there is
a technical solution (however suboptimal), so the technical can't claim
to trump the business.  In the end, our systems run lean enough that no
combination of requirements from the telco could make our systems more
expensive than the difference between this telco and the next more
expensive.  Sigh.
> One fact remains -- you will not be able to use any proxy as you're looking
> to with your current telco
Hrm.  But a cool hack would be nice.


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Removing a VIA line required by Telco.

Iñaki Baz Castillo
In reply to this post by Jeff Pyle
El Lunes, 20 de Abril de 2009, Jeff Pyle escribió:

> Iñaki's right.  You need to find a new telco.  The fact they don't permit
> proxies illustrates they really don't understand what they're getting into
> with SIP, and sooner or later you're going to encounter something they
> can't fix.  Or, if they do know what they're doing

Under my experience with a few carriers, they seem to be mostly legacy telcos
entering in SIP world with no enouch knowledge. In my opinion, carrier
employees with long expertise in SS7 and so, are "forced" to learn SIP in a
very short period of time. This is just because the carrier has bought some
SIP softswitch to a big vendor, and wants to use it to offer IP connectivity
for clients.

As a result, we get a telco with no real knowledge in SIP. Any report from
clients are directly forwarded to the vendor (they have nothing to do with a
well reported issue about SIP).

Basically the carrier has a black box and doesn't understand it. It the black
box fails, then the clients have a big problem. This is, at least, my
experience with "cool" carriers offering SIP.

Regards.


--
Iñaki Baz Castillo <[hidden email]>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Removing a VIA line required by Telco.

Julien Chavanton
Re: [OpenSIPS-Users] Removing a VIA line required by Telco.
Hi, I want to do prefix routing, registration and support NAT
 
Should I use the following : carrierroute, nathelper and mediaproxy
Are they still recommended or any of them is obsolete ?
 
 
I have read that nat_traversal can replace nathelper, will it take care of mediaproxy ?
 
 
Where can I find updated sample config, do I still have to look there ?
 

 

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

prefix routing, registration and NAT / suggested module

Julien Chavanton
Re: [OpenSIPS-Users] Removing a VIA line required by Telco.
 
Hi, I want to do prefix routing, registration and support NAT
 
Should I use the following : carrierroute, nathelper and mediaproxy
Are they still recommended or any of them is obsolete ?
 
 
I have read that nat_traversal can replace nathelper, will it take care of mediaproxy ?
 
 
Where can I find updated sample config, do I still have to look there ?
 

 

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Removing a VIA line required by Telco.

Iñaki Baz Castillo
In reply to this post by Julien Chavanton
El Lunes, 20 de Abril de 2009, Julien Chavanton escribió:
> Hi, I want to do prefix routing, registration and support NAT

Please, if you want to ask a *new* question in the maillist, create a *new*
mail instead of pressing "Reply" over any other mail.

--
Iñaki Baz Castillo <[hidden email]>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Removing a VIA line required by Telco.

Bogdan-Andrei Iancu
In reply to this post by Iñaki Baz Castillo
Hi Iñaki,

Iñaki Baz Castillo wrote:

> El Lunes, 20 de Abril de 2009, David Gilbert escribió:
>
>  
>> Can't OpenSIPS be smart and remember the other VIA line as part of the
>> "state" it keeps?
>>    
>
> This would require storing the second (and others) Via headers in memory and
> appending them back in the responses. Obviously OpenSIPS (as any proxy in the
> world) is not designed for such a mess. Why would a proxy behave as anything
> but a proxy? It doesn't make sense.
>  
Actually, theoretically speaking, it can do that - as being transaction
statefull and VIA being relevant at transaction level, openSIPS could
strip all received VIA , store them into transaction and restore them in
replies when sending out.
Actually, IMHO, VIA stack is pointless in transactions statefull proxies
.....because a proxy keeps in transaction all information required to
route back the replies...no need for VIA..

With some hacks in TM, you could do that, but it is a bit non-sense from
RFC pov.

Regards,
Bogdan

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Removing a VIA line required by Telco.

Bogdan-Andrei Iancu
In reply to this post by David Gilbert-2
Hi Davis,

David Gilbert wrote:

> Jeff Pyle wrote:
>  
>> David,
>>
>> Opensips is a proxy.  A proxy's role is dictated by RFC3261.  It's fast,
>> lightweight, very scalable, and has some very nice features you're already
>> taking advantages of.  But, it's still only a proxy.  A proxy needs Via
>> lines.  Period.  To otherwise manipulate the traffic or keep state in other
>> ways turns it into something it's not.
>>  
>>    
> OK.  I understand.  I was looking for a hack.  I was hoping to keep the
> current setup, but I can munge an asterisk solution for it.
>  
hacks can be done actually (see my previous email on the thread)..the
question is how "natural" such a hack is :P...I mean the RFC has its job
in keeping all SIP guys align to a standard.

Regards,
Bogdan

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: prefix routing, registration and NAT / suggested module

Bogdan-Andrei Iancu
In reply to this post by Julien Chavanton
Hi Julien,

prefix routing - see drouting module

NAT support - nathelper or mediaproxy modules.

Regards,
Bogdan

Julien Chavanton wrote:

>  
> Hi, I want to do prefix routing, registration and support NAT
>  
> Should I use the following : carrierroute, nathelper and mediaproxy
> Are they still recommended or any of them is obsolete ?
>  
>  
> I have read that nat_traversal can replace nathelper, will it take
> care of mediaproxy ?
>  
>  
> Where can I find updated sample config, do I still have to look there ?
> http://openser.svn.sourceforge.net/viewvc/openser/trunk/examples/
>  
>
>  
> ------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>  


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Removing a VIA line required by Telco.

David Gilbert-2
In reply to this post by Bogdan-Andrei Iancu
Bogdan-Andrei Iancu wrote:

> Hi Davis,
>
> David Gilbert wrote:
>> Jeff Pyle wrote:
>>  
>>> David,
>>>
>>> Opensips is a proxy.  A proxy's role is dictated by RFC3261.  It's
>>> fast,
>>> lightweight, very scalable, and has some very nice features you're
>>> already
>>> taking advantages of.  But, it's still only a proxy.  A proxy needs Via
>>> lines.  Period.  To otherwise manipulate the traffic or keep state
>>> in other
>>> ways turns it into something it's not.
>>>      
>> OK.  I understand.  I was looking for a hack.  I was hoping to keep
>> the current setup, but I can munge an asterisk solution for it.
>>  
> hacks can be done actually (see my previous email on the thread)..the
> question is how "natural" such a hack is :P...I mean the RFC has its
> job in keeping all SIP guys align to a standard.
>
Well... it looks like at this point, we're going to juggle things so
that the bidirectional PRI group attaches directly to the Asterisk box
and the incoming only uses the proxy.  This, for now, fixes things.


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Problem RTP-proxy

Vandeweyer, Eric
In reply to this post by Bogdan-Andrei Iancu
 
Hi all,

I have opensips 1.5.1 running and signaling work fine (as far as I know) but I've this problem to get my RTP traffic
Via the RTP-proxy. Can anyone help me out here
Many thanks

Eric


########################################################################
# Routing
########################################################################
route
{
        if (msg:len > 2048)
        {
                sl_send_reply("513", "Message Too Big");
                exit;
        };
        if (!mf_process_maxfwd_header("10"))
        {
                sl_send_reply("483", "Too Many Hops");
                exit;
        };
        if (!method=="REGISTER")
        {
                if(nat_uac_test("19"))
                {
                       record_route("nat=yes");
                }
                else
                {
                       record_route();
                };
        };
        if (loose_route())
        {
                append_hf("P-hint: loose_route \r\n");
                if (nat_uac_test ("19") || search("^Route:.*;nat=yes"))
                {
                       setflag(6);
                       fix_nated_contact();
                       force_rport();
                };
                if (method=="INVITE")
                {
                        sl_send_reply("403", "No Re-INVITES Allowed");
                        exit;
                }
                if (method=="BYE")
                {
                       unforce_rtp_proxy();
                       t_relay();
                       exit;
                }
                route(1);
                exit;
        };
        if (method=="CANCEL")
        {
                if (t_check_trans())
                {
                       unforce_rtp_proxy();
                }
                t_relay();
                exit;
        };
        t_check_trans();
        if (method=="REGISTER")
        {
                route(2);
                exit;
        };
        if (!method=="REGISTER")
        {
                route(3);
                exit;
        };
}


########################################################################
# SENDING Routine
########################################################################
route[1]
{
        t_on_reply("1");
        if (!t_relay())
        {
                sl_reply_error();
                if (method=="INVITE" || method=="ACK")
                {
                        unforce_rtp_proxy();
                };
        };
        exit;
}


########################################################################
# REGISTER Routine
########################################################################
route[2]
{
        if (is_from_local())
        {
                if (!search("^Contact:[ ]*\*") && nat_uac_test("7"))
                {
                         setflag(6);
                         fix_nated_register();
                         force_rport();
                };
                if (!www_authorize("", "subscriber"))
                {
                         www_challenge("", "1");
                         exit;
                };
                if (!check_to())
                {
                         sl_send_reply("403", "Forbidden, Spoofed To-URI Detected");
                         exit;
                };
                save("location");
                if (!lookup("location"))
                {
                        sl_send_reply("404", "Not Found");
                        exit;
                };
                consume_credentials();
                exit;
         }
         else
         {
                sl_send_reply("403", "Forbidden, Not Allowed to Register");
                exit;
         };
}


########################################################################
# Non-REGISTER Routine
########################################################################
route[3]
{
        if (nat_uac_test("19"))
        {
                setflag(7);
                fix_nated_contact();
                force_rport();
        };
        if (is_from_local())
        {
                if (!proxy_authorize("", "subscriber"))
                {
                         proxy_challenge("", "1");
                         exit;
                };
                if (!check_from())
                {
                         sl_send_reply("403", "Forbidden, No From-URI Detected");
                         exit;
                };
                consume_credentials();
                lookup("aliases");
                if (is_uri_host_local())
                {
                          append_hf("P-hint: inbound -> inbound \r\n");
                          if (!lookup("location"))
                       {
                                     sl_send_reply("404", "User Offline");
                                     exit;
                          };
                          if (has_body("application/sdp"))
                          {
                                     force_rtp_proxy();
                          };
                          route(1);
                          exit;
                }
                else
                {
                          append_hf("P-hint: inbound -> outbound \r\n");
                          if (has_body("application/sdp"))
                          {
                                     force_rtp_proxy();
                          };
                          route(1);
                          exit;
                }
        }
        else
        {
                lookup("aliases");
                if (is_uri_host_local())
                {
                          append_hf("P-hint: outbound -> inbound \r\n");
                          if (!lookup("location"))
                       {
                                     sl_send_reply("404", "User Offline");
                                     exit;
                          };
                          if (has_body("application/sdp"))
                          {
                                     force_rtp_proxy();
                          };
                          route(1);
                          exit;
                }
                else
                {
                          append_hf("P-hint: outbound -> outbound \r\n");
                          sl_send_reply("403", "Forbidden, No Transit Allowed");
                          exit;
                };
        };
}


########################################################################
# Reply route 'base-nat-reply'
########################################################################
onreply_route[1]
{
         append_hf("P-hint: onreply route \r\n");
         if (nat_uac_test("19"))
         {
                append_hf("P-hint: fix contact \r\n");
                fix_nated_contact();
                force_rport();
         };
         if (has_body("application/sdp"))
         {
                append_hf("P-hint: SDP \r\n");
                force_rtp_proxy();
         };
         exit;
}



NV Verizon Belgium Luxembourg SA - Siège social: Rue de la Science 37, 1040 Bruxelles, Belgique - Siège principal: Rue de la Science 37, 1040 Bruxelles, Belgique - Registre des Personnes Morales: RPM Bruxelles 0452.182.326

NV Verizon Belgium Luxembourg SA - Maatschappelijke zetel: Wetenschapsstraat 37, 1040 Brussel, België - Hoofdzetel: Wetenschapsstraat 37, 1040 Brussel, België -Rechtspersonenregister: RPR Brussel 0452.182.326

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Problem RTP-proxy

Iñaki Baz Castillo
Please, don't send the mails directly to the developers, send it just
to the maillist.


2009/5/26 Vandeweyer, Eric <[hidden email]>:
>
> Hi all,
>
> I have opensips 1.5.1 running and signaling work fine (as far as I know) but I've this problem to get my RTP traffic
> Via the RTP-proxy. Can anyone help me out here

You don't explain, at all, which problem you have, you just show your
whole config file. Do you expect people here examinating your
configuration trying to guess some error?

--
Iñaki Baz Castillo
<[hidden email]>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Problem RTP-proxy

Vandeweyer, Eric
Well,

The problem is (like I stated before) that I sometimes get a RTPstream on the RTP-proxy and sometimes not,
with the same config file and same devices ...
Traces are identical (beside the audio ports differ per call attempt)
Phones are behind NAT and routers are sip-aware
 

-----Original Message-----
From: Iñaki Baz Castillo [mailto:[hidden email]]
Sent: 26 May 2009 16:19
To: Vandeweyer, Eric
Cc: [hidden email]
Subject: Re: [OpenSIPS-Users] Problem RTP-proxy

Please, don't send the mails directly to the developers, send it just to the maillist.


2009/5/26 Vandeweyer, Eric <[hidden email]>:
>
> Hi all,
>
> I have opensips 1.5.1 running and signaling work fine (as far as I
> know) but I've this problem to get my RTP traffic Via the RTP-proxy.
> Can anyone help me out here

You don't explain, at all, which problem you have, you just show your whole config file. Do you expect people here examinating your configuration trying to guess some error?

--
Iñaki Baz Castillo
<[hidden email]>



NV Verizon Belgium Luxembourg SA - Siège social: Rue de la Science 37, 1040 Bruxelles, Belgique - Siège principal: Rue de la Science 37, 1040 Bruxelles, Belgique - Registre des Personnes Morales: RPM Bruxelles 0452.182.326

NV Verizon Belgium Luxembourg SA - Maatschappelijke zetel: Wetenschapsstraat 37, 1040 Brussel, België - Hoofdzetel: Wetenschapsstraat 37, 1040 Brussel, België -Rechtspersonenregister: RPR Brussel 0452.182.326

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Problem RTP-proxy

Adrian Georgescu
Hi Eric,

Can you turn off the SIP ALG support in the routers to see if the problem still happens?

Adrian


On May 26, 2009, at 4:36 PM, Vandeweyer, Eric wrote:

Well,

The problem is (like I stated before) that I sometimes get a RTPstream on the RTP-proxy and sometimes not,
with the same config file and same devices ...
Traces are identical (beside the audio ports differ per call attempt)
Phones are behind NAT and routers are sip-aware


-----Original Message-----
From: Iñaki Baz Castillo [[hidden email]]
Sent: 26 May 2009 16:19
To: Vandeweyer, Eric
Cc: [hidden email]
Subject: Re: [OpenSIPS-Users] Problem RTP-proxy

Please, don't send the mails directly to the developers, send it just to the maillist.


2009/5/26 Vandeweyer, Eric <[hidden email]>:

Hi all,

I have opensips 1.5.1 running and signaling work fine (as far as I
know) but I've this problem to get my RTP traffic Via the RTP-proxy.
Can anyone help me out here

You don't explain, at all, which problem you have, you just show your whole config file. Do you expect people here examinating your configuration trying to guess some error?

--
Iñaki Baz Castillo
<[hidden email]>



NV Verizon Belgium Luxembourg SA - Siège social: Rue de la Science 37, 1040 Bruxelles, Belgique - Siège principal: Rue de la Science 37, 1040 Bruxelles, Belgique - Registre des Personnes Morales: RPM Bruxelles 0452.182.326

NV Verizon Belgium Luxembourg SA - Maatschappelijke zetel: Wetenschapsstraat 37, 1040 Brussel, België - Hoofdzetel: Wetenschapsstraat 37, 1040 Brussel, België -Rechtspersonenregister: RPR Brussel 0452.182.326

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Problem RTP-proxy

Vandeweyer, Eric
When Sip awareness turned off ... problem still persists
sometimes I get audio though and sometimes not ... I also don't see the RTPstream arrive at the RTP-proxy (when it doesn't work)


From: Adrian Georgescu [mailto:[hidden email]]
Sent: 26 May 2009 16:40
To: Vandeweyer, Eric
Cc: Iñaki Baz Castillo; [hidden email]
Subject: Re: [OpenSIPS-Users] Problem RTP-proxy

Hi Eric,

Can you turn off the SIP ALG support in the routers to see if the problem still happens?

Adrian


On May 26, 2009, at 4:36 PM, Vandeweyer, Eric wrote:

Well,

The problem is (like I stated before) that I sometimes get a RTPstream on the RTP-proxy and sometimes not,
with the same config file and same devices ...
Traces are identical (beside the audio ports differ per call attempt)
Phones are behind NAT and routers are sip-aware


-----Original Message-----
From: Iñaki Baz Castillo [[hidden email]]
Sent: 26 May 2009 16:19
To: Vandeweyer, Eric
Cc: [hidden email]
Subject: Re: [OpenSIPS-Users] Problem RTP-proxy

Please, don't send the mails directly to the developers, send it just to the maillist.


2009/5/26 Vandeweyer, Eric <[hidden email]>:

Hi all,

I have opensips 1.5.1 running and signaling work fine (as far as I
know) but I've this problem to get my RTP traffic Via the RTP-proxy.
Can anyone help me out here

You don't explain, at all, which problem you have, you just show your whole config file. Do you expect people here examinating your configuration trying to guess some error?

--
Iñaki Baz Castillo
<[hidden email]>



NV Verizon Belgium Luxembourg SA - Siège social: Rue de la Science 37, 1040 Bruxelles, Belgique - Siège principal: Rue de la Science 37, 1040 Bruxelles, Belgique - Registre des Personnes Morales: RPM Bruxelles 0452.182.326

NV Verizon Belgium Luxembourg SA - Maatschappelijke zetel: Wetenschapsstraat 37, 1040 Brussel, België - Hoofdzetel: Wetenschapsstraat 37, 1040 Brussel, België -Rechtspersonenregister: RPR Brussel 0452.182.326

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

NV Verizon Belgium Luxembourg SA - Siège social: Rue de la Science 37, 1040 Bruxelles, Belgique - Siège principal: Rue de la Science 37, 1040 Bruxelles, Belgique - Registre des Personnes Morales: RPM Bruxelles 0452.182.326

NV Verizon Belgium Luxembourg SA - Maatschappelijke zetel: Wetenschapsstraat 37, 1040 Brussel , België - Hoofdzetel: Wetenschapsstraat 37, 1040 Brussel, België -Rechtspersonenregister: RPR Brussel 0452.182.326


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
12