Transport identification

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

Transport identification

Daniel Goepp-2
We are doing some interop work with another switch, and it is having some trouble with TCP vs UDP.  Because of the packet size for these specific calls we need to do them TCP.  However the record-route in our 200 OK has no transport set, and according to the RFC, no transport for SIP default is UDP.  This means that all our signaling is TCP, until we get an ACK back from this box, and it then is UDP, but too big and breaks the call.  I have found the add_rr_param, so I could do a add_rr_param(";transport=tcp"), but I only want to do this for calls that are currently using TCP.  I looked for a function to test the protocol used, but couldn't find one.  Anyone know what it is?  Also, it would seem the appropriate thing for OpenSIPS to do would be to automatically put the ;transport=xxx in the RR based on the current protocol of the dialog.  Thoughts on that?

Thanks

-dg

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

Re: Transport identification

Daniel Goepp-2
Oh man...then TWO seconds after sending this, I find:

if(proto==TCP)
{
log("the SIP message was received over TCP\n");
};

However my other comment of perhaps this should be handled automatically by OpenSIPS still stands :)

Thanks

-dg


On Fri, Mar 5, 2010 at 9:18 AM, Daniel Goepp <[hidden email]> wrote:
We are doing some interop work with another switch, and it is having some trouble with TCP vs UDP.  Because of the packet size for these specific calls we need to do them TCP.  However the record-route in our 200 OK has no transport set, and according to the RFC, no transport for SIP default is UDP.  This means that all our signaling is TCP, until we get an ACK back from this box, and it then is UDP, but too big and breaks the call.  I have found the add_rr_param, so I could do a add_rr_param(";transport=tcp"), but I only want to do this for calls that are currently using TCP.  I looked for a function to test the protocol used, but couldn't find one.  Anyone know what it is?  Also, it would seem the appropriate thing for OpenSIPS to do would be to automatically put the ;transport=xxx in the RR based on the current protocol of the dialog.  Thoughts on that?

Thanks

-dg


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

Re: Transport identification

Bogdan-Andrei Iancu
Hi Daniel,

But record_route() will automatically do double routing if a proto / ip
/ port change is detected between the inbound and outbound interface.  
You need to have the "double_rr" enabled (which is by default).

Could you check how the RR added by OpenSIPS looks like ?

Regards,
Bogdan

Daniel Goepp wrote:

> Oh man...then TWO seconds after sending this, I find:
>
> if(proto==TCP)
> {
> log("the SIP message was received over TCP\n");
> };
>
> However my other comment of perhaps this should be handled
> automatically by OpenSIPS still stands :)
>
> Thanks
>
> -dg
>
>
> On Fri, Mar 5, 2010 at 9:18 AM, Daniel Goepp <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     We are doing some interop work with another switch, and it is
>     having some trouble with TCP vs UDP.  Because of the packet size
>     for these specific calls we need to do them TCP.  However the
>     record-route in our 200 OK has no transport set, and according to
>     the RFC, no transport for SIP default is UDP.  This means that all
>     our signaling is TCP, until we get an ACK back from this box, and
>     it then is UDP, but too big and breaks the call.  I have found the
>     add_rr_param, so I could do a add_rr_param(";transport=tcp"), but
>     I only want to do this for calls that are currently using TCP.  I
>     looked for a function to test the protocol used, but couldn't find
>     one.  Anyone know what it is?  Also, it would seem the appropriate
>     thing for OpenSIPS to do would be to automatically put the
>     ;transport=xxx in the RR based on the current protocol of the
>     dialog.  Thoughts on that?
>
>     Thanks
>
>     -dg
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>  


--
Bogdan-Andrei Iancu
www.voice-system.ro


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

Re: Transport identification

Daniel Goepp-2
We actually use record_route_preset not record_route, I would have presumed the logic would be the same for both though regarding this.  I do not explicitly set double_rr, so it should be the default of on as you point out.  My work around of testing and setting manually does appear to be working now.  I also wonder about what the default protocol / priority would be to use on a call.  For example a SIP URI call where you don't know if the called party is UDP or TCP, it appears to default to UDP.  However if the endpoint I'm calling from is using TCP, I would prefer to have the outbound attempt first try TCP, then go to UDP if it fails.  The system we are sending calls to actually just prefers TCP all the time, and then fails over to UDP if it can't complete the call.  We are still experimenting with this, but due to the large packet sizes we are seeing with video, TCP is working better for us in most situations.

