Re: [Sip] RE: Identity after reinvite

Jonathan Rosenberg wrote:
> 
> 
> David R Oran wrote:
> 
>> I have a strong preference for (1). I intensely dislike accumulated 
>> hacks and entropy in a protocol. Backward compatibility is an 
>> important property, but 2543 compatibility is fast becoming a a 
>> concrete block chained to our legs.
>>
>> We should declare a day that 2543 SIP implementations don't have to 
>> work right any more. I suggest we make that when 3261 goes to draft 
>> standard. 
> 
> Cough... cough... [clutching chest as heart attack ensues]
> 
> Draft standard? After the pain we went through to get rfc3261 issued I 
> can't imagine doing that again...
> 
> Practically speaking, based on the current rules for normative 
> references, we are never going to be able to get to draft because 
> RFC3261 has too many normative dependencies on protocols that are not at 
> draft standard.
> 
> I agree we should take approach (1). We could spec it in a backwards 
> compatible way, too. If you change the From field in a request you send 
> mid-dialog, and you get a 481, you know that something along the way got 
> confused about the dialog identifiers. You can then retry, using the 
>  From URI from the original INVITE, and include some kind of flag to 
> signal to the identity service not to try and insert the Identity header.

The situation is a little more difficult to detect if you change the To 
in the response to the INVITE, which I was suggesting. Error responses 
don't help in this case. The to-from-change option would however help to 
know you could do this.

But as you point out below, that doesn't help if the proxies on the path 
get upset. To get around that problem we could use Proxy-Require, but 
that is pretty heavy handed. Or we could use some more cooperative 
option negotiation, where all the proxies must concur before the UAS can 
use the feature.

> Paul wrote:
> 
>> We could define an option to be announced in Supported that indicates 
>> ability to do this. Could end up with:
>>
>>     INVITE ...
>>     To: sip:bob@biloxi.com
>>     From: sip:alice@atlanta.com;tag=alice
>>     Supported: to-from-change
>>     Identity: aaaaaaaa (signed over From)
>>     Identity-Info: https://atlanta.com/cert
>>     ...
>>
>>     180 ...
>>     To: sip:charlie@chicago.com;tag=charlie
>>     From: sip:alice@atlanta.com;tag=alice
>>     Supported: to-from-change
>>     Identity: cccccccc (signed over To)
>>     Identity-Info: https://chicago.com/cert
>>     ...
>>
>>     200 ...
>>     To: sip:charlie@chicago.com;tag=charlie
>>     From: sip:alice@atlanta.com;tag=alice
>>     Supported: to-from-change
>>     Identity: cccccccc (signed over To)
>>     Identity-Info: https://chicago.com/cert
>>     ...
>>
>>     ACK ...
>>     To: sip:charlie@chicago.com;tag=charlie
>>     From: sip:alice@atlanta.com;tag=alice
>>     Supported: to-from-change
>>     Identity: aaaaaaaa (signed over From)
>>     Identity-Info: https://atlanta.com/cert
>>     ...
>>
>>     UPDATE ...
>>     To: sip:alice@atlanta.com;tag=alice
>>     From: sip:charlie@chicago.com;tag=charlie
>>     Supported: to-from-change
>>     Identity: cccccccc (signed over From)
>>     Identity-Info: https://chicago.com/cert
>>     ...
>>
>>     200 ...
>>     To: sip:alice@atlanta.com;tag=alice
>>     From: sip:charlie@chicago.com;tag=charlie
>>     Supported: to-from-change
>>     Identity: aaaaaaaa (signed over To)
>>     Identity-Info: https://atlanta.com/cert
>>     ...
>>
>> (Above shown as they look to receiving UA.) 
> 
> 
> This helps

By "this" I assume you mean the to-from-change option?

 > only if you assume that the problem lies in the UA; I would
> be worred about other nasties along the way.

For changing on subsequent requests within the dialog, what nasties are 
you thinking of? I think only a call stateful proxy would notice, and it 
seems there aren't many of those. Of course there are B2BUAs, but they 
at least *ought* to be UAs and behave as such.

Maybe there would be problems with SBCs, and with "transparent" B2BUAs 
that normally act as proxy but morph into UAs on occasion. But I think 
these nasties will have other problems with Identity too. I suppose we 
must however confront these.

> In any case, I don't see a need for a Supported header field. The 
> feature is supposed to work with any rfc3261 client out there.

Other than just hoping for the best, why would we expect existing 3261 
clients to work with this change?

	Paul

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip