>>>>> "JV" == Johan Vikman <johan.vik...@mobilearts.com> writes:
JV> That was my guess to, but the product owner wants the transport to change in the 300 response. You will need to use two 300 replies. If LRF detects that the final leg will be a sips: uri and the incoming invite is not onver TLS, it needs to send a 300 pointing to its own sips: uri. When the LRF sees invites to its sips: uri, it can 300 those invite to their proper destinations. You need to know the requirements for the case where the initial invite is to your sips: and the final destination does not support sips. Ie, whether non-tls sip: uris are OK in the 300s. Put another way, whether it is OK to downgrade calls from UAs which seem to want encryption if the destination PSAPs do not support sips. Also, there is the case where the UA does not support sips. They won't be able to deal with the initial 300 to your sips: uri. Maybe that 300 can contain a different sip: uri which will not try to upgrade to sips: even when the destination supports that? If the uris in the 300 have a priority ordering, that might work. So, it looks like you would need a primary sips: uri, a primary sip: uri and a secondary sip: uri for the LRF. -JimC -- James Cloos <cl...@jhcloos.com> OpenPGP: 1024D/ED7DAEA6 _______________________________________________ Yxa-devel mailing list Yxa-devel@lists.su.se https://lists.su.se/mailman/listinfo/yxa-devel