Re: comments on draft-kaplan-sip-session-id-01

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of Dale
> Worley
> Sent: Wednesday, March 25, 2009 12:26 AM
> 
> The essential problem (which also shows up in
> draft-loreto-sipping-context-id-requirements) is that you need to
> express a correlation between two dialogs, but the correlation is
> discovered after both of the dialogs have been initiated.

Yeah but I'm not trying to solve that scenario. Session-ID is only trying to create a dialog identifier for a single "end-end dialog" that survives B2BUA's, for the purposes of troubleshooting that dialog.  It's NOT trying to correlate all subsequent dialogs, across all space/time, which may have some relationship to the original one.
  
For example, take Jonathan's example of two-calls get joined together with a REFER processed by a PBX (I think that's one we've actually discussed before, but maybe not).  There is dialog A and dialog B, and at some point half of A and half of B are joined together with re-INVITEs.  Personally I actually think that's a brand new session.  Because had the REFER actually gone end-to-end, that's exactly what would have happened: dialog C would be created.  Just because they happen to be re-using dialog identifiers (call-id/tags) from the original A and B dialogs, is essentially just a nuance of SIP protocol mechanics.  From the user's perspective they got transferred, from the admins/provider's perspective they got transferred, and from an architecture perspective they got transferred (i.e., 
 the real "ends" of the dialog have now changed).

I don't debate that from a troubleshooting perspective it would be valuable to know that the new C dialog was created from the original A and B dialogs, but I'm not sure that needs to be known on the wire.  I mean minimally the PBX logs will show it.  But I can see the benefit for both.

 
> If I may be immodest, the References header could a solution:  State
> that two dialogs are related to each other by (effectively) naming both
> call-id's together, rather than by assigning them a common identifier
> when they are created.

Yeah I think it adds value to have the References header.  I just don't think it should be referencing Call-ID's, or else we'll have to replace that too.  It should be referencing Session-ID's or secure-call-id's.  :)

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