>>>>> "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
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.
James Cloos <cl...@jhcloos.com> OpenPGP: 1024D/ED7DAEA6
Yxa-devel mailing list