Subject: [Sip] S-CSCF expected behavior

From: António Manuel Amaral<[email-masked]>
Date: Fri, 14 Jul 2006 11:17:23 +0100

Dear All,

I don't know if this is the correct mailing list to put my question and if not my apologies for that.

Consider the following IMS scenario

(IMS core Network) -> S-CSCF -> AS

If the connection between AS and S-CSCF fails what is the expected behavior of S-CSCF? It must release all active calls sending BYE messages to caller and called clients in order to terminate the calls?

Thanks in advance

Regards

AA 

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

---

From: Markus Hofmann <[email-masked]>
Date: Fri, 14 Jul 2006 15:36:49 +0200

>>
>>additional 
>>
>>>recipients, can add new Pu(secret) objects for those new 
>>
>>recipients as 
>>
>>>needed.  That does assume a chain of trust among those 
>>
>>given access to 
>>
>>>the secret.
>>>
>>>Is that practical?  I think so, but others may have their opinion.
>>>
>>
>>
>>This is just an optimization of encrypting location objects 
>>to individual recipients. I am not sure we are even closen to 
>>optimizations.
>>
>>
>>
>>>BTW, can someone re-summarize what the requirements are?
>>
>>Requirements for what exactly? Most of the requirements are listed in 
>>the document provided by James & Brian.
>>
>>
>>>It must be modifiable -> must be a header not body
>>>It must provide confidentiality -> encrypted or selectively 
>>
>>handed out
>>
>>>(by ref)
>>>Downstream recipient unknown to UAC must have access -> ???
>>>...
>>
>>What is 'it'?
>>
>>
>>Ciao
>>Hannes
>>
>>
>>>Mike
>>>
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: Hannes Tschofenig [mailto:[email-masked]] 
>>>>Sent: Friday, July 14, 2006 9:39 AM
>>>>To: James Polk (jmpolk)
>>>>Cc: [email-masked]; Henning Schulzrinne
>>>>Subject: Re: [Sip] Location header
>>>>
>>>>Hi James,
>>>>
>>>>James M. Polk wrote:
>>>>
>>>>
>>>>>At 07:25 PM 7/13/2006 -0400, Hannes Tschofenig wrote:
>>>>>
>>>>>
>>>>>
>>>>>>Hi James,
>>>>>>
>>>>>>please explain me the difference (from a security point of view) 
>>>>>>between
>>>>>>* adding a location object into the header that is not 
>>>>
>>>>encrypted, and
>>>>
>>>>
>>>>>>* adding a reference to a location object to the header 
>>>>
>>>>that can be 
>>>>
>>>>
>>>>>>resolved into a location object by everyone that knows the 
>>>>
>>>>reference?
>>>>
>>>>
>>>>>The server which has the by-referenced PIDF-LO can 
>>>>
>>>>challenge whoever 
>>>>
>>>>
>>>>>asks for the PIDF-LO.  The header URI allows for each 
>>>>
>>>>intermediary to 
>>>>
>>>>
>>>>>ask for the dereference, but only those that have permission, 
>>>>>surviving the challenge(s), get the PIDF-LO.  This means not all 
>>>>>dereference attempts learn the UAC's location.  This cannot be 
>>>>>accomplished in a header.
>>>>
>>>>This would assume that the entity that created the location 
>>>>object has a
>>>> relationship with the final location recipient (and to 
>>>>share some credential with them).
>>>>
>>>>I think that this is a totally unrealistic assumption.
>>>>
>>>>
>>>>Ciao
>>>>Hannes
>>>>
>>>>
>>>>
>>>>>>Ciao
>>>>>>Hannes
>>>>>>
>>>>>>James M. Polk wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Right now, the ID lists options 1 and 2 as the only options, and 
>>>>>>>this keeps things simple.  There have been a couple of 
>>>>
>>>>comments here 
>>>>
>>>>
>>>>>>>in Montreal that adding a data URL isn't really wanted.
>>>>>>>One reason given is the inability to encrypt it (easily). 
>>>>
>>>>A message 
>>>>
>>>>
>>>>>>>body can be encypted using S/MIME, and a URI can have the server 
>>>>>>>posessing the PIDF-LO configured to challenge a 
>>>>
>>>>dereference request 
>>>>
>>>>
>>>>>>>- including responding with an encrypted PIDF-LO.  Both these 
>>>>>>>senarios have the PIDF-LO being able to be encrypted.  
>>
>>I'm not so 
>>
>>>>>>>sure encrypting the data URL is so straightforward, or 
>>
>>deployable.
>>
>>>>>>>Others, please inform me and the list if this is untrue.
>>>>>>>Cannot the ID proceed as is (in this respect), and once someone 
>>>>>>>wants to extend this doc (once it's an RFC), propose that 
>>>>
>>>>extention 
>>>>
>>>>
>>>>>>>as a separate ID?
>>>>>>>At 07:19 PM 7/12/2006 -0400, Henning Schulzrinne wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>To follow up on the discussion in the SIP group. I think 
>>>>
>>>>there are 
>>>>
>>>>
>>>>>>>>roughly three options for the content of Location:
>>>>>>>>
>>>>>>>>(1) Point to content in the body  --> can't be modified 
>>>>
>>>>and cannot 
>>>>
>>>>
>>>>>>>>be inserted by proxies (and may not be inspectable by proxies if
>>>>>>>>encrypted)
>>>>>>>>
>>>>>>>>(2) Point to external location --> can be modified, can 
>>>>
>>>>be added, 
>>>>
>>>>
>>>>>>>>but can in69a74e02bbee44ab4f8eafdbcedd94a1
Cc: [email-masked]
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:[email-masked]?subject=unsubscribe>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

Hi António,

I can't answer your question. I think you should contact the 3G which is
responsible for IMS.

Regards

Markus

duce loops if changed in mid-stream and 
>>
>>incurs another 
>>
>>>>>>>>failure mode (and possible security risks if the reference is 
>>>>>>>>generally
>>>>>>>>accessible)
>>>>>>>>
>>>>>>>>(3) Point to data URL (RFC 2397) as in
>>>>>>>>
>>>>>>>>Location: data:application/pidf+xml;base64,<base-64 version of 
>>>>>>>>PIDF-LO)
>>>>>>>>
>>>>>>>>Disadvantage: about 30% larger than as body; can't be encrypted 
>>>>>>>>separately (except as XML-DSIG)
>>>>>>>>
>>>>>>>>Advantages: can be inserted/modified by proxies (similar 
>>>>
>>>>to (2)), 
>>>>
>>>>
>>>>>>>>but avoids difficulty of external reference
>>>>>>>>
>>>>>>>>I think these three methods all have different 
>>>>>>>>time-space-flexibility trade-offs and thus I suspect 
>>>>
>>>>they all serve a need.
>>>>
>>>>
>>>>>>>>Henning
>>>>>>>>
>>>>>>>>
>>>>>>>>This list is for NEW development of the core SIP Protocol Use 
>>>>>>>>[email-masked] for questions on 
>>>>
>>>>current sip Use 
>>>>
>>>>
>>>>>>>>[email-masked] for new developments on the application of sip
>>>>>>>
>>>>>>>
>>>>>>>This list is for NEW development of the core SIP Protocol Use 
>>>>>>>[email-masked] for questions on 
>>
>>current sip Use 
>>
>>>>>>>[email-masked] for new developments on the application of sip
>>>>>
>>>>>
>>>>>
>>>>This list is for NEW development of the core SIP Protocol Use 
>>>>[email-masked] for questions on current sip

---

From: Markus Hofmann <[email-masked]>
Date: Fri, 14 Jul 2006 15:36:49 +0200

Hi António,

Regards

Markus