Thanks

-dg


On Fri, Mar 5, 2010 at 11:50 AM, Bogdan-Andrei Iancu <[hidden email]> wrote:
Hi Daniel,

But record_route() will automatically do double routing if a proto / ip
/ port change is detected between the inbound and outbound interface.
You need to have the "double_rr" enabled (which is by default).

Could you check how the RR added by OpenSIPS looks like ?

Regards,
Bogdan

Daniel Goepp wrote:
> Oh man...then TWO seconds after sending this, I find:
>
> if(proto==TCP)
> {
> log("the SIP message was received over TCP\n");
> };
>
> However my other comment of perhaps this should be handled
> automatically by OpenSIPS still stands :)
>
> Thanks
>
> -dg
>
>
> On Fri, Mar 5, 2010 at 9:18 AM, Daniel Goepp <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     We are doing some interop work with another switch, and it is
>     having some trouble with TCP vs UDP.  Because of the packet size
>     for these specific calls we need to do them TCP.  However the
>     record-route in our 200 OK has no transport set, and according to
>     the RFC, no transport for SIP default is UDP.  This means that all
>     our signaling is TCP, until we get an ACK back from this box, and
>     it then is UDP, but too big and breaks the call.  I have found the
>     add_rr_param, so I could do a add_rr_param(";transport=tcp"), but
>     I only want to do this for calls that are currently using TCP.  I
>     looked for a function to test the protocol used, but couldn't find
>     one.  Anyone know what it is?  Also, it would seem the appropriate
>     thing for OpenSIPS to do would be to automatically put the
>     ;transport=xxx in the RR based on the current protocol of the
>     dialog.  Thoughts on that?
>
>     Thanks
>
>     -dg
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>


--
Bogdan-Andrei Iancu
www.voice-system.ro


_______________________________________________
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: Transport identification

Iñaki Baz Castillo
El Viernes, 5 de Marzo de 2010, Daniel Goepp escribió:
> However if the endpoint I'm calling from is using TCP, I would prefer to
>  have the outbound attempt first try TCP, then go to UDP if it fails.  The
>  system we are sending calls to actually just prefers TCP all the time, and
>  then fails over to UDP if it can't complete the call.  We are still
>  experimenting with this, but due to the large packet sizes we are seeing
>  with video, TCP is working better for us in most situations.

Even if the request come via TCP it will be setn via UDP unless the RURI
contains ";transport=TCP". You can also append such parameter in the RURI when
processing the request in OpenSIPS, so it would be sent via TCP.
This is how SIP works.


--
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: Transport identification

Bogdan-Andrei Iancu
In reply to this post by Daniel Goepp-2
Daniel Goepp wrote:
> We actually use record_route_preset not record_route, I would have
> presumed the logic would be the same for both though regarding this.
rr_preset() is for setting your own rr header, overriding the automatic
building of  the headers.  So you have to red pill - let opensips to do
the job - or the blue pill - you do you yourself, but do it from A to Z

> I do not explicitly set double_rr, so it should be the default of on
> as you point out.  My work around of testing and setting manually does
> appear to be working now.  I also wonder about what the default
> protocol / priority would be to use on a call.  For example a SIP URI
> call where you don't know if the called party is UDP or TCP, it
> appears to default to UDP.
if there is not protocol indication (like SIPS scheme or transport
param), it is UDP - that is what RFC3261 says
> However if the endpoint I'm calling from is using TCP, I would prefer
> to have the outbound attempt first try TCP, then go to UDP if it fails.
if you receive the call over TCP and the caller requests TCP for
delivery, you should have the transport=TCP param in the received RURI.
The presence of this param will force opensips to use the indicated
transport for sending the call out.
Se simple fact you receive the call over TCP does not mean anything -
what is important is what protocol is required via RURI.

Regards,
Bogdan

