Subject: Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 19 Jan 2010 14:16:39 -0600

Hi, Laura,

Ah - yes, I understand what you're saying here, and why it applies to 
"Same-Session", and agree.

Thank you for confirming and clarifying.

Spencer

> Spencer,
>
> Yes, exactly.   But I mixed-up something in my text , the requirement
> should be for Same-Session (dialog correlation) , not for Session-ID.
>
> Thanks a lot
> Laura
>
>
> --------------------------------------------------------------------------------
>
> From: "Spencer Dawkins" <spencer at wonderhamster.org>
> To: <L.Liess at telekom.de>, <HKaplan at acmepacket.com>,
> <Gonzalo.Camarillo at ericsson.com>
> Cc: dispatch at ietf.org, Martin.Huelsemann at telekom.de, Gerold.Pinker
> at telekom.de
> Date: Tue, 19 Jan 2010 07:46:39 -0600
> References: <E6C2E8958BA59A4FB960963D475F7AC31A582F3CBD at
> mail><4B32DC9B.3040406 at
> softarmor.com><36D784AAD47343248BE3274F64A101ED at
> china.huawei.com><4B4F3353.9010507 at ericsson.com>
> <E6C2E8958BA59A4FB960963D475F7AC31A59D96919 at mail>
> <40FB0FFB97588246A1BEFB05759DC8A003DD6D5B at S4DE9JSAANI.ost.t-com.de>
>
> --------------------------------------------------------------------------------
>
> Hi, Laura,
>
>
> Just to make sure I understand - are you saying something like "The
> mechanism should not lead to performance reduction at the UAS for
> dialogs that are not correlated with other dialogs."?
>
>
> (I'm just trying to be more precise about "unnecessary performance
> reduction")
>
> If so, that makes sense to me.
>
> Thanks,
>
> Spencer
>
>
> ----- Original Message ----- From: <L.Liess at telekom.de> To: <HKaplan
> at acmepacket.com>; <Gonzalo.Camarillo at ericsson.com>; <spencer at
> wonderhamster.org> Cc: <dispatch at ietf.org>; <Martin.Huelsemann at
> telekom.de>; <Gerold.Pinker at telekom.de>
> Sent: Tuesday, January 19, 2010 4:19 AM
>
> Subject: RE: [dispatch] FW:
> I-DAction:draft-kaplan-dispatch-session-id-00.txt
>
>
> Hi,
>
> I think if we can show that having the same identifier for both use
> cases has unacceptable consequences we can say that we need two diferent
> identifiers.
> If I understood the draft-loreto-sipping-dialog-correlation-01
> correctly, my feeling is that we get a lot of problems if we try to use
> the same identifier for both Session-ID and Dialog-correlation
> (Same-Session).
>
> Let's assume we have a same identifier, called Correlation-ID , which
> plays both roles, Session-ID and Same-Session.
>
>
> Consequence nr. 1)
> Significant performance reduction in UAS.
>
> When Correlation-ID in it's Session-ID role becomes implemented, every
> INVITE received by every UAS will contain a Correlation-ID. The UAS will
> have to  search for existing dialogs related to the received
> Correlation-ID. For Gateways or Application Servers, this can be very
> CPU consuming. They must search for related dialogs for every received
> INVITE. If we have two identifiers are different, in most cases the UAS
> receives only the Session-ID which it just copies into the Respose. The
> search is done only for the use cases described in the dialog-corelation
> draft.
>
> So I would propose following additional requirenment for the Session-ID
> Header:
> "The mechanism should not lead to unnecessary performance reduction at
> the UAS."
> This requirement is not fulfilled if we have the same identifier.
>
>
>
> Consequence nr. 2)
>
> Imprecise monitoring results
>
> Consider the scenario in chapter 4
> draft-loreto-sipping-dialog-correlation-01. Additionaly, there is a
> B2BUA between Alice and Bob and the service provider monitors the trafic
> E2E.  The trubleshooting people will want to distinguish which messages
> belong to the phone call and which messages belong to  the video call.
>
>
>
>
> Alice
> Bob
>
> UA_A
> -----call-ID_a-----------B2BUA------------------------call-ID_b1--------
>
> UA_B
>
>
> Correlation-ID_a
>                                                         (based on
> call-ID_a)
>
>
>
>
> UA_C
> -----call-ID_c-----------B2BUA------------------------call-ID_b2--------
>
> UA_B
>
>         Correlation-ID_a
> Correlation-ID_a
>        (based on call-ID_a)                         (based on
> call-ID_a)
>
>
>
>
> Alice's phone client UA_A sends the INVITE to UA_B across the B2BUA. The
> B2BUA constructs the Correlation-ID_a based on the Call-ID_a.
> Alice's video client UA_B sends the INVITE to UA_B. This INVITE must be
> correlated to the existing phone call and the UA_B constructs the
> Correlation-ID_a based on the Call-ID_a. The B2BUA passes the
> Correlation-ID_a to the UA_B transparently. Because both messages
> between the B2BUA and UA_B have the same Correlation-ID, the monitoring
> equipment will not be able to distinguish which message belongs to which
> call.
>
>
> So I would propose following additional requirenment for the Session-ID
> Header:
>
> "Different E2E SIP sessions must have different identifiers."
>
> I also would add following Requirement to Session-ID:
>
> "It must be possible to use the identifier without upgrading the end
> devices software."
> This requirement is met by the Session-ID proposal but it is not
> explicitely stated in the draft.
>
>
> Additional personal opinions on the correlation-draft:
> - I think the Same-Session will is usefull for troubleshooting and
> should be standardized.
>
> - The Same-Session header should use the Session-ID instead of the
> call-ID, to be able to cross B2BUAs. Otherwise B2BUAs will drop or
> change it. (I hope there are no conflicts here with the tags.)
>
>
> Thanks  a lot
>
> Laura
> --------------------------------------------------------------------------------
>
> References:
> [dispatch] FW: I-D Action:draft-kaplan-dispatch-session-id-00.txt
> From: Hadriel Kaplan
> Re: [dispatch] FW: I-D Action:draft-kaplan-dispatch-session-id-00.txt
> From: Dean Willis
> Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt
> From: Spencer Dawkins
> Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt
> From: Gonzalo Camarillo
> Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt
> From: Hadriel Kaplan
> Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-00.txt
> From: L.Liess
> Prev by Date: Re: [dispatch] FW:
> I-DAction:draft-kaplan-dispatch-session-id-00.txt
> Next by Date: Re: [dispatch] Comments
> requestedondraft-avasarala-dispatch-comm-div-notification
> Previous by thread: Re: [dispatch] FW:
> I-DAction:draft-kaplan-dispatch-session-id-00.txt
> Next by thread: Re: [dispatch] Test message - please ignore
> Index(es):
> Date
> Thread
> Note Well: Messages sent to this mailing list are the opinions of the
> senders and do not imply endorsement by the IETF.
>
>
>