reSIProcate

Mailing Lists

Source Code

Google Search:



< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate-users] Forcing an Outbound Transport-Type

Hi Scott,
Yes, the problem of the DNS logic selecting the transport is exactly where I am stuck right now. But I guess one could argue, if you force and outgoing transport, you need to deal with TCP/UDP mismatches yourself. The current implementation uses the via.sentHost() but target.ipVersion() for the source. So, if for example the former is an IPv4 address and the latter IPv6, the connection will also fail (or am I missing something?).
Allowing the Stack to only use TCP is the workaround I previously used, but it is not very pretty. Especially since RFC3261 mandates support for both TCP and UDP... 

Gabriel

Am 09.05.2012 15:02, schrieb Scott Godin:

Ah - I missed the use of target when populating the source tuple.  That
logic in the code does makes sense to me though.  If your target is
specifying a particular transport type, then you really need to be sending
on that transport.  For example: You can't really send to a request uri
specifying sip:<domain>;transport=TCP over UDP - the same way you can't
send to an IPv6 address using IPv4.  If you changes this, I'm worried that
things might break for other scenarios.  That being said if the transport
type in the tuple was selected due to SRV priority, then it would be valid
to ignore it and use another (lower priority) transport - but I don't think
there is a way for the TransportSelector to know this - since the DNS logic
has already run and selected a destination tuple.  And since you have both
transport types defined, it will select whichever type has the highest
priority.  Is it an option to remove the UDP transport entirely from the
stack?  If not I think there would need to be some new logic in resip that
allows dum to pass down a subset of valid transports for a particular
request, and let the stack resolve the DNS queries and do transport
selection appropriately using this subset, instead of looking across all
transports added to the stack.

Scott

On Wed, May 9, 2012 at 7:44 AM, Gabriel Hege<" gabriel-mailinglists"@gmx.de

wrote:



Hi Scott,

thanks for the quick reply.

Stepping through the code (resiprocate version 1.7.1) I found the problem
in findTransportByVia(), but the respective code has not changed in trunk.

The problem is findTransportByVia() sets the transport type in the source
tuple, to the transport type found in the target. I think if a Via is
present with the transport set, this should be used.

I will try to provide a patch.

Best regards,
  Gabriel

Am 08.05.2012 23:32, schrieb Scott Godin:


Hi Gabriel,

Looking through the code in SVN head/trunk, I can't see anything
obviously wrong with what you are trying (there may have been bugs in
older releases).  Are you able to trace through findTransportByVia and
see why it is failing to select your TCP transport?  Examining Debug
level logs should also help to understand why as well.

Scott

On Tue, May 8, 2012 at 4:56 PM, Gabriel Hege
<gabriel-mailinglists@xxxxxx<mailto:gabriel-mailinglists@**gmx.de<gabriel-mailinglists@xxxxxx>>>
wrote:

    Hi,

    What is the proper way to force a transport type (e.g. TCP) for an
    outgoing request - or even better for all request from a certain
    UserProfile?

    The comments in Profile.hxx suggest that somebody thought about
    using setOverrideHostAndPort() to also populate the Via entries, but
    it is not implemented.

    I tried setting the transport for the first Via of a request like this:

      invite_msg = mp_dum->makeInviteSession( m_to_addr, m_profile,
    &m_sdp, new MyAppDialogSet(*mp_dum) );
      invite_msg->header(h_Vias).__**front().transport() = "TCP";

      mp_dum->send(invite_msg);



    but the message is still sent over the wire as UDP, although it
    contains the following header:

      Via: SIP/2.0/TCP
    141.22.27.150:5060;branch=__**z9hG4bK-d8754z-__**
bf3a78252072422c-1---d8754z-;_**_rport




    findTransportByVia() and findTransportBySource() are actually called
    in the TransportSelector, since I do have
    setFixedTransportInterface() set for the used profile.

    Can anybody give me some advice please?

    Thank you,
      gabriel

    ______________________________**___________________
    resiprocate-users mailing list
    resiprocate-users@resiprocate.**__org
    
<mailto:resiprocate-users@**resiprocate.org<resiprocate-users@xxxxxxxxxxxxxxx>



    List Archive:
    
http://list.resiprocate.org/__**archive/resiprocate-users/<http://list.resiprocate.org/__archive/resiprocate-users/>
    
<http://list.resiprocate.org/**archive/resiprocate-users/<http://list.resiprocate.org/archive/resiprocate-users/>







______________________________**_________________
resiprocate-users mailing list
resiprocate-users@resiprocate.**org<resiprocate-users@xxxxxxxxxxxxxxx>
List Archive: 
http://list.resiprocate.org/**archive/resiprocate-users/<http://list.resiprocate.org/archive/resiprocate-users/>





_______________________________________________
resiprocate-users mailing list
resiprocate-users@xxxxxxxxxxxxxxx
List Archive: http://list.resiprocate.org/archive/resiprocate-users/