> The system we are sending calls to actually just prefers TCP all the
> time, and then fails over to UDP if it can't complete the call.  We
> are still experimenting with this, but due to the large packet sizes
> we are seeing with video, TCP is working better for us in most situations.
>
> Thanks
>
> -dg
>
>
> On Fri, Mar 5, 2010 at 11:50 AM, Bogdan-Andrei Iancu
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     Hi Daniel,
>
>     But record_route() will automatically do double routing if a proto
>     / ip
>     / port change is detected between the inbound and outbound interface.
>     You need to have the "double_rr" enabled (which is by default).
>
>     Could you check how the RR added by OpenSIPS looks like ?
>
>     Regards,
>     Bogdan
>
>     Daniel Goepp wrote:
>     > Oh man...then TWO seconds after sending this, I find:
>     >
>     > if(proto==TCP)
>     > {
>     > log("the SIP message was received over TCP\n");
>     > };
>     >
>     > However my other comment of perhaps this should be handled
>     > automatically by OpenSIPS still stands :)
>     >
>     > Thanks
>     >
>     > -dg
>     >
>     >
>     > On Fri, Mar 5, 2010 at 9:18 AM, Daniel Goepp <[hidden email]
>     <mailto:[hidden email]>
>     > <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>     >
>     >     We are doing some interop work with another switch, and it is
>     >     having some trouble with TCP vs UDP.  Because of the packet size
>     >     for these specific calls we need to do them TCP.  However the
>     >     record-route in our 200 OK has no transport set, and
>     according to
>     >     the RFC, no transport for SIP default is UDP.  This means
>     that all
>     >     our signaling is TCP, until we get an ACK back from this
>     box, and
>     >     it then is UDP, but too big and breaks the call.  I have
>     found the
>     >     add_rr_param, so I could do a
>     add_rr_param(";transport=tcp"), but
>     >     I only want to do this for calls that are currently using
>     TCP.  I
>     >     looked for a function to test the protocol used, but
>     couldn't find
>     >     one.  Anyone know what it is?  Also, it would seem the
>     appropriate
>     >     thing for OpenSIPS to do would be to automatically put the
>     >     ;transport=xxx in the RR based on the current protocol of the
>     >     dialog.  Thoughts on that?
>     >
>     >     Thanks
>     >
>     >     -dg
>     >
>     >
>     >
>     ------------------------------------------------------------------------
>     >
>     > _______________________________________________
>     > Users mailing list
>     > [hidden email] <mailto:[hidden email]>
>     > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>     >
>
>
>     --
>     Bogdan-Andrei Iancu
>     www.voice-system.ro <http://www.voice-system.ro>
>
>
>     _______________________________________________
>     Users mailing list
>     [hidden email] <mailto:[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
>  


--
Bogdan-Andrei Iancu
www.voice-system.ro


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

Re: Transport identification

Daniel Goepp-2
Thanks for the info.  Looks like I'm dealing with two external problems then.  A device that is not doing what it should by specifying the transport, and this other server we are communicating with that regardless of if it get's a UDP request, it will first try TCP on the way out.  Ah the joy of working around incompatible devices and servers.  I guess this is why we like OpenSIPS so much, it's flexible enough to fix other people's problems ;)

-dg


On Sat, Mar 6, 2010 at 12:27 AM, Bogdan-Andrei Iancu <[hidden email]> wrote:
Daniel Goepp wrote:
> We actually use record_route_preset not record_route, I would have
> presumed the logic would be the same for both though regarding this.
rr_preset() is for setting your own rr header, overriding the automatic
building of  the headers.  So you have to red pill - let opensips to do
the job - or the blue pill - you do you yourself, but do it from A to Z

> I do not explicitly set double_rr, so it should be the default of on
> as you point out.  My work around of testing and setting manually does
> appear to be working now.  I also wonder about what the default
> protocol / priority would be to use on a call.  For example a SIP URI
> call where you don't know if the called party is UDP or TCP, it
> appears to default to UDP.
if there is not protocol indication (like SIPS scheme or transport
param), it is UDP - that is what RFC3261 says
> However if the endpoint I'm calling from is using TCP, I would prefer
> to have the outbound attempt first try TCP, then go to UDP if it fails.
if you receive the call over TCP and the caller requests TCP for
delivery, you should have the transport=TCP param in the received RURI.
The presence of this param will force opensips to use the indicated
transport for sending the call out.
Se simple fact you receive the call over TCP does not mean anything -
what is important is what protocol is required via RURI.

