< Previous by Date | Date Index | Next by Date > |
< Previous in Thread | Thread Index | Next in Thread > |
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@xxxxxxxxxxx]
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 Hi all, Diego Carvalho Domingos |