[OpenSIPS-Users] Transport identification

Bogdan-Andrei Iancu bogdan at voice-system.ro
Tue Mar 9 10:27:53 CET 2010


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 
> <bogdan at voice-system.ro <mailto:bogdan at voice-system.ro>> 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
>     > <bogdan at voice-system.ro <mailto:bogdan at voice-system.ro>
>     <mailto:bogdan at voice-system.ro <mailto:bogdan at voice-system.ro>>>
>     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
>     <dan at goepp.net <mailto:dan at goepp.net>
>     >     <mailto:dan at goepp.net <mailto:dan at goepp.net>>
>     >     > <mailto:dan at goepp.net <mailto:dan at goepp.net>
>     <mailto:dan at goepp.net <mailto:dan at goepp.net>>>> 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
>     >     > Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>     <mailto:Users at lists.opensips.org <mailto:Users at lists.opensips.org>>
>     >     > 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
>     >     Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>     <mailto:Users at lists.opensips.org <mailto:Users at lists.opensips.org>>
>     >     http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>     >
>     >
>     >
>     ------------------------------------------------------------------------
>     >
>     > _______________________________________________
>     > Users mailing list
>     > Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>     > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>     >
>
>
>     --
>     Bogdan-Andrei Iancu
>     www.voice-system.ro <http://www.voice-system.ro>
>
>
>     _______________________________________________
>     Users mailing list
>     Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>     http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>   


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




More information about the Users mailing list