Regards,
Bogdan
> The system we are sending calls to actually just prefers TCP all the
> time, and then fails over to UDP if it can't complete the call.  We
> are still experimenting with this, but due to the large packet sizes
> we are seeing with video, TCP is working better for us in most situations.
>
> Thanks
>
> -dg
>
>
> On Fri, Mar 5, 2010 at 11:50 AM, Bogdan-Andrei Iancu
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     Hi Daniel,
>
>     But record_route() will automatically do double routing if a proto
>     / ip
>     / port change is detected between the inbound and outbound interface.
>     You need to have the "double_rr" enabled (which is by default).
>
>     Could you check how the RR added by OpenSIPS looks like ?
>
>     Regards,
>     Bogdan
>
>     Daniel Goepp wrote:
>     > Oh man...then TWO seconds after sending this, I find:
>     >
>     > if(proto==TCP)
>     > {
>     > log("the SIP message was received over TCP\n");
>     > };
>     >
>     > However my other comment of perhaps this should be handled
>     > automatically by OpenSIPS still stands :)
>     >
>     > Thanks
>     >
>     > -dg
>     >
>     >
>     > On Fri, Mar 5, 2010 at 9:18 AM, Daniel Goepp <[hidden email]
>     <mailto:[hidden email]>
>     > <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>     >
>     >     We are doing some interop work with another switch, and it is
>     >     having some trouble with TCP vs UDP.  Because of the packet size
>     >     for these specific calls we need to do them TCP.  However the
>     >     record-route in our 200 OK has no transport set, and
>     according to
>     >     the RFC, no transport for SIP default is UDP.  This means
>     that all
>     >     our signaling is TCP, until we get an ACK back from this
>     box, and
>     >     it then is UDP, but too big and breaks the call.  I have
>     found the
>     >     add_rr_param, so I could do a
>     add_rr_param(";transport=tcp"), but
>     >     I only want to do this for calls that are currently using
>     TCP.  I
>     >     looked for a function to test the protocol used, but
>     couldn't find
>     >     one.  Anyone know what it is?  Also, it would seem the
>     appropriate
>     >     thing for OpenSIPS to do would be to automatically put the
>     >     ;transport=xxx in the RR based on the current protocol of the
>     >     dialog.  Thoughts on that?
>     >
>     >     Thanks
>     >
>     >     -dg
>     >
>     >
>     >
>     ------------------------------------------------------------------------
>     >
>     > _______________________________________________
>     > Users mailing list
>     > [hidden email] <mailto:[hidden email]>
>     --
>     Bogdan-Andrei Iancu
>     www.voice-system.ro <http://www.voice-system.ro>
>
>
>     _______________________________________________
>     Users mailing list
>     [hidden email] <mailto:[hidden email]>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>


--
Bogdan-Andrei Iancu
www.voice-system.ro


_______________________________________________
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: Transport identification

Bogdan-Andrei Iancu
Well, you should be able to fix is simple from opensips cfg, like: if
call comes via TCP, and there is no  TCP indication in the RURI, add the
"transport=TCP" at RURI, so that the call will go further via TCP.

Regards,
Bogdan

PS: yes, interoperability sucks :)

Daniel Goepp wrote:

