Subject: [Sip] secure-call-id vs. session-id

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 31 Mar 2009 10:26:51 -0400

Howdy,
Several people asked me after the meeting about why we would need a session-id if people just implemented secure-call-id.  Clearly I didn't articulate it well enough, so here goes another try...

ISTM, there are numerous "types" of B2BUA's in the World.  Some of those B2BUA's replace the Call-ID for a single reason: security/privacy, because the Call-ID had an IP/host in it.  For example SBC's are of such a type, typically.  Using a secure-call-id should remove the incentive they have for replacing it, which will improve scenarios for dialog-matching in out-of-dialog requests.  

There are also other B2BUA types, which replace the Call-ID for different reasons.  IP-PBX's, App-Servers, SoftSwitches, etc., I would put in that camp.  I don't know why they replace the Call-ID, but clearly their designers feel they need to.  It may just be for strict compliance with RFC-3261, which may well be the right thing to do for their case.  I believe the designers of those devices fully expect that the out-of-dialog request reaches them, and that it's their Call-ID that is in it.  They just didn't expect *other* B2BUA's to be in the path, such as SBC's.

So the secure-call-id is to provide a better path forward for B2BAU's which only change the call-id for the privacy reason.  

For troubleshooting purposes, however, that's not enough.  People want to correlate the session as it crosses as many B2BUA's as possible in their logs/monitoring-equipment, and thus the session-id draft.

-hadriel

---

From: <[email-masked]>
Date: Tue, 31 Mar 2009 17:08:22 +0200

Another reason for the session-ID is that, different from the
secure-call-id, the mechanism  does not rely on the end devices. 

So service providers 
- can use it as soon as they implement it within their B2BUAs directly
connected to end devices and 
-  can use it for tracing some kind of attacks (we do not expect that
people to upgrade their end devices soon)

Laura 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Hadriel Kaplan
> Sent: Tuesday, March 31, 2009 4:27 PM
> To: SIP List
> Subject: [Sip] secure-call-id vs. session-id
> 
> Howdy,
> Several people asked me after the meeting about why we would 
> need a session-id if people just implemented secure-call-id.  
> Clearly I didn't articulate it well enough, so here goes 
> another try...
> 
> ISTM, there are numerous "types" of B2BUA's in the World.  
> Some of those B2BUA's replace the Call-ID for a single 
> reason: security/privacy, because the Call-ID had an IP/host 
> in it.  For example SBC's are of such a type, typically.  
> Using a secure-call-id should remove the incentive they have 
> for replacing it, which will improve scenarios for 
> dialog-matching in out-of-dialog requests.  
> 
> There are also other B2BUA types, which replace the Call-ID 
> for different reasons.  IP-PBX's, App-Servers, SoftSwitches, 
> etc., I would put in that camp.  I don't know why they 
> replace the Call-ID, but clearly their designers feel they 
> need to.  It may just be for strict compliance with RFC-3261, 
> which may well be the right thing to do for their case.  I 
> believe the designers of those devices fully expect that the 
> out-of-dialog request reaches them, and that it's their 
> Call-ID that is in it.  They just didn't expect *other* 
> B2BUA's to be in the path, such as SBC's.
> 
> So the secure-call-id is to provide a better path forward for 
> B2BAU's which only change the call-id for the privacy reason.  
> 
> For troubleshooting purposes, however, that's not enough.  
> People want to correlate the session as it crosses as many 
> B2BUA's as possible in their logs/monitoring-equipment, and 
> thus the session-id draft.
> 
> -hadriel
> 
> _______________________________________________
> Sip mailing list  https://www.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
>