From brian.rosen@neustar.biz Thu Aug 2 15:48:44 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A17E321E8047 for ; Thu, 2 Aug 2012 15:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.353 X-Spam-Level: X-Spam-Status: No, score=-6.353 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLhPi9EpnZyo for ; Thu, 2 Aug 2012 15:48:44 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id AD10121E8043 for ; Thu, 2 Aug 2012 15:48:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1343947623; x=1659306336; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=2w9C86xvF6UJVrVxYGeox D+xR4MWIdVAPeWOljnbqjE=; b=iFSXYZ5MqntYsWQ7ALa9YqoFGoy97C4MQccxP Vg14s10tAonKUc3XOPTkfwpbqpcK+1/OXFGhSK2Jm6tHwODog== Received: from ([10.31.13.229]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.7963328; Thu, 02 Aug 2012 18:47:01 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::28fd:d8c6:49f0:619b]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Thu, 2 Aug 2012 18:48:29 -0400 From: "Rosen, Brian" To: "siprec@ietf.org" Date: Thu, 2 Aug 2012 18:48:26 -0400 Thread-Topic: Suggestions for text in the Architecture doc security section Thread-Index: Ac1xAO8pI5JIA7wFQ52sCCJ+/1qsIA== Message-ID: <68EA92D0-6B1E-492C-B95C-2462C195FE0F@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: G8gVglpta+BC8halBG1c/w== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [siprec] Suggestions for text in the Architecture doc security section X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 22:48:44 -0000 In today's siprec meeting we discussed security, mostly in the context of t= he protocol document. Looking at the ARCHITECTURE document's security sect= ion, I find it way too weak. I suggest we add: 1. Protection of the RS should be no worse than protection of the CS, and m= ay need to be better because the media is retransmitted (allowing more poss= ibility for interception), stored (allowing malicious attack on the storage= system) and retrievable (through the recorder's authorized retrieval inter= face). This applies to both the signaling and media paths. Cryptosuites, = and protocol mechanisms must be considered. =20 2. It is essential that the SRC authenticate the SRS because the client mus= t be certain that it is recording on the right recording system. It is les= s important that the SRS authenticate the SRC, but implementations must hav= e the ability to perform mutual authentication 3. In some environments, it is desirable to not decrypt and re-encrypt the = media. This means the same key is used on the CS and RS. This only works = when the media is encrypted, not the transport. It implies that the keying= mechanism is the same on the CS as the RS. That has implications on manda= tory to implement keying mechanisms 4. When the media must be decrypted on the CS, and is re-encrypted on the R= S, a new key must be used 5. The document doesn't discuss a retrieval mechanism for recorded media. = The security implications on retrieval are similar to those of recording, b= ut because the retriever is another party to the recording session, item 2 = is reversed - the client must be authenticated. The crypto must be no less= strong than that on the RS, and may need to be better. Brian= From pravindran@sonusnet.com Thu Aug 2 16:51:21 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82D2311E815E for ; Thu, 2 Aug 2012 16:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04b-666wD0Hd for ; Thu, 2 Aug 2012 16:51:20 -0700 (PDT) Received: from na3sys010aog113.obsmtp.com (na3sys010aog113.obsmtp.com [74.125.245.94]) by ietfa.amsl.com (Postfix) with ESMTP id 6666E11E815A for ; Thu, 2 Aug 2012 16:51:20 -0700 (PDT) Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob113.postini.com ([74.125.244.12]) with SMTP ID DSNKUBsSd1MpS2fC4xMRx5GcXfp37vl7Jkau@postini.com; Thu, 02 Aug 2012 16:51:20 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.309.2; Thu, 2 Aug 2012 19:51:18 -0400 Received: from INBA-MAIL02.sonusnet.com ([fe80::f8d4:7090:f632:bbbc]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.02.0309.002; Fri, 3 Aug 2012 05:21:15 +0530 From: "Ravindran, Parthasarathi" To: Paul Kyzivat , "siprec@ietf.org" Thread-Topic: [siprec] comments on draft-ietf-siprec-metadata-07 Thread-Index: Ac1vjQDN8zXHYxh0TdyfDVEBhvV+if//34KA//zng+A= Date: Thu, 2 Aug 2012 23:51:15 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C2BD148A5@inba-mail02.sonusnet.com> References: <059AF07365DC474393A19A3AF187DF740806753E@NAHALD.us.int.genesyslab.com> <5018C5D5.4090207@alum.mit.edu> In-Reply-To: <5018C5D5.4090207@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [siprec] comments on draft-ietf-siprec-metadata-07 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 23:51:21 -0000 Hi all, As discussed today meeting, Paul mentioned below metadata model change is a= n alternative which clarifies the stream XML element usage within the speci= fic single CS instead of spread across. I'm interested in hearing anybody h= as objection to this change. Thanks Partha >-----Original Message----- >From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf >Of Paul Kyzivat >Sent: Wednesday, August 01, 2012 11:30 AM >To: siprec@ietf.org >Subject: Re: [siprec] comments on draft-ietf-siprec-metadata-07 > >Hi Henry, > >Yes, I agree that there is an inconsistency. >We have also been discussing problems with this association that we plan >to talk about on Thursday. My proposal is to change it to: > >CS ------------------- Media Stream > 0..1 0..* > > Thanks, > Paul > >On 7/31/12 7:26 PM, Henry Lum wrote: >> Hi, >> >> I notice that in the metadata model in section 4 CS has a 1..* to 0..* >relation with a media stream and this is inconsistent with further text. >> >> In section 6.3, CS is stating that it has a 0..* to 0..* relation with >a media stream. On top of page 12 it explains that a media stream can be >associated with zero of more CS and points out that a multicast MOH >stream can be without a CS. In section 6.7 a media stream can connect to >1..* CS. >> >> Which one is the intended usage? Note that XML requires the >session_id attribute so it seems like section 6.3 is odd one out. >> >> Regards, >> Henry >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec >> > >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec From jmpolk@cisco.com Thu Aug 2 18:38:42 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C30311E80A4 for ; Thu, 2 Aug 2012 18:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.511 X-Spam-Level: X-Spam-Status: No, score=-110.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MocqdVtTQKEY for ; Thu, 2 Aug 2012 18:38:41 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 380AB11E8072 for ; Thu, 2 Aug 2012 18:38:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=12968; q=dns/txt; s=iport; t=1343957921; x=1345167521; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=MyhSW+hQN3Cx3n326iU1WBIfZFRNFNTrDt6kNcF2eQ0=; b=EIhPfYNh/YWvTJWXynhjXQj9cnDSdGfZHZ2+UhkvX+i1jfyt8ie0C6fn Q71pemF5x8O03ZfmbRkEAxzZV3i7E1dfL3AsRx5vxjl76A+EZNlG8P8Qj 2uUU/5rrBmorhkFS4/lzHZ0w77mjCVtiUecra5zLq9/PSLVRpWacxem2B I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKcqG1CrRDoH/2dsb2JhbABFuSSBB4IgAQEBBAEBAQ8BFBECLgYXBAcEEQQBAQEeCQcZCAYfCQgGCgkbB4dcAwsMnQWWcw2JSgSKY2cahmoDiE2LJ4xdgx2BZoJ9gUE X-IronPort-AV: E=Sophos;i="4.77,704,1336348800"; d="scan'208";a="53856618" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 03 Aug 2012 01:38:40 +0000 Received: from jmpolk-WS.cisco.com ([10.21.166.204]) (authenticated bits=0) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q731cdMR026288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 3 Aug 2012 01:38:40 GMT Message-Id: <201208030138.q731cdMR026288@mtv-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 02 Aug 2012 20:38:39 -0500 To: From: James Polk In-Reply-To: <50176CC9.80701@alum.mit.edu> References: <50176CC9.80701@alum.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Subject: Re: [siprec] "==" padding in Metadata URN UUID [wasFW: [Insipid] Session-ID construction choices] X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 01:38:42 -0000 all the examples in the INSIPID drafts are in hex. There's been discussions for weeks to use hex, and that's the proposal on the table there, so I would suggest not making any decisions in SIPREC based on INSIPID using base64 - because that's not a sure thing at all at this point. James At 12:27 AM 7/31/2012, Paul Kyzivat wrote: >I don't have strong feelings either way. Just understand that >omitting the "==" locks us in to 64 bit values. That doesn't seem to >be a big constraint, since the spec we're referencing for the value >calls for 64 bits. > > Thanks, > Paul > >On 7/30/12 8:12 PM, Ram Mohan R (rmohanr) wrote: >>I am Ok too. >> >>Ram >> >>>On 30/07/12 10:44 PM, "Leon Portman" wrote: >> >>>I am OK >>> >>>Leon >>>On Jul 30, 2012, at 8:13 PM, "Ravindran, Parthasarathi" >>> wrote: >>> >>>>Hi all, >>>> >>>>Metadata uses based 64 encoding of URN UUID. There is a discussion in >>>>INSIPID WG to optimize "==" padding occurs due to base 64 URN UUID. I >>>>attached Paul's snip of the below mail thread. >>>> >>>> >>>>If we go with base64, I agree that we don't need to preserve the >>>>trailing "==". >>>> >>>> >>>>I'm fine with the optimization as it reduces 2 bytes in each URN UUID >>>>of metadata XML element. I'm interested in hearing WG opinion about this >>>>optimization. >>>> >>>>Thanks >>>>Partha >>>> >>>>-----Original Message----- >>>>From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >>>>Behalf Of Paul Kyzivat >>>>Sent: Thursday, July 26, 2012 8:30 PM >>>>To: Paul E. Jones >>>>Cc: 'James Polk'; insipid@ietf.org >>>>Subject: Re: [Insipid] Session-ID construction choices >>>> >>>>On 7/24/12 10:51 PM, Paul E. Jones wrote: >>>>>Paul, >>>>> >>>>>Following up on this thread, as I did not see an outcome. I think >>>>>this message might be the last in the series on this topic. >>>>> >>>>>I think your proposal is along the lines of what we originally >>>>>proposed. As I understand, there is a desire to always include both A >>>>>and B's halves. >>>>>That's fine, so long as devices understand they might change from one >>>>>message to the next. >>>>> >>>>>So given these two abbreviated UUIDs: >>>>> >>>>>UUID 1: 0xaeffa652 >>>>>UUID 2: 0xbe11afc8 >>>>> >>>>>We would have: >>>>> >>>>>Session-ID: 0xaeffa652be11afc8 >>>>> >>>>>If we agree to encode it in hex and agree on the size (a 16 octet >>>>>UUID), that means this will always be a 64-byte hex string and there >>>>>is no need to put a :. We could also base64 encode the 64 octet >>>>>binary value, which would encode in 44 octets (shaving off 20 octets). >>>>> >>>>>Do we want to go for reduced size or more readable hex string? >>>> >>>>I don't have a strong feeling about hex vs. base64. >>>>But I think it would be good to have a separator (I'm not attached to >>>>":" - that is just an example.) I realize it isn't logically necessary >>>>as long as the halves are fixed length. But its not very friendly, and I >>>>think it is worth "wasting" *1* byte on. >>>> >>>>If we go with base64, I agree that we don't need to preserve the >>>>trailing "==". >>>> >>>>>As for putting the entire Session-ID into messages, there are many >>>>>situations where the Session-ID will be wrong. Let me give you just >>>>>one example. >>>>> >>>>>Syntax: >>>>> A == B means A is in a call with B >>>>> >>>>>A == B&& A == C (A in call with B; A has a separate call with C.) >>>>> >>>>> && B == D (B has a separate call with D) >>>>> >>>>>A& B are talking. A puts B on hold. >>>>>A starts talking to C. >>>>>Meanwhile B puts A on hold and talks to D. >>>>> >>>>>A performs some action to join B and C, while at the same time B >>>>>performs some action to join D and C >>>>> >>>>>Assuming a PBX does this magic, we might have some INVITE messages >>>>>going down the wire like this: >>>>> >>>>> + INVITE ----> C (so C can talk to B) (Session-ID: B || C) >>>>>PBX1 ---| >>>>> + INVITE ----> B (so B can talk to C) (Session-ID: B || C) >>>>> >>>>>And we have >>>>> >>>>> + INVITE ----> A (so A can talk to D) (Session-ID: A || D) >>>>>PBX2 ---| >>>>> + INVITE ----> D (so D can talk to A) (Session-ID: A || D) >>>> >>>>I can't fully follow the above. My problem is that I don't know where >>>>PBX1 and PBX2 fit into the topology of A,B,C,D. So I'm not going to >>>>speculate much. >>>> >>>>>Now, these messages are passing on the wire at the same time. So that >>>>>message from PBX1 heading toward B is actually now heading toward D. >>>> >>>>??? >>>> >>>>>So, what D receives is Session-ID "B || C". D thought the Session-ID >>>>>was A >>>>>|| D. It will be confused. Perhaps PBX2 can massage the Session-ID, >>>>>|| but >>>>>it's not supposed to do that. We really don't want intermediaries to >>>>>touch it. >>>> >>>>Can you please map out the full topology, and a lot more of the call >>>>flow you have in mind. (Including REFERs, or some other indication of >>>>how the PBXs are being instructed what to do.) (There are a million ways >>>>this could be done.) >>>> >>>>>To avoid these kinds of race conditions, adding complexity to try to >>>>>straighten it out, etc., I very much prefer to have only the >>>>>Session-ID-UUID header that contains only the UUID of the sender of >>>>>the message. If we did that, the endpoints in the above scenario >>>>>would not be confused and the correct Session-ID could be noted in >>>>>logs. >>>> >>>>I'm not ready to leap to this conclusion until I understand the cases >>>>better. >>>> >>>> Thanks, >>>> Paul K >>>> >>>>>Paul >>>>> >>>>>>-----Original Message----- >>>>>>From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >>>>>>Behalf Of Paul Kyzivat >>>>>>Sent: Wednesday, July 11, 2012 7:38 PM >>>>>>To: James Polk >>>>>>Cc: insipid@ietf.org >>>>>>Subject: Re: [Insipid] Session-ID construction choices >>>>>> >>>>>>On 7/11/12 6:23 PM, James Polk wrote: >>>>>>... >>>>>>>>>Option#1 - attach a prefix (e.g., From: and To:) to each half >>>>>>... >>>>>>>>>We have a proposal going forward: insert the From:/To: tags from >>>>>>>>>Option #1. >>>>>>>>> >>>>>>>>>Does anyone have a technical reason why this wouldn't work? >>>>>>>> >>>>>>>>Do you mean to assign From and To once, and then keep it fixed for >>>>>>>>the duration of the dialog? ISTM that From and To are not well >>>>>>>>defined in all cases. >>>>>>>> >>>>>>>>For instance, consider a BTBUA that sets up a session by inviting >>>>>>>>both endpoints. Which is From and which is To? IIUC, the reason for >>>>>>>>labeling this way is so that someone observing a session id in a >>>>>>>>message can tell which half corresponds to which end. Using From >>>>>>>>and To won't satisfy that unless those tags are reassigned for each >>>>>>request. >>>>>>>>(This is a special case of a conference focus, which you already >>>>>>>>call out as an exception.) >>>>>>> >>>>>>>The desire is to have the same half in the same position throughout >>>>>>>the transaction or dialog (whichever it is). I believe in the case >>>>>>>of a B2BUA initiating or originating the transaction or dialog on >>>>>>>behalf of other endpoint UAs, the B2BUA would pick which Session-ID >>>>>>>is the From and which is the To. IOW - we don't make it a >>>>>>>requirement on an implementation that Alice is always inserting her >>>>>>>half in first, and Bob in as the second half. If the B2BUA is >>>>>>>sending an INVITE to both Alice and Bob, then that's 2 separate >>>>>>>Session-IDs because it's two different dialogs, even if a 3rd party >>>>>>>isn't part (i.e., listening) of the media flow. This would be a hub >>>>>>>and 2 spokes in which the hub doesn't listen or interact with the >>>>>>>media of the 2 UAs. >>>>>>> >>>>>>>We could also have text that says for this scenario, that an INVITE >>>>>>>normally inserts the From half of the Session-ID, but that in this >>>>>>>scenario it can insert the To: half and the invitee inserts the To >>>>>>>half. >>>>>>> >>>>>>> >>>>>>>>Identifying which end is which is easy for any single transaction, >>>>>>> >>>>>>>agreed >>>>>>> >>>>>>>>but hard if you want to use the same identifiers in every message. >>>>>>>>The endpoints can easily figure this out, because they should know >>>>>>>>their half, and the half that isn't theirs is the other end's. But >>>>>>>>its not simple for middleboxes. >>>>>>> >>>>>>>remember that each half is a UUID or GUID, which will always be a >>>>>>>unique value through space and time. >>>>>>> >>>>>>> >>>>>>>>The solution that is used for dialog ids is to use To and From, but >>>>>>>>they must be reassigned depending on the direction of the message. >>>>>>>>We could do the same for session id, but only if they are remapped >>>>>>>>based on the direction of the request. >>>>>>> >>>>>>>I guess I'm no getting why the halves need to switch places yet >>>>>>>depending on whether it's in a request or response. Or are you >>>>>>>saying that for one complete transaction they are in a certain >>>>>>>order, but in a related transaction(s) they are possibly in the >>>>>>>reverse order - depending on who sent the message? >>>>>> >>>>>>When a message is sent in the reverse direction from the dialog >>>>>>establishing message, the From URI and To URI are reversed, as well >>>>>>as the From and To tags. If the session id still has its halves >>>>>>tagged consistent with the from and to of the dialog establishing >>>>>>request, then you will get confused about which half goes with which >>>>>>end. >>>>>> >>>>>>There is no problem for servers that keep state and remember the >>>>>>values for each end. For them we don't need to tag the halves at all. >>>>>> >>>>>>There is also no problem for those who don't *care* which end is >>>>>>which. >>>>>>And there may be a lot of those. >>>>>> >>>>>>This tagging is only there for those who don't keep state yet need to >>>>>>know. Maybe there aren't any of those, in which case we can stop >>>>>>worrying about it. >>>>>> >>>>>>I guess an example that might matter is something analyzing logs, and >>>>>>doesn't have a complete set of logs available to it - in particular >>>>>>it doesn't have a log of the initial signaling that set up the >>>>>>session, so it can't figure out which half-id belongs to which end. >>>>>> >>>>>>Then it sees a change - it sees a message where half of the id >>>>>>matches prior things, but the other half doesn't - is new. From this >>>>>>it can perhaps infer that there was a transfer. And in that case it >>>>>>will want to know which end remains and which was replaced. But it >>>>>>can't figure that out from which half of the id changed without >>>>>>knowing the mapping from half to end. >>>>>> >>>>>>But I will be the first to say that this case is somewhat implausible. >>>>>>In practice there will be lots of stuff in the messages being >>>>>>analyzed that should support figuring this out. Perhaps this just >>>>>>isn't a good example, and there is another that is better. But I >>>>>>don't know a better one. Anybody else? (I think Paul J was the one >>>>>>who raised this concern, so maybe he has an example.) >>>>>> >>>>>>If we can't find a plausible reason why we need to do this mapping, >>>>>>then I propose that we just not bother. In that case I think >>>>>>representation >>>>>>#3 is attractive. It provides for the easiest comparison between id >>>>>>values >>>>>>- a single string comparison is sufficient. And its among the most >>>>>>compact representations. I'd recommend: >>>>>> >>>>>> session-id: SmallestHalf:BiggestHalf >>>>>> >>>>>>Or just >>>>>> >>>>>> session-id: FirstHalf >>>>>> >>>>>>before the half for the far end has been assigned. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>>_______________________________________________ >>>>>>insipid mailing list >>>>>>insipid@ietf.org >>>>>>https://www.ietf.org/mailman/listinfo/insipid >>>>> >>>> >>>>_______________________________________________ >>>>insipid mailing list >>>>insipid@ietf.org >>>>https://www.ietf.org/mailman/listinfo/insipid >>>>_______________________________________________ >>>>siprec mailing list >>>>siprec@ietf.org >>>>https://www.ietf.org/mailman/listinfo/siprec >>> >>>_______________________________________________ >>>siprec mailing list >>>siprec@ietf.org >>>https://www.ietf.org/mailman/listinfo/siprec >> >> >>_______________________________________________ >>siprec mailing list >>siprec@ietf.org >>https://www.ietf.org/mailman/listinfo/siprec > >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@alum.mit.edu Thu Aug 2 19:09:11 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F12821F8BD7 for ; Thu, 2 Aug 2012 19:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.373 X-Spam-Level: X-Spam-Status: No, score=-0.373 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVy+muzaExwx for ; Thu, 2 Aug 2012 19:09:09 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 3165721F8650 for ; Thu, 2 Aug 2012 19:09:08 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta02.westchester.pa.mail.comcast.net with comcast id i1wW1j0030QuhwU5129BnV; Fri, 03 Aug 2012 02:09:11 +0000 Received: from dhcp-40e5.meeting.ietf.org ([IPv6:2001:df8:0:64:19d6:c06f:f140:d490]) by omta02.westchester.pa.mail.comcast.net with comcast id i28w1j0093NDGqc3N28wb9; Fri, 03 Aug 2012 02:08:57 +0000 Message-ID: <501B32C1.7040905@alum.mit.edu> Date: Thu, 02 Aug 2012 19:09:05 -0700 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: siprec@ietf.org References: <50176CC9.80701@alum.mit.edu> <201208030138.q731cdMR026288@mtv-core-2.cisco.com> In-Reply-To: <201208030138.q731cdMR026288@mtv-core-2.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [siprec] "==" padding in Metadata URN UUID [wasFW: [Insipid] Session-ID construction choices] X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 02:09:11 -0000 On 8/2/12 6:38 PM, James Polk wrote: > all the examples in the INSIPID drafts are in hex. There's been > discussions for weeks to use hex, and that's the proposal on the table > there, so I would suggest not making any decisions in SIPREC based on > INSIPID using base64 - because that's not a sure thing at all at this > point. We had a discussion of this in the siprec meeting today. There was violent objection from Joe Hildebrand and Hadriel not to do this because it would make it harder to use standard libraries to do the encode/decode. I'm not an XML guy, so I guess I'll defer to them on that part, though it seems trivial to me to append "==" before calling the decoder and strip the "==" after calling the encoder. But if the conversions are automatic based on the declared typing in the schema then I guess I can see why it might be harder than that. At the end of the day I don't really care. So I'll defer to someone who does. Thanks, Paul > James > > At 12:27 AM 7/31/2012, Paul Kyzivat wrote: >> I don't have strong feelings either way. Just understand that omitting >> the "==" locks us in to 64 bit values. That doesn't seem to be a big >> constraint, since the spec we're referencing for the value calls for >> 64 bits. >> >> Thanks, >> Paul >> >> On 7/30/12 8:12 PM, Ram Mohan R (rmohanr) wrote: >>> I am Ok too. >>> >>> Ram >>> >>>> On 30/07/12 10:44 PM, "Leon Portman" wrote: >>> >>>> I am OK >>>> >>>> Leon >>>> On Jul 30, 2012, at 8:13 PM, "Ravindran, Parthasarathi" >>>> wrote: >>>> >>>>> Hi all, >>>>> >>>>> Metadata uses based 64 encoding of URN UUID. There is a discussion in >>>>> INSIPID WG to optimize "==" padding occurs due to base 64 URN UUID. I >>>>> attached Paul's snip of the below mail thread. >>>>> >>>>> >>>>> If we go with base64, I agree that we don't need to preserve the >>>>> trailing "==". >>>>> >>>>> >>>>> I'm fine with the optimization as it reduces 2 bytes in each URN UUID >>>>> of metadata XML element. I'm interested in hearing WG opinion about >>>>> this >>>>> optimization. >>>>> >>>>> Thanks >>>>> Partha >>>>> >>>>> -----Original Message----- >>>>> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >>>>> Behalf Of Paul Kyzivat >>>>> Sent: Thursday, July 26, 2012 8:30 PM >>>>> To: Paul E. Jones >>>>> Cc: 'James Polk'; insipid@ietf.org >>>>> Subject: Re: [Insipid] Session-ID construction choices >>>>> >>>>> On 7/24/12 10:51 PM, Paul E. Jones wrote: >>>>>> Paul, >>>>>> >>>>>> Following up on this thread, as I did not see an outcome. I think >>>>>> this message might be the last in the series on this topic. >>>>>> >>>>>> I think your proposal is along the lines of what we originally >>>>>> proposed. As I understand, there is a desire to always include both A >>>>>> and B's halves. >>>>>> That's fine, so long as devices understand they might change from one >>>>>> message to the next. >>>>>> >>>>>> So given these two abbreviated UUIDs: >>>>>> >>>>>> UUID 1: 0xaeffa652 >>>>>> UUID 2: 0xbe11afc8 >>>>>> >>>>>> We would have: >>>>>> >>>>>> Session-ID: 0xaeffa652be11afc8 >>>>>> >>>>>> If we agree to encode it in hex and agree on the size (a 16 octet >>>>>> UUID), that means this will always be a 64-byte hex string and there >>>>>> is no need to put a :. We could also base64 encode the 64 octet >>>>>> binary value, which would encode in 44 octets (shaving off 20 >>>>>> octets). >>>>>> >>>>>> Do we want to go for reduced size or more readable hex string? >>>>> >>>>> I don't have a strong feeling about hex vs. base64. >>>>> But I think it would be good to have a separator (I'm not attached to >>>>> ":" - that is just an example.) I realize it isn't logically necessary >>>>> as long as the halves are fixed length. But its not very friendly, >>>>> and I >>>>> think it is worth "wasting" *1* byte on. >>>>> >>>>> If we go with base64, I agree that we don't need to preserve the >>>>> trailing "==". >>>>> >>>>>> As for putting the entire Session-ID into messages, there are many >>>>>> situations where the Session-ID will be wrong. Let me give you just >>>>>> one example. >>>>>> >>>>>> Syntax: >>>>>> A == B means A is in a call with B >>>>>> >>>>>> A == B&& A == C (A in call with B; A has a separate call with C.) >>>>>> >>>>>> && B == D (B has a separate call with D) >>>>>> >>>>>> A& B are talking. A puts B on hold. >>>>>> A starts talking to C. >>>>>> Meanwhile B puts A on hold and talks to D. >>>>>> >>>>>> A performs some action to join B and C, while at the same time B >>>>>> performs some action to join D and C >>>>>> >>>>>> Assuming a PBX does this magic, we might have some INVITE messages >>>>>> going down the wire like this: >>>>>> >>>>>> + INVITE ----> C (so C can talk to B) (Session-ID: B || C) >>>>>> PBX1 ---| >>>>>> + INVITE ----> B (so B can talk to C) (Session-ID: B || C) >>>>>> >>>>>> And we have >>>>>> >>>>>> + INVITE ----> A (so A can talk to D) (Session-ID: A || D) >>>>>> PBX2 ---| >>>>>> + INVITE ----> D (so D can talk to A) (Session-ID: A || D) >>>>> >>>>> I can't fully follow the above. My problem is that I don't know where >>>>> PBX1 and PBX2 fit into the topology of A,B,C,D. So I'm not going to >>>>> speculate much. >>>>> >>>>>> Now, these messages are passing on the wire at the same time. So that >>>>>> message from PBX1 heading toward B is actually now heading toward D. >>>>> >>>>> ??? >>>>> >>>>>> So, what D receives is Session-ID "B || C". D thought the Session-ID >>>>>> was A >>>>>> || D. It will be confused. Perhaps PBX2 can massage the Session-ID, >>>>>> || but >>>>>> it's not supposed to do that. We really don't want intermediaries to >>>>>> touch it. >>>>> >>>>> Can you please map out the full topology, and a lot more of the call >>>>> flow you have in mind. (Including REFERs, or some other indication of >>>>> how the PBXs are being instructed what to do.) (There are a million >>>>> ways >>>>> this could be done.) >>>>> >>>>>> To avoid these kinds of race conditions, adding complexity to try to >>>>>> straighten it out, etc., I very much prefer to have only the >>>>>> Session-ID-UUID header that contains only the UUID of the sender of >>>>>> the message. If we did that, the endpoints in the above scenario >>>>>> would not be confused and the correct Session-ID could be noted in >>>>>> logs. >>>>> >>>>> I'm not ready to leap to this conclusion until I understand the cases >>>>> better. >>>>> >>>>> Thanks, >>>>> Paul K >>>>> >>>>>> Paul >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >>>>>>> Behalf Of Paul Kyzivat >>>>>>> Sent: Wednesday, July 11, 2012 7:38 PM >>>>>>> To: James Polk >>>>>>> Cc: insipid@ietf.org >>>>>>> Subject: Re: [Insipid] Session-ID construction choices >>>>>>> >>>>>>> On 7/11/12 6:23 PM, James Polk wrote: >>>>>>> ... >>>>>>>>>> Option#1 - attach a prefix (e.g., From: and To:) to each half >>>>>>> ... >>>>>>>>>> We have a proposal going forward: insert the From:/To: tags from >>>>>>>>>> Option #1. >>>>>>>>>> >>>>>>>>>> Does anyone have a technical reason why this wouldn't work? >>>>>>>>> >>>>>>>>> Do you mean to assign From and To once, and then keep it fixed for >>>>>>>>> the duration of the dialog? ISTM that From and To are not well >>>>>>>>> defined in all cases. >>>>>>>>> >>>>>>>>> For instance, consider a BTBUA that sets up a session by inviting >>>>>>>>> both endpoints. Which is From and which is To? IIUC, the reason >>>>>>>>> for >>>>>>>>> labeling this way is so that someone observing a session id in a >>>>>>>>> message can tell which half corresponds to which end. Using From >>>>>>>>> and To won't satisfy that unless those tags are reassigned for >>>>>>>>> each >>>>>>> request. >>>>>>>>> (This is a special case of a conference focus, which you already >>>>>>>>> call out as an exception.) >>>>>>>> >>>>>>>> The desire is to have the same half in the same position throughout >>>>>>>> the transaction or dialog (whichever it is). I believe in the case >>>>>>>> of a B2BUA initiating or originating the transaction or dialog on >>>>>>>> behalf of other endpoint UAs, the B2BUA would pick which Session-ID >>>>>>>> is the From and which is the To. IOW - we don't make it a >>>>>>>> requirement on an implementation that Alice is always inserting her >>>>>>>> half in first, and Bob in as the second half. If the B2BUA is >>>>>>>> sending an INVITE to both Alice and Bob, then that's 2 separate >>>>>>>> Session-IDs because it's two different dialogs, even if a 3rd party >>>>>>>> isn't part (i.e., listening) of the media flow. This would be a hub >>>>>>>> and 2 spokes in which the hub doesn't listen or interact with the >>>>>>>> media of the 2 UAs. >>>>>>>> >>>>>>>> We could also have text that says for this scenario, that an INVITE >>>>>>>> normally inserts the From half of the Session-ID, but that in this >>>>>>>> scenario it can insert the To: half and the invitee inserts the To >>>>>>>> half. >>>>>>>> >>>>>>>> >>>>>>>>> Identifying which end is which is easy for any single transaction, >>>>>>>> >>>>>>>> agreed >>>>>>>> >>>>>>>>> but hard if you want to use the same identifiers in every message. >>>>>>>>> The endpoints can easily figure this out, because they should know >>>>>>>>> their half, and the half that isn't theirs is the other end's. But >>>>>>>>> its not simple for middleboxes. >>>>>>>> >>>>>>>> remember that each half is a UUID or GUID, which will always be a >>>>>>>> unique value through space and time. >>>>>>>> >>>>>>>> >>>>>>>>> The solution that is used for dialog ids is to use To and From, >>>>>>>>> but >>>>>>>>> they must be reassigned depending on the direction of the message. >>>>>>>>> We could do the same for session id, but only if they are remapped >>>>>>>>> based on the direction of the request. >>>>>>>> >>>>>>>> I guess I'm no getting why the halves need to switch places yet >>>>>>>> depending on whether it's in a request or response. Or are you >>>>>>>> saying that for one complete transaction they are in a certain >>>>>>>> order, but in a related transaction(s) they are possibly in the >>>>>>>> reverse order - depending on who sent the message? >>>>>>> >>>>>>> When a message is sent in the reverse direction from the dialog >>>>>>> establishing message, the From URI and To URI are reversed, as well >>>>>>> as the From and To tags. If the session id still has its halves >>>>>>> tagged consistent with the from and to of the dialog establishing >>>>>>> request, then you will get confused about which half goes with which >>>>>>> end. >>>>>>> >>>>>>> There is no problem for servers that keep state and remember the >>>>>>> values for each end. For them we don't need to tag the halves at >>>>>>> all. >>>>>>> >>>>>>> There is also no problem for those who don't *care* which end is >>>>>>> which. >>>>>>> And there may be a lot of those. >>>>>>> >>>>>>> This tagging is only there for those who don't keep state yet >>>>>>> need to >>>>>>> know. Maybe there aren't any of those, in which case we can stop >>>>>>> worrying about it. >>>>>>> >>>>>>> I guess an example that might matter is something analyzing logs, >>>>>>> and >>>>>>> doesn't have a complete set of logs available to it - in particular >>>>>>> it doesn't have a log of the initial signaling that set up the >>>>>>> session, so it can't figure out which half-id belongs to which end. >>>>>>> >>>>>>> Then it sees a change - it sees a message where half of the id >>>>>>> matches prior things, but the other half doesn't - is new. From this >>>>>>> it can perhaps infer that there was a transfer. And in that case it >>>>>>> will want to know which end remains and which was replaced. But it >>>>>>> can't figure that out from which half of the id changed without >>>>>>> knowing the mapping from half to end. >>>>>>> >>>>>>> But I will be the first to say that this case is somewhat >>>>>>> implausible. >>>>>>> In practice there will be lots of stuff in the messages being >>>>>>> analyzed that should support figuring this out. Perhaps this just >>>>>>> isn't a good example, and there is another that is better. But I >>>>>>> don't know a better one. Anybody else? (I think Paul J was the one >>>>>>> who raised this concern, so maybe he has an example.) >>>>>>> >>>>>>> If we can't find a plausible reason why we need to do this mapping, >>>>>>> then I propose that we just not bother. In that case I think >>>>>>> representation >>>>>>> #3 is attractive. It provides for the easiest comparison between id >>>>>>> values >>>>>>> - a single string comparison is sufficient. And its among the most >>>>>>> compact representations. I'd recommend: >>>>>>> >>>>>>> session-id: SmallestHalf:BiggestHalf >>>>>>> >>>>>>> Or just >>>>>>> >>>>>>> session-id: FirstHalf >>>>>>> >>>>>>> before the half for the far end has been assigned. >>>>>>> >>>>>>> Thanks, >>>>>>> Paul >>>>>>> _______________________________________________ >>>>>>> insipid mailing list >>>>>>> insipid@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/insipid >>>>>> >>>>> >>>>> _______________________________________________ >>>>> insipid mailing list >>>>> insipid@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/insipid >>>>> _______________________________________________ >>>>> siprec mailing list >>>>> siprec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/siprec >>>> >>>> _______________________________________________ >>>> siprec mailing list >>>> siprec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/siprec >>> >>> >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > From jmpolk@cisco.com Thu Aug 2 23:51:27 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB4FE11E80D5 for ; Thu, 2 Aug 2012 23:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.515 X-Spam-Level: X-Spam-Status: No, score=-110.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdNB8AlspEWR for ; Thu, 2 Aug 2012 23:51:26 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 4BCD111E809A for ; Thu, 2 Aug 2012 23:51:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=14930; q=dns/txt; s=iport; t=1343976686; x=1345186286; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=WBw+wsDnpSKnHJVl48n3dYpd0WdwmY3TTsnMgvSnjvY=; b=CFwhjRvHPWGU6vRX0xZf043LmaseHp+ze2uSz1uZ/++jf4YJerK29r43 NXh3fSltyqCQhZzKQGTi0i6flbH5ruWruC8GxQP4oihjrAYomu9OZSLnZ L/14uuGdSCSKg8wVR0WT2mlmmLqXlzYPcCO4WFKPRcTTvkqrR/w7H7VKR M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAI50G1CrRDoH/2dsb2JhbABFDrkYgQeCIAEBAQQBAQEPARQRAi4GFwQHBA4DBAEBAR4JBxkIBh8JCAYBCQkbB4dcAwsMnQmWXA2JSgSKYGcahmoDiE2LKIxdgx2BZoImV4FB X-IronPort-AV: E=Sophos;i="4.77,705,1336348800"; d="scan'208";a="51382422" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 03 Aug 2012 06:51:25 +0000 Received: from jmpolk-WS.cisco.com ([10.21.166.106]) (authenticated bits=0) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q736pOWo027248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Aug 2012 06:51:24 GMT Message-Id: <201208030651.q736pOWo027248@mtv-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 03 Aug 2012 01:51:24 -0500 To: Paul Kyzivat , From: James Polk In-Reply-To: <501B32C1.7040905@alum.mit.edu> References: <50176CC9.80701@alum.mit.edu> <201208030138.q731cdMR026288@mtv-core-2.cisco.com> <501B32C1.7040905@alum.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Subject: Re: [siprec] "==" padding in Metadata URN UUID [wasFW: [Insipid] Session-ID construction choices] X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 06:51:28 -0000 At 09:09 PM 8/2/2012, Paul Kyzivat wrote: >On 8/2/12 6:38 PM, James Polk wrote: >>all the examples in the INSIPID drafts are in hex. There's been >>discussions for weeks to use hex, and that's the proposal on the table >>there, so I would suggest not making any decisions in SIPREC based on >>INSIPID using base64 - because that's not a sure thing at all at this >>point. > >We had a discussion of this in the siprec meeting today. There was >violent objection from Joe Hildebrand and Hadriel not to do this Paul - which do you mean when you say "this"? IOW, were Joe and Hadriel violently against base64 or hex? Hadriel was in INSIPID when I mentioned the UUID is a RFC 4122 defined 32 byte hex value, and he didn't leap out of his chair to jump my (you know what), but I don't want to assume which way he agrees with or disagrees with. James >because it would make it harder to use standard libraries to do the >encode/decode. > >I'm not an XML guy, so I guess I'll defer to them on that part, >though it seems trivial to me to append "==" before calling the >decoder and strip the "==" after calling the encoder. But if the >conversions are automatic based on the declared typing in the schema >then I guess I can see why it might be harder than that. > >At the end of the day I don't really care. So I'll defer to someone who does. > > Thanks, > Paul > >>James >> >>At 12:27 AM 7/31/2012, Paul Kyzivat wrote: >>>I don't have strong feelings either way. Just understand that omitting >>>the "==" locks us in to 64 bit values. That doesn't seem to be a big >>>constraint, since the spec we're referencing for the value calls for >>>64 bits. >>> >>>Thanks, >>>Paul >>> >>>On 7/30/12 8:12 PM, Ram Mohan R (rmohanr) wrote: >>>>I am Ok too. >>>> >>>>Ram >>>> >>>>>On 30/07/12 10:44 PM, "Leon Portman" wrote: >>>> >>>>>I am OK >>>>> >>>>>Leon >>>>>On Jul 30, 2012, at 8:13 PM, "Ravindran, Parthasarathi" >>>>> wrote: >>>>> >>>>>>Hi all, >>>>>> >>>>>>Metadata uses based 64 encoding of URN UUID. There is a discussion in >>>>>>INSIPID WG to optimize "==" padding occurs due to base 64 URN UUID. I >>>>>>attached Paul's snip of the below mail thread. >>>>>> >>>>>> >>>>>>If we go with base64, I agree that we don't need to preserve the >>>>>>trailing "==". >>>>>> >>>>>> >>>>>>I'm fine with the optimization as it reduces 2 bytes in each URN UUID >>>>>>of metadata XML element. I'm interested in hearing WG opinion about >>>>>>this >>>>>>optimization. >>>>>> >>>>>>Thanks >>>>>>Partha >>>>>> >>>>>>-----Original Message----- >>>>>>From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >>>>>>Behalf Of Paul Kyzivat >>>>>>Sent: Thursday, July 26, 2012 8:30 PM >>>>>>To: Paul E. Jones >>>>>>Cc: 'James Polk'; insipid@ietf.org >>>>>>Subject: Re: [Insipid] Session-ID construction choices >>>>>> >>>>>>On 7/24/12 10:51 PM, Paul E. Jones wrote: >>>>>>>Paul, >>>>>>> >>>>>>>Following up on this thread, as I did not see an outcome. I think >>>>>>>this message might be the last in the series on this topic. >>>>>>> >>>>>>>I think your proposal is along the lines of what we originally >>>>>>>proposed. As I understand, there is a desire to always include both A >>>>>>>and B's halves. >>>>>>>That's fine, so long as devices understand they might change from one >>>>>>>message to the next. >>>>>>> >>>>>>>So given these two abbreviated UUIDs: >>>>>>> >>>>>>>UUID 1: 0xaeffa652 >>>>>>>UUID 2: 0xbe11afc8 >>>>>>> >>>>>>>We would have: >>>>>>> >>>>>>>Session-ID: 0xaeffa652be11afc8 >>>>>>> >>>>>>>If we agree to encode it in hex and agree on the size (a 16 octet >>>>>>>UUID), that means this will always be a 64-byte hex string and there >>>>>>>is no need to put a :. We could also base64 encode the 64 octet >>>>>>>binary value, which would encode in 44 octets (shaving off 20 >>>>>>>octets). >>>>>>> >>>>>>>Do we want to go for reduced size or more readable hex string? >>>>>> >>>>>>I don't have a strong feeling about hex vs. base64. >>>>>>But I think it would be good to have a separator (I'm not attached to >>>>>>":" - that is just an example.) I realize it isn't logically necessary >>>>>>as long as the halves are fixed length. But its not very friendly, >>>>>>and I >>>>>>think it is worth "wasting" *1* byte on. >>>>>> >>>>>>If we go with base64, I agree that we don't need to preserve the >>>>>>trailing "==". >>>>>> >>>>>>>As for putting the entire Session-ID into messages, there are many >>>>>>>situations where the Session-ID will be wrong. Let me give you just >>>>>>>one example. >>>>>>> >>>>>>>Syntax: >>>>>>>A == B means A is in a call with B >>>>>>> >>>>>>>A == B&& A == C (A in call with B; A has a separate call with C.) >>>>>>> >>>>>>>&& B == D (B has a separate call with D) >>>>>>> >>>>>>>A& B are talking. A puts B on hold. >>>>>>>A starts talking to C. >>>>>>>Meanwhile B puts A on hold and talks to D. >>>>>>> >>>>>>>A performs some action to join B and C, while at the same time B >>>>>>>performs some action to join D and C >>>>>>> >>>>>>>Assuming a PBX does this magic, we might have some INVITE messages >>>>>>>going down the wire like this: >>>>>>> >>>>>>>+ INVITE ----> C (so C can talk to B) (Session-ID: B || C) >>>>>>>PBX1 ---| >>>>>>>+ INVITE ----> B (so B can talk to C) (Session-ID: B || C) >>>>>>> >>>>>>>And we have >>>>>>> >>>>>>>+ INVITE ----> A (so A can talk to D) (Session-ID: A || D) >>>>>>>PBX2 ---| >>>>>>>+ INVITE ----> D (so D can talk to A) (Session-ID: A || D) >>>>>> >>>>>>I can't fully follow the above. My problem is that I don't know where >>>>>>PBX1 and PBX2 fit into the topology of A,B,C,D. So I'm not going to >>>>>>speculate much. >>>>>> >>>>>>>Now, these messages are passing on the wire at the same time. So that >>>>>>>message from PBX1 heading toward B is actually now heading toward D. >>>>>> >>>>>>??? >>>>>> >>>>>>>So, what D receives is Session-ID "B || C". D thought the Session-ID >>>>>>>was A >>>>>>>|| D. It will be confused. Perhaps PBX2 can massage the Session-ID, >>>>>>>|| but >>>>>>>it's not supposed to do that. We really don't want intermediaries to >>>>>>>touch it. >>>>>> >>>>>>Can you please map out the full topology, and a lot more of the call >>>>>>flow you have in mind. (Including REFERs, or some other indication of >>>>>>how the PBXs are being instructed what to do.) (There are a million >>>>>>ways >>>>>>this could be done.) >>>>>> >>>>>>>To avoid these kinds of race conditions, adding complexity to try to >>>>>>>straighten it out, etc., I very much prefer to have only the >>>>>>>Session-ID-UUID header that contains only the UUID of the sender of >>>>>>>the message. If we did that, the endpoints in the above scenario >>>>>>>would not be confused and the correct Session-ID could be noted in >>>>>>>logs. >>>>>> >>>>>>I'm not ready to leap to this conclusion until I understand the cases >>>>>>better. >>>>>> >>>>>>Thanks, >>>>>>Paul K >>>>>> >>>>>>>Paul >>>>>>> >>>>>>>>-----Original Message----- >>>>>>>>From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >>>>>>>>Behalf Of Paul Kyzivat >>>>>>>>Sent: Wednesday, July 11, 2012 7:38 PM >>>>>>>>To: James Polk >>>>>>>>Cc: insipid@ietf.org >>>>>>>>Subject: Re: [Insipid] Session-ID construction choices >>>>>>>> >>>>>>>>On 7/11/12 6:23 PM, James Polk wrote: >>>>>>>>... >>>>>>>>>>>Option#1 - attach a prefix (e.g., From: and To:) to each half >>>>>>>>... >>>>>>>>>>>We have a proposal going forward: insert the From:/To: tags from >>>>>>>>>>>Option #1. >>>>>>>>>>> >>>>>>>>>>>Does anyone have a technical reason why this wouldn't work? >>>>>>>>>> >>>>>>>>>>Do you mean to assign From and To once, and then keep it fixed for >>>>>>>>>>the duration of the dialog? ISTM that From and To are not well >>>>>>>>>>defined in all cases. >>>>>>>>>> >>>>>>>>>>For instance, consider a BTBUA that sets up a session by inviting >>>>>>>>>>both endpoints. Which is From and which is To? IIUC, the reason >>>>>>>>>>for >>>>>>>>>>labeling this way is so that someone observing a session id in a >>>>>>>>>>message can tell which half corresponds to which end. Using From >>>>>>>>>>and To won't satisfy that unless those tags are reassigned for >>>>>>>>>>each >>>>>>>>request. >>>>>>>>>>(This is a special case of a conference focus, which you already >>>>>>>>>>call out as an exception.) >>>>>>>>> >>>>>>>>>The desire is to have the same half in the same position throughout >>>>>>>>>the transaction or dialog (whichever it is). I believe in the case >>>>>>>>>of a B2BUA initiating or originating the transaction or dialog on >>>>>>>>>behalf of other endpoint UAs, the B2BUA would pick which Session-ID >>>>>>>>>is the From and which is the To. IOW - we don't make it a >>>>>>>>>requirement on an implementation that Alice is always inserting her >>>>>>>>>half in first, and Bob in as the second half. If the B2BUA is >>>>>>>>>sending an INVITE to both Alice and Bob, then that's 2 separate >>>>>>>>>Session-IDs because it's two different dialogs, even if a 3rd party >>>>>>>>>isn't part (i.e., listening) of the media flow. This would be a hub >>>>>>>>>and 2 spokes in which the hub doesn't listen or interact with the >>>>>>>>>media of the 2 UAs. >>>>>>>>> >>>>>>>>>We could also have text that says for this scenario, that an INVITE >>>>>>>>>normally inserts the From half of the Session-ID, but that in this >>>>>>>>>scenario it can insert the To: half and the invitee inserts the To >>>>>>>>>half. >>>>>>>>> >>>>>>>>> >>>>>>>>>>Identifying which end is which is easy for any single transaction, >>>>>>>>> >>>>>>>>>agreed >>>>>>>>> >>>>>>>>>>but hard if you want to use the same identifiers in every message. >>>>>>>>>>The endpoints can easily figure this out, because they should know >>>>>>>>>>their half, and the half that isn't theirs is the other end's. But >>>>>>>>>>its not simple for middleboxes. >>>>>>>>> >>>>>>>>>remember that each half is a UUID or GUID, which will always be a >>>>>>>>>unique value through space and time. >>>>>>>>> >>>>>>>>> >>>>>>>>>>The solution that is used for dialog ids is to use To and From, >>>>>>>>>>but >>>>>>>>>>they must be reassigned depending on the direction of the message. >>>>>>>>>>We could do the same for session id, but only if they are remapped >>>>>>>>>>based on the direction of the request. >>>>>>>>> >>>>>>>>>I guess I'm no getting why the halves need to switch places yet >>>>>>>>>depending on whether it's in a request or response. Or are you >>>>>>>>>saying that for one complete transaction they are in a certain >>>>>>>>>order, but in a related transaction(s) they are possibly in the >>>>>>>>>reverse order - depending on who sent the message? >>>>>>>> >>>>>>>>When a message is sent in the reverse direction from the dialog >>>>>>>>establishing message, the From URI and To URI are reversed, as well >>>>>>>>as the From and To tags. If the session id still has its halves >>>>>>>>tagged consistent with the from and to of the dialog establishing >>>>>>>>request, then you will get confused about which half goes with which >>>>>>>>end. >>>>>>>> >>>>>>>>There is no problem for servers that keep state and remember the >>>>>>>>values for each end. For them we don't need to tag the halves at >>>>>>>>all. >>>>>>>> >>>>>>>>There is also no problem for those who don't *care* which end is >>>>>>>>which. >>>>>>>>And there may be a lot of those. >>>>>>>> >>>>>>>>This tagging is only there for those who don't keep state yet >>>>>>>>need to >>>>>>>>know. Maybe there aren't any of those, in which case we can stop >>>>>>>>worrying about it. >>>>>>>> >>>>>>>>I guess an example that might matter is something analyzing logs, >>>>>>>>and >>>>>>>>doesn't have a complete set of logs available to it - in particular >>>>>>>>it doesn't have a log of the initial signaling that set up the >>>>>>>>session, so it can't figure out which half-id belongs to which end. >>>>>>>> >>>>>>>>Then it sees a change - it sees a message where half of the id >>>>>>>>matches prior things, but the other half doesn't - is new. From this >>>>>>>>it can perhaps infer that there was a transfer. And in that case it >>>>>>>>will want to know which end remains and which was replaced. But it >>>>>>>>can't figure that out from which half of the id changed without >>>>>>>>knowing the mapping from half to end. >>>>>>>> >>>>>>>>But I will be the first to say that this case is somewhat >>>>>>>>implausible. >>>>>>>>In practice there will be lots of stuff in the messages being >>>>>>>>analyzed that should support figuring this out. Perhaps this just >>>>>>>>isn't a good example, and there is another that is better. But I >>>>>>>>don't know a better one. Anybody else? (I think Paul J was the one >>>>>>>>who raised this concern, so maybe he has an example.) >>>>>>>> >>>>>>>>If we can't find a plausible reason why we need to do this mapping, >>>>>>>>then I propose that we just not bother. In that case I think >>>>>>>>representation >>>>>>>>#3 is attractive. It provides for the easiest comparison between id >>>>>>>>values >>>>>>>>- a single string comparison is sufficient. And its among the most >>>>>>>>compact representations. I'd recommend: >>>>>>>> >>>>>>>>session-id: SmallestHalf:BiggestHalf >>>>>>>> >>>>>>>>Or just >>>>>>>> >>>>>>>>session-id: FirstHalf >>>>>>>> >>>>>>>>before the half for the far end has been assigned. >>>>>>>> >>>>>>>>Thanks, >>>>>>>>Paul >>>>>>>>_______________________________________________ >>>>>>>>insipid mailing list >>>>>>>>insipid@ietf.org >>>>>>>>https://www.ietf.org/mailman/listinfo/insipid >>>>>> >>>>>>_______________________________________________ >>>>>>insipid mailing list >>>>>>insipid@ietf.org >>>>>>https://www.ietf.org/mailman/listinfo/insipid >>>>>>_______________________________________________ >>>>>>siprec mailing list >>>>>>siprec@ietf.org >>>>>>https://www.ietf.org/mailman/listinfo/siprec >>>>> >>>>>_______________________________________________ >>>>>siprec mailing list >>>>>siprec@ietf.org >>>>>https://www.ietf.org/mailman/listinfo/siprec >>>> >>>> >>>>_______________________________________________ >>>>siprec mailing list >>>>siprec@ietf.org >>>>https://www.ietf.org/mailman/listinfo/siprec >>> >>>_______________________________________________ >>>siprec mailing list >>>siprec@ietf.org >>>https://www.ietf.org/mailman/listinfo/siprec >> >>_______________________________________________ >>siprec mailing list >>siprec@ietf.org >>https://www.ietf.org/mailman/listinfo/siprec > >_______________________________________________ >siprec mailing list >siprec@ietf.org >https://www.ietf.org/mailman/listinfo/siprec From pkyzivat@alum.mit.edu Fri Aug 3 00:01:44 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7A8021E8040 for ; Fri, 3 Aug 2012 00:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.273 X-Spam-Level: X-Spam-Status: No, score=-0.273 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2N5Xqa8rg39 for ; Fri, 3 Aug 2012 00:01:43 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 3C39821E8039 for ; Fri, 3 Aug 2012 00:01:43 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta01.westchester.pa.mail.comcast.net with comcast id i71m1j0020QuhwU5171msC; Fri, 03 Aug 2012 07:01:46 +0000 Received: from dhcp-40e5.meeting.ietf.org ([IPv6:2001:df8:0:64:19d6:c06f:f140:d490]) by omta02.westchester.pa.mail.comcast.net with comcast id i71U1j00A3NDGqc3N71VHR; Fri, 03 Aug 2012 07:01:31 +0000 Message-ID: <501B7752.4090900@alum.mit.edu> Date: Fri, 03 Aug 2012 00:01:38 -0700 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: James Polk References: <50176CC9.80701@alum.mit.edu> <201208030138.q731cdMR026288@mtv-core-2.cisco.com> <501B32C1.7040905@alum.mit.edu> <201208030651.q736pOWo027248@mtv-core-2.cisco.com> In-Reply-To: <201208030651.q736pOWo027248@mtv-core-2.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: siprec@ietf.org Subject: Re: [siprec] "==" padding in Metadata URN UUID [wasFW: [Insipid] Session-ID construction choices] X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 07:01:45 -0000 On 8/2/12 11:51 PM, James Polk wrote: > At 09:09 PM 8/2/2012, Paul Kyzivat wrote: >> On 8/2/12 6:38 PM, James Polk wrote: >>> all the examples in the INSIPID drafts are in hex. There's been >>> discussions for weeks to use hex, and that's the proposal on the table >>> there, so I would suggest not making any decisions in SIPREC based on >>> INSIPID using base64 - because that's not a sure thing at all at this >>> point. >> >> We had a discussion of this in the siprec meeting today. There was >> violent objection from Joe Hildebrand and Hadriel not to do this > > Paul - which do you mean when you say "this"? They were opposed to using base64 with the "==" stripped. They were fine with using base64 with the "==" present. Thanks, Paul > IOW, were Joe and Hadriel violently against base64 or hex? > > Hadriel was in INSIPID when I mentioned the UUID is a RFC 4122 defined > 32 byte hex value, and he didn't leap out of his chair to jump my (you > know what), but I don't want to assume which way he agrees with or > disagrees with. > > James > >> because it would make it harder to use standard libraries to do the >> encode/decode. >> >> I'm not an XML guy, so I guess I'll defer to them on that part, though >> it seems trivial to me to append "==" before calling the decoder and >> strip the "==" after calling the encoder. But if the conversions are >> automatic based on the declared typing in the schema then I guess I >> can see why it might be harder than that. >> >> At the end of the day I don't really care. So I'll defer to someone >> who does. >> >> Thanks, >> Paul >> >>> James >>> >>> At 12:27 AM 7/31/2012, Paul Kyzivat wrote: >>>> I don't have strong feelings either way. Just understand that omitting >>>> the "==" locks us in to 64 bit values. That doesn't seem to be a big >>>> constraint, since the spec we're referencing for the value calls for >>>> 64 bits. >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 7/30/12 8:12 PM, Ram Mohan R (rmohanr) wrote: >>>>> I am Ok too. >>>>> >>>>> Ram >>>>> >>>>>> On 30/07/12 10:44 PM, "Leon Portman" wrote: >>>>> >>>>>> I am OK >>>>>> >>>>>> Leon >>>>>> On Jul 30, 2012, at 8:13 PM, "Ravindran, Parthasarathi" >>>>>> wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> Metadata uses based 64 encoding of URN UUID. There is a >>>>>>> discussion in >>>>>>> INSIPID WG to optimize "==" padding occurs due to base 64 URN >>>>>>> UUID. I >>>>>>> attached Paul's snip of the below mail thread. >>>>>>> >>>>>>> >>>>>>> If we go with base64, I agree that we don't need to preserve the >>>>>>> trailing "==". >>>>>>> >>>>>>> >>>>>>> I'm fine with the optimization as it reduces 2 bytes in each URN >>>>>>> UUID >>>>>>> of metadata XML element. I'm interested in hearing WG opinion about >>>>>>> this >>>>>>> optimization. >>>>>>> >>>>>>> Thanks >>>>>>> Partha >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: insipid-bounces@ietf.org [mailto:insipid-bounces@ietf.org] On >>>>>>> Behalf Of Paul Kyzivat >>>>>>> Sent: Thursday, July 26, 2012 8:30 PM >>>>>>> To: Paul E. Jones >>>>>>> Cc: 'James Polk'; insipid@ietf.org >>>>>>> Subject: Re: [Insipid] Session-ID construction choices >>>>>>> >>>>>>> On 7/24/12 10:51 PM, Paul E. Jones wrote: >>>>>>>> Paul, >>>>>>>> >>>>>>>> Following up on this thread, as I did not see an outcome. I think >>>>>>>> this message might be the last in the series on this topic. >>>>>>>> >>>>>>>> I think your proposal is along the lines of what we originally >>>>>>>> proposed. As I understand, there is a desire to always include >>>>>>>> both A >>>>>>>> and B's halves. >>>>>>>> That's fine, so long as devices understand they might change >>>>>>>> from one >>>>>>>> message to the next. >>>>>>>> >>>>>>>> So given these two abbreviated UUIDs: >>>>>>>> >>>>>>>> UUID 1: 0xaeffa652 >>>>>>>> UUID 2: 0xbe11afc8 >>>>>>>> >>>>>>>> We would have: >>>>>>>> >>>>>>>> Session-ID: 0xaeffa652be11afc8 >>>>>>>> >>>>>>>> If we agree to encode it in hex and agree on the size (a 16 octet >>>>>>>> UUID), that means this will always be a 64-byte hex string and >>>>>>>> there >>>>>>>> is no need to put a :. We could also base64 encode the 64 octet >>>>>>>> binary value, which would encode in 44 octets (shaving off 20 >>>>>>>> octets). >>>>>>>> >>>>>>>> Do we want to go for reduced size or more readable hex string? >>>>>>> >>>>>>> I don't have a strong feeling about hex vs. base64. >>>>>>> But I think it would be good to have a separator (I'm not >>>>>>> attached to >>>>>>> ":" - that is just an example.) I realize it isn't logically >>>>>>> necessary >>>>>>> as long as the halves are fixed length. But its not very friendly, >>>>>>> and I >>>>>>> think it is worth "wasting" *1* byte on. >>>>>>> >>>>>>> If we go with base64, I agree that we don't need to preserve the >>>>>>> trailing "==". >>>>>>> >>>>>>>> As for putting the entire Session-ID into messages, there are many >>>>>>>> situations where the Session-ID will be wrong. Let me give you just >>>>>>>> one example. >>>>>>>> >>>>>>>> Syntax: >>>>>>>> A == B means A is in a call with B >>>>>>>> >>>>>>>> A == B&& A == C (A in call with B; A has a separate call with C.) >>>>>>>> >>>>>>>> && B == D (B has a separate call with D) >>>>>>>> >>>>>>>> A& B are talking. A puts B on hold. >>>>>>>> A starts talking to C. >>>>>>>> Meanwhile B puts A on hold and talks to D. >>>>>>>> >>>>>>>> A performs some action to join B and C, while at the same time B >>>>>>>> performs some action to join D and C >>>>>>>> >>>>>>>> Assuming a PBX does this magic, we might have some INVITE messages >>>>>>>> going down the wire like this: >>>>>>>> >>>>>>>> + INVITE ----> C (so C can talk to B) (Session-ID: B || C) >>>>>>>> PBX1 ---| >>>>>>>> + INVITE ----> B (so B can talk to C) (Session-ID: B || C) >>>>>>>> >>>>>>>> And we have >>>>>>>> >>>>>>>> + INVITE ----> A (so A can talk to D) (Session-ID: A || D) >>>>>>>> PBX2 ---| >>>>>>>> + INVITE ----> D (so D can talk to A) (Session-ID: A || D) >>>>>>> >>>>>>> I can't fully follow the above. My problem is that I don't know >>>>>>> where >>>>>>> PBX1 and PBX2 fit into the topology of A,B,C,D. So I'm not going to >>>>>>> speculate much. >>>>>>> >>>>>>>> Now, these messages are passing on the wire at the same time. So >>>>>>>> that >>>>>>>> message from PBX1 heading toward B is actually now heading >>>>>>>> toward D. >>>>>>> >>>>>>> ??? >>>>>>> >>>>>>>> So, what D receives is Session-ID "B || C". D thought the >>>>>>>> Session-ID >>>>>>>> was A >>>>>>>> || D. It will be confused. Perhaps PBX2 can massage the Session-ID, >>>>>>>> || but >>>>>>>> it's not supposed to do that. We really don't want >>>>>>>> intermediaries to >>>>>>>> touch it. >>>>>>> >>>>>>> Can you please map out the full topology, and a lot more of the call >>>>>>> flow you have in mind. (Including REFERs, or some other >>>>>>> indication of >>>>>>> how the PBXs are being instructed what to do.) (There are a million >>>>>>> ways >>>>>>> this could be done.) >>>>>>> >>>>>>>> To avoid these kinds of race conditions, adding complexity to >>>>>>>> try to >>>>>>>> straighten it out, etc., I very much prefer to have only the >>>>>>>> Session-ID-UUID header that contains only the UUID of the sender of >>>>>>>> the message. If we did that, the endpoints in the above scenario >>>>>>>> would not be confused and the correct Session-ID could be noted in >>>>>>>> logs. >>>>>>> >>>>>>> I'm not ready to leap to this conclusion until I understand the >>>>>>> cases >>>>>>> better. >>>>>>> >>>>>>> Thanks, >>>>>>> Paul K >>>>>>> >>>>>>>> Paul >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: insipid-bounces@ietf.org >>>>>>>>> [mailto:insipid-bounces@ietf.org] On >>>>>>>>> Behalf Of Paul Kyzivat >>>>>>>>> Sent: Wednesday, July 11, 2012 7:38 PM >>>>>>>>> To: James Polk >>>>>>>>> Cc: insipid@ietf.org >>>>>>>>> Subject: Re: [Insipid] Session-ID construction choices >>>>>>>>> >>>>>>>>> On 7/11/12 6:23 PM, James Polk wrote: >>>>>>>>> ... >>>>>>>>>>>> Option#1 - attach a prefix (e.g., From: and To:) to each half >>>>>>>>> ... >>>>>>>>>>>> We have a proposal going forward: insert the From:/To: tags >>>>>>>>>>>> from >>>>>>>>>>>> Option #1. >>>>>>>>>>>> >>>>>>>>>>>> Does anyone have a technical reason why this wouldn't work? >>>>>>>>>>> >>>>>>>>>>> Do you mean to assign From and To once, and then keep it >>>>>>>>>>> fixed for >>>>>>>>>>> the duration of the dialog? ISTM that From and To are not well >>>>>>>>>>> defined in all cases. >>>>>>>>>>> >>>>>>>>>>> For instance, consider a BTBUA that sets up a session by >>>>>>>>>>> inviting >>>>>>>>>>> both endpoints. Which is From and which is To? IIUC, the reason >>>>>>>>>>> for >>>>>>>>>>> labeling this way is so that someone observing a session id in a >>>>>>>>>>> message can tell which half corresponds to which end. Using From >>>>>>>>>>> and To won't satisfy that unless those tags are reassigned for >>>>>>>>>>> each >>>>>>>>> request. >>>>>>>>>>> (This is a special case of a conference focus, which you already >>>>>>>>>>> call out as an exception.) >>>>>>>>>> >>>>>>>>>> The desire is to have the same half in the same position >>>>>>>>>> throughout >>>>>>>>>> the transaction or dialog (whichever it is). I believe in the >>>>>>>>>> case >>>>>>>>>> of a B2BUA initiating or originating the transaction or dialog on >>>>>>>>>> behalf of other endpoint UAs, the B2BUA would pick which >>>>>>>>>> Session-ID >>>>>>>>>> is the From and which is the To. IOW - we don't make it a >>>>>>>>>> requirement on an implementation that Alice is always >>>>>>>>>> inserting her >>>>>>>>>> half in first, and Bob in as the second half. If the B2BUA is >>>>>>>>>> sending an INVITE to both Alice and Bob, then that's 2 separate >>>>>>>>>> Session-IDs because it's two different dialogs, even if a 3rd >>>>>>>>>> party >>>>>>>>>> isn't part (i.e., listening) of the media flow. This would be >>>>>>>>>> a hub >>>>>>>>>> and 2 spokes in which the hub doesn't listen or interact with the >>>>>>>>>> media of the 2 UAs. >>>>>>>>>> >>>>>>>>>> We could also have text that says for this scenario, that an >>>>>>>>>> INVITE >>>>>>>>>> normally inserts the From half of the Session-ID, but that in >>>>>>>>>> this >>>>>>>>>> scenario it can insert the To: half and the invitee inserts >>>>>>>>>> the To >>>>>>>>>> half. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Identifying which end is which is easy for any single >>>>>>>>>>> transaction, >>>>>>>>>> >>>>>>>>>> agreed >>>>>>>>>> >>>>>>>>>>> but hard if you want to use the same identifiers in every >>>>>>>>>>> message. >>>>>>>>>>> The endpoints can easily figure this out, because they should >>>>>>>>>>> know >>>>>>>>>>> their half, and the half that isn't theirs is the other >>>>>>>>>>> end's. But >>>>>>>>>>> its not simple for middleboxes. >>>>>>>>>> >>>>>>>>>> remember that each half is a UUID or GUID, which will always be a >>>>>>>>>> unique value through space and time. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> The solution that is used for dialog ids is to use To and From, >>>>>>>>>>> but >>>>>>>>>>> they must be reassigned depending on the direction of the >>>>>>>>>>> message. >>>>>>>>>>> We could do the same for session id, but only if they are >>>>>>>>>>> remapped >>>>>>>>>>> based on the direction of the request. >>>>>>>>>> >>>>>>>>>> I guess I'm no getting why the halves need to switch places yet >>>>>>>>>> depending on whether it's in a request or response. Or are you >>>>>>>>>> saying that for one complete transaction they are in a certain >>>>>>>>>> order, but in a related transaction(s) they are possibly in the >>>>>>>>>> reverse order - depending on who sent the message? >>>>>>>>> >>>>>>>>> When a message is sent in the reverse direction from the dialog >>>>>>>>> establishing message, the From URI and To URI are reversed, as >>>>>>>>> well >>>>>>>>> as the From and To tags. If the session id still has its halves >>>>>>>>> tagged consistent with the from and to of the dialog establishing >>>>>>>>> request, then you will get confused about which half goes with >>>>>>>>> which >>>>>>>>> end. >>>>>>>>> >>>>>>>>> There is no problem for servers that keep state and remember the >>>>>>>>> values for each end. For them we don't need to tag the halves at >>>>>>>>> all. >>>>>>>>> >>>>>>>>> There is also no problem for those who don't *care* which end is >>>>>>>>> which. >>>>>>>>> And there may be a lot of those. >>>>>>>>> >>>>>>>>> This tagging is only there for those who don't keep state yet >>>>>>>>> need to >>>>>>>>> know. Maybe there aren't any of those, in which case we can stop >>>>>>>>> worrying about it. >>>>>>>>> >>>>>>>>> I guess an example that might matter is something analyzing logs, >>>>>>>>> and >>>>>>>>> doesn't have a complete set of logs available to it - in >>>>>>>>> particular >>>>>>>>> it doesn't have a log of the initial signaling that set up the >>>>>>>>> session, so it can't figure out which half-id belongs to which >>>>>>>>> end. >>>>>>>>> >>>>>>>>> Then it sees a change - it sees a message where half of the id >>>>>>>>> matches prior things, but the other half doesn't - is new. From >>>>>>>>> this >>>>>>>>> it can perhaps infer that there was a transfer. And in that >>>>>>>>> case it >>>>>>>>> will want to know which end remains and which was replaced. But it >>>>>>>>> can't figure that out from which half of the id changed without >>>>>>>>> knowing the mapping from half to end. >>>>>>>>> >>>>>>>>> But I will be the first to say that this case is somewhat >>>>>>>>> implausible. >>>>>>>>> In practice there will be lots of stuff in the messages being >>>>>>>>> analyzed that should support figuring this out. Perhaps this just >>>>>>>>> isn't a good example, and there is another that is better. But I >>>>>>>>> don't know a better one. Anybody else? (I think Paul J was the one >>>>>>>>> who raised this concern, so maybe he has an example.) >>>>>>>>> >>>>>>>>> If we can't find a plausible reason why we need to do this >>>>>>>>> mapping, >>>>>>>>> then I propose that we just not bother. In that case I think >>>>>>>>> representation >>>>>>>>> #3 is attractive. It provides for the easiest comparison >>>>>>>>> between id >>>>>>>>> values >>>>>>>>> - a single string comparison is sufficient. And its among the most >>>>>>>>> compact representations. I'd recommend: >>>>>>>>> >>>>>>>>> session-id: SmallestHalf:BiggestHalf >>>>>>>>> >>>>>>>>> Or just >>>>>>>>> >>>>>>>>> session-id: FirstHalf >>>>>>>>> >>>>>>>>> before the half for the far end has been assigned. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Paul >>>>>>>>> _______________________________________________ >>>>>>>>> insipid mailing list >>>>>>>>> insipid@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/insipid >>>>>>> >>>>>>> _______________________________________________ >>>>>>> insipid mailing list >>>>>>> insipid@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/insipid >>>>>>> _______________________________________________ >>>>>>> siprec mailing list >>>>>>> siprec@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>>> >>>>>> _______________________________________________ >>>>>> siprec mailing list >>>>>> siprec@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/siprec >>>>> >>>>> >>>>> _______________________________________________ >>>>> siprec mailing list >>>>> siprec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/siprec >>>> >>>> _______________________________________________ >>>> siprec mailing list >>>> siprec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/siprec >>> >>> _______________________________________________ >>> siprec mailing list >>> siprec@ietf.org >>> https://www.ietf.org/mailman/listinfo/siprec >> >> _______________________________________________ >> siprec mailing list >> siprec@ietf.org >> https://www.ietf.org/mailman/listinfo/siprec > > From pkyzivat@alum.mit.edu Fri Aug 3 20:40:09 2012 Return-Path: X-Original-To: siprec@ietfa.amsl.com Delivered-To: siprec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79D5311E8091 for ; Fri, 3 Aug 2012 20:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.284 X-Spam-Level: X-Spam-Status: No, score=-0.284 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbRd0jCBn5o5 for ; Fri, 3 Aug 2012 20:40:08 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 90AC411E8072 for ; Fri, 3 Aug 2012 20:40:06 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta02.westchester.pa.mail.comcast.net with comcast id iTcf1j0040EZKEL51Tg9dw; Sat, 04 Aug 2012 03:40:09 +0000 Received: from dhcp-40e5.meeting.ietf.org ([IPv6:2001:df8:0:64:8d66:c310:2c90:f92]) by omta01.westchester.pa.mail.comcast.net with comcast id iTgH1j00c5JjU8M3MTgJYY; Sat, 04 Aug 2012 03:40:18 +0000 Message-ID: <501C9994.8020207@alum.mit.edu> Date: Fri, 03 Aug 2012 20:40:04 -0700 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Ravindran, Parthasarathi" References: <059AF07365DC474393A19A3AF187DF740806753E@NAHALD.us.int.genesyslab.com> <5018C5D5.4090207@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C2BD148A5@inba-mail02.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C2BD148A5@inba-mail02.sonusnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "siprec@ietf.org" Subject: Re: [siprec] comments on draft-ietf-siprec-metadata-07 X-BeenThere: siprec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Recording Working Group Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2012 03:40:09 -0000 On 8/2/12 4:51 PM, Ravindran, Parthasarathi wrote: > Hi all, > > As discussed today meeting, Paul mentioned below metadata model change is an alternative which clarifies the stream XML element usage within the specific single CS instead of spread across. I'm interested in hearing anybody has objection to this change. In followup to the presentation at the meeting, which probably wasn't very clear... (This will be longer than I'd like, but I don't know how to say it more concisely.) In metadata-07 we have the following model: Participant | 0..* 1..*| receives| |sends | 0..* 0..*| +-------------------------+ | Media Stream | | | Communication 1..* 0..* +-------------------------+ Session ------------| | | Media Stream Reference | | Content-type | | | +-------------------------+ Note that a Media Stream can associate with one or more Communication Sessions. One issue with this is that we had wanted to allow a media stream with zero sessions. That's an easy change. Normally there would be no need for a media stream to associate with more than one CS. We made the change to allow multiple to accommodate the Turret use case, where there is a desire to record a mix of streams from multiple CSs. What we ended up with for the XML of the Media Stream element in metadata-07 is called , has two attributes, identifying the stream itself as well as a Communication Session. If you never think about streams that associate with more than one one CS, this seems reasonable. You can then think of it as a stream element with one attribute identifying its key, and another non-key attribute identifying the CS its associated with. But if you attempt to do an example where a media stream associates with multiple CSs (see section 4.6 of draft-ram-siprec-callflows-01) it gets weird. Because we need to identify two CSs, and can only do one per , we need two instances of . But because they are supposed to be the same stream, they must have the same stream id. We can see that in 4.6: In the above, both have the same id=, and are distinguished by differing session= values. If had only one key attribute, then the 2nd of these would *replace* the first. For that not to happen, both the 'id' and 'session' attributes must be key attributes. The XML representing senders and receivers only identifies the 'id' of the stream, such as: UAAMm5GRQKSCMVvLyl4rFw== UAAMm5GRQKSCMVvLyl4rFw== This isn't consistent with the model. In the XML, regular elements have a single key attribute that identifies the element itself. Assoc elements have two key attributes that identify the keys of the two elements they associate. So our XML is more consistent with: +-------------------------+ | Media Stream | | | Communication 1..* 0..* +-------------------------+ Session ------------| | | | Media Stream Reference | | | Content-type | | | | | +-------------------------+ | | +-------------------------+ | | MediaStream_CS_Assoc | +-------| | +-------------------------+ But not quite, because we don't have two XML types. Rather we have one XML element called that has the two keys of the association class, but also carries the attributes of the Media Stream. But the and reference the single 'id' of Media Stream that isn't explicitly coded at all. This disturbs me. Its inconsistent with the way the rest of the model is represented. So the way I propose to fix this is to change the model a bit: Participant | 0..* 1..*| receives| |sends | 0..* 0..*| +-------------------------+ | Media Stream | | | Communication 0..1 0..* +-------------------------+ Session ------------| | | Media Stream Reference | | Content-type | | | +-------------------------+ In this model, a Media Stream can associate with at most one CS. No association class is needed. The association can be represented in XML as an optional attribute of . This appears not to support the turret case. I propose to address that simply by having multiple distinct instances of reference a common m-line by using the same