> Thanks for the info.  Looks like I'm dealing with two external
> problems then.  A device that is not doing what it should by
> specifying the transport, and this other server we are communicating
> with that regardless of if it get's a UDP request, it will first try
> TCP on the way out.  Ah the joy of working around incompatible devices
> and servers.  I guess this is why we like OpenSIPS so much, it's
> flexible enough to fix other people's problems ;)
>
> -dg
>
>
> On Sat, Mar 6, 2010 at 12:27 AM, Bogdan-Andrei Iancu
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     Daniel Goepp wrote:
>     > We actually use record_route_preset not record_route, I would have
>     > presumed the logic would be the same for both though regarding this.
>     rr_preset() is for setting your own rr header, overriding the
>     automatic
>     building of  the headers.  So you have to red pill - let opensips
>     to do
>     the job - or the blue pill - you do you yourself, but do it from A
>     to Z
>
>     > I do not explicitly set double_rr, so it should be the default of on
>     > as you point out.  My work around of testing and setting
>     manually does
>     > appear to be working now.  I also wonder about what the default
>     > protocol / priority would be to use on a call.  For example a
>     SIP URI
>     > call where you don't know if the called party is UDP or TCP, it
>     > appears to default to UDP.
>     if there is not protocol indication (like SIPS scheme or transport
>     param), it is UDP - that is what RFC3261 says
>     > However if the endpoint I'm calling from is using TCP, I would
>     prefer
>     > to have the outbound attempt first try TCP, then go to UDP if it
>     fails.
>     if you receive the call over TCP and the caller requests TCP for
>     delivery, you should have the transport=TCP param in the received
>     RURI.
>     The presence of this param will force opensips to use the indicated
>     transport for sending the call out.
>     Se simple fact you receive the call over TCP does not mean anything -
>     what is important is what protocol is required via RURI.
>
>     Regards,
>     Bogdan
>     > The system we are sending calls to actually just prefers TCP all the
>     > time, and then fails over to UDP if it can't complete the call.  We
>     > are still experimenting with this, but due to the large packet sizes
>     > we are seeing with video, TCP is working better for us in most
>     situations.
>     >
>     > Thanks
>     >
>     > -dg
>     >
>     >
>     > On Fri, Mar 5, 2010 at 11:50 AM, Bogdan-Andrei Iancu
>     > <[hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email] <mailto:[hidden email]>>>
>     wrote:
>     >
>     >     Hi Daniel,
>     >
>     >     But record_route() will automatically do double routing if a
>     proto
>     >     / ip
>     >     / port change is detected between the inbound and outbound
>     interface.
>     >     You need to have the "double_rr" enabled (which is by default).
>     >
>     >     Could you check how the RR added by OpenSIPS looks like ?
>     >
>     >     Regards,
>     >     Bogdan
>     >
>     >     Daniel Goepp wrote:
>     >     > Oh man...then TWO seconds after sending this, I find:
>     >     >
>     >     > if(proto==TCP)
>     >     > {
>     >     > log("the SIP message was received over TCP\n");
>     >     > };
>     >     >
>     >     > However my other comment of perhaps this should be handled
>     >     > automatically by OpenSIPS still stands :)
>     >     >
>     >     > Thanks
>     >     >
>     >     > -dg
>     >     >
>     >     >
>     >     > On Fri, Mar 5, 2010 at 9:18 AM, Daniel Goepp
>     <[hidden email] <mailto:[hidden email]>
>     >     <mailto:[hidden email] <mailto:[hidden email]>>
>     >     > <mailto:[hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email] <mailto:[hidden email]>>>> wrote:
>     >     >
>     >     >     We are doing some interop work with another switch,
>     and it is
>     >     >     having some trouble with TCP vs UDP.  Because of the
>     packet size
>     >     >     for these specific calls we need to do them TCP.
>      However the
>     >     >     record-route in our 200 OK has no transport set, and
>     >     according to
>     >     >     the RFC, no transport for SIP default is UDP.  This means
>     >     that all
>     >     >     our signaling is TCP, until we get an ACK back from this
>     >     box, and
>     >     >     it then is UDP, but too big and breaks the call.  I have
>     >     found the
>     >     >     add_rr_param, so I could do a
>     >     add_rr_param(";transport=tcp"), but
>     >     >     I only want to do this for calls that are currently using
>     >     TCP.  I
>     >     >     looked for a function to test the protocol used, but
>     >     couldn't find
>     >     >     one.  Anyone know what it is?  Also, it would seem the
>     >     appropriate
>     >     >     thing for OpenSIPS to do would be to automatically put the
>     >     >     ;transport=xxx in the RR based on the current protocol
>     of the
>     >     >     dialog.  Thoughts on that?
>     >     >
>     >     >     Thanks
>     >     >
>     >     >     -dg
>     >     >
>     >     >
>     >     >
>     >    
>     ------------------------------------------------------------------------
>     >     >
>     >     > _______________________________________________
>     >     > Users mailing list
>     >     > [hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email] <mailto:[hidden email]>>
>     >     > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>     >     >
>     >
>     >
>     >     --
>     >     Bogdan-Andrei Iancu
>     >     www.voice-system.ro <http://www.voice-system.ro>
>     <http://www.voice-system.ro>
>     >
>     >
>     >     _______________________________________________
>     >     Users mailing list
>     >     [hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email] <mailto:[hidden email]>>
>     >     http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>     >
>     >
>     >
>     ------------------------------------------------------------------------
>     >
>     > _______________________________________________
>     > Users mailing list
>     > [hidden email] <mailto:[hidden email]>
>     > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>     >
>
>
>     --
>     Bogdan-Andrei Iancu
>     www.voice-system.ro <http://www.voice-system.ro>
>
>
>     _______________________________________________
>     Users mailing list
>     [hidden email] <mailto:[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
>  


--
Bogdan-Andrei Iancu
www.voice-system.ro


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