[Spce-user] Internal error when using TLS
agranig at sipwise.com
Thu Aug 30 18:56:07 EDT 2012
> client-> LB: INVITE
> LB -> proxy: INVITE
> proxy -> B2BUA: INVITE
> B2BUA -> proxy: 100 - connecting
> B2BUA -> LB: INVITE - but it goes to port 5888 (plain TCP, not TLS)
> B2BUA -> proxy: 500 Server internal error
> proxy -> B2BUA: ACK
When you register a client, the LB puts itself into the Path header, and
this is stored along with the registration in kamailio.location table.
It might help if you can post the result from this query:
SELECT FROM kamailio.location WHERE username = 'your username'\G
Note the \G for better readability of the result.
> So to me it looks like the B2BUA is trying to reach the TLS client using plain TCP instead of TLS and logically fails.
Are you sure about that? I don't even think the B2BUA supports TCP :)
I guess it's rather like proxy->B2BUA->lb, and from there it goes to the
IP/port of the Contact using the indicated transport, which is TCP in
> so just a thought... I have noticed, that our own client uses this contact string:
>> sips:1001 at 192.168.178.23:54073;transport=tcp
We don't support sips URIs, rather than "sip:user at ip:port;transport=tls"
as you've written below. Which client are you using?
This is the first time ever I'm seeing this in the wild, so I'm really
> while another client, that seems to work fine (except for some rtp issues, but I believe these are not related) uses the following form:
>> sip:1001 at 192.168.178.21:50162;transport=tls
This is the correct format we're expecting, right.
> Now as far as I understand this, these two should be equivalent for calls between two subscribers in the same domain. Is that really so and is this a dead end or is this something worth looking into? What does the B2BUA use to determine which port and protocol to use to contact the client?
No, it's purely driven by the Contact header used during the initial
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 900 bytes
Desc: OpenPGP digital signature
More information about the Spce-user