Subject: [Sipping] Fwd: Re: location-requirements-02

From: "James M. Polk" <[email-masked]>
Date: Tue, 09 Nov 2004 14:21:00 -0600

I oopsed on two counts below... (hopefully) corrected in-line

>Date: Tue, 09 Nov 2004 10:57:56 -0600
>To: Cullen Jennings <[email-masked]>, sipping <[email-masked]>
>From: "James M. Polk" <[email-masked]>
>Subject: Re: location-requirements-02
>Cc: Brian Rosen <[email-masked]>
>
>At 09:08 PM 11/5/2004 -0800, Cullen Jennings wrote:
>
>>I think you
>>need to get it so that the proxy will not fail things it can not fail. (page
>>36)
>
>don't I state that on page 36 already?

I misread your comment the first time.

Imagine a good citizen UAC that uses good security properties in an INVITE 
to a 911-type service and the request fails. I believe we want the 
situation to be that the subsequent INVITE is sent by that same UAC is in 
clear-text (concluding some security property failed the original attempt) 
to ensure the Request gets to the destination as fast as possible. We don't 
want the UAC searching for why the first attempt failed (by reducing 
security properties a step at a time) and thus taking a long time getting 
the INVITE to the ERC

>>Imagine that A is calling B via proxy-a and proxy-b. I think it is a
>>requirement that A should be able to reveal it's location to proxy-a but not
>>to B. I'm not sure I can think of a good reason why.
>
>Wouldn't this require Proxy-A conceal the body from Proxy-B (middle-2-end 
>security)? This will add time to the call set-up in an emergency 
>situation, many will not like that, and we should have a discussion about it.

I misread this comment of yours the first time too

Is proxy-a removing the LO message body ok with you here? Now, keep in mind 
proxy-a needs to know that B isn't to get the LO from A. I do not know of 
any indication that A can put in the SIP message or body to address the LO 
to proxy-a and not for B's viewing pleasure if the packet is destined for B.

cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP