Calling a 'non secure' peer in secured mode

[Philippe Torrelli]

Hello,

With minisip configured to encrypt rtp packet (mikey ) , I try to call an
xlite peer ( with no srtp support ).
xlite answers 200 OK with no Key-Mgmt header . 

On 200 Ok, minisip sends back the answer to the gui 
invite_ok  unprotected, but stays in the 'calling_auth' state.

For the gui, we are in call.
For the transaction layer, we are in terminated state, so (no timer is armed
to leave this state )
For the dialog, we are still in calling_auth ( so no ack is sent ).

For Xlite, that expects an ACK, the session is not "in call".. It then
re-sends 200 OK packets ( that are ignored by transaction layer ), then
BYE..
...

Testing with a grandstream budget tone 100 
phone, I see it directly declines the offer with a 488 status code.


What I'd like to be able to do  is to call preferably with srtp, and, 
if the remote peer doesn't support it, be able to 
inform the user that the call is unsecure, and, if the user
agrees ( either from a 'preference option' ) or 
explicitely prompt the user to ask if he accepts 
to speak on an unsecure channel. 


So I would like to know 
1) how it is supposed to behave, I mean,
Will minisip deny the call and inform the gui ? 
Should it accept the call and and inform the gui 
( so that it can warn the user it's not secure ) ? 
Should it prompt the user and ask if he wants to 
accept the call in a non secured way between the 200 ok 
and the ack  ?

2) I don't know which of the behavior of Xlite or the grand stream phone 
is OK, I plan to dig the rfc and the archives to figure out..
The code from minisip server assumes there can be more than one 
Media proto ... 
Is an option to support more than one media proto in the sdp offer carried
by the invite generated by minisip planned ? 


Philippe Torrelli