Re: [reSIProcate] Decorator reporting wrong source port

[Scott Godin <sgodin@xxxxxxxxxxxxxxx>]

The language in the base SIP RFC has UA's establish TCP/TLS connections in both directions.  So the contact header must list the port we are listening on for TCP/TLS connections.  If you want to have the SIP stack share a single connection for messages in both directions, you need to start looking at RFC5626, or coming up with your own custom way for doing this (which I wouldn't recommend).  Websocket clients use RFC5626, so the contact header isn't even used.  repro supports RFC5626 and it supports a mode where you can treat registrations like the UA's support RFC5626 even though they may not (called something like FlowTokenHack).  

DUM has the ability to be able to be a RFC5626 enabled client (see dum/test/basicClient example).  You really need to read RFC5626 to understand this stuff better though.

Here is a wiki page with some info:  https://www.resiprocate.org/DUM_Client_Outbound_Support

Best Regards,

Scott

On Tue, Feb 20, 2018 at 11:52 AM, Diego Carvalho Domingos <ddomingos@xxxxxxxxxxxxxxx> wrote:

Hi Dario, thanks for answering

I totally agree with you on this:

"For any other server-initiated transaction in dialog, for example BYE/200, TLS server should reuse the SAME connection toward TLS client otherwise server couldn’t know if it is able to contact client."

But that's not what is happening. The TLS UAS sometimes open a new connection on 5061 to send a BYE and sometimes doesn't and then the BYE never arrives. Then I saw that Bria does this change on the contact header (I tried when it was registered using TCP, but I guess it would be the same for TLS).

So, this is the second time you guys point me to this RFC 5626. The other time was a similar question, but about the fact websocket clients put an invalid contact header and I wanted to get the actual connection IP/port to send the BYE (exact same problem in the opposite direction). So, could you explain how I use this RFC in DUM? (in the response for my other e-mail, Scott also pointed repro. Can I use this in DUM?). Also, regardless if this is the right thing to do or not, isn't resiprocate reporting an incorrect port in the decorator? Thanks again.

 

Diego Carvalho Domingos

 

From: Dario Bozzali [mailto:Dario.Bozzali@ifmgroup.it]
Sent: Tuesday, February 20, 2018 5:13 AM
To: Diego Carvalho Domingos <ddomingos@xxxxxxxxxxxxxxx>
Cc: resiprocate-devel@resiprocate.org
Subject: RE: Decorator reporting wrong source port

 

Hello Diego,

I don’t undertand why you want to set actual port in Contact header, so I’ll try to explain my point of view of the matter.

If you are writing a TLS client using reSIProcate or any other SIP library, receiving TLS server should send status message for INVITE through established TLS connection (in this case actual port is not relevant).

For any other server-initiated transaction in dialog, for example BYE/200, TLS server should reuse the SAME connection toward TLS client otherwise server couldn’t know if it is able to contact client.

This is true even if you write the right/actual port in Contact header of INVITE message because you don’t have to create another TLS connection from server to client on that port. Actually TLS client could be just only a TLS client, that cannot act as server and receive connections on TLS port, even 5061, because it doesn’t have server certificate with private key, for example.

As far as I know you should reuse the same connection in a similar way that you act using RFC 5626 “Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)”.

Try to have a look at method ResponseContext::getInboundFlowToken() in repro.

Hope that the things I wrote are right (Scott could be more precise), I hope that this could help you.

Best regards,

Dario

 

From: resiprocate-devel [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxx] On Behalf Of Diego Carvalho Domingos
Sent: Monday, 19 February, 2018 21:30
To: resiprocate-devel@resiprocate.org
Subject: [reSIProcate] Decorator reporting wrong source port

 

Hi all,
I want to populate the contact header of an INVITE message with the actual port used by the stack to establish a TLS connection instead of the default 5061. The decorator example does exactly that for the SDP so I tried to use that code but source.getPort() returns 5061. I investigated the code and found that initially the method determineSourceInterface is used but the port is set to 0 because via.sentPort() is 0. Then, because of that, the port is set to transport->port(), which I think is the same transport that is setup on resiprocate initialization (which of course had the port set to 5061). How do I get the actual port used by the stack to initiate the TLS connection? Is this a bug in reciprocate? I appreciate any help. Thanks

 

Diego Carvalho Domingos

_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@resiprocate.org
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel